On 10/23/2010 11:09 AM, Domagoj Saric wrote:
"Beman Dawes" <bdawes@acm.org> wrote in message news:AANLkTinFigAxpqkbgwQCnOXrr-Jg44=_dep1QWn+hy-Z@mail.gmail.com...
What you are really asking for, I think, is a C language interface or something pretty close to that.
Yeah that's how I would think about it.
The attitude/assumption that anything C++ must implicitly become intimate with the keywords new, virtual and throw otherwise it is actually 'only C' is just plain wrong in the fullest sense of the word: - it is wrong 'factually' not only because (most of) C is a subset of C++ but because it is quite possible to do heavy C++ programming (e.g. so heavy that it causes GCC 4.2.1 to allocate tens of gigabytes of RAM before it eventually kills the entire OS) practically without using any of the before mentioned STL 'goodies'...
It's possible to write an entire novel without using the letter 'e'. http://en.wikipedia.org/wiki/Gadsby:_Champion_of_Youth So GCC can DoS your OS. I don't see what that proves about C++.
- it is wrong 'morally' because it is guilty of the typical 'premature pessimization' that feeds the typical anti C++ and anti Boost arguments...
So what? They don't have to use it.
IOW Linus will no longer have to ask 'How many memory allocations does it take a C++ programmer to concatenate two strings?' but 'Guess how many tens of kilobytes will calling boost::temp_dir_path() add to your binary?'
In all seriousness: why should I care what he thinks? So how many crashes and security vulnerabilities have been caused by programmers using C-style string handling over the years? Even just in Linux? This is they guy with the kernel which in its default configuration commits more memory than it has backing store for and then when some process touches memory it properly allocated it's terminated ungracefully. If that happens to be an important OS process that touches memory next, the OS crashes. Even if it was your compiler that allocated gigabytes of memory (compiling code that doesn't use std::string). Nevertheless, the question "how much size will a single call to boost::foo add to my binary?" is important. It's one of the reasons I'm cautious about using new Boost libraries. Which is not to say there's something wrong about Boost libraries, just that I'm cautious in general about adding dependencies. In the particular case of string and vector, I'm already using them all over the place.
The 'plain char buffer' can also be understood in a more 'relaxed'/'broader' way to for example also encompass a, more C++ like, iterator_range that specifies a preallocated chunk of storage...
If the modern history of software development has taught us one thing, particularly from a security perspective, it's that C-style char string buffers suck. Anyone is free to write C++ without using string or vector. But it's not a common enough case for which the typical Boost library should be optimized. - Marsh