Re: [boost] [filesystem] temp_dir_path()
"Beman Dawes" <bdawes@acm.org> wrote in message news:AANLkTinFigAxpqkbgwQCnOXrr-Jg44=_dep1QWn+hy-Z@mail.gmail.com...
On Tue, Oct 19, 2010 at 3:35 AM, Domagoj Saric <dsaritz@gmail.com> 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
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
"Marsh Ray" <marsh@extendedsubset.com> wrote in message news:4CC31E3C.1030400@extendedsubset.com...
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.
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
participants (3)
-
Domagoj Saric -
Domagoj Saric -
Marsh Ray