"Matthew Herrmann" <matthew.herrmann@zomojo.com> wrote in message news:4B9041F0.5020408@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