Could you name a book that focuses on Modern C++, that isn't one of these 1200 page tomes? I ask because sooner or later at my job I will probably have to code in C++. It will undoubtedly be a greenfield project, so I don't have to worry about anyone else's horror show (only my own).
There's no better place to start than Alexandrescu's eponymous Modern C++ Design http://www.amazon.com/Modern-Design-Generic-Programming-Patt.... Scott Meyers will soon come out with "Effective C++11" which from the table of contents looks like it will do a great job of covering the new language features.
As for coding standards, I suggest a book by the same author plus the current chair of the standard committee: http://www.amazon.com/Coding-Standards-Rules-Guidelines-Prac.... Another commenter has suggested the Google C++ Coding Standards, but despite their popularity they do not conform very well to "Modern C++" as I understand it.
Or just get Stroustrup's "The C++ Programming Language" and read the intro bit - it covers the language in fleeting detail but then you still have the rest of the book to look at if you are having a hard time understanding the section at the beginning.
Doesn't the Google coding standard use uppercase function names (like Microsoft)? Brrr. Classes are nouns -> uppercase, functions are verbs -> lowercase. Well, alt least if you speak German that is the logical choice.
It also completely forbids the use of exceptions. I can understand that for their stated purpose of working with non-exception-safe legacy code, but it shouldn't be extended to other circumstances.
Exceptions have a significant performance impact, and making code exception safe distorts your interfaces. Insisting on no exceptions is reasonable for these and other reasons, even for new code.
Depends on if you need to gracefully handle malloc failures or not. Otherwise any write operation on an STL type (like appending to a string) will potentially throw an exception that you need to care about.
In the C world this is extremely arduous since need to bubble the allocation-failure down through every level of code, adding cleanup to just about every function call. If you're using C++ and RAII you can just catch std::exception in one place to cover a huge number of places that an allocation can fail.
Do you work on systems that handle this? I'd like to know if any still exist.
In modern systems I'm familiar with, malloc only reports failure on bogus inputs like -1, or address space exhaustion. Your process is likely to be killed before exhausting your address space (think iOS OOM handling, or Linux overcommit), especially on 64 bit. So checking for allocation success just isn't that useful any more.
The second is exhausting kernel data structure space for things like page mappings. I've seen this recently in AIX when allocating lots of memory that alternates mprotect permissions.
I worked on an embedded system that aggressively cached images in memory dedicated to the GPU. It wasn't uncommon for gl texture allocation errors to occur - and in addition to that, we needed to decompress images packed in various formats into whatever format the GPU supported (typically from png to rgba32). In low memory situations, it also wasn't uncommon to not have enough contiguous memory to perform that decompression - in which case malloc would fail.
Gotta love putting forth every effort in software to keep the BOM down :)
As @jjnoakes points out, you'll get malloc()==NULL if your ulimits are set. For a long-running program you definitely want to have a ulimit that will kick in before the OOM killer does.
Even in the absence of the OOM killer (i.e. the old days) you had to do this -- otherwise the machine might be swapping itself unresponsive for ages before you ever get malloc()==NULL
Can you elaborate on the "significant performance impact"? If used properly, they should have no runtime overhead - they are predicted "not taken" in modern compilers.
Early C++ implementations used setjmp/longjmp to support exceptions, and then each try block would lead to settting the setjmp context. So there definitely was a runtime overhead, even with no exceptions thrown.
I don't think it's very popular today. Modern implementation don't use this anymore and do not incur run-time overhead when no exception are thrown. However, they do incur some space overhead: the implementation need to maintain pretty large tables to know what needs to be unwound (which destructors to call, in which order) when an exception is thrown. In most environment this space overhead shouldn't be a problem (PC, server). But for embedded development it may be a problem. And then disabling exception to save space brings back the issues with error checking (or the lack of it...).
For more details, search for C++ exception implementation and you should find all the info you need. Or look into G++ documentation for example, this topic is covered somewhere.
