As some of you know, the C User Group UK and the European C and C++ User Group long ago merged to create the Association of C and C++ Users (ACCU). Over the years, the emphasis on C and C++ gave way to a more diverse approach including patterns, Java, Python, Go, agile processes. Even the name of the group formally changed to ACCU to lose the direct C and C++ link. Due to the history, members of the group had and retain roles with the British Standards Institute, as the UK representatives on the C and C++ standards committees, especially the C++ one. When it is the UK's turn to host a C++ standards committee meeting, the meeting is either before or after the ACCU conference, and the obvious suspects get drafted in to do keynotes and other talks at the conference, as well as ACCU members attending the open meetings of JTC1/SC22/WG21. http://accu.org/index.php/conferences/accu_conference_2013

This seems like an ideal opportunity to do a lightning talk (5 mins) on why C++ is crap and D is the only native code language that should be used. (I have a history in this group of bashing C++ :-) It would be really helpful to create a few one liners (with code examples) as to why D is the clear language of choice for native code working and, C++, Go, Rust, Clay, etc. should be consigned to the dustbin of history. People will expect me to emphasize concurrency and parallelism issues so it would be good to throw others into the mix as well.

Thanks in advance for any input. Attribution of sources if appropriate will be given unless people prefer anonymity!

-- 
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

On Sunday, 20 January 2013 at 09:15:36 UTC, Russel Winder wrote:
> Thanks in advance for any input. Attribution of sources if appropriate
> will be given unless people prefer anonymity!

static if vs enable_if is always very convincing. OK, bashing template in C++ is easy, but showing that it can be easy is usually worthwhile.

scope statement replacing bunch of try/catch is also very demonstrative.

Am 20.01.2013 10:15, schrieb Russel Winder:
> As some of you know, the C User Group UK and the European C and C++ User
> Group long ago merged to create the Association of C and C++ Users
> (ACCU). Over the years, the emphasis on C and C++ gave way to a more
> diverse approach including patterns, Java, Python, Go, agile processes.
> Even the name of the group formally changed to ACCU to lose the direct C
> and C++ link. Due to the history, members of the group had and retain
> roles with the British Standards Institute, as the UK representatives on
> the C and C++ standards committees, especially the C++ one. When it is
> the UK's turn to host a C++ standards committee meeting, the meeting is
> either before or after the ACCU conference, and the obvious suspects get
> drafted in to do keynotes and other talks at the conference, as well as
> ACCU members attending the open meetings of JTC1/SC22/WG21.
> http://accu.org/index.php/conferences/accu_conference_2013
>
> This seems like an ideal opportunity to do a lightning talk (5 mins) on
> why C++ is crap and D is the only native code language that should be
> used. (I have a history in this group of bashing C++ :-) It would be
> really helpful to create a few one liners (with code examples) as to why
> D is the clear language of choice for native code working and, C++, Go,
> Rust, Clay, etc. should be consigned to the dustbin of history. People
> will expect me to emphasize concurrency and parallelism issues so it
> would be good to throw others into the mix as well.
>
> Thanks in advance for any input. Attribution of sources if appropriate
> will be given unless people prefer anonymity!
>

Modules already here. C++ might get them, if ever, around 2020. Who
knows how the computing landscape will look then.

Compile time meta-programming via use of templates and mixins.

C++ has lots of nice features, however with the increasing size of the standard, I doubt anyone will be able to understand it past the planned C++17 revision.

And the most dear to my heart, C's legacy just opens the door to security exploits by design, which force you to rely on third-party tools to assess that you not doing any buffer overrun, strange pointer manipulation and so on.

As for arguments against the other languages you pointed out.

Beating on Go is kind of easy, due to the stubbornness of the language designers to leave certain common features out, like the ever recurring
discussion on generics that even I take part in go-nuts.

Plus showing that certain Go PR features are actually also available in D, like actors having a similar role to channels, strides, fast compilation times.

Actually I kind of like Rust, since I am a big ML fan. They just should
give up on their Perlisms for pointer definitions. And the language is not yet fully defined.

I would rephrase the "clear language of choice for native code working" to "clear language of choice for system native code working", because almost any mainstream static type language also has native code compilers available.

--
Paulo

