November 2011 - Boost - lists.preview.boost.org

[program_options] Improving error text in exceptions
by Leo Goodstadt 15 Nov '11

15 Nov '11

As a long time fan of boost::program_options, I would very much like to make the error messages in program_options exceptions more consistent and informative. Exception text is usually aimed at the developer as a diagnostic for rare errors. If the exception needs to be propagated to the end-user, it can be caught, and a more appropriate message substituted. This is not true for program_options: Exceptions from invalid program arguments are the common (and normal) reason for early program termination. It would be nice if, out of the box, exception text could be clear enough to present to the end user more or less as is. This would allow a single try/catch(exception) in main() cerr << "Error: " << e.what() << "\n"; return 1; >From the attached list of error messages, there are many, many different exception types which are thrown. The usual practice of repackaging / reformatting exceptions to be more user-friendly would be tedious or impractical. I grep-ed "boost::throw_exception" to get a list of all the exceptions and messages. I suggested revisions for all but 5. These I have set them aside at the end. I have modelled some of the proposed text on GNU genparse examples (i.e. the behaviour of "ls" and "cat" etc.). These, by dint of their frequent use / hammering by the huge linux user base, are probably good examples of the sort of friendlier clarity I would hope for. In some cases, I have tried to understand the exception text from the code but might have misunderstood the original intent. If this is useful, I shall painstaking go through the code and submit a patch. Leo Goodstadt P.S. I realise there are pitfalls to do with option prefix styles "--" and "/" but the addition of option prefixes to the exception text makes the message a lot clearer. P.P.S. I have kept the current style of starting the text in lower case even though my own preference would be for a capitalised sentence ending in a full stop. ======================================================= Original (CURRENT) and revised (CHANGED) text resulting from exception.what() ======================================================= CURRENT: <ambiguous option option_name> CHANGED: <option '--option_name' is ambiguous and matches options "--aa"," --b" and "--c".> // abbreviated instead of long/short because // length might imply too many/few letters CURRENT: <style disallows parameters for long options> CHANGED: <arguments are not allowed for unabbreviated option names> CURRENT: <style disallows parameters for short options> CHANGED: <arguments are not allowed for abbreviated option names> CURRENT: <style disallows all characters for short options> CHANGED: <abbreviated option names are not valid> CURRENT: <adjacent parameter is empty> CHANGED: <Invalid command line syntax: each option with an equal sign must be followed immediately by its argument.> CURRENT: <parameters adjacent to long options not allowed> CHANGED: <arguments are not allowed for unabbreviated options> CURRENT: <required parameter is missing in 'option_name'> CHANGED: <option '--option_name' requires an argument> CURRENT: <in option 'option_name': invalid option value> CHANGED: <invalid argument for option '--option_name'> CURRENT: <unrecognised line in 'DODGY LINE'> CHANGED: <options configuration file contained an invalid line: 'DODGY LINE'> CURRENT: <multiple occurrences> CHANGED: <option '--option_name' cannot be specified more than once> CURRENT: <can not read file NON_EXISTENT_FILE_NAME> CHANGED: <cannot read options configuration file 'FILE_NAME'> CURRENT: <missing required option required_option> CHANGED: <option '--option_name' is required> CURRENT: <too many positional options> CHANGED: <too many positional arguments have been specified> CURRENT: <unknown option unknown_option> CHANGED: <unrecognised option 'option_name'> CURRENT: <in option 'invalid_option': invalid bool value> CHANGED: <at least one argument is required for option '--option_name> CURRENT: <in option 'option_name': invalid bool value> CHANGED: <invalid argument for option '--option_name'. Valid arguments are 'on|off', 'yes|no', '1|0' and 'true|false'> CURRENT: <in option 'option_name': multiple values not allowed> CHANGED: <option '--option_name' only takes a single argument> Not sure what these mean and have left them alone. libs/program_options/src/parsers.cpp:112: boost::throw_exception(error("long name required for config file")); libs/program_options/src/config_file.cpp:60: boost::throw_exception(error("bad prefixes")); libs/program_options/src/value_semantic.cpp:102: boost::throw_exception(multiple_values()); libs/program_options/src/convert.cpp:66: boost::throw_exception(std::logic_error("character conversion failed")); libs/program_options/src/convert.cpp:74: boost::throw_exception(std::logic_error("character conversion failed")); libs/program_options/src/value_semantic.cpp:33: boost::throw_exception(std::runtime_error("UTF-8 conversion not supported.")); -- Dr. Leo Goodstadt University of Oxford United Kingdom

