www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++ developer choices in open source projects

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.codergears.com/Blog/?p=421

This is interesting as it relates to D's choices:

1. No common build system ,Visual Studio, make and  CMake are the most widely
used

D - no change.

2. Namesapces not widely used

D - forces use of namespaces, i.e. modules

3. Inheritance and polymorphism are widely used

It's my impression that D uses a lot more parametric polymorphism (i.e. 
templates) than virtual inheritance.

4. Design Patterns not widely used

Don't know if D changes that.

5. No common frameworks for the GUI, database access and logging needs.

Same for D, though std.experimental.logger may change that.

6. Smart pointers not enough used

The general problem with SP is you have to proactively use them, they are not 
the default. D's gc pointers are the default.

7. STL widely used , not boost

Phobos' ranges appear to be widely used.

8. Exceptions not widely used

Exceptions are embraced in D, perhaps even excessively :-)

9. For many projects two or more ways used to represent a string class

D's strings are built-in to the language, which is a huge win for consistency. 
Even modern C++ suffers from two distinct string types.

10. New created projects use more the new C++ standards

As they should.
Oct 28 2014
next sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 28 Oct 2014 21:37:45 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 3. Inheritance and polymorphism are widely used
=20
 It's my impression that D uses a lot more parametric polymorphism (i.e.=20
 templates) than virtual inheritance.


this is true at least for my case. i tend to write templates that
accepts entities that can do what i need instead of building class
hierarchies. my data reading primitives, for example, works with
any entity that has appropriate rawRead() method.

the only disadvantage is a size of a compiled binary, but i can live
with that. and if i want really small binary, i have to drop Phobos
anyway, and in this case i'd better use open()/read()/close() directly.

easy parametric polymorphism is one of those things that i absolutely
love in D.
Oct 28 2014
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 29 October 2014 at 04:37:47 UTC, Walter Bright 
wrote:

 http://www.codergears.com/Blog/?p=421

 This is interesting as it relates to D's choices:

 1. No common build system ,Visual Studio, make and  CMake are 
 the most widely used

 D - no change.

 2. Namesapces not widely used

 D - forces use of namespaces, i.e. modules

 3. Inheritance and polymorphism are widely used

 It's my impression that D uses a lot more parametric 
 polymorphism (i.e. templates) than virtual inheritance.

 4. Design Patterns not widely used

 Don't know if D changes that.

 5. No common frameworks for the GUI, database access and 
 logging needs.

 Same for D, though std.experimental.logger may change that.

 6. Smart pointers not enough used

 The general problem with SP is you have to proactively use 
 them, they are not the default. D's gc pointers are the default.

 7. STL widely used , not boost

 Phobos' ranges appear to be widely used.

 8. Exceptions not widely used

 Exceptions are embraced in D, perhaps even excessively :-)

 9. For many projects two or more ways used to represent a 
 string class

 D's strings are built-in to the language, which is a huge win 
 for consistency. Even modern C++ suffers from two distinct 
 string types.

 10. New created projects use more the new C++ standards

 As they should.


I do like C++, even with its warts, as my bookshelf can attest.

However, this is the sad reality of the language. In which what 
ANSI/ISO give us and what we are allowed to use are two different 
realities.

Almost everything from the standard that makes C++ modern, is 
frowned upon in most companies, leaving it little more than a 
safer C.

This was well shown at CppCon, with one corner showing what cool 
stuff C++11 and C++14 bring to the table, and the other corner 
showing laundry lists of forbidden features.

Personally, this is the reason I enjoy C++ in projects under my 
control and am an happy JVM/.NET camper at work. It just wouldn't 
be the language I enjoy.

Now with Java 9+ AOT compilation, .NET Native, Swift, Go, D, 
Rust, Objective-C coming into the picture, C++ will be driven 
further down the stack it seems, regardless of what the committee 
might say.

Which in the end might be good opportunity for D.

--
Paulo
Oct 29 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-10-29 at 07:53 +0000, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]

 Almost everything from the standard that makes C++ modern, is=20
 frowned upon in most companies, leaving it little more than a=20
 safer C.


Hopefully those companies then go to the wall. C++14 is the only C++ in
2014.

[=E2=80=A6]

 Now with Java 9+ AOT compilation, .NET Native, Swift, Go, D,=20
 Rust, Objective-C coming into the picture, C++ will be driven=20
 further down the stack it seems, regardless of what the committee=20
 might say.


C++ will remain the language of choice if Fortran is not used, for all
the big computational intensive activities. Objective-C and Object-C++
may well be effectively killed off by Swift, but that is an OSX iOS
issue that no-one else really cares about. Go and Rust are interesting.
Go is creating a large, and increasingly so, active community around a
language that has two interesting features that make it fun to programme
with =E2=80=94 and the annoyance of checking error codes every other statem=
ent.
Rust is currently too unstable to make any real judgements about except
that everyone outside Mozilla who is using it loves it. Rust's choice to
borrow heavily from OCaml is proving a wise move.


 Which in the end might be good opportunity for D.


It would be nice if this was to be the case. D needs a programme of
"new" things every 4 to 6 months for a short while, whilst being
fundamentally the same language (i.e. stable). As any marketer will tell
you, rebranding the same product every 6 months is de rigueur to achieve
increased market penetration.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 29 2014
next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 29 October 2014 at 14:58:39 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Wed, 2014-10-29 at 07:53 +0000, Paulo Pinto via 
 Digitalmars-d wrote:
 […]

 Almost everything from the standard that makes C++ modern, is 
 frowned upon in most companies, leaving it little more than a 
 safer C.


 Hopefully those companies then go to the wall. C++14 is the 
 only C++ in
 2014.


I have my doubts looking at the examples provided at CppCon from 
the likes of Sony, JPL, Google, Ubisoft and my own until 2005.

The only two workplaces I was allowed to use C++ properly was at 

Managed C++.

--
Paulo
Oct 29 2014
next sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-10-29 at 15:11 +0000, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]

 I have my doubts looking at the examples provided at CppCon from=20
 the likes of Sony, JPL, Google, Ubisoft and my own until 2005.


Sad.


 The only two workplaces I was allowed to use C++ properly was at=20

 Managed C++.


CERN remains at the centre of so much good software development. Which
is why they use Python.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 29 2014
parent reply "Atila Neves" <atila.neves gmail.com> writes:
 The only two workplaces I was allowed to use C++ properly was 

 via Managed C++.




Well, at CERN, "allowed" mostly because nearly everybody writes 
code for themselves only and people do whatever they want to do. 
Never mind that there's no common CERN-wise codebase that isn't 
called ROOT.


 CERN remains at the centre of so much good software 
 development. Which
 is why they use Python.


Wait, what? Good software development? At CERN?? Really??? As a 
friend of mine one put it:

"At CERN, 10% of people writing code know what they're doing, 45% 
don't know what they're doing but are aware of it, and 45% don't 
know what they're doing but think they do because software 
development is 'so much easier than Physics'".

I've seen recently (as in weeks ago) written Python code from 
ATLAS. It's so atrocious it doesn't even look like Python. Most 
people I know still working at CERN don't even know what C++11 
is, much less use it.

Atila
Oct 30 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 30.10.2014 um 16:52 schrieb Atila Neves:

 The only two workplaces I was allowed to use C++ properly was at CERN





 Well, at CERN, "allowed" mostly because nearly everybody writes code for
 themselves only and people do whatever they want to do. Never mind that
 there's no common CERN-wise codebase that isn't called ROOT.


Well my workgroup at DAQ Dataflow cared for C++ quality, but it was not 
the same everywhere.

That is why one of our projects was a C++ stress tester for parallel 
algorithms.

Still, the quality of the code there was way better that any C or C++ 
code that I have seen in the wild in the typical corporations, specially 
codebases that suffered the magic offshore wand.

--
Paulo
Oct 30 2014
prev sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Oct 30, 2014 at 03:52:51PM +0000, Atila Neves via Digitalmars-d
wrote: [...]

