- Boost - lists.boost.org

[Graph] Bundled properties
by Douglas Gregor 14 May '04

14 May '04

Introducing internal properties for vertices and edges is too hard, and is one of the various things that came up in the "forced client complexity" thread. For a simple task, I ended up writing this: -------------------------------------------------------- namespace boost { enum edge_length_t { edge_length }; enum edge_speed_limit_t { edge_speed_limit }; enum edge_direction_t { edge_direction }; enum edge_snow_route_t { edge_snow_route} ; BOOST_INSTALL_PROPERTY(edge, length); BOOST_INSTALL_PROPERTY(edge, direction); BOOST_INSTALL_PROPERTY(edge, speed_limit); BOOST_INSTALL_PROPERTY(edge, snow_route); } typedef boost::adjacency_list< boost::listS, boost::vecS, boost::bidirectionalS, // Vertex properties boost::property<boost::vertex_name_t, std::string>, // Edge properties boost::property<boost::edge_name_t, std::string, boost::property<boost::edge_length_t, double, boost::property<boost::edge_speed_limit_t, int, boost::property<boost::edge_direction_t, char, boost::property<boost::edge_snow_route_t, bool> > > > > > RouteMap; -------------------------------------------------------- I'm basically enumerating all of the fields in a struct, but it's not represented efficiently (for the human, compiler, or run-time). I'd really like to do something like this: -------------------------------------------------------- struct Intersection { std::string name; }; struct Street { std::string name; double length; int speed_limit; char direction; bool snow_route; }; typedef boost::adjacency_list< boost::listS, boost::vecS, boost::bidirectionalS, Intersection, Street> RouteMap; -------------------------------------------------------- It's a heck of a lot shorter and more intuitive. The attached patch introduces this capability for adjacency_list. The UDT's Intersection and Street are referred to as "bundled properties", and may occur at the end of the vertex or edge property list passed to adjacency_list. Accessing these bundled properties is done using the graph's subscript operator: void foo(Map& g, Map::vertex_descriptor v, Map::edge_descriptor e) { map[v].name = "Albany"; map[e].length = 25.3; } Often one needs a property map for an internal property. With bundled properties this is achieved through an overloaded ->* operator. So if you want to create a property map from edge descriptors to the speed_limit property for a graph g, use: g->*&Street::speed_limit And here's a real usage: void shortest(Map& g, Map::vertex_descriptor from) { dijkstra_shortest_paths(g, from, weight_map(g->*&Street::length)); } The attached patch implements this functionality. It is completely backward-compatible (no new regressions on GCC 3.3.x), includes documentation and a test case, and seems to work well. Comments? Doug

1 1

Why don't lambda funcs work for stl function objects?
by Neal D. Becker 13 May '04

13 May '04

Any reason lambda functions can't meet requirements for std::unary_function, for example? Specifically, it seems result_type is not defined. For example boost::constant(0) doesn't have result_type, so can't be used where a std::unary_function is needed.

3 2

Re: [boost] Re: static sized strings
by Reece Dunn 13 May '04

13 May '04

