April 2004 - Boost - lists.preview.boost.org

How to get an unique identifier for an edge
by Lodewijk Smit 06 Apr '04

06 Apr '04

Hi, I tried to get an unique identifier for a node and an edge. The node is possible e.g.: adjacency_list<> someGraph; std::pair<adjacency_list<>::vertex_iterator,adjacency_list<>::vertex_iterator> p; ed = add_edge(0,1, someGraph); property_map< adjacency_list<> , vertex_index_t>::type in; in = get(vertex_index_t(), someGraph); for (p = vertices(processGraph); p.first != p.second ; ++p.first) { cout << *p.first << "\n"; cout << "index: " << in[*p.first] << " \n"; } However, the same idee does not work for an edge: std::pair<adjacency_list<>::edge_iterator,adjacency_list<>::edge_iterator> pe; property_map< adjacency_list<> , edge_index_t>::type inedge; inedge = get(edge_index_t(), processGraph); for (pe = edges(someGraph); pe.first != pe.second; ++pe.first) { cout << *pe.first << " "; cout << "index: " << inedge[*pe.first] << " \n"; } I can not figure out how to get an unique id for an edge and I can not understand how the property maps works from the documentation nor I can find how such a edge_index_t property is defined. Can somebody provide some help. With kind regards, Lodewijk __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/

3 2

RE: [boost] Re: [program_options] Unicode support
by Ferdinand Prantl 06 Apr '04

06 Apr '04

Hi, > From: Vladimir Prus [mailto:ghost@cs.msu.su] > > > I understand, that stl support unicode for unicode is not the best, > > but there are facilities, that can provide required > functionality if > > properly extended/configured. > > Let's break the question in two parts. > > 1. Should 'unicode support' mean that there are two versions > of each interface, one using string and the other using > wstring? I think this kind of Unicode support is not good. It > means that each library which accepts or returns strings must > ultimately have double interface and be either entirely in > headers, or use instantinate two variants in sources -- which > doubles the size of the library. Not all libraries must have doubled interface or templated interface for any basic_string<C, T, A>. Different libraries have different string on their interface and one must convert among them. Typical is for example ANSI <-> UCS-2 on Windows. It is only convenient to be able to avoid such conversions when working with standard or widely used libraries, for example boost_regex, which provide templated interface and one can choose 8-bit or 16-bit character space (in future probly 32-bit with a new basic_string<> ;-). I think program_options, being also such a widely used and quite small library, shoud be also templated (no offence, meant just the size, not the importance ;-). > 2. Should program_options library use UTF-8 or wstring. As > I've said, neither is clear leader, but UTF-8 seems better. Here I disagree. Command-line shells work with all characters in the current locale (the whole 255 characters space of 8 bits is used). You would give the user a character array in UTF-8 encoding, which is not typical case today, one processes the parameters by basic_string<char>(argv[x]) in the current locale. I think you should simply use basic_string<> as a template and the encoding let on the caller providing its specialization or perform the conversion himself. Or support the encoding internally by providing an interface to set it, not to do it with a fixed encoding support, even if I like UTF-8 because it suppors full Unicode character range, not like UCS-2. Thinking more, you can expect rather short strings coming to program_options, not megabytes of text. For this usage is more suitable to use fixed-size character encodings because they are faster and easier to work with, having direct support in basic_string<>. Does anybody know, if there are plans to add something like basic_string<ucs2char_t> into the next C++ standard? > > I think, that there is no big reason to try to reinvent a wheel and > > provide all encopasing solution in the library like program_options. > > It should be enough if it will be unicode-enabled so it can > be used in > > the any specific scenario, provided that all necessary > facilities are > > on place. > > It's *far* from all encopassing solution. In fact, the > changes in program_options will include: > > 1. Adding ascii -> UTF-8 conversion in parsers 2. Adding > UTF-8 -> ascii conversion in value parsers 3. Adding unicode > parsers with UCS-4 -> UTF-8 conversion 4. Adding unicode > value parsers and UTF8 -> UCS-4 conversion > > That's all, and given that there's at least two UTF-8 codecs > announced on the mailing list, not a lof of work. And this > will add Unicode support without changing interface a bit. Yes, you are right; there is not much work to add the conversion code into the internals of program_options. I also wrote my own UCS-2 <-> UTF-8 encoding routines to use them for basic_string<char> <-> basic_string<wchar_t> conversion. However, I think, that we should reuse as much as possible and not to rewrite similar code in every library, which works with strings coming from a real user input. Your solution to support UTF-8 invisibly changes the interface anyway - not the text of prototypes directly but the behavior of the interface (encoding of strings). Nevertheless, you could support this encoding conversion not only by providing your own conversion routines, but rather by accepting existgin facets, which help streams similarly (as I wrote in the former e-mail). Then one could simply write a conversion facet once and use it for a stream input and also for a cmdline input, sharing the implementation. Ferda > - Volodya

