The C++ solution would most likely be shorter, more flexible, and more secure. Personally, I fail to understand why anyone would choose to write new C over C++.
http://www.matasano.com/log/914/c-a-cautionary-tale-or-1-hou...
People choose C over C++ because C is a simpler language than C++, something which this new standard does nothing to address.
That's something I've never found to be the case. Most of my C functions are 5-15 lines long. Anything more than 20 lines long is a candidate for refactoring - the unit tests will tell you if you've broken anything.
If your functions are huge, you should rethink your design, regardless of the language.
How do you suppose memory management works in high-level languages? Magic?
Moreover, the C++ garbage collectors are pretty darned easy to use, given that the language builds in support for custom allocators, overriding new/delete, etc.
If you're using C++ as its own language, you get many of the nice things that come with memory management in dynamic languages, but you don't have to pay for it at runtime (the inclusion of shared_ptr in C++0x is a great example of this, actually). If you merely use C++ as "C with classes" (I'm not saying that you do this...just generally), then you don't see this benefit of the language.
In any case, the reference-counting used by the safe pointers is probably an order of magnitude less heavy than a garbage collector. Even if you use them, you aren't paying that much...
Garbage collection is not an "order of magnitude" more heavy than reference counting, and there's more than one axis to measure memory management on --- in fact, there are several axes for allocation transactions alone.
Just as importantly, if you go to Google Code Search and randomly select ten C++ projects that (a) have more than 10,000 lines of ".cpp" and ".i" file code and (b) use shared_ptr, I'm betting you're going to find that 8 of them rewrote some of the memory allocator for performance reasons. All the fancy template BS in the world doesn't save you from the fact that "new" is just "malloc", and there's no one allocator design that works for every program.
"Avoiding third party deps". The dev team that embraced that standard sure sounds like a blast to work on. The wheel I can't wait to reinvent? Zlib.
Somehow I doubt it.
For what it's worth, pretty much all good C++ devs I know are getting nauseous at any mentioning of Boost .. with "passionate hatred" being a more accurate description. Very professional (older) crowd, responsible for some very notable and large-scale projects.
In general, C++ is too feature-full to ensure any sort of consistency of coding and design styles between any two C++ developers. Some use it as beefed up C, others - strictly as OO language. Former will never be pleased with the code produced by latter, and vice versa. Boost only amplifies these differences, so it's really not a big surprise that it is despised in certain C++ circles.
"Greenspun"
Spoken like someone who has never used a template function.