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
> On 10/23/2010 11:09 AM, Domagoj Saric wrote:
>> "Beman Dawes" <bdawes_at_[hidden]> wrote in message
>>> 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.
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
>> 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'.
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
> 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?
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'...
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
> 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
This is not a matter of 'optimization' but about avoiding unwarranted
-- "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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk