Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

linkedin.com

Post reply on HN
Print view View original

71–80 of 264 posts

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

#71

Post by mannykannot »

justsaysmthng wrote: post #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…

HFT is one of those uses C++ is supposed to be particularly good for. Many of Stroustrup's justifications for C++ take the form "You get without compromising performance."

The style outlined in your penultimate paragraph - an approach I also follow - suggests that there is some alignment between you and the author.

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

#72

Post by blazespin »

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…

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.

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

#73

Post by typon »

If he is complaining about C++ being bad and suggesting Verilog on FPGAs as an alternative, boy do I have some bad news for him.

HDLs (yes including Systemverilog) have 10x worse design than the worst software languages. This is why there are entire companies out there that make high level synthesis tools or high level HDL specification languages (like Bluespec).

And I haven't even said anything about the quality of FPGA tool chains.

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

#74

Post by jerf »

coldtea wrote: post #43
messel wrote: 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 Pyth…

Languages can incorporate as many features as they like, but where two features conflict, they have to privilege one over the other. Nothing stops a language from having both statically- and dynamically-typed elements, but the library it ships with is going to privilege one over the other, and it's going to drag the rest of the code in the language in that direction. Nothing stops a language from having both immutable and mutable elements, but the language is going to have to privilege one over the other. (If all the library code uses mutable values, then you will have a harder time using immutable values with it; if all the library code requires immutable values then you'll have to copy a lot of stuff if you're using mutable values.) And so on and so on for a large number of features.

In the end you can not help but have a language that is either a "systems" language, a "scripting" language, or something uselessly in-between. You can't help but have an "imperative" language or a "functional" language or something uncomfortably in-between. And in a lot of ways it's more the libraries driving this than the language itself; a language can be a kitchen-sink language but when it comes time to write the function that splits a string on the given character, you're gonna have to choose whether the strings are immutable and how arrays get allocated and how they get passed by that specific function no matter how flexible the underlying language is. Multiply by several hundred for even a simple standard library. (And there will be a standard library; even if you don't bless one by the language designers the community will develop a "standard" loadout and make the decisions for you even if you didn't.)

You can imagine this sort of language as being a good idea because you can hide in the conceptual ambiguities in the vague idea, but when you try to manifest it concretely, you can't help but make a long series of decisions that will create a language that is better at some things than others, or, if you choose sufficiently poorly, not terribly good at anything.

You can always do the "multiple language on the same base system" approach; it's not just Java that works that way with its virtual machine, it's the way the real machine works too. You've got the base machine code and a whole bunch of things that back to that already.

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

#75

Post by pjmlp »

jonathankoren wrote: post #33

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 still like it a lot.

However I have came to realize that I rather use it on as an infrastructure language.

Just when I need to write portable code across mobile OSes without dependencies on third party SDKs, interact with LLVM or give an helping hand to my actual daily programming languages.

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

#76

Post by pjmlp »

coldtea wrote: post #43
messel wrote: 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 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.

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

#77

Post by logicchains »

hendzen wrote: post #59
justsaysmthng wrote: post #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…

Not milliseconds. Nanoseconds. Competitive tick-to-trade times are on the order of 1000ns or less.

That really depends on the market in question. There are places where you can still make fat stacks with over 100us tick-to-trade time.

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

#79

Post by adzm »

pjmlp wrote: post #70
pheon wrote: post #42

Earlier quoted context omitted.

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.

Compiler intrinsics as Assembly replacement go back all the way to the 60s.

But good codegen from intrinsics goes back only a dozen years or so (ymmv)

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

#80

Post by mannykannot »

lmm wrote: post #37
susam wrote: post #22

Earlier quoted context omitted.

I disagree. A complicated function may be made of a bunch of statements where each statement makes sense easily. The entire function may still be complicated. The same argument can be extended for files and projects. Even if each file is simple, if the code in those files interact with each other in a complicated manner, the project becomes complicated. This can happen despite having neat boundaries between files. No…

> A complicated function may be made of a bunch of statements where each statement makes sense easily. The entire function may still be complicated. Statement yes, but I avoid them where possible - the complexity comes from their interactions because their interactions are unmanaged, implicit and arbitrary. If you make each function an expression made up of expressions and functions, then I think it becomes true that…

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 seem to come from a poor design that has been repeatedly patched instead of fixed, or from programmers who write functions because they think they will be part of the solution, but not backing out and replacing them them when they find a complication they had not anticipated.

Using small functions is a necessary, but not sufficient, condition for making understandable code.

Post reply on HN