[deleted]
Why I don't spend time with Modern C++ anymore
111–120 of 264 posts
Re: Why I don't spend time with Modern C++ anymore
#112This article is not very general. Much of what it tries to convince us is not going to matter for most developers, and has the cost of suggesting modern features are not good for any developers. For example: >It is not rare to see Modern C++ applications taking 10 minutes to compile. With traditional C++, this number is counted in low seconds for a simple change. This is simply a bogus statement with respect to what…
(re 10 minute compile times) > This is simply a bogus statement I work on a C++ project and believe me, 10 minute compile times would be great :)
have you tried ccache? the 5x to 10x improvement isn't a bogus statement in my experience
Re: Why I don't spend time with Modern C++ anymore
#113I know why I don't like C++ anymore, it's just no fun.Its slow to compile, the errors are like 6 lines long full of template and class hierarchy that makes it hard to understand what exactly happened, and then of course there's the common coding shortcut of declaring everything auto. (What type is this list? I don't know, it's auto all the way down.) Then there's the whole thing about making constructors, but leaving…
It is funny that people on HN are so critical of `auto` when many people here are also coding in Ruby, Python, Swift and Javascript. Is the intersection between the two groups that small?
Re: Why I don't spend time with Modern C++ anymore
#114I recently had to switch a project to -std=c++11 because a header I include now uses C++11 files. This change alone made compilation at least twice if not three times as slow. The new safety and convenience features are nice but compile times seem to be out of focus and getting slower and slower every year. I don't know how I feel with g++ 6.1 defaulting to -std=gnu++14.
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 have a choice whether I compile my consumer module in C++11 mode or not. And it's a major fault of the C++ language that there are no modules and therefore this include file overhead and mess. They appear to be working towards a module system, thankfully.
Re: Why I don't spend time with Modern C++ anymore
#115> Today the "Modern Technologist" has to rely on a new set of languages: Verilog, VHDL
That was a complete surprise ending! :)
I like surprise endings, and he makes a lot of good points, whether or not I agree with them. But, I totally wasn't expecting "I'm done with C++ because: hardware." I was expecting because web or because awesome new high performance functional scripting language .
A lot of what he's talking about there will still run compiled software though... FPGA programming and C++ aren't exactly mutually exclusive, right?
Re: Why I don't spend time with Modern C++ anymore
#116In 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…
Fully agree with what you're saying. Just a nitpick about bind (which I'm sure you're aware of, just for the sake of others).
The return type of {boost,std}::bind is unspecified (it's basically just a "callable"). This means that bind doesn't have to do type erasure. On the other hand, {boost,std}::function has to do type erasure, which can boil down to a virtual function call. But that's orthogonal to where the callable came from.
Another thing to keep in mind is that if you're writing a function like `copy_if` which takes a callback, but doesn't have to store it for later use, it's much better to take the callback as a template type rather than going through the type-erasing {boost,std}::function. Doing the latter makes the compiler's job a lot harder.
Re: Why I don't spend time with Modern C++ anymore
#117In 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…
Fully agree with what you're saying. Just a nitpick about bind (which I'm sure you're aware of, just for the sake of others). The return type of {boost,std}::bind is unspecified (it's basically just a "callable"). This means that bind doesn't have to do type erasure. On the other hand, {boost,std}::function has to do type erasure, which can boil down to a virtual function call. But that's orthogonal to where the call…
[deleted]
Re: Why I don't spend time with Modern C++ anymore
#118There are two separate rants here that aren't delineated well. 1) C++ is too complicated, and therefore hard to reason about and slow to compile. We're going to argue about this forever, but you'll have to agree that the spec is very large and warty compared to other languages, and that C++ tends to take far longer to compile (this was already a problem a decade ago, it's not specific to "modern" C++). 2) The future…
Can't really argue about 1. About 2, in-order single instruction execution hasn't been an assumption for a very long time; c and c++ optimizers (and programmers) have been able to take advantage of these CPU features for a while. There are language extensions (Cilk++, OpenMP), to take advantage of extra cores for fine grained parallelism. Regarding GPUs, arguably C and C++ have the most mature and transparent offload…
> Regarding the flat memory model, for large scale programming the only sane model is a flat, cache coherent one; those architectures that don't provide that, either evolve to provide it or die (cf. CELL) supplanted by those that do (yes, that doesn't mean that all memory is the same, but that is true with your standard CPU anyway).
CUDA on Nvidia GPUs gives a non-coherent last level cache. Most programs distributed over multiple nodes have no shared address space abstraction, but instead do explicit message passing. I agree that coherent caches make programming easier to think about, but I don't think I would go as far to say they are the "only sane model" for "large scale programming" given that MPI and CUDA both are popular.
Re: Why I don't spend time with Modern C++ anymore
#119Earlier quoted context omitted.
(re 10 minute compile times) > This is simply a bogus statement I work on a C++ project and believe me, 10 minute compile times would be great :)
have you tried ccache? the 5x to 10x improvement isn't a bogus statement in my experience
ccache doesn't help as soon as you change a popular header file. distcc helps quite a bit, but there was a project I worked on for years where by the end the compile time was 15 minutes after you'd distributed it across 20 machines.
Re: Why I don't spend time with Modern C++ anymore
#120Earlier 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…
> Because it's a C++11 header that doesn't exist in C++98.
That is supposed to be a fault of C++11?