2 1

Re: [boost] Re: Planning Next Release
by Aleksey Gurtovoy 06 Apr '04

06 Apr '04

Giovanni Bajo writes: > Aleksey Gurtovoy wrote: > > > I'd like to test the waters for the last week of June -- let's > > say Monday, June 28 -- being the target date for the next major > > release, which I am volunteering to manage. Correspondingly, > > June 21 or so would be a branch-for-release date, by which > > everything should be in CVS and in the releasable shape. > > I think we should try and allow a larger period of time to fix the > regression tests. It's definitely going to be more than one week, and the above wasn't meant to suggest otherwise (note "the releasable shape"). I did imply a different branch creation pattern than you suggest below, though. > I suggest we branch for instance 1 month before the release, and then > we restrict the branch only to the patches which stabilize the > regression tests (no new features allowed there). Plus, the trunk is > free for new features, and development is not stalled. Early branching would definitely give us more freedom for main trunk evolvement, and might even improve our release cycle in terms of predictability (although it's been my impression that in past almost all destabilizing checkins were due to "judgment errors" rather than accidental mistakes). On the other hand, any major development should be led in a separate branch anyway, so stalling is more a theoretical problem, IMO. The downside of branching early, is, of course, that the developers making fixes would have to do more work incorporating those both in the branch and the main trunk. I guess it's worth trying. What do others think? -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

BCP suggestion
by Edward Diener 06 Apr '04

06 Apr '04

First off, BCP is excellent. Here is a suggestion which might make it even more excellent, but it might not be deemed doable or important enough considering the extra parsing that needs to be done. I would like to see BCP be able to take a compiler-version/operating system/standard library, or some combination of these possibilities, and produce its file list with these extra narrowing possibilities. This would largely mean being able to look at the config files and eliminate the files which don't pertain to a particular compiler/os/standard library, but it might also affect other files among Boost's headers and libraries. My idea is that one may want to only distribute certain Boost files and libraries for a particular implementation, whereas BCP gives all related files for a particular file without considering specific implementations. I realize that such an undertaking may be a considerable amount of work and I am not trying to saddle John Maddock with it, especially as manually eliminating files which do not pertain to a particular implementation may be fairly easy. Ideally, however, it would be nice if one could do this programatically.

3 3

Segfault in token_functions.hpp
by Joshua Moore-Oliva 05 Apr '04

05 Apr '04

It appears that there is a problem in token_functions.hpp with probably the *next iterator. It appears to read out of previously freed memory. I recompiled boost with debugging information, and here is the backtrace of boosts invalid memory access's. ==7336== Thread 2: ==7336== Invalid read of size 1 ==7336== at 0x80537C6: _ZN5boost14char_separatorIcSt11char_traitsIcEEclIN9__gnu_cxx17__normal_iteratorIPKcSsEESsEEbRT_SA_RT0_ (token_functions.hpp:305) ==7336== by 0x8053741: boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>::increment() (token_iterator.hpp:55) ==7336== by 0x80536DA: void boost::iterator_core_access::increment<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string> >(boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>&) (iterator_facade.hpp:347) ==7336== by 0x804FC88: boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>, std::string, boost::forward_traversal_tag, std::string const&, int>::operator++() (iterator_facade.hpp:472) ==7336== by 0x80531E6: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::getNext(std::string&, std::string&, std::string&) (getNext.cpp:119) ==7336== by 0x805156C: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:29) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== Address 0x41C7F7AD is 57 bytes inside a block of size 240 free'd ==7336== at 0x4002B466: operator delete(void*) (in /usr/lib/valgrind/vgskin_memcheck.so) ==7336== by 0x403AFA96: (within /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF3F1: std::__default_alloc_template<true, 0>::deallocate(void*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF469: std::allocator<char>::deallocate(char*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B642A: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B2FA3: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B304B: std::string::~string() (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x8051F60: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::load(PostgresConnection<std::logic_error, std::runtime_error>&) (load.cpp:48) ==7336== by 0x8051496: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:20) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== ==7336== Thread 2: ==7336== Invalid read of size 1 ==7336== at 0x8053825: _ZN5boost14char_separatorIcSt11char_traitsIcEEclIN9__gnu_cxx17__normal_iteratorIPKcSsEESsEEbRT_SA_RT0_ (token_functions.hpp:314) ==7336== by 0x8053741: boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>::increment() (token_iterator.hpp:55) ==7336== by 0x80536DA: void boost::iterator_core_access::increment<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string> >(boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>&) (iterator_facade.hpp:347) ==7336== by 0x804FC88: boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>, std::string, boost::forward_traversal_tag, std::string const&, int>::operator++() (iterator_facade.hpp:472) ==7336== by 0x80531E6: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::getNext(std::string&, std::string&, std::string&) (getNext.cpp:119) ==7336== by 0x805156C: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:29) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== Address 0x41C7F7AE is 58 bytes inside a block of size 240 free'd ==7336== at 0x4002B466: operator delete(void*) (in /usr/lib/valgrind/vgskin_memcheck.so) ==7336== by 0x403AFA96: (within /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF3F1: std::__default_alloc_template<true, 0>::deallocate(void*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF469: std::allocator<char>::deallocate(char*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B642A: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B2FA3: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B304B: std::string::~string() (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x8051F60: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::load(PostgresConnection<std::logic_error, std::runtime_error>&) (load.cpp:48) ==7336== by 0x8051496: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:20) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== ==7336== Thread 2: ==7336== Invalid read of size 1 ==7336== at 0x805388D: _ZN5boost14char_separatorIcSt11char_traitsIcEEclIN9__gnu_cxx17__normal_iteratorIPKcSsEESsEEbRT_SA_RT0_ (token_functions.hpp:319) ==7336== by 0x8053741: boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>::increment() (token_iterator.hpp:55) ==7336== by 0x80536DA: void boost::iterator_core_access::increment<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string> >(boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>&) (iterator_facade.hpp:347) ==7336== by 0x804FC88: boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>, std::string, boost::forward_traversal_tag, std::string const&, int>::operator++() (iterator_facade.hpp:472) ==7336== by 0x80531E6: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::getNext(std::string&, std::string&, std::string&) (getNext.cpp:119) ==7336== by 0x805156C: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:29) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== Address 0x41C7F7AE is 58 bytes inside a block of size 240 free'd ==7336== at 0x4002B466: operator delete(void*) (in /usr/lib/valgrind/vgskin_memcheck.so) ==7336== by 0x403AFA96: (within /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF3F1: std::__default_alloc_template<true, 0>::deallocate(void*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF469: std::allocator<char>::deallocate(char*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B642A: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B2FA3: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B304B: std::string::~string() (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x8051F60: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::load(PostgresConnection<std::logic_error, std::runtime_error>&) (load.cpp:48) ==7336== by 0x8051496: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:20) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== ==7336== Thread 2: ==7336== Invalid read of size 1 ==7336== at 0x80538B2: _ZN5boost14char_separatorIcSt11char_traitsIcEEclIN9__gnu_cxx17__normal_iteratorIPKcSsEESsEEbRT_SA_RT0_ (token_functions.hpp:319) ==7336== by 0x8053741: boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>::increment() (token_iterator.hpp:55) ==7336== by 0x80536DA: void boost::iterator_core_access::increment<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string> >(boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>&) (iterator_facade.hpp:347) ==7336== by 0x804FC88: boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>, std::string, boost::forward_traversal_tag, std::string const&, int>::operator++() (iterator_facade.hpp:472) ==7336== by 0x80531E6: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::getNext(std::string&, std::string&, std::string&) (getNext.cpp:119) ==7336== by 0x805156C: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:29) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== Address 0x41C7F7AE is 58 bytes inside a block of size 240 free'd ==7336== at 0x4002B466: operator delete(void*) (in /usr/lib/valgrind/vgskin_memcheck.so) ==7336== by 0x403AFA96: (within /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF3F1: std::__default_alloc_template<true, 0>::deallocate(void*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF469: std::allocator<char>::deallocate(char*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B642A: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B2FA3: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B304B: std::string::~string() (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x8051F60: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::load(PostgresConnection<std::logic_error, std::runtime_error>&) (load.cpp:48) ==7336== by 0x8051496: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:20) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== ==7336== Thread 2: ==7336== Invalid read of size 1 ==7336== at 0x80538D7: _ZN5boost14char_separatorIcSt11char_traitsIcEEclIN9__gnu_cxx17__normal_iteratorIPKcSsEESsEEbRT_SA_RT0_ (token_functions.hpp:320) ==7336== by 0x8053741: boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>::increment() (token_iterator.hpp:55) ==7336== by 0x80536DA: void boost::iterator_core_access::increment<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string> >(boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>&) (iterator_facade.hpp:347) ==7336== by 0x804FC88: boost::iterator_facade<boost::token_iterator<boost::char_separator<char, std::char_traits<char> >, __gnu_cxx::__normal_iterator<char const*, std::string>, std::string>, std::string, boost::forward_traversal_tag, std::string const&, int>::operator++() (iterator_facade.hpp:472) ==7336== by 0x80531E6: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::getNext(std::string&, std::string&, std::string&) (getNext.cpp:119) ==7336== by 0x805156C: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:29) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so) ==7336== Address 0x41C7F7AE is 58 bytes inside a block of size 240 free'd ==7336== at 0x4002B466: operator delete(void*) (in /usr/lib/valgrind/vgskin_memcheck.so) ==7336== by 0x403AFA96: (within /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF3F1: std::__default_alloc_template<true, 0>::deallocate(void*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403AF469: std::allocator<char>::deallocate(char*, unsigned) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B642A: std::string::_Rep::_M_destroy(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B2FA3: std::string::_Rep::_M_dispose(std::allocator<char> const&) (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x403B304B: std::string::~string() (in /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libstdc++.so.5.0.5) ==7336== by 0x8051F60: Batch<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::load(PostgresConnection<std::logic_error, std::runtime_error>&) (load.cpp:48) ==7336== by 0x8051496: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::poll() (poll.cpp:20) ==7336== by 0x8050D9A: Worker<PostgresConnection<std::logic_error, std::runtime_error>, std::logic_error, std::runtime_error>::threadLaunch(void*) (threadLaunch.cpp:16) ==7336== by 0x402E3739: (within /usr/lib/valgrind/libpthread.so) ==7336== by 0x40156395: (within /usr/lib/valgrind/valgrind.so)

2 2

Re: [boost] Review Result: Indexed Set
by JOAQUIN LOPEZ MU?Z 05 Apr '04

05 Apr '04

----- Mensaje original ----- De: Pavel Vozenilek <pavel_vozenilek(a)hotmail.com> Fecha: Lunes, Abril 5, 2004 0:05 am Asunto: [boost] Review Result: Indexed Set > Indexed set library by Joaquín Mª López Muñoz > has been accepted into Boost. > First of all I'd like thank Pavel, without whose encouragement over many months the library wouldn't have reached the review stage. Thanks also to all the people who participated in the review: it's been a lot of fun and a number of interesting issues have been raised. I plan to deliver a post-review version during April, addressing all of the minor pending requests. As for the new features (ranked indices, bimap, etc.) I guess I'll wait till the first official Boost release in order to gain some feedback first. It is my understanding that noone opposed to new features being postponed until a first official version has been released. A couple of features will probably make it before, though: utilities for composition of key extractors (which are now in the examples only) and serialization support. The naming issues are still not closed, as I'm growing more doubtful that we should embed the library into boost::container. I'll probably post a revised naming scheme during this week or the following. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[BGL] forced client complexity
by Provisional Dissonance 05 Apr '04

05 Apr '04

If one accepts the axiom that "a picture is worth a thousand words," then it naturally follows that discussion of graphs is always overly prolix. Sadly, the same reasoning is also applicable to the code of graph libraries. Boost.Graph seems to expose and require an unnecessarily large amount of complexity, though. Whereas libraries like Spirit go to great lengths to make hard things easy, BGL seems to try only to make hard things possible. The amount of scaffolding required to use BGL for even the simplest of projects often dwarfs the code size of a naive, yet functional, special-purpose implementation. While I understand that the BGL is deeply entrenched in boost culture, certain academic circles, and even publications, I nonetheless suggest that BGL lacks the ease of use necessary for widespread adoption. Even knowing that ease-of-use is not a criterion for acceptance into boost, looking at what is required of the client to use the BGL always leaves me feeling perplexed. Is there any particular reason that a simplified interface is not made available? Perhaps a container adapter could be packaged with the library allowing a compromise of functionality and flexibility for simplicity? If a graphing problem is trivial, shouldn't BGL provide a trivial solution? Why are the simplest useful examples several hundred lines of code? I apologize for all of my vague criticisms - my intention is not to flame but rather to test the waters. It is difficult for me to assess whether the simplicity I yearn for isn't present for stylistic reasons or whether it would rather necessitate a sacrifice of flexibility, functionality or implementation clarity. Nor is it clear to me to what extent these criteria can be compromised to promote clarity of client code. For what it is worth, the kind of ease-of-use I'm imagining might look like: #include <less_than_10_graph_headers> ... digraph<some_node_type,some_edge_context_type> g; g << "vertex" << make_pair("vertex", "implicit_vertex"); g.add_edge("brother", "sister", "sibling"); if(g.find(make_pair("brother", "sister"))) related = true; Could someone please elucidate on why it is impossible/impractical/unnecessary/whatever for a graph library to have such an interface? Should I accept that the BGL is not the magic bullet graph library and move on, or can this kind of simplicity be somehow found within? Thanks in advance, prs __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

3 7

Re: Re: Re: C++ subranges
by Brian Martin 05 Apr '04

05 Apr '04

Maciej - I need to think deeply about some of the things that have been pointed out. At the moment (this week) there's a project I want to progress a bit so won't be able to do that just yet. One thing I might do immmediately is to do something about that conversion operator. I think it's causing some problems with the stream operators, just for starters. You sometimes get ambiguities in certain contexts and, as you said, these operators can do that. I have a fix, but am not totally satisfied. I've attached the "fixed" version. The comment at the top has also been corrected. Nice to have comments that don't tell porkies.

1 0

Traits and Policies
by Malcolm Smith 05 Apr '04

05 Apr '04

Hi, I am new to this list and saw the messages related to traits and policies. I am an experienced C++ developer but have a limited knowledge of the STL and even less of boost - I've joined this list in an effort to become more familiar. I understand policy classes but am not very familiar with traits. Can someone recommend a link for me to follow so I can better understand what they are as well as when, why and how to use them. TIA. Malcolm Smith MJ Freelancing http://www.mjfreelancing.com Borland Technology Partner

4 4

1.31.1?
by Stephan T. Lavavej 05 Apr '04

05 Apr '04

I remember hearing shortly after its release that 1.31.0 had some serious problems and that 1.31.1 was in the works. Whatever happened to that? Stephan T. Lavavej http://nuwen.net

3 2