Re: [boost] [filesystem] temp_dir_path()

Subject: Re: [boost] [filesystem] temp_dir_path()
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2011-02-21 06:30:25

"Marsh Ray" <marsh_at_[hidden]> wrote in message
news:4CC31E3C.1030400_at_extendedsubset.com...
> 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.

Honestly, why?
What I was asking for was simply an interface that does not make you pay for 
something you do not use _and_ is in fact not needed by the underlying 
implementation to make the required simple OS/system call...why is that 
suddenly 'not C++'?

>> 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

The point of course was not that of a flame-war-like 
my-shoes-run-faster-than-yours or a 'because I can' type of argument _but_ 
that the STL constructs to whose injudicious use I objected are not 
necessarily used by every C++ project (either because those can simply be 
avoided in such projects or because some third party library forces you to 
use its own counterparts in the few places that you actually need those 
containers) and that Boost libraries should not use them so 
injudiciously/'without blinking an eye' when it is not really required (and, 
in the case of a simple temp dir path getter, it is not required)...

> So GCC can DoS your OS. I don't see what that proves about C++.

What usually 'kills' a compiler are templates which are a strictly C++ 
feature...ergo it is possible to write strictly/'true' C++ code without 
using many of the new-virtual-throw invoking STL constructs...and not just 
as an 'academic exercise', I work on a real world commercial project that 
happily thrives like this...

>> - 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.

The fact that it (the criticism) is true, that's what...
And answering 'who cares'/'you don't have to use it' to grounded criticism 
is IMO just irrational fanboyism...not something Boost would want to boast 
with, I hope.

>>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?

a)
Because if you give credence to one or two of his claims/criticisms, as 
pointed out above, his other arguments (i.e. irrational prejudices) 
automatically also get more 'exposure'...

b)
This is not a discussion about what should _you_ care about what should/does 
the Boost community care about...

> 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).

Right, I hate this behaviour in Mac OS X...but bringing this up here is just 
of form of an ad hominem argument...i.e. it does not invalidate other points 
of criticism that can be valid by themselves...

> 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.

Well, seeing the inefficient implementation of temp_dir_path() I made a 
simple test of the latest trunk Boost.Filesystem v3 code to see how does 
justifying premature pessimization as 'proper C++' reflect on an entire 
library: a simple MSVC++ 10 project that does not link to a built Boost 
(BOOST_ALL_NO_LIB) but simply includes the 
boost/libs/filesystem/v3/src/*.cpp files, the required 
boost::system::error_code.cpp (with LTCG and all for-size optimizations 
enabled) and cpp with a main() function that simply returns 0 and includes 
no headers...the release build result: ~225 kB !
Now, for a library that is suppose to wrap existing OS functionality, that 
is just obnoxious by any standard...
Note that absolutely no code from Boost.Filesystem is invoked whatsoever, 
only its .cpp files are included in the project...

> In the particular case of string and vector, I'm already using them all
> over the place.

Even if you do already use them, every new place of usage pollutes the 
calling code with EH code and the calls to their constructors and 
destructors are always larger than simple pushing of a static string on the 
stack and passing it (almost) directly to the OS function (and a simple 
inspecting of a return code that can sometimes be handled on the call site 
as opposed to having to use a try-catch block)...

>> 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.

If you work on anti-virus software where security is your primary concern 
then yes...if OTOH you work with multimedia or on a compiler you simply do 
not care about security at all but _do_ care about efficiency...

> 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.

This is not a matter of 'optimization' but about avoiding unwarranted 
premature pessimization...

-- 
"What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than
from one whose countenance exudes suspicion and hate."
Neil Postman