CERN remains at the centre of so much good software development.
Which is why they use Python.


 
 Wait, what? Good software development? At CERN?? Really??? As a friend
 of mine one put it:
 
 "At CERN, 10% of people writing code know what they're doing, 45%
 don't know what they're doing but are aware of it, and 45% don't know
 what they're doing but think they do because software development is
 'so much easier than Physics'".
 
 I've seen recently (as in weeks ago) written Python code from ATLAS.
 It's so atrocious it doesn't even look like Python. Most people I know
 still working at CERN don't even know what C++11 is, much less use it.


[...]

It's probably a good thing they don't know what C++11 is, otherwise they
might start writing even more horrendous code using operator""(). I
suppose I've been a frog in the well, but it was only yesterday when I
discovered that C++11 allows user-defined literals via operator""().
Skimming over the docs for that today, I couldn't help but shake my head
at just how wrong the whole conception of it is. It's just *asking* to
be abused for writing inscrutable, unreadable, unmaintainable code. I
honestly have trouble imagining any sane use case for it apart from
submitting obfuscated code contest entries. But hey, what's one more
nail in a coffin already crawling with monstrosities like
Boost.Xpressive?

D had it right by moving all these user-defined literals into strings
that are parsed at compile-time. Much more powerful than the crippled
stuff operator""() can accept, and far less dangerous and lightyears
more maintainable. Sighhh... D has ruined my life, I just can't go back
to C++ anymore...


T

-- 
Don't throw out the baby with the bathwater. Use your hands...
Oct 30 2014
next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 30.10.2014 um 21:04 schrieb H. S. Teoh via Digitalmars-d:

 On Thu, Oct 30, 2014 at 03:52:51PM +0000, Atila Neves via Digitalmars-d
 wrote: [...]

 CERN remains at the centre of so much good software development.
 Which is why they use Python.


 Wait, what? Good software development? At CERN?? Really??? As a friend
 of mine one put it:

 "At CERN, 10% of people writing code know what they're doing, 45%
 don't know what they're doing but are aware of it, and 45% don't know
 what they're doing but think they do because software development is
 'so much easier than Physics'".

 I've seen recently (as in weeks ago) written Python code from ATLAS.
 It's so atrocious it doesn't even look like Python. Most people I know
 still working at CERN don't even know what C++11 is, much less use it.


 [...]

 It's probably a good thing they don't know what C++11 is, otherwise they
 might start writing even more horrendous code using operator""(). I
 suppose I've been a frog in the well, but it was only yesterday when I
 discovered that C++11 allows user-defined literals via operator""().
 Skimming over the docs for that today, I couldn't help but shake my head
 at just how wrong the whole conception of it is. It's just *asking* to
 be abused for writing inscrutable, unreadable, unmaintainable code. I
 honestly have trouble imagining any sane use case for it apart from
 submitting obfuscated code contest entries. But hey, what's one more
 nail in a coffin already crawling with monstrosities like
 Boost.Xpressive?


That was extended in C++14, for example:

#include <string>

int main()
{
     using namespace std::string_literals;

     auto s1 = "Hello\0\0World"s;
}

// s1 == std::string

There a few other pre-defined literals.
Oct 30 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/30/2014 1:04 PM, H. S. Teoh via Digitalmars-d wrote:

 D has ruined my life, I just can't go back to C++ anymore...


Ehhhxcellleeeennnntt!


http://www.gocurrycracker.com/wp-content/uploads/2014/07/cm-23138-050624abe3a9e6.jpeg
Oct 30 2014
prev sibling next sibling parent "Araq" <rumpf_a web.de> writes:
 It's probably a good thing they don't know what C++11 is, 
 otherwise they
 might start writing even more horrendous code using 
 operator""(). I
 suppose I've been a frog in the well, but it was only yesterday 
 when I
 discovered that C++11 allows user-defined literals via 
 operator""().
 Skimming over the docs for that today, I couldn't help but 
 shake my head
 at just how wrong the whole conception of it is. It's just 
 *asking* to
 be abused for writing inscrutable, unreadable, unmaintainable 
 code. I
 honestly have trouble imagining any sane use case for it apart 
 from
 submitting obfuscated code contest entries. But hey, what's one 
 more
 nail in a coffin already crawling with monstrosities like
 Boost.Xpressive?


