- Boost - lists.boost.org

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

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