Rob Stewart wrote: >From: John Nagle <nagle(a)animats.com> > > > > STL strings are variable-sized, with no limit. When you > > add characters, "size()" increases. Should fixed-size > ^^^^ >I presume you're referring to fixed-capacity strings which can >have a variable size, right? yup. The idea is to make it a buffer-overflow safe replacement for C style character buffers, e.g.: char buf[ 100 ]; ::sprintf( buf, "...", ... ); while allowing it to behave like a basic_string. > > strings be similar? If the STL string operations are > > to be meaningful, they have to be. > >Only if you want to apply mutating algorithms that modify size. >IOW, it isn't unreasonable to choose either fixed-size or >fixed-capacity strings. If the former, then there are no >mutating algorithms that affect the size. If the latter, the >size can change, but an exception occurs when trying to exceed >the capacity. That's the way I see it, but instead of throwing an exception, the class simply prevents overrun and fills the available space, e.g.: char_string< 5 > buf; buf.copy( "Meine Grosse Welt!" ); std::cout << buf << '\n'; // prints "Mein" (null terminated) > > In STL strings, "size" doesn't include a trailing null. > > Using "c_str" can result in expanding the string to add a > > trailing null. With fixed-size strings, we don't have that > > option. > > > > If c_str is provided, there must always be space > > for a trailing null. So you can't use char_string > > when you need a specific fixed length, as for Macintosh > > 4-character file signatures. Perhaps "boost::array<char>" > > is the way to go for that sort of thing. Trying to do > > both null-terminated and non-null-terminated strings > > in the same class will get ugly. > >If the string if fixed-capacity *and* there remains sufficient >capacity, c_str() can null terminate the buffer. If there isn't >sufficient remaining capacity, then throw an exception. > >IOW, make it a runtime error to fix the capacity too small to >permit null termination when calling c_str(). That still leaves >room for things like the 4-character file signature to which you >referred, and yet prevents buffer overrun, but doesn't require >foregoing flexibility. That is a good idea. It will mean keeping track of the string length, but it does permit both versions without requiring complex internals/semasntics or seperate classes. In order to keep interoperability with C style usage (i.e. operator const char *()), we can have the following: inline const char_type * c_str() { // null-terninate buffer: str[ len ] = char_type( '\0' ); return( str ) } inilne operator const char *() { return( c_str()); } Regards, Reece _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

5 8

Re: [boost] Re: static sized strings
by Reece Dunn 13 May '04

13 May '04

Rob Stewart wrote: >From: John Nagle > Reece Dunn wrote: > > > Rob Stewart wrote: > > >> From: John Nagle >You're comparing apples to oranges. Either you mean for the >buffer to be exactly four bytes or you don't. If you do, then >there's no room for a null terminator. You're not dealing with a >"C string" (a null terminated string), you're dealing with a four >byte buffer. If you allocated four bytes for a "C string" and >write "ABCDE" to it, or even strcat() "ABCD" to it, you overrun >the buffer. Why would we want to provide consistent semantics >for that behavior? The idea is to prevent overrun when this type of situation occurs. Thus, it will be a 3 character buffer with the extra character being a null-terminator. > > >> IOW, make it a runtime error to fix the capacity too small to > > >> permit null termination when calling c_str(). That still leaves > > >> room for things like the 4-character file signature to which you > > >> referred, and yet prevents buffer overrun, but doesn't require > > >> foregoing flexibility. > > > > If you want a 4-char file signature, you can use > > "boost::array<char,4>", which does that job. Is there any > > real need for that functionality in char_string? Isn't boost::array specific to generic arrays, whereas using a variant of char_string, you can use string functions that will be optimized for string operations. This is the main reason for using a special string class. > > char_string might have some convenience template functions to > > interconvert "boost::array" and "boost::char_string". > > > > > That is a good idea. It will mean keeping track of the string length, > > > > Yes, that seems to be necessary. > >The question is, which is better: char_string<4> or >boost::array<char,4>? I suggest that the latter is better. In C >code, and similar C++ code, arrays of char are used as buffers of >fixed length and as memory for strings. Code will be clearer if >one uses boost::array<char,N> for the former and char_string<N> >for the latter. Once you make that distinction of purpose, null >termination can be integral to char_string without complication >or unwanted overhead. That makes sense. > > What about the base class issue? There's a need to be able to > > write something like "char_string_base& s" when you want to > > pass around fixed-capacity strings of more than one capacity. > >If that is a necessary feature, then the length can be stored in >the base class. However, such a base class means that the dtor >must be virtual. Is vtable overhead acceptable in such a class? >Perhaps two types are needed. My design does not use a virtual base class, so that isn't an issue. John Nagle's version does, so that is where the problem arises. I have several issues with the use of a virtual base class: [1] If you want to operate on a variable length character string specifically, why not templatize the function: template< int n > void myfn( boost::char_array< n > & s ){ ... } [2] How do you deal with wide-character strings? My update generalizes to support char and wchar_t based buffers, but with a virtual base class, you are limited to char buffers. [3] One of the reasons for having a virtual class is to supply custom string operations, e.g. using Windows-specific string functions instead of the standard library ones. This can also be solved with a policy template like that found in basic_string. My current version uses this approach, improving interoperability with basic_strings. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

3 2

Re: [boost] Re: static sized strings
by Reece Dunn 13 May '04

13 May '04

Rob Stewart wrote: >From: David Abrahams > John Nagle writes: > > > > > If you're willing to accept a call to "new", you can just > > > use std::string and reserve some initial size. > > > > It's not the same thing. You might only be willing to accept a call > > to "new" if things go beyond a certain length. That's *usually* the > > only reason I'd ever have a fixed-size buffer. Very occasionally > > I'll be in code that where I don't want to throw an exception, but > > then a string that responds to overflow by throwing is no better. > >char_string can throw a more meaningful exception than >std::bad_alloc. > >In the small string optimization or std::string with reserve >approaches, the buffer grows when the input is too large, and >other, downstream code may overflow or behave badly. Stopping >the overflow early may be better and having an automated >mechanism for preventing overflow is wise. There is not meant to be any buffer allocation. char_string is a fixed-capacity string that will not write beyond the length of that buffer. > > > So you don't need that capabiilty in char_string. char_string is > > > for situations when you don't want to invoke dynamic allocation at > > > all. In desktop applications, that's not too common, but in real > > > time work, inside operating systems, and in embedded applications > > > it's not unusual. > > > > I'm saying, it's almost always better to degrade performance > > gracefully as the program's input grows than it is to introduce an > > execution discontinuity like an exception (if possible). In many of > > those scenarios you've named, exceptions, like dynamic allocation have > > been banned anyway for similar real and/or imaginary reasons. > >There's probably room and need for both types of strings. I don't intend the char_string buffer to be increased. I intended that the operations on the buffer would not go beyond the buffer (which would lead to overflow) and also that going over the buffer would not generate an exception. It may be beneficial to have an error policy to determin the behaviour in the event of an overflow. I am not advocating this approach, just putting it up for discussion. The only exception I can see keeping is the one in the constructor to test for a buffer of 0, but this would be better re-implemented as a compile-time check using mpl code, e.g.: template< int n, ... > class char_string { class ok{ typedef char value; }; class zero_buffer_error{}; typedef mpl::if_< mpl::equal< n, 0 >, zero_buffer_error, ok >::value value; }; Regards, Reece _________________________________________________________________ Find a cheaper internet access deal - choose one to suit you. http://www.msn.co.uk/internetaccess

3 2

RE: [boost] Re: static sized strings
by Martin Bosticky 13 May '04

13 May '04

>> >>There's probably room and need for both types of strings. > >I don't intend the char_string buffer to be increased. I intended that the >operations on the buffer would not go beyond the buffer (which would lead >to >overflow) and also that going over the buffer would not generate an >exception. >It may be beneficial to have an error policy to determin the behaviour in >the event of an overflow. I am not advocating this approach, just putting >it >up for discussion. In the spirit of contributing to this 'discussion', I would suggest a size limited string that would throw exception if assigned data that is too long. However I would also add a friend function(s) that would assign and truncate supplied data. So by default the string would be safe for use, but you could assign using a 'truncation' technique in which case no exception could ever be thrown. This would then satisfy requirements of both parties. Martin Bosticky This email message contains confidential information and is intended for the use of its intended recipient only. Access to this email by anyone else is unauthorised. If you are not the intended recipient you are hereby notified that any use, disclosure, copying or distribution or any action taken or omitted to be taken in reliance on it is strictly prohibited. If this communication has been sent to you in error, please notify us immediately. Action Information Management Ltd. 129 Devizes Road, Hilperton, Trowbridge, Wiltshire BA14 7SZ. Tel: +44 (0) 1225 711200 Fax: +44 (0) 1225 711222 Website www.aimltd.co.uk email: support(a)aimltd.co.uk

1 0

big_integer and boost::random::uniform_int
by Joel Young 13 May '04

13 May '04

I tried to use boost::random::uniform_int with the in-development big_integer library. Here is a test code: #include <boost/random/uniform_int.hpp> #include "boost/big_integer.hpp" /////////////////////// int main(int argc, char* argv[]) { typedef boost::big_integer data_t; // typedef long long data_t; data_t n(235345345); boost::uniform_int<data_t> rng(0,n-1); return 0; } /////////////////////// ==> g++ --version g++ (GCC) 3.3.2 20031022 (Red Hat Linux 3.3.2-1) Compiling this yields: /////////////////////// g++ -o a -I ~/boost/boost/include/boost-1_31/ randomtest.cpp /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/random/uniform_int.hpp: In constructor `boost::uniform_int<IntType>::uniform_int(IntType,IntType) [with IntType = main(int, char**)::data_t]': randomtest.cpp:10: instantiated from here /home/afit1/fac/jyoung/boost/boost/include/boost-1_31/boost/random/uniform_int.hpp:52: error: invalid application of `sizeof' to an incomplete type ////////////////////// Joel

2 1

Boost.Test and free 7.1 tools
by Vladimir Prus 13 May '04

13 May '04

I've just tried building the Boost.Test library with the free VC 7.1 tools. I get this error: msvc.compile.c++ ..\..\.. \bin\libs\test\build\msvc-7.1\debug\link-static\execution_monitor.obj execution_monitor.cpp ..\..\..\libs\test\src\execution_monitor.cpp(52) : fatal error C1083: Cannot open include file: 'wtypes.h': No such file or directory call "W:/Program Files/Microsoft Visual C++ Toolkit 2003\bin\vcvars32.bat" > nul cl /Zm800 -nologo -TP -DBOOST_TEST_NO_AUTO_LINK=1 /Z7 /Od /Ob0 /GX /GR /MDd -I"..\..\.." -c -Fo"..\..\.. \bin\libs\test\build\msvc-7.1\debug\link-static\execution_monitor.obj" ".. \..\..\libs\test\src\execution_monitor.cpp" All the other files compile fine, so I assume it's not misconfiguration, and that Boost.Test uses some header which is not included in free tools. Is it possible to fix that? I guess that I'm not the only one Linux user who would like to test code with free vc 7.1 and if Boost.Test fails to build that's not possible. TIA, Volodya

2 1

signals lib bug
by Alexey Subbota 13 May '04

13 May '04

Under windows <signals>.dll not export some function because absent #include <boost/config.hpp> before #ifdef BOOST_HAS_DECLSPEC at boost/signals/detail/config.hpp

2 1

[boost][serialization] Adding State to Archives
by martin.ecker＠tab.at 13 May '04

13 May '04

Hello, I was wondering what the best way would be to extend the serialization library to allow storing state in e.g. the archive objects during the serialization process. We could use such a facility in our project for various purposes. For example, it would be possible to influence the serialization of certain classes, i.e. make them write out only their internal state but not any pointers or references to other objects, or something like that. Another use case for having state variables in archives: We're using another library in our project that has its own serialization system. So instead of writing boost::serialization code for the classes of this library we want to use its serialization system. This is straightforward enough by having the library serialize into a memory buffer which is then written out using boost::serialization's binary_object. However, we also need to do proper tracking of pointers for that library, so we can't just create a new memory buffer every time we encounter a pointer to one of its objects during serialization. Therefore it would be convenient to store an "archive" object of the library's serialization system (which calls an archive a "stream") in the boost::serialization archive and simply write all objects of the library we encounter to it. The library's serialization system will track all these objects for us in a similar way boost::serialization does. Then at the end of the serialization process we write the additional serialization data out to the archive using a binary_object. In general, there are a lot of use cases I can think of where having state variables in an archive is useful (setting flags to influence the serialization process, deserializing smart pointers, registering objects upon deserialization in some kind of object registry, etc.). One way of achieving all this would, of course, be to derive from one of the existing archive classes and add the required functionality. However, we don't want to lose the flexibility of being able to write out data to a binary, text, XML, or any other archive with some other kind of representation. So basically we're looking for a good way of inserting an additional layer in between the archives and the actual serialize functions that can store state variables. Thanks for any comments. Best Regards, Martin Ecker TAB Austria Industrie- und Unterhaltungselektronik GmbH & CoKG http://www.tab.at

1 0