Yeah, who cares about language extensibility or useful features. 
These all beg to be abused. Let's all use Go instead.
Oct 31 2014
prev sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Thursday, 30 October 2014 at 20:06:30 UTC, H. S. Teoh via 
Digitalmars-d wrote:

 D had it right by moving all these user-defined literals into 
 strings
 that are parsed at compile-time. Much more powerful than the 
 crippled
 stuff operator""() can accept, and far less dangerous and 
 lightyears
 more maintainable.


I believe there are examples of system software going wrong 
because one library used SI units and another one did not. So 
being able to typecast doubles into something more restricted is 
useful:

3.0_miles vs 3.0_km

Sure you could have done it this way instead:

miles(3.0) vs km(3.0)

But people don't, so providing literals is a good addition for 
C++.

(And no, string processing at compile time is not a good idea! It 
suffers from the same problems as macros.)
Oct 31 2014
parent "ROOAR" <youwants yahoo.com> writes:
 3.0_miles vs 3.0_km

 Sure you could have done it this way instead:

 miles(3.0) vs km(3.0)

 But people don't, so providing literals is a good addition for 
 C++.

 (And no, string processing at compile time is not a good idea! 
 It suffers from the same problems as macros.)


  UDL is a nice feature yah
Oct 31 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 29 Oct 2014 16:02:28 +0000
Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 good software development
 Python


nice joke.
Oct 29 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Wednesday, 29 October 2014 at 14:58:39 UTC, Russel Winder via 
Digitalmars-d wrote:

 Hopefully those companies then go to the wall. C++14 is the 
 only C++ in 2014.


Our current target platform is almost a decade old, so if current 
trends continue, C++14 will be the only C++ in 2024.

In all honesty, we're close to pushing through the use of a newer 
compiler, so C++14 will become a reality fairly soon, but I think 
most large companies are in the position where legacy code or 
legacy systems have them working a decade or more behind current. 
  Most C++ programmers I meet today still aren't comfortable with 
templates and the STL, if they understand/use them at all, and 
that stuff has been around for 20 years.
Oct 29 2014
next sibling parent "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 29 October 2014 at 16:15:12 UTC, Sean Kelly wrote:
…

 I think most large companies are in the position where legacy 
 code or legacy systems have them working a decade or more 
 behind current.


I think this presentation on why things go into the Google C++ 
styleguide was quite interesting for getting a overview of large 
scale issues:

http://www.youtube.com/watch?v=NOCElcMcFik
Oct 29 2014
prev sibling parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 29 Oct 2014 16:15:11 +0000
Sean Kelly via Digitalmars-d <digitalmars-d puremagic.com> wrote:


   Most C++ programmers I meet today still aren't comfortable with=20
 templates and the STL, if they understand/use them at all, and=20
 that stuff has been around for 20 years.


i'm doing programming for living for almost two decades. i did alot of
C and C++ developement. and i still can't properly understand and use
C++ templates. they sux. it worth nothing that i have some expirience
in FP and concept of generics and metaprogramming is nothing new for
me. and i catched D templates almost without troubles.
Oct 29 2014
prev sibling next sibling parent reply "ponce" <contact gam3sfrommars.fr> writes:
On Wednesday, 29 October 2014 at 04:37:47 UTC, Walter Bright 
wrote:

 http://www.codergears.com/Blog/?p=421

 This is interesting as it relates to D's choices:

 1. No common build system ,Visual Studio, make and  CMake are 
 the most widely used

 D - no change.

 2. Namesapces not widely used

 D - forces use of namespaces, i.e. modules

 3. Inheritance and polymorphism are widely used

 It's my impression that D uses a lot more parametric 
 polymorphism (i.e. templates) than virtual inheritance.

 4. Design Patterns not widely used

 Don't know if D changes that.

 5. No common frameworks for the GUI, database access and 
 logging needs.

 Same for D, though std.experimental.logger may change that.

 6. Smart pointers not enough used

 The general problem with SP is you have to proactively use 
 them, they are not the default. D's gc pointers are the default.

 7. STL widely used , not boost

 Phobos' ranges appear to be widely used.

 8. Exceptions not widely used

 Exceptions are embraced in D, perhaps even excessively :-)

 9. For many projects two or more ways used to represent a 
 string class

 D's strings are built-in to the language, which is a huge win 
 for consistency. Even modern C++ suffers from two distinct 
 string types.

 10. New created projects use more the new C++ standards

 As they should.


