Re: [boost] [filesystem] temp_dir_path()

Subject: Re: [boost] [filesystem] temp_dir_path()
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2010-10-23 12:09:11

"Beman Dawes" <bdawes_at_[hidden]> wrote in message
news:AANLkTinFigAxpqkbgwQCnOXrr-Jg44=_dep1QWn+hy-Z_at_mail.gmail.com...
> On Tue, Oct 19, 2010 at 3:35 AM, Domagoj Saric <dsaritz_at_[hidden]> wrote:
>> Would it be perhaps possible to provide a lower-level function (even in 
>> the detail namespace) that uses a plain char buffer and an error code, 
>> that is free of std::vectors, std::strings, boost::paths, 
>> system::error_codes and
>> other things one might not want to pay for (especially if one does not 
>> use them otherwise) just to make a system API call..? The 'proper' 
>> version can then wrap the thinner one...
>
> It would be technically possible, of course, but ...
>
> What you are really asking for, I think, is a C language interface or
> something pretty close to that.

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 is wrong 'morally' because it is guilty of the typical 'premature 
pessimization' that feeds the typical anti C++ and anti Boost 
arguments...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?'

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

> I could have designed the library that way, but didn't want to add a
> third way for users to do things, and didn't want to take on the
> increased documentation, test, etc, workload.

Calling it a 'third way' is bit too hard IMO, why not think of it just as an 
overload (albeit of a more extreme kind)?

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