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

61–70 of 264 posts

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

#61

Post by okasaki »

Ygg2 wrote: post #48
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 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.

Because it doesn't make sense. These types would have infinite size.

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

#62

Post by xg15 »

Ygg2 wrote: post #48
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 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.

C++noob here, but: Given that the members in your example are no pointers but actual substructures within your data structure, wouldn't that result in an infinite data structure? Therefore it sewms quite logical to me it's not allowed.

Disallowing cyclical dependencies via pointer would make no sense though.

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

#63

Post by adrianratnapala »

leni536 wrote: post #46
adrianratnapala wrote: post #36

Earlier quoted context omitted.

"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?

Yes, I think so, though I was never truly clear on what PIMPL was supposed to mean.

I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file. There are some other tricks you can do too, such as using pointers-to-incomplete types.

When I do any of these tricks, find that someone else later comes and makes a changes that introduces the extra #includes after all.

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

#64

Post by humanrebar »

xg15 wrote: post #62
Ygg2 wrote: post #48

Earlier quoted context omitted.

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.

C++noob here, but: Given that the members in your example are no pointers but actual substructures within your data structure, wouldn't that result in an infinite data structure? Therefore it sewms quite logical to me it's not allowed. Disallowing cyclical dependencies via pointer would make no sense though.

Right. C++ objects are values, not references to values like in almost all other languages. So C++ needs to know the sizes of everything to construct them. If you tried to write out the mathematical series describing the ultimate size you would need to allocate for A or B, you would end up with a value approaching infinity.

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

#65

Post by n00b101 »

As has always been the case, effective use of modern C++ requires knowing which subset of the language to use and which to avoid.

I agree with the author's criticisms of many C++ features. At the same time, I think that a proper simple, modern subset of C++ exists that is much more productive and safer than C, without sacrificing performance. You can also optimize progressively, for example start with using std::string and std::vector and then replace the stock implementations if they aren't performant on your target architecture. I would not, however, recommend using C++ for GPU kernel code - a mix of C++ for CPU code and C for GPU kernel code works best. It is not ideal, but it's the best toolset available for serious industrial development.

FPGAs are exciting, but they've also been the "next big thing" in general purpose computing forever. Obviously it makes sense to use FPGAs for certain HFT and embedded applications, but that's not the same as general purpose computing which is what C/C++ is for. Not to mention, FPGA compile times can take hours or even days, which pales in comparison to most C++ template overhead. I would also say that for IOT, I'm not sure why it is obvious that "$10 FPGAs" should dominate. Why not a $0.50 microcontroller? Or the $5 Raspberry Pi Zero board? Both of which are eminently programable in C and even C++. Embedded devices have been around long before "IOT" became a buzzword, and we can see that microcontrollers, FPGAs, SOCs, and custom ASICs all have a role to play depending on the application.

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

#67

Post by gpderetta »

hellofunk wrote: post #3

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

"Well, I worked at a HFT firm for a long time until last year, the firm places millions of trades per day and is among the most successful in the markets it trades. And what did we use? Only modern features. Lambdas, auto, unique_ptr, range-fors, even std::async -- everywhere in our code. "

FWIW, I have been on the industry only 3 years so far, but I also see modern C++ and boost everywhere. I'm aware of the obvious selection bias, but then again it also applies to the author: if a firm has to call an external consultant to make sense of their codebase, it wasn't probably very good to start with.

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

#68

Post by cpwright »

I find the beginning and end of the article quite contradictory. Basically that C++ is too complicated; and oh by the way we should start programming FPGAs, which are much harder to get right.

I like modern C++, because I think it simplifies a lot of things (RAII for the win here). Templates let you engage in duck typing, but with (if you are careful) very performant results.

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

#69

Post by hellofunk »

adrianratnapala wrote: post #63
leni536 wrote: post #46

Earlier quoted context omitted.

>There's tricks You mean PIMPL?

Yes, I think so, though I was never truly clear on what PIMPL was supposed to mean. I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file. There are some other tricks you can do too, such as using pointers-to-incomplete types. When I do any of these tricks, find that someone else later comes and makes a changes that introduce…

PIMPL means "pointer to implementation" and the reason you and your colleagues are having difficulty with it is because you don't understand it, and therefore should not be using it, or, investing the time to understand it before trying to use it.

>every class has its own .cpp and .h file

Wrong. There are so many high-quality and widely-used libraries that are "header only".

>When I do any of these tricks, find that someone else later comes and makes a changes that introduces the extra #includes after all.

It is possible to write sloppy code in any language, and also to receive low-quality contributions from anyone else to your code. This is not unique to C++. That's why it is important that everyone in a team be on the same page about how code is organized.

>I am referring to writing a base class in the header and then doing the actual implementation in a derived class visible only inside one .cpp file.

This is not the PIMPL idiom, though it is halfway right.

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

#70

Post by pjmlp »

pheon wrote: post #42
pjc50 wrote: 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.

Compiler intrinsics as Assembly replacement go back all the way to the 60s.
Post reply on HN