On Sunday, 20 January 2013 at 10:46:04 UTC, Paulo Pinto wrote:
> C++ has lots of nice features, however with the increasing size of the standard, I doubt anyone will be able to understand it past the planned C++17 revision.
>

Given how D is evolving, we will be soon at the same point.

deadalnix:

> Given how D is evolving, we will be soon at the same point.

The complexity of a language comes partially from the number of its features, but I think most of it comes from the unwanted and unexpected side interactions between different features.

Bye,
bearophile

On Sunday, 20 January 2013 at 09:15:36 UTC, Russel Winder wrote:
> As some of you know, the C User Group UK and the European C and C++ User
> Group long ago merged to create the Association of C and C++ Users
> (ACCU). Over the years, the emphasis on C and C++ gave way to a more
> diverse approach including patterns, Java, Python, Go, agile processes.
> Even the name of the group formally changed to ACCU to lose the direct C
> and C++ link. Due to the history, members of the group had and retain
> roles with the British Standards Institute, as the UK representatives on
> the C and C++ standards committees, especially the C++ one. When it is
> the UK's turn to host a C++ standards committee meeting, the meeting is
> either before or after the ACCU conference, and the obvious suspects get
> drafted in to do keynotes and other talks at the conference, as well as
> ACCU members attending the open meetings of JTC1/SC22/WG21.
> http://accu.org/index.php/conferences/accu_conference_2013
>
> This seems like an ideal opportunity to do a lightning talk (5 mins) on
> why C++ is crap and D is the only native code language that should be
> used. (I have a history in this group of bashing C++ :-) It would be
> really helpful to create a few one liners (with code examples) as to why
> D is the clear language of choice for native code working and, C++, Go,
> Rust, Clay, etc. should be consigned to the dustbin of history. People
> will expect me to emphasize concurrency and parallelism issues so it
> would be good to throw others into the mix as well.
>
> Thanks in advance for any input. Attribution of sources if appropriate
> will be given unless people prefer anonymity!

Arrays and slices. They might be very "basic" features, but don't underestimate how having something basic as a starting point can transcend through an entire language.

Also: Unicode. And algorithms that are Unicode aware.

Forget the high level fancy stuff. I cam to D for all those basic things. All the rest is (very tasty) sugar.

On 2013-01-20 11:46, Paulo Pinto wrote:

> Modules already here. C++ might get them, if ever, around 2020. Who
> knows how the computing landscape will look then.

Clang has already started to implement them.

-- 
/Jacob Carlborg

Am 20.01.2013 12:16, schrieb Jacob Carlborg:
> On 2013-01-20 11:46, Paulo Pinto wrote:
>
>> Modules already here. C++ might get them, if ever, around 2020. Who
>> knows how the computing landscape will look then.
>
> Clang has already started to implement them.
>

They are still experimental and who knows if the standard will ever get them.

The last time I did a 100% fully new C++ project was back in 2005. Since then I have replaced quite a few "legacy" C++ applications by JVM/.NET based solutions.

Will modules be part of C++17?

Will anyone care about C++17 or will it be like ISO Extended Pascal or COBOL 2002? Standards that no one cares to implement.

It is 5 years until 2017, now look back at the IT industry for the past 5 years and imagine a similar set of changes.

--
Paulo

On 1/20/2013 1:15 AM, Russel Winder wrote:
> Thanks in advance for any input. Attribution of sources if appropriate
> will be given unless people prefer anonymity!

SFINAE vs static if

On Sunday, 20 January 2013 at 18:10:47 UTC, Walter Bright wrote:
> On 1/20/2013 1:15 AM, Russel Winder wrote:
>> Thanks in advance for any input. Attribution of sources if appropriate will be given unless people prefer anonymity!
>
> SFINAE vs static if

 Substitution failure is not an error. Wasn't that where if the template use/instantiation failed it would go onto the next one (and hope one of them worked)? Although it could work assuming you have enough templates to handle the cases, being able to determine if they quality (as in D) is a superior solution.

 Reminds me... Wasn't there a problem with the min/max in C++ where to correctly make it work there was some 90+ templates for the STL? (I think it was rejected). Makes you wonder sometimes what they are thinking when they decide this stuff.