• Paulo Pinto (17/17) Sep 13 2014 Just discovered this talk while watching the CUFP 2014 talks.
• po (9/12) Sep 13 2014 Why they were using C++ for that type of software is beyond me,
• Paulo Pinto (18/28) Sep 13 2014 Some form STL did exist, but it was still being discussed for inclusion

Paulo Pinto <pjmlp progtools.org> writes:

Just discovered this talk while watching the CUFP 2014 talks.

What is interesting for the D users, are the slides related with the
C++ issues that caused the decision to move away, between 03:00 and 05:30.

https://www.youtube.com/watch?v=Wu8eJh6OqhI#t=181

Basically the usual points how real enterprise C++ looks like, where no
one cares about "Effective C++" and similar practices.

- uninitialised memory, memory leaks
- no use of safer idioms like RAII, usage of deprecated idioms
- low level pointer arithmetic, copy pasted in 100 places
- off-by-one errors
- undefined behaviours
- static initialization order fiasco
- race conditions
- valgrid and purify could not be used everywhere

Issues that D, specially in  safe blocks, takes care of.

--
Paulo

"po" <yes no.com> writes:

 Basically the usual points how real enterprise C++ looks like, 
 where no
 one cares about "Effective C++" and similar practices.

  Why they were using C++ for that type of software is beyond me, 
I'd rather use Haskell if latency & throughput aren't my main 
concerns.

  The paper he referenced in regards to prototyping is from 1994. 
I'm not even sure if C++ has STL at that point. Which makes it 
pretty well meaningless.

  In the end all this really says is that legacy C++ is 
terrible(which it is), it doesn't really apply to C++14. Also the 
tooling advantage C++ has over Haskell or D is pretty wide--

Paulo Pinto <pjmlp progtools.org> writes:

Am 13.09.2014 17:27, schrieb po:
 Basically the usual points how real enterprise C++ looks like, where no
 one cares about "Effective C++" and similar practices.

   Why they were using C++ for that type of software is beyond me, I'd
 rather use Haskell if latency & throughput aren't my main concerns.

   The paper he referenced in regards to prototyping is from 1994. I'm
 not even sure if C++ has STL at that point. Which makes it pretty well
 meaningless.


Some form STL did exist, but it was still being discussed for inclusion 
in the standard.

C++ compilers bundled their own collection classes based in common root 
class or magic macros.

It was however already possible to get initial versions of the STL from 
SGI, the STLport and a few others. Some compilers with initial template 
support, bundled these instead of their own.


   In the end all this really says is that legacy C++ is terrible(which
 it is), it doesn't really apply to C++14. Also the tooling advantage C++
 has over Haskell or D is pretty wide--

I don't do C++ at work since 2005, but do get to replace C++ systems by 


This is the archtype of enterprise C++ code I get to see. Probably by 
the time C++17 gets approved is when some of these IT departments (or
managers) will allow the use of C++11 compliant compilers.

So far, the only workplace I could enjoy C++ being done properly, was 
during my stay at CERN.

Tooling is a big factor, yes.

--
Paulo