Live data from Hacker News

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

linkedin.com

41–50 of 264 posts

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

#41

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

Swift solves the "auto" issue pretty nicely - with the help of the IDE:

let x = someFunction()

Alt-click on x and it shows the type.

Otherwise, as you say, the code becomes very confusing and I abstain from auto except in cases where the type is clearly obvious.

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

#42
post #6

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

As for 2) totally agree, GPU and FPGA programming has become "the new assembly language".

It use to be you could drop from C/C++ to assembler and gain massive performance boosts. These days with C intrinsics there`s no need for pure assembly code. But droping to GPU or FPGA code is a total must now, if you need any significant juice from your system.

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

#43
post #24

Ok. Try a different language :)? A single language needed to solve all problems is a fallacy. I don't see FPGA programming ousting c++, but expect higher level languages with strong parallel semantics to gain "market share". You can always call a dedicated process written in optimized c for the hottest components. Compose the rest in go, elixir, or any high level language (lisp). Architectures will naturally gravitat…

>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 Python).

It's just cultural, monetary, design and community issues with most current languages.

And even if we want to have different profiles for each domain, ideally I'd do it with a 2-layered language implementation like this:

1) Base library: network, threads/fibers, UI, database etc of Python/Java SDK proportions

2) A "close-to-the-metal" layer without a (big or any) runtime (can use RAII, ARC, etc).

3) A "scripting" layer that is a GC'ed an easier to use superset of the (2)'s syntax. Ideally all (2) code should also be valid (3) code.

Both use the same base library (written in the "metal" layer or C). (3) can be embedded into (2) as a scripting engine, and (3) can call all (2) APIs trivially (e.g. no need for declarations like for using C from Go, Python etc -- just import and call).

Programmers can use (2) or (3), mix them, share code between the two. And what's best, the core APIs are all the same -- which is most difficult part to master in a language.

(Think like Java and Groovy, but with the parent language closer to the metal and the later closer to C).

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

#44

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

Swift solves the "auto" issue pretty nicely - with the help of the IDE: let x = someFunction() Alt-click on x and it shows the type. Otherwise, as you say, the code becomes very confusing and I abstain from auto except in cases where the type is clearly obvious.

Visual Studio shows the type of auto on hover.

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

#45

It 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 as not passive, they influence how we use them and what we can do with them.

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

#46
post #10

Earlier quoted context omitted.

Yes, templates make the compiler work harder (sometimes at least), but badly modularized code with "big ball of mud" dependency structure also makes the compiler work a lot. You don't need fancy features to do that.

"Big ball of mud" dependency structures are common because the most pragmatic quick-fix for so many compile errors it to just whack in a new #include. C++ is worse than most languages in this way, because private members are defined in public headers. This forces you add #includes to the headers. Thus the #include graph is much denser than the true dependencies in your program. There's tricks for getting around this,…

>There's tricks

You mean PIMPL?

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

#47

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

Bottom line, if your code base is a mess don't blame the tool. Blame the programmers. The problem is the attitude towards these new features that naturally leads to programmers abusing them, building overabstracted complex bloated behemoths to accomplish the simplest of tasks. I'd say the vast majority of programmers, for some reason, seem to have an appetite for complexity --- they tend to feel that overly complicat…

A common assumption among C++ programmers seems to be that if an ounce of prevention is worth a pound of cure, the value of a ton of prevention must scale up similarly. But a ton of anything is too much weight for most projects to handle.

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

#48

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

I had to write C++ yesterday and hated every second of it, from the clunky header files, to the errors that make no sense, to the can't make a cyclic dependency between classes i.e.

      class A { B: b}
      class B { a: A}
Long story short - I was to create a wrapper around a Poco::Runnable, so you can use the wrapper as a Poco::Runnable (don't ask why, it's TEH LAW) but without extending it.

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

#49
HFT 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 apply to other application fields where C++ is used - and it's used almost everywhere, with great success I might add.

In my view C++ is actually a couple of languages mixed into one.

The hard part is knowing which part of the language to use for which part of the problem.

The "modern" C++ solves a lot of the nuisances of the "old" C++, but you can do without these features just fine. I apply them carefully to my code and so far it's been a pleasant experience. Even if I don't use all of the new features, it's nice to know that I can (and I will some day!).

So I don't really buy this rant..

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

#50

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

> Then there's the whole thing about making constructors, but leaving the bodies empty because everything should be on initialize lists now, and now there's wrapped pointers for some reason.

I fail to see how this line is supposed to be a "criticism" of modern C++.

Post reply on HN