March 2004 - Boost - lists.boost.org

RE: [boost] Standard C Library and C++ / BOOST
by Reece Dunn 28 Mar '04

28 Mar '04

Klaus Nowikow wrote: >Reece Dunn wrote: >[snip] > > A trick I use when handling HRESULT error codes is to have a > > class like this > > (adapted for int error type): > > > > class errorcheck > > { >[snip] > > public: > > inline errorcheck( int ec ): error( ec ) > > { > > if( ec < 0 ) throw( *this ); > > } > >Careful. Throwing an exception from a constructor >means that the object won't be constructed (i. e., does not exist). >So you are throwing a non-existing object here. > >Or am I wrong? If I've got the standard correct, the object will be partially constructed up to the point where the exception is thrown. Thus, if this throws an exception, the error member will be set. If you had: struct test { errorcheck ec; std::string msg; test(): ec( -1 ), msg( "hello" ) { } }; an exception will be generated before the msg string is set and thus test would be invalid. However, I use it like: class myfile { ... myfile( const char * fn ) { errorcheck ec = open( fn, ... ); } ~myfile() { close( ... ); } }; where because the file is not opened if an exception is thrown above, it will not call the destructor to close a non-opened file. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

3 2

Is there any mirrors of boost?
by 胡香冬 28 Mar '04

28 Mar '04

I cannot access www.boost.org, :(

2 1

Re: [boost] Re: Formal Review: Indexed Set
by JOAQUIN LOPEZ MU?Z 27 Mar '04

27 Mar '04

Hi Joerg ----- Mensaje original ----- De: jhr.walter(a)t-online.de (Joerg Walter) Fecha: Sábado, Marzo 27, 2004 6:44 pm Asunto: Re: [boost] Re: Formal Review: Indexed Set > > OTOH it might be surprising to search for the components of one > library in > different namespaces. Yes, probably indexed_set should live in boost::container::whatever with the rest of associated components, and additionally, be lifted to boost or boost::container. > > Two more remarks: > > 1. Documentation > > My linux browser (konqueror) has difficulties to correctly display the > indexed_set documentation. HTML tidy shows a couple of problems. Please send them to me privately and I'll try to fix them. > > 2. Performance test > > Compiling the performance tests with ICC 8.0 uncovered a problem in > indexed_set.hpp: > > 67,69c67,69 > < template <typename,typename,typename,typename> friend class > detail::index_base; > < template <typename,typename> friend class > detail::header_holder; > < template <typename,typename> friend class > detail::converter; > --- > > template <typename,typename,typename> friend class > detail::index_base;> template <typename,typename> > friend class > detail::header_holder; > > template <typename,typename> friend class > detail::converter; There's an extra typename in the friend declaration for index_base, right? I wonder how this splipped through unnoticed for so long. I'll fix it, thanx for the tip. > Test results for GCC 3.3.2 > > 1 regular index > 10^3 elmts: 141.24% > 10^4 elmts: 147.67% > 10^5 elmts: 152.57% > space gain: 100.00% > 1 sequenced index > 10^3 elmts: 154.99% > 10^4 elmts: 157.43% > 10^5 elmts: 153.71% > space gain: 100.00% > 2 regular indices > 10^3 elmts: 108.23% > 10^4 elmts: 124.78% > 10^5 elmts: 121.79% > space gain: 90.00% > 1 regular index + 1 sequenced index > 10^3 elmts: 123.96% > 10^4 elmts: 137.12% > 10^5 elmts: 145.98% > space gain: 87.50% > 3 regular indices > 10^3 elmts: 100.11% > 10^4 elmts: 119.70% > 10^5 elmts: 129.12% > space gain: 86.67% > 2 regular indices + 1 sequenced index > 10^3 elmts: 99.25% > 10^4 elmts: 113.62% > 10^5 elmts: 116.37% > space gain: 84.62% > > Test results for ICC 8.0 > > 1 regular index > 10^3 elmts: 105.45% > 10^4 elmts: 106.74% > 10^5 elmts: 105.98% > space gain: 100.00% > 1 sequenced index > 10^3 elmts: 112.29% > 10^4 elmts: 112.20% > 10^5 elmts: 111.43% > space gain: 100.00% > 2 regular indices > 10^3 elmts: 63.17% > 10^4 elmts: 67.35% > 10^5 elmts: 71.65% > space gain: 90.00% > 1 regular index + 1 sequenced index > 10^3 elmts: 65.19% > 10^4 elmts: 69.00% > 10^5 elmts: 72.62% > space gain: 87.50% > 3 regular indices > 10^3 elmts: 49.76% > 10^4 elmts: 57.97% > 10^5 elmts: 60.94% > space gain: 86.67% > 2 regular indices + 1 sequenced index > 10^3 elmts: 49.07% > 10^4 elmts: 52.71% > 10^5 elmts: 51.55% > space gain: 84.62% > > I don't have an explanation for the difference. > How have you compiled the performance test in GCC? Maybe you forgot to turn on optimization flag -O3. The library has a jamfile that builds all the test, examples and the eprformance test, if you use this the performance program should compile in release mode. I except performance results to be roughly the same as with GCC 3.3.1, which I measured in my performance section. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

RE: [boost] errorcheck (was Standard C Library and C++ / BOOST)
by Reece Dunn 27 Mar '04

27 Mar '04

Thorsten Ottosen wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> wrote in message > > > A trick I use when handling HRESULT error codes is to have a class like >this > > (adapted for int error type): > >Maybe you should start on such a small helper library and submit it? I have attached what I have so far. It is a policy-based approach that allows you to specify the error type/check mechanism and a message holder. It also fixes the throw on constructor problem mentioned by others. e.g. try { boost::errorcheck<> ec = 7; ec = -1; std::cout << "Hello\n"; } catch( boost::errorcheck<> ec ) { std::cout << "error: check failed" << '\n'; } output ==> error: check failed If you want to note the function called from, like in Volodya's examples, you can use: typedef boost::errorcheck< boost::policy::error_storage<>, boost::policy::errormsg_storage > msgerrorcheck; try { msgerrorcheck em; em( "open" ) = -1; em( "write" ) = 3; } catch( msgerrorcheck em ) { std::cout << "error: " << em.get_msg() << '\n'; } output ==> error: open This is a slightly different syntax, but gives what is intended. NOTE: I have not yet provided an errno class, but it should not be difficult to do. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

Bug in Date_Time library + Patch
by Frank Wolf 27 Mar '04

27 Mar '04

Hi all! While adding some additional functionality to the Date_Time library I've found a minor bug in it: According to the documentation the contructor of the "ptime" type also accepts a special value but this overloaded constructor is missing in the library code. I've made this trivial fix and attached a patch file... Regards, Frank

2 2

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

27 Mar '04

>Hi Gary, thanks for reviewing the library! You are welcome. It's always a pleasure to see another cool library. >Have you looked at the performance section? No, will do soon. >Umm... Sequenced indices are modelled after std::list, which >contains both erase and remove operations, with different >semantics (remove meaning erasing *all* elements with a given >value.) yeah but vector, does a "move"... blech.. its in the details section, do what you want. >If you still have time to devote to the library, please >please take a look at the review notes on naming and >header organization and cast your opinions: >http://groups.yahoo.com/group/boost/files/indexed_set_review_notes.html Namespace: I like boost::container::multi_indexed_sets But I could live without the "::container". I'm not crazy about lifting the namespace into boost. I foresee that boost is going to get cluttered so some organization early will help. "mix" hits my pun loving funny bone, hence it shouldn't be used! Besides "mix_in" has a different meaning and will confuse people. I don't have to type the name of the container very often in comparison to everything else so a clear name is worth a few extra characters. Regular indices: I like "ordered indices" as it says what they are. I hate writing documentation when readinghte code explains everything clearly. Index names: ordered_unique ordered_non_unique They say what they do. Always good for self docuementing code. "set_like" sounds so 90's teenage talk... "whatever.." Nth_index_type & family. Yeah, I'd like to see the _type dropped. If you have to have a unique name, "_t" is ok, but still sucks. Header Organization: The only reason for omitting dependant headers is if they are not "dependent." I.e. that you need the sub header for accessing the container, but the primary header is all that is needed to declare the container. Otherwise include everything that is required. (IMO) >> 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. >Thanks. First time I had an animal companion in decades, >so I wasn't prepared for this sense of loss. BTW, once some time has passed, get another one. There are plenty of nice ones that need a home. Least ways there are always a heap of cats in the pound. They are never the same but each has been worth it. -Gary-

3 3

Re: [program_options] good work
by Hagen Moebius 27 Mar '04

27 Mar '04

Hi list, > Thanks for your encouragement! I, too, hope that the library will be added > to CVS soon -- the only issue that was specifically requested as needed > before inclusion is Unicode support. I've already made up my mind how to > best add it, but it might take a couple of weeks to discuss the approach > and really implement it. At this point I would like to state a question I have since some time. How is a boost library supposed to implement unicode support? There seems to be no Unicode support in the whole STL standard and not in boost either, except for the wide character support which as far as I know is limited to UCS-2 (or does it allow UCS-4?) Anyway, with linux, the most common unicode system is UTF-8. And I can seem to find any library or functionality in any way to support this (world-wide) accepted approach. Now, I wouldn't like to support the UTF-8 idea but it is impossible for a unix/linux developer to do something meaningful withou doing it some unicode way. So, what is the boost approach to undicode? Thanks and regards ... Hagen M.

2 1

Moving tss changes from thread_dev branch to HEAD
by Michael Glassford 27 Mar '04

27 Mar '04

The thread_dev branch in CVS contains a number of changes to the thread_specific_ptr / tss implementation that I would like to move to the main branch. I plan to look at it more carefully before I do so, but will anyone interested please take a look at the implementation on the thread_dev branch to see if has any problems (or if there are known problems that it doesn't fix)? It contains changes to fix a number of issues with the current implementation, including, among others: 1) thread_specific_ptr::reset() doesn't check error: http://lists.boost.org/MailArchives/boost/msg55713.php. 2) Double deletes: http://lists.boost.org/MailArchives/boost/msg50266.php, http://lists.boost.org/MailArchives/boost/msg50543.php, http://lists.boost.org/MailArchives/boost/msg30433.php, http://lists.boost.org/MailArchives/boost-users/msg05531.php. 3) Not enough tss keys/slots: http://lists.boost.org/MailArchives/boost/msg55376.php, http://lists.boost.org/MailArchives/boost/msg55712.php. 4) Ability to register custom cleanup functions. For reference, see: tss.hpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/boost/thread/t… tss.cpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/thread/sr… threadmon.cpp, http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost/boost/libs/thread/sr… Mike

3 8

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