Hacker News Reader

Comment by flohofwoe | Hacker News Reader

I fully agree with the authors concept that C++ is both a high-level and low-level language, and it is important to choose the right 'sub-language' for a given context.

I'd love to have the ability in C++ (and basically all other languages) to turn on/off language and standard library features right in the source code, it would do wonders for the maintainability of projects with many contributors and large code bases in general.

Instead of writing a style guide in the sense of "don't use new/delete, don't use raw pointers or arrays, don't use exceptions, don't use CRT functions, don't use stl containers, etc...", and hope that everyone follows the guide or catch violations in code reviews, the style guide would be part of the source code, and violating it would result in compilation errors.

View on HN

I will soon be making a library and will be used on micrcontrollers and PCs. I'd like to use C++ but past experiences suggest that using C and writing a C++ wrapper later will save me frustration with things like code size and manual memory management.

If I could turn off a number of features, C++ would be great. I keep flashing back to blog posts [0][1] written by the ZeroMQ author trying to settle on C being the way to go.

[0] http://250bpm.com/blog:4

[1] http://250bpm.com/blog:8

One of the first things he says is that constructors and destructors can't be used. Is that true? If so, why?

Exceptions should be able to be turned off in the compiler, but destructors, move semantics, simple template type substitution, and lambdas should be zero overhead in modern C++11/14.

I think a lot of people think about C++ and think inheritance and exceptions, but after having done modern C++11 for two years, those are two of the features I've used the least.

Many embedded style guides argue against dynamic memory allocation altogether. So you statically allocate all the variables you will ever need. And in an embedded environment there may not be a loader to run the constructors, or you don't want to run them at bootup until you've configured the DRAM or suchlike.

Edit: the ZeroMQ point is that, if you have a constructor or a destructor, then it must not do anything that can fail because the mechanism for recovery is an exception and clean recovery from exceptions bubbling up through code is quite hard to achieve. This is basically the Go/Rust argument against exceptions and in favour of explicit error return.

It's not that constructors and destructors can't be used.

What he said IIRC is that you can't manage errors in them without either using exceptions or using trivial constructors/destructors plus a state machine for the remainder of the lifecycle (initialisation etc). As he's mostly into writing libraries not applications, both approaches were, in his opinion, more hassle than they were worth.

A few words of advice: don't use C++ on microcontrollers or in kernel code. Explicitness is important for those applications.

Sounds like a great idea for a check-in tool.

Honest question: why wouldn't someone want to use STL containers?

Because someone might require different tradeoffs than those that were chosen by the STL's designers, such as in game development.

Which is why EA created the EASTL: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n227...

Do note that some of the issues with STL as pointed out in the link above got improved upon as both implementations and compilers improved.

I use STL now, but in the past I've seen several reason not to.

Compiler support hasn't always been there, especially on embedded systems with old or poorly supported compilers.

Strict control over memory allocation hasn't always been possible with STL, and it's still not very convenient if/when you need your own allocator, e.g., embedded systems, console games.

And this isn't true any more, but I still remember what the error messages used to look like more than 15 years ago. Sometimes a single error exceeded the maximum output length for error messages in whatever compiler I was using, probably Microsoft's, and you couldn't actually see what the problem was. That left me with impressions of STL that took a long time to recover from.

A bit of the no one ever got fired for buying IBM. By using the STL containers you can quickly learn a not great, but not horrible API and have a good chance of it being around down the road, your stuff will still compile, api wont change and it might be available on other platforms.

Honestly, the API doesn't seem that bad when you understand what it's trying to achieve. There are some hairy areas though (dealing with std::bind many years ago comes to my mind, but I didn't understand back then that they were basically trying to shoehorn half of Common Lisp into C++).

They aren't always the right tool for the job. Maps allocate every node separately (c.f. Boost Intrusive). Vectors don't generalize to multiple dimensions efficiently. Lists for a long time had only the doubly linked type. Vendor specific hash tables had O(n) erase by iterator. Strings are not part of the STL strictly speaking, but anyway they have had varying performance and design characteristics on different platforms...e.g. short string optimization.

GNU pissed me off in the latest long-awaited ABI break by making std::string a whopping 32 bytes on 64bit platforms, yet only supporting 16 bytes inline for SSO. Their argument is it takes no more memory because std::string always allocated at least that much anyway, but it bloats structs and classes unnecessarily, and every single other vendor does it better.

I don't think you can blame the C++ standards committee for vendors creating shitty implementations.

At the moment, unless you're exposing an object via a public API, I recommend using boost::string and boost::multi_index for hash tables. In public APIs expose a good old fashioned char*,size_t pair, or copy to a std::string.

Because they're well designed, good enough 90% of the time, safer than writing your own, and easier than finding and integrating another library.

Once I was handling a big data set for natural language processing. It's big enough it nearly ate all my memory and was somewhat slow if I remember correctly. Then I switched to a C-based toolkit, memory usage dropped significantly. I never knew STL overhead was high until that point. Yeah STL is great, but for big data, maybe not.

We worked on a game that was being released simultaneously on 6 different platforms. STL was out of the question, too much overhead, we wrote our own containers for pretty much every single platform.

Like an automatic linter/formatter?

I was thinking more along the line of "#pragma disable(std::vector)", but a post-processing/analysis tool could do the job as well I guess. Would be a nice addition to the LLVM tools family.

IIRC we're about to deploy this so it must already exist :P

Reply on news.ycombinator.com