The sad reality of C++ programming is that you can't use most 
things, and people might resist basic stuff like exceptions and 
smart pointers on unfamiliarity alone. Some small things like the 
lack of std.path in the STL cause inordinate amount of damage.
Oct 29 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Wednesday, 29 October 2014 at 08:55:39 UTC, ponce wrote:

 On Wednesday, 29 October 2014 at 04:37:47 UTC, Walter Bright 
 wrote:

 http://www.codergears.com/Blog/?p=421

 This is interesting as it relates to D's choices:

 1. No common build system ,Visual Studio, make and  CMake are 
 the most widely used

 D - no change.

 2. Namesapces not widely used

 D - forces use of namespaces, i.e. modules

 3. Inheritance and polymorphism are widely used

 It's my impression that D uses a lot more parametric 
 polymorphism (i.e. templates) than virtual inheritance.

 4. Design Patterns not widely used

 Don't know if D changes that.

 5. No common frameworks for the GUI, database access and 
 logging needs.

 Same for D, though std.experimental.logger may change that.

 6. Smart pointers not enough used

 The general problem with SP is you have to proactively use 
 them, they are not the default. D's gc pointers are the 
 default.

 7. STL widely used , not boost

 Phobos' ranges appear to be widely used.

 8. Exceptions not widely used

 Exceptions are embraced in D, perhaps even excessively :-)

 9. For many projects two or more ways used to represent a 
 string class

 D's strings are built-in to the language, which is a huge win 
 for consistency. Even modern C++ suffers from two distinct 
 string types.

 10. New created projects use more the new C++ standards

 As they should.


 The sad reality of C++ programming is that you can't use most 
 things, and people might resist basic stuff like exceptions and 
 smart pointers on unfamiliarity alone. Some small things like 
 the lack of std.path in the STL cause inordinate amount of 
 damage.


On Ubisoft's presentation at CppCon, Nicolas Fleury even mentions 
that they have written tools to generate code, instead of relying 
on templates due to error messages and compilation time.

--
Paulo
Oct 29 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-10-29 at 11:05 +0000, Paulo Pinto via Digitalmars-d wrote:
[=E2=80=A6]

=20
 On Ubisoft's presentation at CppCon, Nicolas Fleury even mentions=20
 that they have written tools to generate code, instead of relying=20
 on templates due to error messages and compilation time.


Now there is the thing that has the possibility to kill off C++, the
error message the template system leads to.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 29 2014
parent reply "eles" <eles eles.com> writes:
On Wednesday, 29 October 2014 at 14:59:54 UTC, Russel Winder via 
Digitalmars-d wrote:

 On Wed, 2014-10-29 at 11:05 +0000, Paulo Pinto via 
 Digitalmars-d wrote:
 […]

 
 On Ubisoft's presentation at CppCon, Nicolas Fleury even 
 mentions that they have written tools to generate code, 
 instead of relying on templates due to error messages and 
 compilation time.


 Now there is the thing that has the possibility to kill off 
 C++, the
 error message the template system leads to.


http://concepts.axiomatics.org/~ans/
Oct 29 2014
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2014-10-29 at 15:09 +0000, eles via Digitalmars-d wrote:
[=E2=80=A6]

=20
 http://concepts.axiomatics.org/~ans/


Andrew's work on Concepts Lite may prove to be the saving of C++
templates=E2=80=A6

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 29 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 29.10.2014 um 17:05 schrieb Russel Winder via Digitalmars-d:

 On Wed, 2014-10-29 at 15:09 +0000, eles via Digitalmars-d wrote:
 […]

 http://concepts.axiomatics.org/~ans/


 Andrew's work on Concepts Lite may prove to be the saving of C++
 templates…


