Re: [boost] [filesystem] temp_dir_path()

Subject: Re: [boost] [filesystem] temp_dir_path()
From: Marsh Ray (marsh_at_[hidden])
Date: 2010-10-23 13:41:16

On 10/23/2010 11:09 AM, Domagoj Saric wrote:
>
> "Beman Dawes" <bdawes_at_[hidden]> wrote in message
> news:AANLkTinFigAxpqkbgwQCnOXrr-Jg44=_dep1QWn+hy-Z_at_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