Me too :)
Why I don't spend time with Modern C++ anymore
91–100 of 264 posts
Re: Why I don't spend time with Modern C++ anymore
#92HFT is a pretty limited and extreme application case. From what I understand - everything is not enough for HFT - network cards, kernel drivers, cables, etc. You have milliseconds (edit: nanoseconds !) to receive, process and push your orders before someone else does it and gets the prize. It's an arms race between technologists for the purpose of making a small number of people rich. I doubt that these requirements…
HFT = Insider trading + Algorithm trading
Re: Why I don't spend time with Modern C++ anymore
#93Earlier quoted context omitted.
But good codegen from intrinsics goes back only a dozen years or so (ymmv)
Precisely. Also the instruction sets have been designed for compilers vs minimizing gate counts. Making it easier for compilers to schedule optimally - alot less weird and bizzare shit they have to deal with.
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 after another. When C came out, at one of the SIGPLAN compiler conferences, there was a debate between Steve Johnson from Bell Labs, who was supporting C, and one of our people, Bill Harrison, who was working on a project that I had at that time supporting automatic optimization.
The nubbin of the debate was Steve's defense of not having to build optimizers anymore because the programmer would take care of it. That it was really a programmer's issue. The motivation for the design of C was three problems they couldn't solve in the high-level languages: One of them was interrupt handling. Another was scheduling resources, taking over the machine and scheduling a process that was in the queue. And a third one was allocating memory. And you couldn't do that from a high-level language. So that was the excuse for C.
-Seibel-: Do you think C is a reasonable language if they had restricted its use to operating-system kernels?
-Allen-: Oh, yeah. That would have been fine. And, in fact, you need to have something like that, something where experts can really fine-tune without big bottlenecks because those are key problems to solve.
By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reasons compilers are... basically not taught much anymore in colleges and universities.
--- End Quote ---
Re: Why I don't spend time with Modern C++ anymore
#94Kernel is my new home;
Re: Why I don't spend time with Modern C++ anymore
#95I 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…
My personal rules for using auto. Only use it iff: 1. the actual type is clearly visible on the right hand side. auto f = make_widget(); // it's a widget auto i = 123; // it's an int auto x = vec3(1.0, 0.0, 0.0); // it's a vector 2. the actual type doesn't really matter so much or is complicated to type out. auto it = vec.begin(); // it's an iterator auto it = // some template expression 3. the actual type is not kno…
In a word where most new code is JavaScript, just use auto everywhere. It will be OK.
Re: Why I don't spend time with Modern C++ anymore
#96In 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…
I think the author was mostly referring to meta programming / templates. You have to admit, they can get pretty obscure sometimes. I agree, lambdas simplify callbackas/async programming immensely.
Right, but there's nothing "modern" about templates. Those have been a disaster for compile times forever.
C++98 with no Boost is an awful language that nobody should want to go back to. It's one where you could legitimately prefer C99, despite its lack of RAII and other conveniences. Actual modern C++ is a great language to write, though the compile times haven't really improved.
Re: Why I don't spend time with Modern C++ anymore
#97This 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 :)
Re: Why I don't spend time with Modern C++ anymore
#98Earlier quoted context omitted.
As far as the complexity of programs are concerned, there is a similarity between statements at one level of abstraction and functions at a higher level. I have seen many cases where small functions have been assembled into complicated programs. These programs often have a proliferation of 'helper' classes and functions, where you have to trace through long series of calls to get to where the work is done. They often…
I think what you're describing is a case where you can't understand what those helpers do, and therefore can't understand what the function that calls them does. I maintain that if each individual function makes sense then the whole will too.
Sensible, understandable functions can be assembled into complicated, incomprehensible programs in exactly the same way that the sensible, understandable operators of a programming language can.
Re: Why I don't spend time with Modern C++ anymore
#99Amen.
Re: Why I don't spend time with Modern C++ anymore
#100It just sounds like someone who couldn't handle C++ whining and making a bunch of blanket statements without really having any proper understanding. I agree that some of the features such as lambdas can use to hard to track bugs (lifetime issues) and difficult to follow code when abused. When used nicely though they can lead to simple, elegant and straightforward code (anyone who tried to use the STL algorithms befor…
> It just sounds like someone who couldn't handle C++ whining As if you have so more experience and skills than him in the language? He's not some newbie trying C++ for the first time... > Bottom line, if your code base is a mess don't blame the tool. Blame the programmers. If the tool is a programming language, then its syntax, modularization and other features absolutely affect the code being a mess or not. Tools a…
>>As if you have so more experience and skills than him in the language? He's not some newbie trying C++ for the first time...
Not much experience. Just 15 years writing C++.
>>If the tool is a programming language, then its syntax, modularization and other features absolutely affect the code being a mess or not.
In any language there's the idiomatic way of doing things. There are designs to which the language lends itself nicely and there are designs to which it doesn't lend itself. There are badly written code in any language. It's up to the programmer to choose designs and paradigms that work well with the language.