- Boost - lists.boost.org

[variant]anyone working on variadic template version?
by Larry Evans 22 Sep '09

22 Sep '09

Is anyone working on a variadic template version of variant, i.e. one that defined as: template<typename... T>class variant; instead of: template < typename T0 = detail::variant::void_ , typename T1 = detail::variant::void_ ... , typename T19 = detail::variant::void_ > class variant; ? I'm thinking of attempting that, but I'd hate to waste time if someone else has already done it or made some progress on it. Although BoostCon09 did have a workshop on CXX0x: http://www.boostcon.com/community/wiki/show/Start/HandsOnCXX0x/ the sandbox directory for that: https://svn.boost.org/svn/boost/sandbox/boost0x didn't appear to use the variadic template feature in variant: https://svn.boost.org/svn/boost/sandbox/boost0x/boost/variant/variant_fwd.h… TIA. -regards, Larry

3 6

[rdb] 0.04
by Jean-Louis Leroy 21 Sep '09

21 Sep '09

I have uploaded a new version of my relational database library to the vault. It implements the ideas I described in another thread. This time it even puts things in a real (odbc) database and retrieves them. I see that 12 have downloaded the previous versions. If you have time please send me feedback. Have you been able to compile it ? Has anybody tried on Unix or with other compilers ? Please note: * It's a work in progress ; for the curious only. * I develop on Windows with Visual Studio Express 2008. There is a solution file in the msvc dir. Nothing bjam works yet. * Currently the doc is the test suite Jean-Louis Leroy

3 8

[rdb] 0.05 - also a fusion problem
by Jean-Louis Leroy 21 Sep '09

21 Sep '09

