Boost C++ Libraries: Ticket #4142: Option names should be constructible from strings

anonymous — Mon, 26 Apr 2010 06:26:49 GMT

Here is one problem. Lets look at the following declaration:

options_description_easy_init::operator()(const char* name,
                                          const value_semantic* s,
                                          const char* description);

Note that you can't replace it with

options_description_easy_init::operator()(const std::string& name,
                                          const value_semantic* s,
                                          const std::string& description);

because the latter is not exception-safe due to unspecified order of arguments' evaluation.

Vladimir Prus — Mon, 26 Apr 2010 12:53:54 GMT

I am not sure I follow what exception safety issues are there? It's only possible to leak 's' when ctor of std::string throws, which can happen only in 'out of memory' condition, and I'm not sure I care much about that use case -- especially for a library that parses program's command line.

anonymous — Tue, 27 Apr 2010 11:09:01 GMT

Replying to vladimir_prus:

I am not sure I follow what exception safety issues are there? It's only possible to leak 's' when ctor of std::string throws,

Yes, that's what I meant.

which can happen only in 'out of memory' condition, and I'm not sure I care much about that use case -- especially for a library that parses program's command line.

It is hard to argue against such reasoning. Don't forget that B.PO parses not only command line now.

Sat, 01 Oct 2011 13:05:15 GMT

Instead of std::string, you could use a template function and use data() and size() member functions of the passed in argument. Or, better yet, support a str_ref class (not yet available in Boost).