- Boost - lists.boost.org

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

30 Mar '04

>From: Rob Stewart <stewart(a)sig.com> >From: "Reece Dunn" <msclrhd(a)hotmail.com> > > So the errorcheck object will be in a half-constructed state. That is, >the > > int will be constructed, but the errorcheck object isn't, therefore the > > int's destructor will be called, but errorcheck's deconstructor will >not. > > > > The solution would therefore be to throw an intermediate object, like >the > > Trules from the C++ Templates book by David Vandervoorde and Nico >Josuttis. > > This would then get around the throwing in a constructor problem. >Why not throw a new errorcheck object using a private ctor that >stores but doesn't check the return value? That would work (I realised an implementation after the post). But this is what I was trying to achieve using the copy constructor (and copy assignment), since that copies the object, but does not throw on failure. The errorcheck class now has a policy-based implementation, so it would look something like: template< typename ErrorStorage, typename ErrorMsgStorage > class errorcheck: public Storage, public MsgStorage { private: inline errorcheck( const Storage & s, const MsgStorage & ms ): Storage( s ), MsgStorage( ms ) { } public: inline errorcheck( typename Storage::error_type e ): Storage( e ), MsgStorage() { if( failed()) throw( errorcheck< Storage, MsgStorage >( *this, *this )); } }; which, IMHO, is more confusing than the straight throw( *this ), but does not use the copy constructor, relying instead of the fully constructed Storage and MsgStorage base classes. Regards, Reece _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

2 1

RE: [boost] Region Library?
by Powell, Gary 30 Mar '04

30 Mar '04

2D games do this all the time. It's more than a OS problem. -Gary- -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Allan Odgaard Sent: Tuesday, March 30, 2004 11:04 AM To: boost(a)lists.boost.org Subject: [boost] Region Library? A region is used as the term to describe a set of rectangles -- e.g. could be as simple as std::vector<rectangle>. When working with regions, one often needs to perform various operations like finding the intersection of two regions, the union, subtract one region from another or xor two regions (which is the union minus the intersection). I would like to know if there is a) any interest in such a library and/or b) if such a library already exists? I figure the usefulness of such a library mostly has to do with optimizing (and clipping) refresh in a graphical view port, which is often something the operating system takes care of. And thus user code rarely has to deal with these things. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

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

30 Mar '04