This upload is mostly for fixing an embarassing bug that the test suite would have detected if I had not put a "return 0" in the middle of it. In addition I have restructured the tests into suites and cases. Jam files begin to work, at least they allow me to build with bjam from the boost tree. While I'm at it, here's the bug, in case somebody has an idea. I have to initially create my fusion::list's of expressions and tables with `push_back(list<>(), val)' instead of just `make_list(val)', otherwise I get access violations. I see in the debugger that the first element of my list is damaged during the next function call, most probably because a reference to a temporary was created along the way. Has anybody had this kind of problem ? I use boost 1.39. J-L

1 0

Problems testing compiling on AS400/i5/whatever
by Jon Brisbin 21 Sep '09

21 Sep '09

I'm using the QSH environment on AS400 and the "ixlc" compiler (basically just CRTCPPMOD), trying to compile the following test program: #include <iostream> #include <boost/foreach.hpp> int main(int argc, char** argv) { std::string hello = "Hello, world!"; BOOST_FOREACH( char ch, hello ) { std::cout << ch << std::endl; } return (EXIT_SUCCESS); } Which results in the following errors: The compilation failed. /home/jbrisbin/include/boost/type_traits/is_member_pointer.hpp Line 000054 "/home/jbrisbin/include/boost/type_traits/ is_member_pointer.hpp", line 54.63: CZP0403(30) "template <class T, class U> struct boost::is_member_pointer<U T::* const>" is alread ERROR 1 001 /home/jbrisbin/include/boost/type_traits/is_member_pointer.hpp Line 000055 "/home/jbrisbin/include/boost/type_traits/ is_member_pointer.hpp", line 55.63: CZP0403(30) "template <class T, class U> struct boost::is_member_pointer<U T::* volatile>" is alr ERROR 1 001 /home/jbrisbin/include/boost/type_traits/is_member_pointer.hpp Line 000056 "/home/jbrisbin/include/boost/type_traits/ is_member_pointer.hpp", line 56.63: CZP0403(30) "template <class T, class U> struct boost::is_member_pointer<U T::* const volatile>" ERROR 1 001 2 000051 The full text of the error complains that these are already defined. Does anyone have pointers or tricks that could point me in the right direction to compile programs that use header-only Boost libs on the AS400? Any help would be appreciated! :) Jon Brisbin Portal Webmaster NPC International, Inc.

1 0

[PBGL] and [MTGL]
by Cosimo Calabrese 21 Sep '09

21 Sep '09

Hi to all, I open this discussion as a "branch" of "[BGL] Multithread problem inserting edges and exploring the same graph". Can someone tell me if the PBGL and MTGL can help me? I report my problem below, for sake of comfort. Thanks in advance, Cosimo Calabrese. ************************************************** I've a problem on BGL. My environment is WinXP, Visual Studio 2005, Boost 1.37. I'm trying to use BGL in the following way. I've a single graph in my application, that is an adjacency_list< vecS, vecS, ... >, and I've 2 kind of threads that work on the graph: - some "Explorer" threads, that executes a Dijkstra's algorithm repeatedly; - some "Integrator" thread, that call the add_edge() function repeatedly. The program often crashes, because it cannot dereference some graph elements, some auto_ptr... The crash isn't sistematic, so I think there's a concurrency problem. [...] **************************************************

2 1

Python 3 support has landed on boost trunk
by Stefan Seefeld 21 Sep '09

21 Sep '09

Hi there, as some of you may know, Haoyu Bai has worked over the summer on Python 3 support for Boost.Python. This work happened on a branch, which I merged back into trunk last night. Now we need to set up testers to run the testsuite with some Python 3 variant, as that is a new platform to track. I will see whether I can set one up on one of my machines. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 4

[filesystem] Compatibility with STLPort
by Andrey Semashev 21 Sep '09

21 Sep '09

Hi, I've created ticket #3241 some time ago, with a patch attached. It's about Boost.Filesystem compatibility with STLPort expression templates feature. So far no activity has appeared on it, although the fix is trivial. Is it OK if I go ahead and commit the patch? PS: Ticket URL is https://svn.boost.org/trac/boost/ticket/3241

3 6

unsigned long vs unsigned int vs std::size_t (32b platform)
by Christoph Mathys 21 Sep '09

21 Sep '09

Hello! First: I'm working on 32b Linux (gcc 4.2.4) and 32b XP (Visual Studio 9 SP1). I tried to switch from stdint.h to boost/cstdint.hpp, but had to find out that this is not as straight forward as I thought. The compilers handle 'unsigned int' and 'unsigned long' as different types, even though on 32b it is AFAIK the same type. This by itself is OK, but gcc and VS9 seem to disagree in where it comes to defining std::size_t. The result is that the code at the end compiles on visual studio, but not on gcc: asdf.cpp: In function ‘void someFunc(size_t)’: asdf.cpp:6: error: redefinition of ‘void someFunc(size_t)’ asdf.cpp:5: error: ‘void someFunc(uint32_t)’ previously defined here asdf.cpp: In function ‘int main(int, char**)’: asdf.cpp:16: error: call of overloaded ‘someFunc(long unsigned int&)’ is ambiguous asdf.cpp:4: note: candidates are: void someFunc(uint16_t) asdf.cpp:5: note: void someFunc(uint32_t) In the stdint.h we used for visual studio previously, this error did not occur because uint32_t was typedefd to 'unsigned __int32'. Now, the questions are: - should boost::uint32_t be typedefed to the same thing that std::size_t is on 32b platforms? - Is the size of std::size_t fixed or dependant on the platform it is used on? - Did I do something wrong and there is a much better way of doing it avoiding those problems in the first place? #include <boost/static_assert.hpp> #include <boost/cstdint.hpp> void someFunc(boost::uint16_t) { } void someFunc(boost::uint32_t) { } void someFunc(std::size_t) { } int main(int, char**) { BOOST_STATIC_ASSERT(sizeof (unsigned long) == sizeof (unsigned int)); BOOST_STATIC_ASSERT(sizeof (unsigned long) == sizeof (std::size_t)); unsigned long ul = 42; unsigned int ui = 1337; std::size_t st = 2; someFunc(ul); someFunc(ui); someFunc(st); return 0; }

5 7

[repost][multi_index][serialization][Huang-Vista-x86_32_intel] Help with weird test failure
by joaquin＠tid.es 21 Sep '09

21 Sep '09

Hi, my first attempt went unanswered, reposting in the hope it'll bring more attention this time around: Huang-Vista-x86_32_intel toolset, which runs Intel 11.1 for Window, has this weird error on the serialization test for Boost.MultiIndex: Running 1 test case... ../libs/multi_index/test/test_serialization_template.hpp(82): error in "test_main_caller( argc, argv )": check all_indices_equal(m,m2) failed unknown location(0): fatal error in "test_main_caller( argc, argv )": std::exception: invalid signature (http://tinyurl.com/nd89x2 ) What I find weird is the throwing of invalid_signature, a Boost.Serialization exception that, according to docs, indicates that the beginning of a serialization file is not correct. I can't see how a problem with serializing multi_index_containers can lead to a file signature error. Any clue? Maybe the toolset maintainer can run this manually and provide more info? Thank you in advance, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[Foreach] Proposal to simplify using Boost.Foreach with maps
by Chris Purcell 20 Sep '09

20 Sep '09

As documented in the manual ("Pitfalls"), BOOST_FOREACH is a little awkward to use with associative containers. I've used the following in the past to simplify my own code, and wondered if it was suitable to add to the Boost Foreach library proper. std::map<int, int> my_map; BOOST_FOREACH_PAIR(int key, int value, my_map) std::cout << key << " : " << value << "\n"; The BOOST_FOREACH_PAIR macro is a clone of the BOOST_FOREACH macro with an extra for loop in it to assign both first and second from each pair in the map. If either is not wanted, ignore from Boost.Tuples can be used: std::vector<int> values; BOOST_FOREACH(boost::tuples::ignore, int value, my_map) values.push_back(value); References can be used just as with BOOST_FOREACH, to create a modifying loop: BOOST_FOREACH_PAIR(int key, int& value, my_map) value += key; There are a few alternatives to my solution that I have seen: (1) Predeclare a pair and use it each time around the loop: std::pair<int, int> kv; BOOST_FOREACH(kv, my_map) std::cout << kv.first << " : " << kv.second << "\n"; This adds overhead from copying pairs, and does not give meaningful names to the two halves of the pair. It also has no simple extension to a mutating loop that I am aware of. (2) Typedef the value type of the map before the loop, and use .first and .second: typedef std::pair<const int, int> KeyValue; BOOST_FOREACH(KeyValue const& kv, my_map) std::cout << kv.first << " : " << kv.second << "\n"; This removes the copying overhead, and is easy to change to a mutating loop, but still does not meaningfully name the key and value (3) Use Boost.Tuple's tie to turn the single assignment of BOOST_FOREACH into a double assignment: int key, value; BOOST_FOREACH(boost::tie(key, value), my_map) std::cout << key << " : " << value << "\n" This gives meaningful names, but has copying overhead (albeit not in this simple example). It also has no simple extension to a mutating loop that I am aware of. The key objection to all of these alternatives, from my point of view, is simply that they are unnecessarily complicated. The new macro is much cleaner. Implementation of BOOST_FOREACH_PAIR is simple: turn the innermost assignment loop of BOOST_FOREACH into a pair of loops, one assigning key, one value. Cheers, Chris Purcell

6 11