March 2004 - Boost - lists.boost.org

Standard C Library and C++ / BOOST
by Eljay Love-Jensen 26 Mar '04

26 Mar '04

Dear BOOST folks, Here's an recipe idea for a BOOST library: Take the Standard C Library. Create a new namespace, "boost::xtd::" for instance. For every function in the Standard C Library, create an analog in the "boost::xtd::" namespace. The analog function would have the same functional behavior as the StdCLib function, with the notable difference that any errors will generate an exception. Some of my projects here at work have done something similar, with a limited subset of C. That subset being only those handful of routine that we cared about. The value of having this in the BOOST repertoire: 1. a (BOOST) standard convention that would be the same for everyone 2. maybe it'd get folded into ISO/IEC 14882 at some future point 3. Standard C Library with C++ exceptions Example 18 header files being... <boost/xtd/stdio.hpp> <boost/xtd/stdlib.hpp> <boost/xtd/stddef.hpp> <boost/xtd/stdassert.hpp> <boost/xtd/time.hpp> <boost/xtd/errno.hpp> <boost/xtd/ctype.hpp> <boost/xtd/wtype.hpp> <boost/xtd/string.hpp> <boost/xtd/wchar.hpp> <boost/xtd/locale.hpp> <boost/xtd/limits.hpp> <boost/xtd/float.hpp> <boost/xtd/setjmp.hpp> <boost/xtd/signal.hpp> <boost/xtd/math.hpp> <boost/xtd/iso646.hpp> <boost/xtd/stdarg.hpp> Opinions of this idea merits being implemented? Does it sound appropriate for a BOOST library? Sincerely, John "Eljay" Love-Jensen Adobe Systems Incorporated

3 2

[program_options] simple question
by Neal D. Becker 26 Mar '04

26 Mar '04

So far I see examples where the result of using program_options parsers is to store something into a variable map. Is it possible to directly store results into variables? For example, assume: int main (int argc, char** argv) { double value = 10.; mythical_parser (...); }; How do I use program_options to set "value"? Any examples? So far the only way I know is: po::options_description desc("Allowed options"); desc.add_options() ("help", "produce help message") ("value", po::value<int>()) ; po::variables_map vm; po::store(po::parse_command_line(argc, argv, desc), vm); po::notify(vm); if (vm.count("value")) value = vm["value"].as<int>();

5 8

boost::bind and boost::lambda::bind
by Matthew Hurd 26 Mar '04

26 Mar '04

Got tripped up again today by boost::thread's boost::function constructor not working with boost::lambda::bind but working fine with boost::bind. Silly me. Been down that track before many moons ago... It is still a tad confusing, a unification would be nice sometime, but perhaps a note in the thread and/or function documentation in the meanwhile. Regards, Matt Hurd.

2 1

Question on DLL import/export
by Vladimir Prus 26 Mar '04

26 Mar '04

Reading http://www.boost.org/more/separate_compilation.html I see suggestion that all library sources start with: #define BOOST_WHATEVER_SOURCE #include <boost/whatever.hpp> Is there any particular reason why this define should be placed in source, and not in Jamfile for the library? E.g: dll boost_program_options : ...some sources... : <define>BOOST_PROGRAM_OPTIONS_SOURCE ..... ; - Volodya

2 1

RE: [boost] Re: Formal Review: Indexed Set
by Powell, Gary 26 Mar '04

26 Mar '04

I have been reading the code, and am working through the docs. I compiled and ran the examples with gcc 3.2. All compiled and ran as advertised. I did try with gcc 2.95.3 but it fails :< I have occasionally needed a container just like this one. So I am glad to see such a nice one being offered to boost. I made an earlier comment about operator== et.al. I don't think its worth holding up this change in attempt to get all the std::containers and boost containers to conform. I did complain about this with circular buffer but I've deleted the response. If no one else complains about this, I'll write a paper for the std committee for presentation in Redmond in Oct 2004. I don't see the harm in fixing containers as they are proposed to boost though. When we first wrote the VTL library we did this with no ill effects. I have not run any timing tests, of using this container vs using two (N) maps with links or whatever with pointers to the same data. A small nit, sequenced_index::remove and sequenced_index_remove should be called "erase". Its a small nit because they live in "details". But really they do erase. I like having index_fwd.hpp I wish all the std::containers had such a file. Also you should look at Dave Abraham's and my paper on Move semantics/copy construction vs Andrei's MOJO. IMO Its worth implementing. :> BTW, I also really like the example that uses boost::lambda to help set up the conditionals! And a plug for my library in no way influences my vote.. no sir yee, I'm totally impartial here... I vote to accept unconditionally. Yours, -Gary- PS Sorry to hear about your cat. I had one that only made it to 3 yrs, and that was hard to take. But cats gotta be cats.

2 1

[program_options] post-review version
by Vladimir Prus 26 Mar '04

26 Mar '04