Vladimir Prus wrote: >Reece Dunn wrote: > > >>Yes, you're right. However, there's one additional wish -- I'd like an > >>appraoch different macroses for different functions. E.g. for POSIX >calls > >>I only encounter -1 returns and NULL returns for error reporting. So I'd > >>like > > > >> int tty = check(open(check(ctermid(0)), O_RDRW); > > > >>to work. I guess this could be done by providing two overloads for the > >>'Wrong' function...., but not, the 'Enforcer' template only works for > >>specific type of return value :-( > > > > My errorcheck class (see other posts) has an error policy where you can > > change the fail test. The default is to test errorcode < 0. > >The code you've posted had the check hardcoded, maybe I've missed some >other >post? The error_storage::failed() function has the hard-coded check, but the errorcheck class gets the storage (and check) policy as a template, so you can provide your own class to perform a custom check. > > A current weakness is that it does not return the value passed to it on > > assignment, so you cannot use exactly like the above example. I have >been > > updating it to support errno handling, but this (at present) requires > > something like: > > > > boost::errorcheck< ... > check; > > > > FILE * fp = ::fopen( 0, "r" ); > > check( fp != 0 ); // assert-like syntax > > ::fclose( fp ); > > > > If you are interested, I'll work on supporting constructs like your > > example above. > >I actually wonder if we need a class. Does it have any advantages over >function? E.g: > template<class Checked = default_checker, class T = void> > T check(T t) > { > if (Checker(t)) > throw ... > return t; > } I suppose it comes down to what you are used to and aesthetics. I have been using MS COM objects heavily that rely on HRESULT error code returns, where the code looks like: HRESULT hr; IHTMLStyle * s = 0; if( FAILED( hr = elem -> get_style( &s ))) goto clean; // use the style object clean: if( elem != 0 ) elem -> Release(); if( s != 0 ) s -> Release(); Which is ugly IMHO, so I use a smart pointer for COM object management and have a com::hresult class for storing the HRESULT, mapping it to a string, etc. The errorcheck class is based on a com::result (throwing version of com::hresult) now defined using errorcheck: typedef boost::errorcheck< hresult > result; I suppose there are applications for both approaches, depending on what style you want, what facilities you want, etc. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

1 0

RE: [boost] Standard C Library and C++ / BOOST
by Klaus Nowikow 30 Mar '04

30 Mar '04

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? Best regards, Klaus

5 8

RE: [boost] Re: Standard C Library and C++ / BOOST
by Klaus Nowikow 30 Mar '04

30 Mar '04

> From: Rene Rivera [mailto:grafik.list@redshift-software.com] > Rob Stewart wrote: > > From: Rene Rivera <grafik.list(a)redshift-software.com> > > > >>Gennaro Prota wrote: > >> > >>>On Sat, 27 Mar 2004 19:23:50 -0500, David Abrahams > >>><dave(a)boost-consulting.com> wrote: > >>> > >>>>"Klaus Nowikow" <nowikow(a)decomsys.com> writes: > >>>> > >>>>>Reece Dunn wrote: > >>>>>[snip] > >>>>> > >>>>> > >>>>>> 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? > >>>> > >>>>You're wrong. *this is copied before it is thrown. > Still, the idiom > >>>>above seems a bit suspicious, unless you somehow prevent > derivation > >>> > >>>>from errorcheck. > >>> > >>>I can't believe you are justifying the above. You copy an > object that > >>>doesn't exist yet! (The class is not a POD and has a non trivial > >>>constructor - and even if this wasn't the case...) > >> > >>I don't see how the object is not fully initialized inside > its constructor?? > >>Could you explain your objection? > > > > > > Until the ctor finishes -- after the closing } -- there is no > > object (see 3.8/1). > > Yes the object lifetime hasn't started... but the object is > initialized. Which > according to 12.7 allows for referring to members of the > object directly or > indirectly, in this case by a copy ctor function. I think you are right. When I posted the message above, I didn't take into consideration that the object (*this) is copied before it is thrown. Best regards, Klaus

1 0

Re: [boost] Re: IndexedSet Review
by JOAQUIN LOPEZ MU?Z 30 Mar '04

30 Mar '04

Hi Dave ----- Mensaje original ----- De: "David B. Held" <dheld(a)codelogicconsulting.com> Fecha: Lunes, Marzo 29, 2004 9:57 pm Asunto: [boost] Re: IndexedSet Review > "Joaquín Mª López Muñoz" <joaquin(a)tid.es> wrote in message > news:406802F9.4990B35C@tid.es... > > [...] > > Ummm... If I followed your approach I would be incurring two > > extra copies which is precisely what modify() is meant to avoid. > > For non-destructive updating you can use update(), that's the > > idea. If I'm not making myself clear please tell me so. > > Yeah, I'm not understanding where the extra copies would come > from. As far as I can tell, it's possible to reorder the operations > in modify() without increasing the cost of execution except by a > few instructions. This is my understanding of how modify() works > now: > > mod(element); // changes the element immediately and in-place > unlink(element); // takes the node out of the index > link2(element); // puts it back in at the correct spot Sort of, yes. > > This is what I'm suggesting: > > i = find(new_element); // look to see if modify() can even succeed > if (*i == new_element) return; > mod(element); // now change the node, since modify() will succeed > unlike(element); // same as before > link2(element, i); // reinsert, but use i as a hint (which will be > correct) OK, I know now where you're getting at. You are assumming that a change in the name key won't affect other indices. In general, this is not true: keys are not orthogonal, the simplest example is two indices having the same key. More interesting examples include indices with composite keys or, in general, any function that depends on the whole element rather than a single data member. OK so far? So, you just cannot feed an index with the new key and expect the other indices to remain unaltered. You *must* provide the indices with the final modified object. From this it easily follows that you need two copies: one from the original element to the modified one (which you must supply separately from the original) and other to do the final commit. If you look at the implementation of modify_ (the internal backbone of modify) you'll see that each index is given its turn to rearrange the element, not only the one from which you called modify. This is the reason behind the existence of different update and modify memfuns: there's a tradeoff between copying penalty and reversible semantics. Got it? Allow me to snip the rest of the discussion. If you're not convinced or I haven't explained myself please tell me so. [...] > > > [...] > > > Some of the lines are > 80 columns (e.g.: the copyright notice). > > > > Is this strictly required? If so I'll go thru the code and make the > > changes. If not, I'd rather leave it like that. > > I don't think it's strictly required, but a lot of people complain > about long lines. Reluctantly added to my todo list (I'm lazy.) > > > <off topic> It'd be nice if Boost.Config provided a (possibly > > automatically generated) reference table showing which > > compilers do have a specific defect macro.</off topic> > > That would be great, but as with many things, complaints are > usually satisfied by the complainer. ;) > Oh, I'm too young for commitment :) [...] > > Well, I stated previously that I'll do what people agree on. I don't > > know if the final decision should be made by Pavel as the review > > manager. IMHO, qualified identifiers will be so long anyway that > > having an additional ::container:: won't hurt much. > > It won't hurt, but if it won't help, why should it be there? We > can add > gratuitous namespace levels all day long, but that doesn't mean > we should. Others (not talking about me) think differently. > > > [...] > > The main problem with "Set" slipping into the name of the > > container is that, for instance, the following > > > > indexed_set<int,index_list<sequenced<> > > > > > > does not have anything to do with sets (it resembles a std::list of > > constant ints.) For this reason I like Multicontainer better (or > > something along this line.) > > Perhaps, but "multicontainer" sounds *too* generic. I would expect > something with that name to support any number of back-ends, like > vector, deque, etc. Actually, come to think of it, that might not be > such a bad idea. However, it wouldn't really fit the implementation > of the library, because the container is a node-based one, and > vector wouldn't play as nicely as the others. But if you could not > only created computed indices, but also *virtual indices*, then you > could create an associative vector! However, this might exceed > the scope of the library. By a virtual index, I mean that the vector > itself would remain sorted, and you would have an index that > performs a binary search without actually storing any additional > node information. That sounds like a big mess, though. I don't think I'll go down that route. As you point out, the container delivers for node based structures. > > The reason I think that "Set" is ok is that the STL "Set" is only > vaguely related to mathematical sets. The only property of > essence that is related to mathematical sets is the uniqueness > property, and even that is violated by the multiset. The vagarities > of computational performance necessitate that the STL notion > of Set be stricter than the mathematical notion for it to be usable. > In the same way, I think that IndexedSet need not strictly be even > an STL Set for similar reasons. It supports the "essential > properties" of uniqueness and intrinsic ordering, and adds > additional concepts which cater to computational practicalities. > It's not *merely* a container, but a special kind of container. It's > not truly a generic container, so I think it would benefit from a > more specific name. It's primarily associative, and that's the > essence of the STL Set, which is why I think your container > ultimately *is* a set, even though a degenerate configuration > may not be. Then again, not even the general feel of a std::set has to be met. Imagine a bunch of sequenced indices (like a lot of std::list without duplicate storage): this is not just a degenerate case (it might be useful) and it is definitely not a set. I agree "Multi" is probably too generic, and clashes with, for instace, multi_array. What about CompositeContainer for the lib (and composite_container for the class)? it matches the name of the concept it satisfies, it *is* some sort of container and it's certainly composite. Admittedly a bimap could be also a considered a composite container, but composite_container is *the* composite container, if you know what I mean. Please allow me to answer the rest of your post in a separate message so as to keep its size bounded. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 4

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

30 Mar '04

Bo Persson wrote: >"Reece Dunn" <msclrhd(a)hotmail.com> skrev i meddelandet >news:BAY7-F123eo6WutfjDM00010dd8@hotmail.com... > > 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. > >No, when the constructor fails any partial construction will be undone by >calling the destructors for those subobjects. So the errorcheck object will be in a half-constructed state. That is, the int will be constructed, but the errorcheck object isn't, therefore the int's destructor will be called, but errorcheck's deconstructor will not. The solution would therefore be to throw an intermediate object, like the Trules from the C++ Templates book by David Vandervoorde and Nico Josuttis. This would then get around the throwing in a constructor problem. Regards, Reece _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

small but handy (to me) data buffer class
by Matthew Hurd 30 Mar '04

30 Mar '04

I'm a simple fellow and get confused about who is responsible for deleting a raw buffer, is it me, the library, should it be free or delete? Maybe I get a pointer the buffer and I must free it. May I get the pointer to the buffer and I should do nothing... When I create the buffer and send it to the library, the lib will delete, so I shouldn't but should I malloc or new the thing? Any way, to kill annoying mozzie with a hammer I wrote a little policy buffer, perhaps others might find this useful and it might make its way into a utility section somewhere in boost. I also had a goal of the potential for binary compatibility with a struct buffer { size t size; char * data; } as per WSABUF on win32, and many other standardish buffers, which limited the choices a little. hpp attached. Test that passes on vc7.1 below: Seem trivial enough but there are plenty of colours on the bike shed that might be wrong ;-) Comments? If it is desirable I can write a one page doc and put it in the queue for a mini-review. Matt Hurd. __________________________________________ void data_test() { net::data_standard b(6, "Hello"); CPPUNIT_ASSERT_EQUAL( b[0], 'H'); CPPUNIT_ASSERT_EQUAL( b[1], 'e'); CPPUNIT_ASSERT_EQUAL( b[2], 'l'); CPPUNIT_ASSERT_EQUAL( b[3], 'l'); CPPUNIT_ASSERT_EQUAL( b[4], 'o'); CPPUNIT_ASSERT_EQUAL( *b.begin(), 'H'); net::data_standard::iterator i = b.begin(); CPPUNIT_ASSERT_EQUAL( *i, 'H'); CPPUNIT_ASSERT_EQUAL( *(i+4), 'o'); ++i; CPPUNIT_ASSERT_EQUAL( *i, 'e'); i++; CPPUNIT_ASSERT_EQUAL( *i, 'l'); --i; CPPUNIT_ASSERT_EQUAL( *i, 'e'); i = b.end(); i = i - 3; CPPUNIT_ASSERT_EQUAL( *i, 'l'); i = b.begin(); *i = 'h'; CPPUNIT_ASSERT_EQUAL( b[0], 'h'); b[1] = 'u'; CPPUNIT_ASSERT_EQUAL( std::string( b ), std::string("hullo") ); std::string c = b; CPPUNIT_ASSERT_EQUAL( c, std::string("hullo") ); net::data_standard::const_iterator ci = b.begin(); CPPUNIT_ASSERT_EQUAL( *ci, 'h'); ci = b.end(); ci = ci - 3; CPPUNIT_ASSERT_EQUAL( *ci, 'l'); CPPUNIT_ASSERT( b.end() - b.begin() == 6); // malloc / free example where one side creates and the other destroys net::data<4096, net::create_malloc, net::kill_nothing > source; std::string bye = "Goodbye"; source.overwrite(bye.length() + 1 , bye.c_str()); net::data<4096, net::create_refer, net::kill_free > dest( source.size() , source.begin() ); std::string bye_bye = dest; CPPUNIT_ASSERT_EQUAL(bye, bye_bye); } ______________ 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Data<4096> constructed for char with 6 incoming | d:\finray\simple_server\data.hpp:158 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Empty data<4096> constructed for char | d:\finray\simple_server\data.hpp:145 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Data<4096> constructed for char with 8 incoming | d:\finray\simple_server\data.hpp:158 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Data<4096> for char has the fat lady singing | d:\finray\simple_server\data.hpp:165 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Data<4096> for char has the fat lady singing | d:\finray\simple_server\data.hpp:165 2004-Mar-25 Thu 15:43:55 | net.data | TRACE | 2984 | Data<4096> for char has the fat lady singing | d:\finray\simple_server\data.hpp:165 OK (1)

2 6

Re: [boost] anonymous namespaces and Intel C++ 8
by Matthias Troyer 30 Mar '04

30 Mar '04

On Dec 14, 2003, at 9:55 PM, Matthias Troyer wrote: > In trying to get our boost-based codes to compile with Intel C++ > version 8 I realized one important restriction of that compiler with > anonymous namespaces (used in boost for the placeholder symbols _1, > _2,... ). With Intel C++ version 8 these anonymous namespace symbols > give multiple definition errors at link time if they occur in two > different object files with the same name (even if one of these object > files is part of a static library (.a file). The only solution I could > find is to rename all my source files that clashed with file names > inside libraries. Does anybody know a better workaround? I want to report that this bug has been fixed in the latest release. Matthias

1 0

Re: Patches for Octonion/quaternion libs
by Hubert Holin 30 Mar '04

30 Mar '04

Somewhere in the E.U., le 29/03/2004 Bonjour I am happy to see you managed to keep this library alive while I was in limbo. My current plans for it (and its siblings) is to transition from MWCWPro to XCode (gcc), to add valarray support to the various special functions (it was on the way, and is locally partially implemented), and further on to replace the quaternion/octonion input operators by something sane, probably based upon Spirit. Were there any requests formulated that I missed? Merci Hubert Holin

2 3