For those willing to wait until circa 2020. :(
Oct 29 2014
parent reply "eles" <eles215 gzk.dot> writes:
On Wednesday, 29 October 2014 at 22:03:52 UTC, Paulo Pinto wrote:

 Am 29.10.2014 um 17:05 schrieb Russel Winder via Digitalmars-d:

 On Wed, 2014-10-29 at 15:09 +0000, eles via Digitalmars-d 
 wrote:
 […]

 http://concepts.axiomatics.org/~ans/


 Andrew's work on Concepts Lite may prove to be the saving of 
 C++
 templates…


 For those willing to wait until circa 2020. :(


C'mon, the TR's are promised far sooner.
Oct 29 2014
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 29.10.2014 um 23:27 schrieb eles:

 On Wednesday, 29 October 2014 at 22:03:52 UTC, Paulo Pinto wrote:

 Am 29.10.2014 um 17:05 schrieb Russel Winder via Digitalmars-d:

 On Wed, 2014-10-29 at 15:09 +0000, eles via Digitalmars-d wrote:
 […]

 http://concepts.axiomatics.org/~ans/


 Andrew's work on Concepts Lite may prove to be the saving of C++
 templates…


 For those willing to wait until circa 2020. :(


 C'mon, the TR's are promised far sooner.


Ubisoft presentation at CppCon and also the reality I knew as C++ dev: 
"Our standard is what all target compilers support".


--
Paulo
Oct 29 2014
parent reply "rst256" <ussr.24 yandex.ru> writes:
On Wednesday, 29 October 2014 at 22:40:33 UTC, Paulo Pinto wrote:

 Am 29.10.2014 um 23:27 schrieb eles:

 On Wednesday, 29 October 2014 at 22:03:52 UTC, Paulo Pinto 
 wrote:

 Am 29.10.2014 um 17:05 schrieb Russel Winder via 
 Digitalmars-d:

 On Wed, 2014-10-29 at 15:09 +0000, eles via Digitalmars-d 
 wrote:
 […]

 http://concepts.axiomatics.org/~ans/


 Andrew's work on Concepts Lite may prove to be the saving of 
 C++
 templates…


 For those willing to wait until circa 2020. :(


 C'mon, the TR's are promised far sooner.


 Ubisoft presentation at CppCon and also the reality I knew as 
 C++ dev: "Our standard is what all target compilers support".


 --
 Paulo


Hi Paulo.

Amazingly, but i understand your feelings.
Maybe I can help you, that compiler do you need?
Seem you mentioned the Managed C++ ()?
Oct 29 2014
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 30 October 2014 at 04:51:33 UTC, rst256 wrote:

 On Wednesday, 29 October 2014 at 22:40:33 UTC, Paulo Pinto 
 wrote:

 Am 29.10.2014 um 23:27 schrieb eles:

 On Wednesday, 29 October 2014 at 22:03:52 UTC, Paulo Pinto 
 wrote:

 Am 29.10.2014 um 17:05 schrieb Russel Winder via 
 Digitalmars-d:

 On Wed, 2014-10-29 at 15:09 +0000, eles via Digitalmars-d 
 wrote:
 […]

 http://concepts.axiomatics.org/~ans/


 Andrew's work on Concepts Lite may prove to be the saving 
 of C++
 templates…


 For those willing to wait until circa 2020. :(


 C'mon, the TR's are promised far sooner.


 Ubisoft presentation at CppCon and also the reality I knew as 
 C++ dev: "Our standard is what all target compilers support".


 --
 Paulo


 Hi Paulo.

 Amazingly, but i understand your feelings.
 Maybe I can help you, that compiler do you need?
 Seem you mentioned the Managed C++ ()?


I don't get from where you got the point I am looking for
compilers.
Oct 30 2014
parent "rst256" <ussr.24 yandex.ru> writes:
On Thursday, 30 October 2014 at 08:03:30 UTC, Paulo  Pinto wrote:

 On Thursday, 30 October 2014 at 04:51:33 UTC, rst256 wrote:

 On Wednesday, 29 October 2014 at 22:40:33 UTC, Paulo Pinto 
 wrote:

 Am 29.10.2014 um 23:27 schrieb eles:

 On Wednesday, 29 October 2014 at 22:03:52 UTC, Paulo Pinto 
 wrote:

 Am 29.10.2014 um 17:05 schrieb Russel Winder via 
 Digitalmars-d:

 On Wed, 2014-10-29 at 15:09 +0000, eles via Digitalmars-d 
 wrote:
 […]

 http://concepts.axiomatics.org/~ans/


 Andrew's work on Concepts Lite may prove to be the saving 
 of C++
 templates…


 For those willing to wait until circa 2020. :(


 C'mon, the TR's are promised far sooner.


 Ubisoft presentation at CppCon and also the reality I knew as 
 C++ dev: "Our standard is what all target compilers support".


 --
 Paulo


 Hi Paulo.

 Amazingly, but i understand your feelings.
 Maybe I can help you, that compiler do you need?
 Seem you mentioned the Managed C++ ()?


 I don't get from where you got the point I am looking for
 compilers.


sent to you by mistake. I'm sorry
Oct 30 2014
prev sibling parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2014-10-28 at 21:37 -0700, Walter Bright via Digitalmars-d
wrote:

 http://www.codergears.com/Blog/?p=3D421
=20
 This is interesting as it relates to D's choices:
=20
 1. No common build system ,Visual Studio, make and  CMake are the most wi=


dely used

Don't forget the far superior SCons. And also Waf, Tup,=E2=80=A6


 D - no change.


Apart from Dub?


 2. Namesapces not widely used


Really? Maybe I habg out with better than average C++ programmers ;-)


 D - forces use of namespaces, i.e. modules
=20
 3. Inheritance and polymorphism are widely used
=20
 It's my impression that D uses a lot more parametric polymorphism (i.e.=


=20

 templates) than virtual inheritance.
=20
 4. Design Patterns not widely used
=20
 Don't know if D changes that.


Most programmers still only know of GoF patterns if they know of any,
and they are now 21 years old and nothing like as useful/relevant as
they we 20 years ago.


 5. No common frameworks for the GUI, database access and logging needs.
=20
 Same for D, though std.experimental.logger may change that.
=20
 6. Smart pointers not enough used
=20
 The general problem with SP is you have to proactively use them, they are=


 not=20

 the default. D's gc pointers are the default.


unique_ptr and shared_ptr are now standard and widely used with RAII so
as to ensure all heap use is properly managed. Or maybe the C++
programmers I know are not representative?

=20
 7. STL widely used , not boost
=20
 Phobos' ranges appear to be widely used.


Boost is both great and a real problem=E2=80=A6


 8. Exceptions not widely used
=20
 Exceptions are embraced in D, perhaps even excessively :-)


To be fair, exceptions in C++ have termination semantics and so should
be very rarely used. Your comment implies D exceptions are more like
Java exceptions, for handling errors.
=20

 9. For many projects two or more ways used to represent a string class
=20
 D's strings are built-in to the language, which is a huge win for consist=


ency.=20

 Even modern C++ suffers from two distinct string types.


And there was me thinking std::string was standard in C++ ;-)


 10. New created projects use more the new C++ standards
=20
 As they should.


Indeed; any C++ project not using C++14 is wrong. ;-)

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Oct 29 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2014 7:49 AM, Russel Winder via Digitalmars-d wrote:

 On Tue, 2014-10-28 at 21:37 -0700, Walter Bright via Digitalmars-d
 wrote:

 2. Namesapces not widely used


 Really? Maybe I habg out with better than average C++ programmers ;-)


