- Boost - lists.boost.org

BGL least common ancestor
by Walter Landry 01 Apr '04

01 Apr '04

Greetings, Does anyone have an implementation of least common ancestor (LCA) for the graph library? I could hack something together to fit my needs, but it would be nice if someone already did the work for me. Thanks, Walter Landry wlandry(a)ucsd.edu

1 0

Region Library?
by Allan Odgaard 31 Mar '04

31 Mar '04

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.

4 6

Re:[boost] Serialization: versioning and XML.
by Robert Ramey 31 Mar '04

31 Mar '04

Anatoli Tubman wrote: >My boss just gave me OK to discuss this, so here goes. >A common drawback of various serialization libraries is the need to >provide versioning code for each data structure to be serialized. This >need not be the case for XML archives (and other formats that store >NVPs). Because the program knows which data members it needs, and >the names are stored in the archive, the program can leave any missing >members in their current state (typically just after construction) and >ignore any extra ones. After all, this is one of the ideas behind XML! >More often than not this tactic is sufficient to handle versioning. When >it's not, there's always the old way of explicit version checks. The included XML archive presumes that saving and loading of class variables are synchronized. This is consistent with all the the other archives so that once the serialization for a class is specified it is guaranteed to work with all archives with no code changes. >It seems that this should be easy to implement for boost::serialization. It might be make an archive which implements XML archive in a different way so that data members would be optional and in an arbitrary sequence. Clearly it would be less efficient than the current version and its not clear whether it would be easy or hard to do. Its probably harder than it would first appear. (as most things are). >Just make two passes through the deserialization function. In the first >pass, just collect information on data members to be deserialized into >some kind of map keyed on tag. In the second pass, perform actual >deserialization, looking at the map built in the first pass. Any tags >in the archive but not in the map are ignored together with their >contents. This method would destroy the independence between class serialization specification and archive format. If I were going to do such a thing (which I'm not), I would build this logic into a new XML archive class. You're free to do this. (if your boss will give you permission) Of course, if such an archive can't made, there would be no motivation to use the serialization library at all for this purpose. Actually this question touches upon a central issue about what serialization is all about and how it conflicts with what XML is all about. Serialization is about making an arbitrary set of data structures moveable from one context to another. The serialized data stream is a function of the data structures to be moved. That is, program code => XML definition. The main attraction of serialization is that the code which saves/loads data streams is automatically generated and kept in sync with program data structures. In the XML archive, XML data definition is driven by the program code and data structures. XML is about rendering data in a program independent manner. Program code is synchronized to match the XML structure. That is, XML definition => program code. There are packages that, given and XML definition, will generate C++ code to save/load data as an XML structure. In essence, these packages are the mirror image of serialization. So the question really is: Which is the independent variable? Program code and data structures or the XML definition?. If it's the former serialization to XML archives is a good choice. If it's the latter, a different approach would probably be better. As long as code and XML definition doesn't change, It doesn't make much difference. When something has to change the question arises, do we change he XML and adjust the program to match or vice versa? This question also touches on another topic that comes up regularly. There is often a desire to use the serialization library to generate a specific data format. If this format is a meta-data specification such as XML it's possible. If it's a more specific format - serialization is probably not the right approach. Again the question comes down to who's boss. Is the data stream format driving the program design or vice versa. With the serialization library, data stream format is driven by the program data structures. Attempts to mandate a too specific data stream format may be possible but ultimately not worthwhile. Robert Ramey

2 1

Re: [boost] [BGL] forced client complexity
by Cromwell Enage 31 Mar '04

31 Mar '04

Hello, prs. I'll be happy to discuss the complexity of the Boost Graph Library with you in the boost-users mailing list (as soon as I rejoin it). Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

1 0

Using bcp
by Edward Diener 31 Mar '04

31 Mar '04

If the --boost=path is not used when executing bcp, how does bcp know where the beginning of the Boost tree is ? If I execute bcp from within the Boost tree without specifying --boost=path, does it work by scanning down through the directory structure from the current directory ? I think such info should be in the bcp docs.

2 1

patch for boost/config/compiler/gcc.hpp
by Benjamin Kosnik 31 Mar '04

31 Mar '04

Any chance this could be applied? best, benjamin

2 1

Serialization: versioning and XML.
by Anatoli Tubman 31 Mar '04

31 Mar '04

My boss just gave me OK to discuss this, so here goes. Please excuse me if it has been brought up before. Please excuse me also if what follows is just downright stupid. A common drawback of various serialization libraries is the need to provide versioning code for each data structure to be serialized. This need not be the case for XML archives (and other formats that store NVPs). Because the program knows which data members it needs, and the names are stored in the archive, the program can leave any missing members in their current state (typically just after construction) and ignore any extra ones. After all, this is one of the ideas behind XML! More often than not this tactic is sufficient to handle versioning. When it's not, there's always the old way of explicit version checks. It seems that this should be easy to implement for boost::serialization. Just make two passes through the deserialization function. In the first pass, just collect information on data members to be deserialized into some kind of map keyed on tag. In the second pass, perform actual deserialization, looking at the map built in the first pass. Any tags in the archive but not in the map are ignored together with their contents. I'm not sure whether current serialization syntax can or should be used with this functionality. Best of luck, -- Anatoli Tubman PTC Israel (Haifa) Tel. (+972) 4-8550035 ext. 229

1 0

[BGL] separate mailing list for boost/graph?
by Jeremy Siek 31 Mar '04

31 Mar '04

Hi All, I just received a request for a separate mailing list for development work on boost/graph. I'm curious as to how many people would be interested in such a list. Please send email to *me* if you have a preference for discussing BGL on a separate list or on the main boost list. Cheers, Jeremy _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu/~jsiek Ph.D. Student, Indiana University Bloomington Graduating in August 2004 and looking for work C++ Booster (http://www.boost.org) _______________________________________________

1 0

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

31 Mar '04

----- Mensaje original ----- De: Arkadiy Vertleyb <vertleyb(a)hotmail.com> Fecha: Domingo, Marzo 28, 2004 3:28 pm Asunto: [boost] Re: Formal Review: Indexed Set > Hi Joaquin, > > Sorry for joining this discussion so late, but here are my comments: Hello Arkadiy, thanks for joining in. I was certainly waiting for you to show up. > > - What is your evaluation of the design? > - What is your evaluation of the implementation? > > The code looks clean. One minor question: the index class template's > equal_range method forwards to lower/upper_bound. Is it really > the best you > can achieve here or is it just a temporary shortcut? Well, there's some room for improvement. Pavel touched on this issue some time ago, too. I didn't optimize the code at the time cause (1) this is how other STL implementations do it anyway and (2) the gain is not that much. But consider this QoI detail in my todo list. [...] > - Do you think the library should be accepted as a Boost library? > > Yes, definitely. Definitely thank you :) I'm glad you like the library. Maybe you have still some spare time to take a look at the review notes and state your opinions on best namings and header organization for indexed_set. Once fixed, there's no way back and we'll have to live with whatever cool/ugly names we have settled on. Two more questions: * Have you looked at mpl_index_list? This facility was designed with RTL in mind so as to ease the internal creation of indexed_set instantiations. Useful for your particular needs? * (off-topic) How's the RTL stuff going on? Planning on open some public discussion on its design aspects? I'd certainly love to contibute in that. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 2

boost-1.31.0 def() and VC7.1.3088 strangeness
by Peter Hornby 31 Mar '04

31 Mar '04

Hi, The boost version is the Version_1_31_0 tag from the CVS repository. The VC version is 7.1.3088. Compiling foo.cpp (attached) results in the error reported in BuildLog.htm (attached). The VC options are also in the BuildLog.htm Uncommenting the line in foo.cpp that that begs you to, results in a clean compile. Has anybody else encountered this sort of weirdness?? I'm getting a lot of related behaviour, but this one is simple. #include <boost/python.hpp> using namespace boost::python; class World { public: World(std::string msg): msg(msg) {} // added constructor void set1(std::string msg) throw(std::exception) { this->msg = msg; } void set2(std::string msg) { this->msg = msg; } private: std::string msg; }; void wrap_World(class_<World> &foobar) { // foobar.def("set2", &World::set2); // OK, uncomment this and the compilation works!! foobar.def("set1", &World::set1); // Error on VC7.1 }

2 3