Why I don't spend time with Modern C++ anymore

Post by nickpsecurity » Wed, May 18, 2016, 3:18 PM UTC

pjmlp wrote: post #76

coldtea wrote: post #43

Earlier quoted context omitted.

> A single language needed to solve all problems is a fallacy. Has that been proven and do we have pointers to any peer reviewed papers on that? Because else its just an old's wives tale. I don't see any logical impossibilities for one language to solve all problems (meaning, to work well for at least 4 domains: OS and drivers a la C, apps/games a la C++, network programming a la Go, Java etc, and scripting a la Pyth…

Mesa/Cedar, Ada, Oberon(-2) and Modula-3 come to mind as such languages. Specially the interactive environments of Mesa/Cedar and Oberon OSes.

Post by [deleted] » Wed, May 18, 2016, 3:20 PM UTC

cm3 wrote: post #114

netheril96 wrote: post #110

Earlier quoted context omitted.

How do you know that it is c++11 switch that dramatically increased your compile time, instead of the header file and the headers it includes? Two conditions are changed, and you feel confident that one of them is responsible for the outcome. Why?

Because it's a C++11 header that doesn't exist in C++98. And I cannot compile that version without switching to C++11 mode. Edit: there appears to be some confusion here. I don't include the C++11 header myself. I include a public API header of another project which now happens to include a C++11 header in their public include file. Unless I want to stay on the old version of that API and accept the risks, I don't ha…

Post by pjmlp » Wed, May 18, 2016, 3:29 PM UTC

pheon wrote: post #101

pjmlp wrote: post #93

Earlier quoted context omitted.

Well, we also have to thank C for the set back in optimizing compilers. Fran Allen. In Coders at Work (pp. 501-502): --- Begin Quote --- -Seibel-: When do you think was the last time that you programmed? -Allen-: Oh, it was quite a while ago. I kind of stopped when C came out. That was a big blow. We were making so much good progress on optimizations and transformations. We were getting rid of just one nice problem a…

ah your siding on the lisp machine vs todays hardware arch. I think if the lisp hardware architecture has significant advantages we`ll see that emerging in "soft cpu`s" on fpga`s. Particularly as the Xeon/FPGA gear gathers steam.

Post by neutronicus » Wed, May 18, 2016, 3:35 PM UTC

gpderetta wrote: post #32

pjc50 wrote: post #27

Earlier quoted context omitted.

Parallelism: yes, although OpenMP isn't nearly as accessible as e.g. Swift async closures. C++ only got proper language-native threading in C++11. for large scale programming the only sane model is a flat, cache coherent one Do google view their datacenters as a single flat cache-coherent memory space? No, they built mapreduce instead. That's the point of view I'm coming from: distributed systems engineering working…

"Parallelism: yes, although OpenMP isn't nearly as accessible as e.g. Swift async closures." I'm not familiar with them, do you have a pointer? Cilk does have powerful semantics and a very light weight syntax. "C++ only got proper language-native threading in C++11." Sure, but OpenMP and Cilk are significantly older. "Do google view their datacenters as a single flat cache-coherent memory space?" No, but I'm pretty s…

Post by roel_v » Wed, May 18, 2016, 3:38 PM UTC

jupp0r wrote: post #57

In my experience, the opposite of what the author claims is true: modern C++ leads to code that's easier to understand, performs better and is easier to maintain. As an example, replacing boost::bind with lambdas allowed the compiler to inline functor calls and avoided virtual function calls in a large code base I've been working with, improving performance. Move semantics also boosted performance. Designing APIs wit…