Re: [boost] [program_options]

Subject: Re: [boost] [program_options]
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2010-03-05 03:37:48

"Matthew Herrmann" <matthew.herrmann_at_[hidden]> wrote in message 
news:4B9041F0.5020408_at_zomojo.com...
> Last I checked, boost::program_options took const char* in several places 
> where it would end up storing them as std::strings anyway. Taking "const 
> std::string&" would also clarify that passing temporary strings is fine, 
> whereas "const char*" as an arg hints to me that the pointers should remain 
> valid until options_description is destroyed (purely question of taste 
> though).
>
> I'd vote to replace const char* everywhere in the program options interface 
> with std::string. (excluding the "char* argv[]" of course)

That would cause an additional memory allocation for every call that takes a 
std::string const & and you pass a char const *...unless you are using an 
implicitly shared/internal refcounted std::string implementation...

The one allocation that is now reqired (what I gather from your post, as I did 
not look at program_options for quite some time), and all the exception 
throwing/handling that dynamic mem.alloc. entails, is also one-too-many IMO for 
cases where you know all of your options/strings at compile time and thus 
specify them directly with tchar const pointers...

I know of a Windows specific way for detecting whether or not a particular 
object is statically allocated (MSVC 7.1 and later provide a specifically 
trivial/cheap way of detecting that)...if a cross platform version of such a 
utility function could be made it could be used, internally in a library, to 
circumvent the dyn.mem.alloc issues in certain cases like these...

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