2 1

[Serialization] Proposal for TR2
by Ruediger Berlich 15 Nov '11

15 Nov '11

Dear Robert, dear all. from what I understand, Boost.ASIO has been proposed for TR2 quite a while ago. Since I use ASIO and Boost.Serialization quite a bit and feel that both strongly benefit from each other (and not only ASIO -- see e.g. Boost.MPI), are there any efforts to make Boost.Serialization part of TR2 ? We live in the era of cloud computing and networked execution. Without this facility, C++ will have a hard time to compete. And Boost.Serialization is established and mature (thanks, Robert!). Best, Ruediger

3 2

[context] ready
by Oliver Kowalke 14 Nov '11

14 Nov '11

Hi, https://github.com/olk/boost.context.git contains the new version of boost.context (docu at http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html) Any comments are welcome - in the meantime I'm awaiting Giovanni's OK for the mini-review. regards, Oliver

8 15

Boost.Local Review (Nov 10, 2011 to Nov 19, 2011) by Krzysztof Czaiński
by Krzysztof Czainski 14 Nov '11

14 Nov '11

Hello, About me: I write C++ apps and RTS, mostly for embedded devices. I often use complicated C++ structures, and of course boost. Boost.Local caught my interest, so I decided to review it. I intend to try to use this library on MinGW-4.5, and on a Texas Instruments/DSP compiler, however I can't do that this week, so I won't make it until the end of this review. I studied the docs in depth. I state my comments below. Each of my comments is numbered in the style (0), so they can be referenced. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… : Variable Binding: [quote] programmers might want to bind variables of complex types by (constant) reference instead than by value [/qoute] (1) s/instead than/instead of/ Binding the Object this: [quote] It is also possible to bind the object this when it is in scope (e.g., from an enclosing non-static member function). This is done by using this as the name of the variable to bind in the local function declaration and by using the special symbol this_ (instead of this) to access the object within the local function body. [/qoute] (2) Why not use this_ in both places? Local Blocks: (3) How is a Local Block better then just an ordinary C++ block: {}? So far, I have an idea of what such a Local Block is for, but a reference to a rationale at this point in the tutorial would be nice. Local Exits: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. [16] [/qoute] (4) To me this note requires more explanation. Consider three examples: (4a) [code] int main() { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } // Local exit executed here. [/code] (4b) [code] int main() { try { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } catch ( ... ) {} } // Local exit executed here. [/code] (4c) [code] int main() { try { throw 0; BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END } catch ( ... ) {} } // Local exit executed here. [/code] I which of the abouve examples is printing "hello" guaranteed? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… : Assigning Local Functions: (5) In the example, variables named "l" (lowercase L) are used, which is easy to confuse with "1" (one), and therefore the example is hard to read. I suggest renaming that variable. Deducing Bound Types (concepts, etc): [qoute] it will also be a reference is the variable is bound by reference [/qoute] (6) typo: is -> if Inlining Local Functions [qoute]On C++03 compliant compilers, inlined local functions always have a run-time comparable to their equivalent implementation that uses local functors (see the Alternatives section). However, inlined local functions have the limitation that they cannot be assigned to other functors (like boost::function) and they cannot be passed as template parameters. [21] On C++11 compilers, inline has no effect because this library will automatically generate code that usesC++11 specific features to inline the local function calls whenever possible even if the local function is not declared inlined (unless the BOOST_LOCAL_CONFIG_COMPLIANT configuration macro is defined). Furthermore, non C++11local functions can always be passes as template parameters even when they are declared inlined.[/quote] (7) I read this paragraph four time, and still don't get it. Please rephrase is somehow ;-) (8) After reading the Introduction, Getting started, Tutorial and Advanced topics I still don't have an overview of the overhead, memory allocations, and exceptions that Local constructs can cause. Please add this information. Right now, I can deduce this information from the Implementation section. However, could things like lack of memory allocations or not emitting exceptions be promised in the public interface? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics). [/quote] (9)What are: the overhead, possible memory allocations, and exceptions, that Local constructs can cause? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [quote]If programmers leave this configuration macro undefined, its default value is to be left not defined.[/qoute] (10) What does it mean "its default value is to be left not defined"? Does it mean, that whether it's defined or not depends on the library, which tries to guess if the compiler supports variadic macros? [quote]If this macro is defined, variadic macros and empty macro parameters are not used by this library. Using variadic macros and empty macro parameters allows this library to provide the variadic macro and empty macro syntaxes which some programmers might find more readable than the sequencing macro syntax (see the Tutorial section, BOOST_LOCAL_FUNCTION_PARAMS, BOOST_LOCAL_BLOCK, and BOOST_LOCAL_EXIT). If this configuration macro is defined then only the sequencing macro syntax is allowed (regardless of whether the compiler supports variadic and empty macros or not).[/quote] (11)This paragraph is a bit unclear: first it says what happens if this macro is defined, then it says why variadic macros are useful, and lastly is says again what happens when this macro is defined. I suggest to make two paragraphs: first: state clearly what this macro does - disables the use of variadic macros, and second: comment on why variadic macros are useful. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/qoute] (12) Notes (4) and (9) apply here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/quote] (13) Note (9) applies here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: (14) What about the typename keyword inside templates? I think i remember from the previous sections, that typename is not required, but that information is missing here. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… Description: [qoute]For example, if the expression type is know (and contains no commas)[/quote] (15) typo: know -> known This concludes my study of the docs, and I won't be able to try to use this library before the end of this review, so I state my conclusions now. 2011/11/10 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> > Please state clearly whether you think this library should be accepted as a > Boost library. > Yes. Other questions you may want to consider: > > - What is your evaluation of the design? > I like it. > - What is your evaluation of the documentation? > I enjoyed reading it, and I think it gave me a pretty good idea about the library. > - What is your evaluation of the implementation? > >From what I read in the Implementation section of the docs, looks reasonable. > - What is your evaluation of the potential usefulness of the library? > I can imagine it would improve readability of some of my code. > - Did you try to use the library? With what compiler? Did you have any > problems? > No. I intend to, but not until the end of this review. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > In-depth study of the docs. > - Are you knowledgeable about the problem domain? > Hmm... I'll just say, I miss something like this for most of my 3-year experience of C++ programming. Please also consider the following issues and proposals specific to > Boost.Local. Your opinion is welcome on any or all of these. > > - Boost.Local's local exits provide the same functionality (and then some) > as Boost.ScopeExit. Does this duplication of functionality need to be > dealt with, and if so, how? I haven't used ScopeExit, so I don't have an opinion on this. - Lorenzo is proposing to add boost::local::function::overload to > Boost.Function as boost::function::overload. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… I don't remember missing such a utility in my experience, but it seems reasonable to add it to boost function. However, I don't understand, how can it be added as boost::function::overload, when boost::function is a class template? > - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… > - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to > boost/utility. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… > I don't remember missing any of the above in my experience. One of "more readable alternatives" described in the docs have sufficed. Thanks in advance to all who participate in the review discussion; I'm > looking forward to it! > > - Jeffrey Hellrung (Review Manager) > - Gregory Crosswhite (Review Assistant) This was my first review, and I hope it's useful ;-) Regards, Kris