I wouldn't be in the least surprised if there was a fair amount of selection 
bias in who you choose to hang out with!

Note that dmd itself doesn't use namespaces (hangs head in shame). I guess I'm 
not good enough to hang out with you :-(



 8. Exceptions not widely used

 Exceptions are embraced in D, perhaps even excessively :-)


 To be fair, exceptions in C++ have termination semantics and so should
 be very rarely used. Your comment implies D exceptions are more like
 Java exceptions, for handling errors.


I don't see anything that prevents C++ exceptions to be used for handling 
recoverable errors.


 9. For many projects two or more ways used to represent a string class

 D's strings are built-in to the language, which is a huge win for consistency.
 Even modern C++ suffers from two distinct string types.


 And there was me thinking std::string was standard in C++ ;-)


"hello" is not an std::string. There are also quite a few leftover string 
classes in C++ from the olden daze, and people still cannot resist the urge to 
roll their own.
Oct 29 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 29 October 2014 at 19:10:48 UTC, Walter Bright 
wrote:

 "hello" is not an std::string. There are also quite a few 
 leftover string classes in C++ from the olden daze, and people 
 still cannot resist the urge to roll their own.


You can use "hello"s to get std::string in recent editions. 
There's a lot of type deduction going on so if one parameter is 
std::string the c string literals will be handled too: e.g: 
"hello"+"world"s should yield std::string. (At least in theory)
Oct 29 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2014 12:34 PM, "Ola Fosheim Grøstad" 
<ola.fosheim.grostad+dlang gmail.com>" wrote:

 On Wednesday, 29 October 2014 at 19:10:48 UTC, Walter Bright wrote:

 "hello" is not an std::string. There are also quite a few leftover string
 classes in C++ from the olden daze, and people still cannot resist the urge to
 roll their own.


 You can use "hello"s to get std::string in recent editions. There's a lot of
 type deduction going on so if one parameter is std::string the c string