The first post-review version of the program_options library is now available. I believe that all important interface changes are finished and would like to ask for feedback on the current version, before I go on. Some of the interesting changes include: - better way to describe option values - support for positional options - support for environment variables The library and documentation can be obtained at http://zigzag.cs.msu.su:7813/program_options The documentation can also be browsed online at http://zigzag.cs.msu.su:7813/program_options/html And the source can also be browsed online at http://zigzag.cs.msu.su:7813/repos/trunk/program_options Since the interface has changes quite a bit, the brief list of changes is included in docs, to help with migration. See http://zigzag.cs.msu.su:7813/program_options/html/ch01s04.html All comments are very appreciated. - Volodya

7 32

min/max again. opinions? speak now.
by Eric Niebler 26 Mar '04

26 Mar '04

I was hoping I'd be able to fix this once and be done with it, but alas it is not to be. I need to change my fix. The problem has been noted here already in the thread "std_min/std_max reference return value is problematic with boost::interval." Basically, the std_min/std_max helpers cannot be made to work on old compilers that cannot detect reference returns. I have to rip out std_min and std_max. If you want to make an unqualified call to min or max, the recommended way will be as follows: using std::min; min BOOST_PREVENT_MACRO_SUBSTITUTION ( a, b ); I have 2 questions: 1) Is this the best name for the macro? Perhaps people would prefer something shorter. I'm open to suggestions. 2) Is there anyone who wants me to hold off until they finish making some big check-in to avoid merge hell? If so, please contact me privately and we'll work out a schedule. Thanks. -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

Re: about license
by Alexander Terekhov 25 Mar '04

25 Mar '04

< I'll reply to the .user post here because .devel is much faster ;-) > Jonathan Arnold wrote: > > A little late to this license party, but I want to make sure I > know what it means: > > David Abrahams wrote: > > Marleny Rafferty <marleny(a)rafferty.net> writes: > > > >>Hi- > >> > >>I am considering using boost in my applications, but I have a question > >>about the boost license at http://www.boost.org/LICENSE_1_0.txt . It > >>says (edited) "Permission is hereby granted, free of charge, to ... > >>use [and] reproduce ... the Software". > >> > >>It also says that any derivative works must also have the same license > >>grant. > >> > >>If my application uses boost libraries unchanged, is it considered a > >>derivative work? > > > > Yes. Nope. It is considered a compilation (mere aggregation if you like) and only if the "distribution package" of the application includes the boost stuff (which is the case with things like templates). I presume "black box" type of usage according to boost's functional specs, of course. (no copying of protected elements[1] from boost into "your" code) http://www.digital-law-online.com/lpdi1.0/treatise27.html (see VI.D.4. Derivative Works and Compilations) > > > >>If so, does that mean that if I distribute my compiled software, I > >>must allow free of charge use and distribution? > > > > No, the license gives an explicit exemption for compiled code > > So if we use boost in our program: > > 1] If we sell it as a compiled program, we can retain our own license > > 2] If we sell it to a customer who wants the source code too, we have > to use the boost license, and thus the customer is free to give our > source code away at that point? Yes/Yes (lack of explicit distribution permission for derivative works aside for a moment). But only the portions that are truly derivative works of (in the sense of the copyright law) [and/or] original boost licensed work(s). IOW, all your non-derivative code is unconditionally[2] yours and you're free to distribute and license it on whatever terms you like (well, but you should better stick to lawful/enforceable terms, of course ;-) ). You might want to take a look at the CPL FAQ and perhaps also this: http://www.xfree86.org/pipermail/forum/2004-March/004248.html regards, alexander. [1] http://www.digital-law-online.com/lpdi1.0/treatise24.html [2] http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:7651

1 0

[Boost.Format] 64 bit failure test case
by Angus Leeming 25 Mar '04

25 Mar '04

