- Boost - lists.boost.org

C++ subranges
by Brian Martin 01 Apr '04

01 Apr '04

I have a suggestion for a simple Boost feature - subranges. For those of you who may not know, subranges are a Pascal idea. Using un-restricted numeric types such as ints, shorts and floating point types is somewhat dangerous. For example, if you write a function that, given a date, returns the number of the day in the year that date falls on, what type do you return? Most C/C++ programmers would automatically use an int but ints can be negative and -1 as a day of the year is meaningless. So use unsigned types. But then 0 is invalid, as is any value above 365. Subranges to the rescue... In pascal one would write type DayOfYear = 1..365; function NthDayOfYear(const d : Date) : DayOfYear; The type statement declares a new data type that is restricted to the range 1 to 365 and this is used as the return type of the function. If NthDayOfYear has a fault that sometimes generates a value outside this range, you'll get a runtime error. The idea is to have range checking switched on during development, but to switch if off for release code for efficiency reasons, something that all good pascal compilers can do. My own personal experience having used pascal type languages with this feature is that it's very, very useful indeed. On a number of projects, subranges have illuminated obscure bugs in my code that I might otherwise have missed. After having switched to C++ from Pascal, I soon found myself missing subranges so I wrote a class template that emulates them: template <typename T, T min, T max> class subrange; This would contain the usual operators/constructors etc. that I've omitted for shortness. The above example would now become in C++: typedef subrange<int, 1, 365> day_of_year; day_of_year NthDayOfYear(const Date& d); The class is very simple - all it does is store a value and then checks to make sure it's always in the range min to max when you assign variables of type T to it, do arithmetic and so on and throws an exception if the new value is out of range. A preprocessor symbol is used to switch this range checking on or off as required so that you can release code without the checking overhead. The big question is, do any of you think this is a useful enough feature? Regards, Brian

2 1

Service Pack 6 for Visual Studio 6.0 released
by Bronek Kozicki 01 Apr '04

01 Apr '04

Relevant Knowledge Base article with list of fixes is here http://support.microsoft.com/default.aspx?scid=kb;en-us;834001 Actual download (63MB) is here http://www.microsoft.com/downloads/details.aspx?FamilyId=A8494EDB-2E89-4676… I though that Boost.Python users might be interested B.

3 6

simplifying library install names
by Benjamin Kosnik 01 Apr '04

01 Apr '04

When I build boost-1.31.0, like so: bjam -sPYTHON_ROOT=/usr -sPYTHON_VERSION=2.2 -sTOOLS=gcc -sBUILD=release --prefix=/usr I end up with a bunch of oddly-named library files: libboost_filesystem-gcc-1_31.a libboost_filesystem-gcc-1_31.so.1.31.0* libboost_filesystem-gcc.a libboost_filesystem-gcc.so* is there a way to run bjam or configure the build process so I get something sensible, like: libboost_filesystem.a libboost_filesystem.so.1.31.0 libboost_filesystem.so (symlink) ? best, benjamin

2 2

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