literals
 will be handled too: e.g: "hello"+"world"s should yield std::string. (At least
 in theory)


There are still two string types, something you can't quite escape dealing with.
Oct 29 2014
parent reply ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 29 Oct 2014 13:07:38 -0700
Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 There are still two string types, something you can't quite escape dealin=


g with.
and D has three string types. it's even better than C++!
Oct 29 2014
next sibling parent reply "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= writes:
On Wednesday, 29 October 2014 at 20:13:34 UTC, ketmar via 
Digitalmars-d wrote:

 On Wed, 29 Oct 2014 13:07:38 -0700
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> 
 wrote:


 There are still two string types, something you can't quite 
 escape dealing with.


 and D has three string types. it's even better than C++!


Only three? C++ has seven:

1. const char*  /* zero terminated single byte*/
2. const char*  /* zero terminated multi byte */
3. const wchar_t*  /* zero terminated wide */
4. std::string	
5. std::wstring
6. std::u16string
7. std::u32string
Oct 29 2014
parent ketmar via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 29 Oct 2014 20:29:33 +0000
via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 On Wednesday, 29 October 2014 at 20:13:34 UTC, ketmar via=20
 Digitalmars-d wrote:

 On Wed, 29 Oct 2014 13:07:38 -0700
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com>=20
 wrote:


 There are still two string types, something you can't quite=20
 escape dealing with.


 and D has three string types. it's even better than C++!


=20
 Only three? C++ has seven:
=20
 1. const char*  /* zero terminated single byte*/
 2. const char*  /* zero terminated multi byte */
 3. const wchar_t*  /* zero terminated wide */
 4. std::string=09
 5. std::wstring
 6. std::u16string
 7. std::u32string


ah, D has those 'char*' family too, but i don't count them as string
types. ok, C++ wins. again. ;-)
Oct 29 2014
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/29/2014 1:13 PM, ketmar via Digitalmars-d wrote:

 On Wed, 29 Oct 2014 13:07:38 -0700
 Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:


 There are still two string types, something you can't quite escape dealing
with.


 and D has three string types. it's even better than C++!


That's a different issue. (I didn't point out C++'s "L" string literals.)
Oct 29 2014
prev sibling parent "eles" <eles215 gzk.dot> writes:
On Wednesday, 29 October 2014 at 19:10:48 UTC, Walter Bright 
wrote:

 On 10/29/2014 7:49 AM, Russel Winder via Digitalmars-d wrote:

 On Tue, 2014-10-28 at 21:37 -0700, Walter Bright via 
 Digitalmars-d
 wrote:





 "hello" is not an std::string. There are also quite a few


Proof:

C++

int main(int argc, char **argv) {

}

D

int main(string[] args) {

}
Oct 29 2014