3 3

Need for BOOST_PP_VARIADIC_POP_FRONT
by Gennadiy Rozental 14 Nov '11

14 Nov '11

Hi, I consider using Boost.PP variadic macros support, but I seems to be missing subject macro (with support for zero arguments). Any chance we can one? I'd hate to reinvent the wheel. Regards, Gennadiy

4 16

1.48 is another release without the logger
by Jeff Graham 14 Nov '11

14 Nov '11

Hello, Any progress on the logger?

2 1

Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Lorenzo Caminiti 14 Nov '11

14 Nov '11

Hello all, I have received a couple of questions on Boost.Local and I will answer them on the ML. On Mon, Nov 14, 2011 at 4:20 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > 1. Can Boost.Local be used to create global functions? No, Boost.Local macros need to be used at local scope. If it were important to use the functionality of Boost.Local at global scope, it _might_ be possible to do so but another set of macros (BOOST_GLOBAL_?) will have to be defined for that. Does anyone see a need to use LOCAL_EXIT, LOCAL_BLOCK, or LOCAL_FUNCTION at global scope? If so, why? > 2. For Local Exits, is it possible not to bind any variable (because I will > only be calling global functions): > > int runCommand() { > ::DisplayWaitCursor(); > BOOST_LOCAL_EXIT( /*nothing*/ ) { > ::DisplayNormalCursor(); > } BOOST_LOCAL_EXIT_END; > > DoALongLastingOperation(); > } Yes, you can do this. However, the most portable syntax is to use void for the empty parameter list: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… For example: #include <boost/local/exit.hpp> #include <iostream> void f() { std::cout << "f" << std::endl; } int main() { ::f(); BOOST_LOCAL_EXIT(void) { ::f(); } BOOST_LOCAL_EXIT_END return 0; }; This compiles and it prints "f" twice (at main entry and exit). HTH, --Lorenzo

