- Boost - lists.boost.org

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

[Boost-bugs] [ boost-Bugs-926039 ] examples/kruskal-example.cpp shadows variables
by SourceForge.net 30 Mar '04

30 Mar '04

Bugs item #926039, was opened at 2004-03-30 06:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=926039&group_i… Category: graph Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Jeremy Siek (jsiek) Summary: examples/kruskal-example.cpp shadows variables Initial Comment: $g++ -Wshadow -Wall kruskal-example.cpp -lbgl-viz generates a lot of shadow warnings, making it impossible to use kruskal-example related code in a program that is supposed to be shadow-free. $g++ --version g++ (GCC) 3.3.3 (Debian 20040321) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=926039&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

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

30 Mar '04

Hi Dave, 2nd part of your post. ----- Mensaje original ----- De: "David B. Held" <dheld(a)codelogicconsulting.com> Fecha: Lunes, Marzo 29, 2004 9:57 pm Asunto: [boost] Re: IndexedSet Review [...] > > As for the Composite Sorted Associative Container concept, we > > have the same problem. Technically, the requirements imposed > > to current or future index types by indexed_set are much weaker > > than being some sort of associative container. I cannot even state > > global complexity bounds (please check the reference, page > > "Index reference", section "Complexity signature"). > > Ok, so if the concept is not a refinement of Associative Container, > then create a new concept! > > > I agree with you a concept section would be highly desirable, but > > here I definitely need some help. What you request is not trivial. > > Then let's take a first stab at it. What you have is similar to an > Associative Container, but is fundamentally different. The way in > which it is different is that there is more than one way to access > the data. And, as you say, it is like multiple containers in one. > So > I think the most fundamental concept here is Composite Container. > [...] Agreed. > Let's rip off SGI for a minute: > > Description > > A Composite Container is a variable-sized Container that > supports retrieval of elements (values) based on one or more > keys. It supports insertion and removal of elements, but differs > from an Associative Container in that the complexity of the > operations depends on the type of key indices used. Not agreed. A Composite Container is more primitive than that. Keys properly belong to the indices (some indices are even not key-based.) I would try first to forge the Index concept. Then a Composite Container is more or less trivially defined as a "composition" (wants definition) of indices. We could call an Associative Composite Container to a Composite Container whose indices model Associative Index (wants def). A bimap is a model Assoc Comp Container, as well as some instantiations of indexed_set. The part of index retrieval (the get<> stuff) I don't see any hope of being conceptualized, as bimap, for instance, could perfectly lack such interface in favor of something simpler for the data structure at hand. Probably, a Composite Container is *not* any kind of Container (its indices are, though): imagine an indexed_set that does not inherit the functionality of its first index. [...] > Now, here we have a tricky issue. By default, IndexedSet *is* > default constructible, but we can't say that Composite Container > should be, because IndexedSet might *not* be default c'tible if > one of the key types are not. The STL solved this by simply > implicitly requiring key comparators to be default c'tible, but > perhaps this requirement is not justified. Anyway, let's continue: Oh, I hadn't thought of this before. Really std::sets implicitly require that their key objetcs are Default Constructible. Seems a defect to me. [snipped rest of stuff] Well, all these sections really belong (IMHO) to the Index concept. > > Models > > * indexed_set (of course) > * bimap (if anyone makes it ;) > > That's a start anyway, and if you fill in as much of that as you can, > I think others will be able to help you fill in the rest. It also > mighthelp if you define other concepts first, like Ordered Unique > Index,etc. I know it's a lot of work, but I think it's worthwhile > (especiallyfor people wanting to extend the library, i.e.: by > defining custom > index types). Well, I'll try to come up with something, but it'll take long. If this is a requirement for acceptance, it certainly will affect to the availability time. > > > [...] > > My Latin (I speak Spanish) heritage makes me favor "indices" > > to "indexes" (and "minuscule" to "miniscule", etc.) The Google > > metric could be biased by the fact that "indexes" is not only the > > plural of "index" but also the 3rd singular formal of the Present > > tense of the verb "index". > > Good call! That was some sloppy reasoning on my part. ;) To be honest, there's bias on the other side to: "indices" is a valid French and Spanish word. Cheers, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Problem: no matching function for call to `parse(const char*, RE_Parser&, const boost::spirit::space_parser&)
by Stephen Torri 30 Mar '04

30 Mar '04

I am having problems with compiling a simple parsing example that I created. I have read over half of the spirit guide and took one of the examples a guide for creating my program. Here is the full error message that I hinted above. What is wrong with my code? I am using boot-1.31.0 with gcc-3.3.2 (gentoo). g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"cs507_EC\" -DVERSION=\"0.1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -I. -I. -I../../src -O2 -c -o RE_Parser.o `test -f RE_Parser.cpp || echo './'`RE_Parser.cpp RE_Parser.cpp: In function `int main()': RE_Parser.cpp:18: error: no matching function for call to `parse(const char*, RE_Parser&, const boost::spirit::space_parser&)' make[2]: *** [RE_Parser.o] Error 1 The code is: -------------------- Parser -------------------- #ifndef RE_PARSER_H_ #define RE_PARSER_H_ #include <string> #include "FileException.hpp" #include <boost/spirit.hpp> #include <iostream> using namespace std; using namespace boost::spirit; //namespace re_parser { class RE_Parser; struct RE_Grammar : public grammar<RE_Grammar> { template <typename ScannerT> struct definition { definition (RE_Grammar const& self) { r_rule = *r_rule[&RE_Parser::process_Kleene] | (r_rule >> s_rule)[&RE_Parser::process_Concat] | (r_rule >> ch_p('+') >> s_rule)[&RE_Parser::process_Or] | s_rule[&RE_Parser::process_Char]; s_rule = ch_p('a') | ch_p ('b') | ch_p ('c') | ch_p ('^') | ch_p ('0'); } rule<ScannerT> r_rule, s_rule; rule<ScannerT> const& start() const { return r_rule;} }; }; class RE_Parser { public: void process_Kleene (char const*, char const*){ cout << "Kleene star" << endl;}; void process_Concat (char const*, char const*){ cout << "Concatenate" << endl; }; void process_Or (char const*, char const*, char* const*){ cout << "Or" << endl;}; void process_Char (char const*){ cout << "Char" << endl;}; }; //} /* namespace re_parser */ #endif /* RE_PARSER_H_ */ ---------- Main ---------- #include "Parser.hpp" #include <string> #include <iostream> #include <fstream> using namespace re_parser; int main () { RE_Parser reg_rdr; string input_str; ifstream reg_file; reg_file.open("reg_expr.txt"); while (getline(reg_file,input_str)) { parse_info<> info = parse(input_str.c_str(), reg_rdr, space_p); if (info.full) { cout << "Parsing succeeded." << endl; } else { cout << "Parsing failed. Stopped at: " << info.stop << endl; } } } Stephen -- Stephen Torri GPG Key: http://www.cs.wustl.edu/~storri/storri.asc

2 1

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

30 Mar '04

Vladimir Prus wrote: >John Torjo wrote: > >>> I really wish there were exception-throwing versions -- since that > >>> code is > >>> boring and still contains a couple of error-handling problems. > >>> However, most > >>> of the functions above are acutally from POSIX, not from standard C, > >>> so I'm > >>> not sure how much wrapped C functions would help me. > > Unless I'm mistaken, you're talking something similar to Andrei > > Alexandrescu's ENFORCE: > > http://www.cuj.com/documents/s=8250/cujcexp2106alexandr/ >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. 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. Regards, Reece _________________________________________________________________ Express yourself with cool new emoticons http://www.msn.co.uk/specials/myemo

2 1