This test code aborts at run time when compiled against version 1.31 of the boost libraries using g++ 3.3.3 on a Linux/Alpha machine (64bit architecture.). It also aborts at run time when compiled against current cvs. #include <boost/format.hpp> #include <string> #include <iostream> using std::string; string bformat(string const & fmt, string const & arg1) { return (boost::format(fmt) % arg1).str(); } int main() { std::cout << bformat("Creating directory %1$s and running configure...", "/home/foo/.bar") << std::endl; return 0; } I believe that I have tracked down the cause of the failure. Adding this patch to format/feed_args.hpp $ diff -u lyx/devel/boost/boost/format/feed_args_orig.hpp lyx/devel/boost/boost/format/feed_args.hpp --- lyx/devel/boost/boost/format/feed_args_orig.hpp 2004-03-24 15:13:50.000000000 +0000 +++ lyx/devel/boost/boost/format/feed_args.hpp 2004-03-24 15:10:59.000000000 +0000 @@ -162,6 +162,14 @@ static_cast<std::streamsize>(specs.truncate_ - !!prefix_space), oss_.pcount()); + std::cout << "std::numeric_limits<std::streamsize>::max() " << std::numeric_limits<std::streamsize>::max() << '\n' + << "specs.truncate_ " << specs.truncate_ << '\n' + << "!!prefix_space " << !!prefix_space << '\n' + << "static_cast<std::streamsize>(a - b) " + << static_cast<std::streamsize>(specs.truncate_ - !!prefix_space) << '\n' + << "oss_.pcount() " << oss_.pcount() << '\n' + << "res_size " << res_size << std::endl; + mk_str(res, res_beg, res_size, w, oss_.fill(), fl, prefix_space, (specs.pad_scheme_ & format_item_t::centered) !=0 ); } leads to the following output prior to the code aborting: $ ./trial std::numeric_limits<std::streamsize>::max() 9223372036854775807 specs.truncate_ -1 !!prefix_space 0 static_cast<std::streamsize>(a - b) -1 oss_.pcount() 14 res_size -1 Aborted specs.truncate_ is being initialised incorrectly in the format_item constructor because it is an int (sizeof(4)) whilst std::streamsize has sizeof(8) on the Alpha. FWIW, I attach the gdb backtrace also. Note the 'size == -1' in #9 of this backtrace. Hoping this all makes sense, Regards, Angus (gdb) where #0 0x00000200002384a8 in kill () from /lib/libc.so.6.1 #1 0x0000020000238224 in raise () from /lib/libc.so.6.1 #2 0x0000020000239bb0 in abort () from /lib/libc.so.6.1 #3 0x00000200000ff638 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5 #4 0x00000200000ff690 in std::terminate() () from /usr/lib/libstdc++.so.5 #5 0x00000200000ff82c in __cxa_throw () from /usr/lib/libstdc++.so.5 #6 0x0000020000098d30 in std::__throw_length_error(char const*) () from /usr/lib/libstdc++.so.5 #7 0x00000200000ed348 in std::string& std::string::_M_replace_safe<char const*>(__gnu_cxx::__normal_iterator<char*, std::string>, __gnu_cxx::__normal_iterator<char*, std::string>, char const*, char const*) () from /usr/lib/libstdc++.so.5 #8 0x00000200000e9a34 in std::string::append(char const*, unsigned long) () from /usr/lib/libstdc++.so.5 #9 0x0000000120008ec8 in void boost::io::detail::(anonymous namespace)::mk_str<char, std::char_traits<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, char const*, long, long, char, std::_Ios_Fmtflags, char, bool) ( res=@0x120025a58, beg=0x1200265e8 "/home/foo/.bar", size=-1, w=0, fill_char=32 ' ', f=4098, prefix_space=0 '\0', center=false) at feed_args.hpp:73 #10 0x0000000120008568 in void boost::io::detail::(anonymous namespace)::put<char, std::char_traits<char>, std::string const&>(std::string const&, boost::io::detail::format_item<char, std::char_traits<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, boost::io::basic_outsstream<char, std::char_traits<char> >&) (x=@0x11ffff950, specs=@0x120025a50, res=@0x120025a58, oss_=@0x11ffff738) at feed_args.hpp:165 #11 0x0000000120007544 in void boost::io::detail::distribute<char, std::char_traits<char>, std::string const&>(boost::basic_format<char, std::char_traits<char> >&, std::string const&) (self=@0x11ffff6e0, x=@0x11ffff950) at feed_args.hpp:241 #12 0x00000001200056c8 in boost::basic_format<char, std::char_traits<char> >& boost::io::detail::feed<char, std::char_traits<char>, std::string const&>(boost::basic_format<char, std::char_traits<char> >&, std::string const&) ( self=@0x11ffff6e0, x=@0x11ffff950) at feed_args.hpp:249 #13 0x0000000120003b0c in operator%<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > (this=0x11ffff6e0, x=@0x11ffff950) at format_class.hpp:61 #14 0x00000001200035f8 in bformat(std::string const&, std::string const&) ( fmt=@0x11ffff930, arg1=@0x11ffff950) at trial.C:11 #15 0x0000000120003748 in main () at trial.C:16

2 3

UnitTest/BOOST_CHECK_EQUALS always fails with Intel + C-strings
by Stefan Slapeta 25 Mar '04

25 Mar '04

BOOST_CHECK_EQUAL c style strings does not work on Intel if strings are passed in a buffer: char val[10]; strcpy(val, "test"); BOOST_CHECK_EQUAL("test", "test"); // ok BOOST_CHECK_EQUAL(val, "test"); // fails always The reason: void f(const char *, const char *) { } template <typename T1, typename T2> void f(const T1&, const T2&) { } int main() { char val[100]; strcpy(val, "test"); // Here is the difference to VC 7.1: // VC calls f(const char *, const char*) // Intel calls the function template f(val, "test"); } I would guess that Intel works correctly here as f(const char*, const char*) is no exact match for the arguments char[10], const char*. Any suggestions? Stefan *********************************** Stefan Slapeta Wien/Vienna, Austria http://www.slapeta.com

1 0