- Boost - lists.boost.org

RE: errorcheck
by Reece Dunn 27 Mar '04

27 Mar '04

Eljay Love-Jensen wrote: >Hi Reece, > >Cool! I think I'll add that to my repertoire. Glad you like it :). >A slight tweak, and it can ignore the passed in value, and peep at errno. >I'd call that "errnocheck" (or errnoCheck ... my orthographical standard). Sure. The class I posted is an adaption of com::result that deals with Windows/COM HRESULT error handling that simplifies COM object usage. It may be possible to use a policy-based approach, something like: struct DefaultCheck { static bool IsError( int err ) { return( err < 0 ); } }; struct ErrNoCheck { static bool IsError( int err ) { return( errno < 0 ); // ??? } }; struct HRESULTCheck { static bool IsError( HRESULT hr ) { return( FAILED( hr )); } }; template< class ErrorPolicy = DefaultCheck, typename T = int > class errorcheck { public: inline errorcheck( T e ): error( e ) { if( ErrorPolicy::IsError( e )) throw( *this ); } // ... }; // example usage: errorcheck<> error; error = open( ... ); // ... errorcheck< ErrNoCheck > en; en = std::sin( -1 ); errorcheck< HRESULTCheck, HRESULT > hr; BSTR str; hr = pStyle -> get_color( &str ); or maybe to have extended information, so you could use something like: error( open( ... ), "open" ); en( ::sin( -1 ), errno ); en( ::cos( 0 )); // use errno by default Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Re: [boost] Re: Naming Issues [part of Formal Review: Indexed
by Dave Gomboc 26 Mar '04

26 Mar '04

> The standard may have made a mistake. It's fairly easy to > swallow "multixxx" but when there are more x's it gets much harder. Multigraph, multitask, multihyphenate, multimethod, etc. -- I think it's normal. Dave

3 2

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