Thread overview | ||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
October 29, 2014 C++ developer choices in open source projects | ||||
---|---|---|---|---|
| ||||
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. |
October 29, 2014 Re: C++ developer choices in open source projects | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright Attachments: | 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
>
> It's my impression that D uses a lot more parametric polymorphism (i.e. 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.
|
October 29, 2014 Re: C++ developer choices in open source projects | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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
|
October 29, 2014 Re: C++ developer choices in open source projects | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
October 29, 2014 Re: C++ developer choices in open source projects | ||||
---|---|---|---|---|
| ||||
Posted in reply to ponce | 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
|
October 29, 2014 Re: C++ developer choices in open source projects | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright Attachments:
| On Tue, 2014-10-28 at 21:37 -0700, Walter Bright via Digitalmars-d 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 Don't forget the far superior SCons. And also Waf, Tup,… > 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 > > 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. 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. > > 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. 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? > > 7. STL widely used , not boost > > Phobos' ranges appear to be widely used. Boost is both great and a real problem… > 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. > 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++ ;-) > 10. New created projects use more the new C++ standards > > As they should. Indeed; any C++ project not using C++14 is wrong. ;-) -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 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 |
October 29, 2014 Re: C++ developer choices in open source projects | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto Attachments:
| 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. […] > 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. 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 — and the annoyance of checking error codes every other statement. 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. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 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 |
October 29, 2014 Re: C++ developer choices in open source projects | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto Attachments:
| 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. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net 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 |
October 29, 2014 Re: C++ developer choices in open source projects | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | 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/ |
October 29, 2014 Re: C++ developer choices in open source projects | ||||
---|---|---|---|---|
| ||||
Posted in reply to Russel Winder | 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 CERN and at a startup on a C#/C integration project done via Managed C++.
--
Paulo
|
Copyright © 1999-2021 by the D Language Foundation