- Boost - lists.boost.org

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

[program_options] good work
by Neal D. Becker 25 Mar '04

25 Mar '04

I am really excited to see program_options progress. From my limited testing so far it looks really good, and I have been looking forward to using it in my code. I hope we can add it to boost soon, because I'm reluctant to rely on unreleased boost code. The doc needs work. It was hard for me to find the doc for the function parse_environment for example. There needs to be links from the top-level html page. Also, how can I build the html docs myself from the distributed xml? It looks like I need the "boost v2" build stuff, but I don't know what that means.

2 5

[Threads] Much faster try_mutex on Windows NT
by Adal Chiriliuc 25 Mar '04

25 Mar '04

Hello. try_mutex uses a Mutex instead of a CRITICAL_SECTION because on Windows 9x and Me it's impossible to try the aquisition of a CRITICAL_SECTION. On Windows NT/2000/XP this is possible, using the function TryEnterCriticalSection. So I suggest this: choose at runtime what syncronization primitive to use based on the running OS. CRITICAL_SECTIONS are much faster and since Windows NT is gradually replacing Windows 9x systems I think it is good to use this feature. A sketch follows. ---------- mutex.cpp ----------- namespace { bool g_Init = false; bool g_UseTryCritical; TryCriticalProcType g_TryCritical; void TryCriticalInit() { g_Init = true; g_UseTryCritical = false; get windows version; if (!windows nt) return; lib = load library (kernel32.dll); g_TryCritical = get proc address (lib, TryEnterCriticalSection); g_UseTryCritical = true; } } try_mutex::try_mutex() { if (!g_Init) TryCriticalInit(); if (g_UseTryCritical) { try { m_mutex = reinterpret_cast<void*>(new CRITICAL_SECTION); } catch (...) { } } else { m_mutex = reinterpret_cast<void*>(CreateMutex(0, 0, 0)); } if (!m_mutex) throw thread_resource_error(); if (g_UseTryCritical) InitializeCriticalSection(reinterpret_cast<LPCRITICAL_SECTION>(m_mutex)); } bool try_mutex::do_trylock() { if (g_UseTryCritical) { return g_TryCritical(reinterpret_cast<LPCRITICAL_SECTION>(m_mutex)) != 0; } else { unsigned int res = 0; res = WaitForSingleObject(reinterpret_cast<HANDLE>(m_mutex), 0); assert(res != WAIT_FAILED && res != WAIT_ABANDONED); return res == WAIT_OBJECT_0; } } ---------- mutex.cpp ----------- There is only one potential problem: if (!g_Init) TryCriticalInit(); might not be thread safe. Something like a thread safe singleton might be needed. Or maybe we could use InterlockedExchange & co. I'm not sure if timed_mutex could also benefit from this. In the docs you should explain what joining means. I worked a lot with threads in the past, but I've never heard of such a concept. I had to look through the source codes to understand what join means. Many Win32 developers will not know of concepts not covered by the Platform SDK. You do explain that conditions are some sort of events, but you use joining in sample code without explaining what it does. Regards, Adal Chiriliuc

7 13