1 0

[1.48][flyweight] regression in release branch
by JOAQUIN M. LOPEZ MUÑOZ 13 Nov '11

13 Nov '11

Hi, Sorry for not having tracked this before. There's a trivial regression in Boost.Flyweight due to a change of namespace name in Boost.Interprocess: https://svn.boost.org/trac/boost/changeset/75464 OK to commit to branch? Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

2 2

[iostreams][io_state_savers] Request for interest in some ios_base basic utilities
by Vicente J. Botet Escriba 12 Nov '11

12 Nov '11

Hi, I'm a beginner of the standard IOStream library. While restructuring Boost.Chrono I/O I have find some classes that could be of general use (if the design is correct, of course). The first one is quite simple, is used to define manipulators with parameters. Instead of defining a class and the correspondent stream inserters and extractors the manip template class do all this at once. It can be used as follows class mendl: public manip<mendl> { public: explicit mendl(size_t how_many) : count(how_many) {} template <typename out_stream> void operator()(out_stream &out) const { for (size_t line = 0; line < count; ++line) { out.put(out.widen('\n')); } out.flush(); } private: size_t count; }; Now mendl can be use to insert n new lines at once as follows cout << mendl(3); The second one is an ios specific smart pointer ios_base_state_ptr (based on the use of ios_base::pword and ios_base::xalloc). The class ios_base_state is a ios_base_state_ptr that can not be null. It can be used like struct MyData { std::string time_fmt; std::string duration_fmt; }; std::string get_time_fmt(std::ios_base & ios) { return ios_base_state<MyData>(ios)->time_fmt; } ios_base_state stores a new MyData in the ios if not already stored and provides an smart pointer interface to it. The 3rd one (ios_base_flags) uses the ios_base::iword and xalloc to provide access to specific ios flags. It can be used as follows: class fmt_masks : ios_base_flags<fmt_masks> { typedef ios_base_flags<fmt_masks> base_type; public: fmt_masks(std::ios_base& ios): base_type(ios) {} enum type { uses_symbol = 1 << 0, uses_local = 1 << 1 }; }; Usage of this class can be duration_style::type get_duration_style(std::ios_base& ios) { return (fmt_masks(ios).flags() & fmt_masks::uses_symbol) ? duration_style::symbol : duration_style::prefix; } The interface and the implementation of these classes is attached. Do you see a design flag on these classes? If not, do you think these kind of utilities could be added to boost? If yes, could these be merged with Boost.io_state_savers or Boost.IOStreams to form a larger io utilities libraries? Best, Vicente

3 14

Are some of the trunk regression tests running in C++0x mode when they shouldn't be?
by Richard Webb 11 Nov '11

11 Nov '11

Looking at the Trunk regression tests, it appears that some of the GCC tests are running in C++0x mode when they shouldn't be. for example: Large numbers of the Sandia-gcc-3.4.6 tests are failing with the error: unrecognized command line option "-std=c++0x" If you look at the test results for assign, there are rvalue-reference related errors in toolsets which shouldn't have them. Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it? Thanks, Richard Webb

7 10