October 2005 - Boost-users - lists.preview.boost.org

Boost Graph Library and Boehm Garbage Collector
by FBSL 08 Sep '08

08 Sep '08

Hello I am having trouble to garbage-collect adjacency_list<>. I have instanciated it with correctly garbage-collected vectors and lists (I have copied vecS and listS definitions, and added Boehm GC's default allocator so that they are garbage-collected). In my application I need to dynamically allocate many graphs, but it does not work, there is a (big) memory leak. Unfortunately, there is no template argument in adjacency_list<> to specify Boehm GC's allocator. Does anyone have a hint ? Snippet code "main.cpp" follows, compiled with Boost Graph Library 1.32, Boehm GC 6.4 and G++ 3.3.5, with command line : $ g++ -o main main.cpp -lgc -lgccpp -- #include <boost/graph/adjacency_list.hpp> #include <gc/gc_allocator.h> #include <gc/gc_cpp.h> #include <iostream> #include <vector> #include <list> using namespace std; using namespace boost; namespace boost { struct collected_vecS {}; struct collected_listS {}; template <class ValueType> struct container_gen<collected_vecS, ValueType> { typedef vector<ValueType,gc_allocator<ValueType> > type; }; template <class ValueType> struct container_gen<collected_listS, ValueType> { typedef list<ValueType,gc_allocator<ValueType> > type; }; template <> struct parallel_edge_traits<collected_vecS> { typedef allow_parallel_edge_tag type; }; template <> struct parallel_edge_traits<collected_listS> { typedef allow_parallel_edge_tag type; }; namespace detail { template <> struct is_random_access<collected_vecS> { enum { value = true }; typedef true_type type; }; } } typedef adjacency_list<collected_vecS, collected_vecS, directedS, no_property, no_property, no_property, collected_listS> graph; int main() { // leaks... while(true){ graph * g=new (UseGC) graph; for(unsigned int i=0; i<100; ++i){ add_vertex(*g); } for(unsigned int i=0; i<100; ++i){ for(unsigned int j=0; j<100; ++j){ add_edge(i,j,*g); } } } }

3 4

[statechart] history transitions make state-local-storage "un-cool"
by Mick Hollins 26 Jun '08

26 Jun '08

Apologies if this has been discussed before, but I couldn't find any mention of it: I am currently using the history facility of boost::fsm. I've discovered that when I re-enter a state, X, via a history transition I don't actually re-enter the same instance of X that I was in before, but instead enter a newly constructed instance of X. I just checked the UML spec regarding history transitions and it says that "Any necessary entry actions are performed", so given that boost::fsm uses constructors to represent entry actions I guess a new instance of X has to be constructed to ensure UML compliance. My actual concern is the effect this has on the "coolness" of state-local-storage (see http://boost-sandbox.sourceforge.net/libs/statechart/doc/faq.html#Whats_so_…) It seems to me that state-local-storage, which I agree is generally cool, is particularly un-cool (and bug-inducing) in the presence of history transitions. I'm not sure what a good alternative is, but just thought I'd raise the discussion. cheers, mick PS: does the history facility display the same semantics in boost::statechart? I plan to move to statechart real soon now ...

4 19

BGL: INTERNAL COMPILER ERROR in VC7.1
by Yariv Tal 10 Jun '07

10 Jun '07

This one was already posted by Nicholas Burlett awhile back (see http://lists.boost.org/MailArchives/boost-users/msg06534.php) but I have some new info that may help. The problem: ========= When compiling code that uses the boost.graph library the VC7.1 compiler shouts: c:\boost_1_32_0\boost\mpl\aux_\preprocessed\plain\apply_wrap.hpp(48) : fatal error C1001: INTERNAL COMPILER ERROR As Nicholas already noted, this seems to be due to some compiler problem with the boost.graph out_edge_iterators since it is caused by the following lines in my code: (FilteredGraphGenerator::FilteredGraph is a typedef of a boost::filtered_graph) typedef boost::graph_traits<FilteredGraphGenerator::FilteredGraph> ::out_edge_iterator oedge_iterator; oedge_iterator edgesItr, edgesEnd; boost::tie(edgesItr, edgesEnd) = boost::out_edges(itr->first, m_g.m_filteredGraph); while (edgesItr != edgesEnd) { // do anything! } In fact, it seems to be related to the operator!= between iterators (if the while loop is commented out it compiles). How ever, the error persists even after changing the operator!= to operator== : while (edgesItr == edgesEnd) { // do anything! } ========================================================================== Some findings: =========== * We used to use boost_1_30_0 and the code used to compile PERFECTLY. The problem only appeared after migrating to boost_1_32_0. * Calling directly to the "equal" function in iterator_core_access instead of the operator== works. typedef boost::graph_traits<FilteredGraphGenerator::FilteredGraph> ::out_edge_iterator oedge_iterator; oedge_iterator edgesItr, edgesEnd; boost::tie(edgesItr, edgesEnd) = boost::out_edges(itr->first,m_g.m_filteredGraph); while (boost::iterator_core_access::equal(edgesItr, edgesEnd, boost::mpl::true_())) { // do somthing } * The error message location is at the mpl::apply_wrap2 function. Any relation to the mpl::apply2 function used for declaring the operator== in the BOOST_ITERATOR_FACADE_INTEROP_HEAD macro? Have these functions changed since v1.30.0?

9 8

[BGL] how to actually search with DFS/BFS?
by martin f krafft 22 Nov '06

22 Nov '06

This may seem like a silly question, but how does one actually search with DFS or BFS? Say I want to find the first node for which a predicate returns true in a BFS traversal starting at node N... The function signatures don't have a parameter for "criteria" or "predicate", so I guess it's up for a Visitor to implement such a check. What is not clear to me is how the visitor functions can break out of the search once a condition is true. Thanks, -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus(a)madduck.net "information superhighway" is just an anagram for "i'm on a huge wispy rhino fart".

9 12

Building boost for 64-bit on AIX
by Patrik Jonsson 17 Aug '06

17 Aug '06

Hi, I'm trying to build boost (1.32.0) on an IBM SP2 under AIX5, using the 64-bit ABI. This is troublesome. I do: bjam "-sTOOLS=gcc" "-sGXX=g++ -maix64 -pthread" --prefix=$HOME --libdir=$HOME/lib64-gcc --includedir=$HOME/include-gcc install But it doesn't work. I get loads of errors like: gcc-Link-action bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/libboost_date_time-gcc-d-1_32.so ld: 0711-738 ERROR: Input file bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/greg_month.o: XCOFF32 object files are not allowed in 64-bit mode. collect2: ld returned 8 exit status set -e LIBPATH=bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true:$LIBPATH export LIBPATH "g++" -maix64 -pthread -g -fPIC -shared -o "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/libboost_date_time-gcc-d-1_32.so" "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/greg_month.o" "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/greg_weekday.o" "bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/date_generators.o" ...failed gcc-Link-action bin/boost/libs/date_time/build/libboost_date_time.so/gcc/debug/shared-linkable-true/libboost_date_time-gcc-d-1_32.so... ...skipped <@boost!lib64-gcc>libboost_date_time-gcc-d-1_32.so for lack of <@boost!libs!date_time!build/libboost_date_time.so/gcc/debug/shared-linkable-true>libboost_date_time-gcc-d-1_32.so... It seems it's using -maix64 ok when trying to build the library, but not when compiling... Can anyone tell me what the proper way of building boost under these conditions are? Thanks, /Patrik Jonsson

5 16

case insensitive less_than string comparison
by Matthias Kaeppler 07 Mar '06

07 Mar '06

Hi, I am aware that string_algo has an if_iequal functor. Is there also an equivalent for a less-than comparison? I have to compare strings ignoring the case but taking locales into account. Right now I'm calling boost::algorithm::to_lower on two copies of the original strings. I'm not so sure if this is very efficient when I'm comparing thousands of strings. Here's the functor as it is now: struct FileLessNameA : std::binary_function<const File&,const File&,bool> { bool operator() (const File& lhs, const File& rhs) const { std::string path1( lhs.get_name().c_str() ); std::string path2( rhs.get_name().c_str() ); boost::algorithm::to_lower( path1 ); boost::algorithm::to_lower( path2 ); return path1 < path2; } }; Any suggestions for improvements appreciated :) Regards, Matthias -- Matthias Kaeppler

7 17

MultiArrays of Std::Lists: why const iterators?
by Joshua Schpok 12 Nov '05

12 Nov '05

I want to make a 3D array of std::lists: boost::multi_array<std::list<CSomething>,3> listbin; Then I'd like to actually use those lists: /// Walk through list at x,y,z for(std::list<CSomething>::iterator iter = listbin[x][y][z].begin(); reti != iter[x][y][z].end(); iter++) { iter->m_foo += 42; } But multi_array is giving me back *const* list iterators, producing the error: error: conversion from `std::_List_const_iterator<CSomething>' to non-scalar type `std::_List_iterator<CSomething>' requested Why is this so? I can trick the compiler by doing a cast like: std::list<CSomething>::iterator iter = ((std::list<CSomething>)listbin[x][y][z]).begin(); but this seems to poop out at runtime. Is there a proper way to do this? Joshua Schpok

3 2

[BGL] a.k.a. [Graph] -- bundled properties not compiling for me under MS Dev
by Goldman, Jon 08 Nov '05

08 Nov '05

Hello, I am using Microsoft Development Environment 2002. I am trying to compile a Graph and use bundled properties. The error I am getting: \src\vtkSNL\Applications\RouteViz\rtrGraph.cxx(37) : error C2676: binary '[' : 'SimpleGraph' does not define this operator or a conversion to a type acceptable to the predefined operator \src\vtkSNL\Applications\RouteViz\rtrGraph.cxx(37) : error C2228: left of '.i' must have class/struct/union type The code snippet below exhibits the problem: struct nodeProp { int i; }; struct edgeProp { int i; }; typedef adjacency_list<boost::listS, boost::vecS, boost::bidirectionalS, nodeProp, edgeProp> SimpleGraph; void someFunc() { SimpleGraph someGraph(3); Graph::vertex_descriptor v = *vertices(someGraph).first; someGraph[v].i = 7; // This line is where the error is occuring } Anybody familiar with this problem? Thanks for looking this over, -Jon

2 1

[iostreams] problem with gzip_compressor
by Tiago de Paula Peixoto 07 Nov '05

07 Nov '05

Hello. I've been experiencing the following problem with the gzip_compressor filter: It always writes data down the stream, regardless if any data has been written to the filtering_stream. Consider the following program: -------------------------------------------------------- #include <iostream> #include <fstream> #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/filter/gzip.hpp> using namespace std; using namespace boost; int main() { ofstream file; file.open("hello.gz", ios_base::out | ios_base::app | ios_base::binary); iostreams::filtering_stream<boost::iostreams::output> stream; stream.push(iostreams::gzip_compressor()); stream.push(file); return 0; } -------------------------------------------------------- If compiled as "test", the following behavior is observed: $ ./test; ls -l hello.gz -rw-r--r-- 1 count0 users 8 2005-10-30 19:51 hello.gz $ ./test; ls -l hello.gz -rw-r--r-- 1 count0 users 16 2005-10-30 19:51 hello.gz $ ./test; ls -l hello.gz -rw-r--r-- 1 count0 users 24 2005-10-30 19:51 hello.gz That is, it always adds 8 bytes to the file, despite the fact that nothing was written to the stream. To top things off, the data inside the file isn't even recognizable by gzip: $ gunzip hello.gz gunzip: hello.gz: not in gzip format When bzip2_compressor is used, this strange behavior doesn't happen, and the file remains with 0 bytes. I guess this is a bug, right? I'm using boost 1.33.0 with GCC 4.0.1 in a GNU/Linux system. Thanks for any help. -- Tiago de Paula Peixoto <tiago(a)forked.de>

2 6

Translating an absolute path to a path relative to the current directory
by Hermann Rodrigues 06 Nov '05

06 Nov '05

Hi, I am running into the following problem these days: I need to translate an absolute path to a path relative to the current directory on Windows. The translation process need to include all required ".." directory specifiers in the path to make sure it can be accessed from the current directory. The following path samples may clarify the problem. -------------------------------------------------------------------------------- Current Directory: C:\x\y\z Absolute Path: C:\x\y\z\k\w.txt Translated Path: k\w.txt (C:\x\y\z is a common parent) Current Directory: C:\x\y\z Absolute Path: D:\a\b\c\d.txt Translated Path: D:\a\b\c\d.txt (no common parent found) Current Directory: C:\x\y\z Absolute Path: C:\x\k\w.txt Translated Path: ..\..\k\w.txt (C:\x is a common parent) -------------------------------------------------------------------------------- Is there any built-in support in the boost filesystem library to achieve such translation? At first I thought the path::relative_path could solve my problem but it does not seem to take into account the current directory, only the path itself. Any sugestion? Thanks in advance. Hermann

2 2

design question for boost::program_options and dynamic options
by boost＠nogga.de 02 Nov '05

02 Nov '05

Hello, I'm new to the boost::program_options library and tried to use it for a command pattern based software. The program is launched with the following commandline: > program command [Options] <Files> The program can use different output formatters with --formatter={XML|binary|text}. Every command and formatter specify their own set of options. I first tried to collect all options form the commands and formatters and parse the command line only once. This lead to the problem, that due to the different positional options information the commandline parser always threw an exception due to wrong command line formatting. Since I couldn't find a way to add mutliple optional option groups to the parser, I moved the parsing code into my command base class and query the derived commands for the different required information, like: class Command { public: vritual options_description GetOptionsDescription (); virtual options_description GetHiddenOptionsDescription (); virtual positional_program_options GetPositionalProgramOptions (); virtual Run (variables_map const & vm) = 0; int Execute (std::vector<std:.string> args) { options_description desc; descr.add (GetOptionsDescription ()).add (GetHiddenOptionsDescription ()); variables_map vm; store(command_line_parser(args) .options(desc). .positional(GetPositionalProgramOptions ()) .run(), vm); notify(vm); Run (vm); } } The execute function is called form the program main after the "command" has been stripped from the commandline and the concrete command was created by the factory. So far so good. This works for the different commands, but not for the formatters. How can I parse the command line dynamically? E.g. if I encounter the "--formatter=xml" argument, a new XMLFormatter is created and the options description from this formatter are added to list of valid options? I know, that there is the notify mechanism, but this only works after the commandline has been successfully parsed. And also the custom parsers do not solve my problem. Any idea how to solve this issue? Best regards Dirk

2 2

configuring a library to work with multiple versions of boost
by Ross Boylan 01 Nov '05

01 Nov '05

I have a library that uses boost and also uses a pre-release version of the ptr_container (header only) library that eventually made it into boost 1.33 (I think). I would like people to be able to compile my code with various versions of boost. I've had it working with 1.31 and 1.32, and expect to have it working with 1.33 when that reaches my distribution. I have a subdirectory with the pre-release ptr_container library and some supporting code from elsewhere in boost. This is in a "boost" subdirectory of my project, which has included the directory above that unconditionally in my compilations. With 1.33 I think I want to ignore my local stuff completely. I'm using autoconf and libtool. Are there autoconf macros available for detecting the boost libraries? Do people have any suggestions about the best way to proceed? One possibility that occurs to me is to test for the version of the library at configure time, and make the include path depend on the results. Thanks. Ross Boylan

2 2

ptr_map
by Oleg Smolsky 01 Nov '05

01 Nov '05

Hello Thorsten, thanks for the ptr_vector clarifications. I have another question about ptr_map: I can declare a map iterator in the following way: ptr_map<string, SomeClass>::iterator i = m.begin(); Now, I'd expect to be able to compile the following, as with a normal map: string s = i->first; i->second.SomeMethod(); ...assuming SomeClass::SomeMethod() exists and is declared as public. However, "first" and "second" don't seem to exist in ptr_map. Could you shed some light on how I can iterate your map please? Best regards, Oleg.

2 3

Visual C++ 2005 (8.0) support
by Ovanes Markarian 01 Nov '05

01 Nov '05

Hi all, did someone test boost 1.33 with Visual C++ 2005(8.0)? I am wondering how I can compile the library using jam. Should I use VC++ 7.1 option? Another question. I derived an iterator from the iterator_facade template. As I have recently found out VC++ 8.0 did not support friend template classes, e.g. template<class ....> class my_type { template <class> friend class my_type; ... }; This will not work in VC++ 8.0. Did you know about this issue? Should this be filed as a bug at MS? With Kind Regards, Ovanes Markarian

5 5

How to build Boost for Cygwin (asked the noob)
by Olumide 01 Nov '05

01 Nov '05

Hi - Would someone please give me some (SIMPLE) pointers on how to build Boost for Cygwin. Thanks, - Olumide

2 1

[threads] read_write_mutex and condtion
by Phil Endecott 01 Nov '05

01 Nov '05

Dear All, Is it possible to use a boost::condition in combination with a read_write_mutex? I've tried but failed. This is with 1.32.0. My test code follows. As you can see it can use either a mutex or a read_write_mutex depending on which bits are commented-out. It works as expected with a mutex, but with a read_write_mutex I get a compiler error, shown below. Perhaps I am missing some fundamental reason why conditions can't work with read_write_mutexes. Can someone explain? Thanks, Phil. #include <string> #include <iostream> #include <boost/thread/mutex.hpp> #include <boost/thread/read_write_mutex.hpp> #include <boost/thread/condition.hpp> #include <boost/thread/thread.hpp> #include <boost/bind.hpp> #include <unistd.h> using namespace std; using namespace boost; struct shared_thing { string data; //typedef mutex mx_t; //typedef mutex::scoped_lock read_lock; //typedef mutex::scoped_lock write_lock; typedef read_write_mutex mx_t; typedef read_write_mutex::scoped_read_lock read_lock; typedef read_write_mutex::scoped_write_lock write_lock; mx_t mx; condition cn; shared_thing::shared_thing(void): //mx() mx(read_write_scheduling_policy::writer_priority) {} void writer(void) { while(1) { sleep(1); { write_lock l(mx); data += "."; cn.notify_all(); } } } void reader(void) { while(1) { read_lock l(mx); cn.wait(l); cout << data << endl; } } }; int main(int argc, char* argv[]) { shared_thing t; thread wr_thread(bind(&shared_thing::writer,&t)); t.reader(); } $ g++ -pthread -O -Wall -o condvar condvar.cc -lboost_thread /usr/include/boost/thread/detail/read_write_lock.hpp: In member function `void boost::condition::wait(L&) [with L = boost::detail::thread::scoped_read_lock<boost::read_write_mutex>]': condvar.cc:51: instantiated from here /usr/include/boost/thread/detail/read_write_lock.hpp:297: error: ` boost::read_write_mutex&boost::detail::thread::scoped_read_lock<boost::read_write_mutex>::m_mutex ' is private /usr/include/boost/thread/condition.hpp:92: error: within this context

3 2

Re: [Boost-users] [Multi-Index] composite_key problems
by JOAQUIN LOPEZ MU?Z 31 Oct '05

31 Oct '05

----- Mensaje original ----- De: Andreas Volz <lists(a)brachttal.net> Fecha: Lunes, Octubre 31, 2005 7:27 pm Asunto: Re: [Boost-users] [Multi-Index] composite_key problems > The questions seems to by stupic, but how > could I > access the data looked up by B alone? What should I assign to the > left? > > ??? = es.get<1>().find(b); > > An iterator or what else? This returns an iterator, yep. Please notice that es.get<1>() returns a reference to an index, which is, in many respects, entirely similar to a regular std::set. So you have find(), equal_range() etc. just like in the STL case, with equivalent syntax and semantics. You might want to give the Boost.MultiIndex tutorial a further read --anyway, don't hesitate to come back here if things aren't still clearer. Joaquin M Lopez Muñoz Telefonica, Investigacion y Desarrollo

2 1

Re: [Boost-users] Translating an absolute path to a path relative
by Gottlob Frege 31 Oct '05

31 Oct '05

> > Date: Mon, 31 Oct 2005 09:55:57 -0300 > From: Hermann Rodrigues <hermann.rodrigues(a)gmail.com> > Subject: [Boost-users] Translating an absolute path to a path relative > to the current directory > To: boost-users(a)lists.boost.org > Message-ID: > <497dfc460510310455j1bd56615peffd2f6040fe849e(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > I am running into the following problem these days: > > I need to translate an absolute path to a path relative to the current > directory on Windows. The translation process need to include all > required ".." directory specifiers in the path to make sure it can be > accessed from the current directory. > > Have you tried the Windows functions such as PathRelativePathTo, and its compliment PathCombine?

2 1

[BUG] missing references in docs on web site (threads)
by Ross Boylan 31 Oct '05

31 Oct '05

While reading the web pages for the threads library I noticed some missing references. I don't know if they reflect a problem with the documentation source or a problem with the processing converting the source into html (if there was any such processing). I did check the html source of teh web pages to verify that it wasn't a display problem with my browser. http://boost.org/doc/html/threads.html#id1357380 In "Potentially non-thread-safe functions" this appears: "It is possible to write thread-safe implementations of these by using thread specific storage (see boost::thread_specific_ptr), and several C++ compiler vendors do just that. The technique is well-know and is explained in ." The reference at the end is missing. I thought I saw another example like this in the threads doc, but can't find it now. Also, the quote from Brinch Hansen at the end of http://boost.org/doc/html/threads/rationale.html doesn't indicate the source (though one could at least guess the article from the bibliography, though he's co-author of another one in the bibliography).

1 0

Re: [Boost-users] [Multi-Index] composite_key problems
by Andreas Volz 31 Oct '05

31 Oct '05

Am Mon, 31 Oct 2005 18:14:00 +0100 schrieb JOAQUIN LOPEZ MU?Z: > // lookup by (A,B); > > es.find(make_tuple(a,b)); > > // lookup by A alone > > es.find(make_tuple(a)); > > // lookup by B alone > // note get<1> retrieves the second index. > > es.get<1>().find(b); > > Is the issue clearer now? If not, please tell me > so and I'll try to explain myself a bit further. A little clearer, but not at all. I'm really new to Boost, so I doesn't understand all. The questions seems to by stupic, but how could I access the data looked up by B alone? What should I assign to the left? > ??? = es.get<1>().find(b); An iterator or what else? There was a print_out_by_name function in docs that I tried to adopt, but I failed. And the compile errors are not very helpfull. As normal with template programming :-( regards Andreas

1 0

[Boost.filesystem] Support of Unicode OS ?
by Marc Viala 31 Oct '05

31 Oct '05

Hi, I would like to know if there are some implementations of "Boost.filesystem" to support Unicode OS like Windows XP? We are involved in a large project, we use Boost libraries intensively, version 1.33, and we are looking forward for this mandatory feature. Thanks in advance for your reply. Marc Viala www.acticm.com <http://www.acticm.com> mailto:mviala@acticm.com <mailto:mviala@acticm.com>

1 0

C++ Connections question
by Elisha Berns 31 Oct '05

31 Oct '05

Ok, So this isn't a Boost.X question, but I have to ask since Dave Abrahams is giving two talks at the C++ Connections conference next week. The question is since the sessions, any session not just Dave's, are either only 60 or 75 minutes max, how informative and in depth can they possibly be? It would appear they are only to whet one's appetite for learning something, but that is precisely my question. Thanks for offering an appraisal whether this conference is really worth the bother. Elisha Berns e.berns(a)computer.org tel. (310) 556 - 8332 fax (310) 556 - 2839

2 1

Re: [Boost-users] downcasting shared pointer
by Bjorn.Karlsson＠readsoft.com 31 Oct '05

31 Oct '05

Hello Faheem, > From: Faheem Mitha [mailto:faheem@email.unc.edu] > > It would be nice if there was some method to downcast the shared_ptr > itself. See http://www.boost.org/libs/smart_ptr/shared_ptr.htm#static_pointer_cast for details on how to do just that. Regards, Bjorn Karlsson

2 1

Implementing lock/unlock with boost::thread
by Johan Torp 31 Oct '05

31 Oct '05

I'm trying to implement a class having a lock and an unlock-method. If several different threads call scoped_lock::lock, what is the effect? class AntiRAII{ public: AntiRAII() : mLock(mMutex, false) {} void Lock() {mLock.lock(); } void Unlock() {mLock.unlock();} private: boost::mutex mMutex; boost::mutex::scoped_lock mLock; }; I cannot find any documentation on the behaviour. The usual usage of scoped_lock is one per thread, which is why I'm sceptical to this approach. How can this be implemented? Is it better to expose the mutex? Regards, Johan Torp

3 2

Re: [Boost-users] [Multi-Index] composite_key problems
by JOAQUIN LOPEZ MU?Z 31 Oct '05

31 Oct '05

----- Mensaje original ----- De: Andreas Volz <lists(a)brachttal.net> Fecha: Domingo, Octubre 30, 2005 8:15 pm Asunto: [Boost-users] [Multi-Index] composite_key problems > Hi, > > I like to build a data structure and like to access it with different > keys, so I try multi_index for this. [...] > I hacked the basic example to get this working. My example compiles, > but if I execute it, I get only warnings: > > probe: /usr/include/boost/multi_index/detail/index_iterator.hpp:107: > typename Node::value_type& > boost::multi_index::detail::index_iterator<Node, > Container>::operator*() const [with Node = > Container>boost::multi_index::detail::ordered_index_node<boost:: > multi_index::detail::index_node_base<learnedMeasure> > Container>>, Container = > Container>>boost::multi_index::detail::ordered_index<boost:: > multi_index::composite_key<learnedMeasure, > Container>>boost::multi_index::member<learnedMeasure, std::string, > Container>>&learnedMeasure::measu > .... more warnings > > I put my example code online. Perhaps someone could take a look in it > and help me to find this problem. > > http://cpp.sourceforge.net/?show=9550 > Hello Andreas, I can't compile your source right now, but from the looks of it I cannot see anything wrong. What compiler are you using? If MSVC++ 6.0 or 7.0, take into account they have non-conformances you must take into account when using Boost.MultiIndex, see http://boost.org/libs/multi_index/doc/compiler_specifics.html Your particular code won't work on either of these compilers due to problems with member<> and composite_key that are addresses in the aforementioned page. Is this the problem? If not, I'll try to get back to you in a couple of days. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

regexp: New problem with trailing - in character class
by Greg Ferrar 31 Oct '05

31 Oct '05

Hi, I've been using Boost regexp library forever, and it's great. But I just grabbed 1.33.0 (trying to get it to compile on 64-bit Windows), and I'm getting an error I never got before: it refuses to allow this regular expression: [a-z-] which is supposed to mean "a lower case letter or a dash". Previous versions of Boost regexp allowed this, and grep allows it, and version 1.33.0 does allow this one: [-a-z] Is this a deliberate restriction? It's causing me lots of problems, because my application has a lot of existing regular expressions which use this syntax. This occurs both on x64 with VC8, and on a pretty standard (and old) 32-bit Linux system. I've hacked around it horribly for now by adding this to the top of regcompA (I use the A posix interface exclusively): // HACK by GMF to fix problem that [a-z-] is not accepted as valid, but [-a-z] is. Fix it by moving the dash. char *p = (char*) ptr; while (*p) { printf("p: %c\n", *p); if (*p == '\\') p++; else if (*p == '[') { char *q = p+1; while (*q && (*q != ']')) { printf("*q: %c\n", *q); q++; } if (*q == ']') { q--; if (*q == '-') { memmove(p+2, p+1, (q-p)-1); *(p+1) = '-'; p = q; } } } p++; } but that's very nasty, and probably doesn't work properly anyway, and I'd sure like to get that out of my production code. Help! Greg

2 1

Using iterator_facade from base class with sub classes
by Daniel Lidström 31 Oct '05

31 Oct '05

Hello! I have implemented the iterator_facade for a base class called DataObject. So now I am able to write things like this: boost::shared_ptr<PxyFileData> file(...); const DataObject& points = file->GetPoints(); int num_points = std::distance(points.begin(), points.end()); //! random access iterator A DataObject acts like a tree structure. Each DataObject holds a vector of pointers to children, which are also DataObjects. Now to my problem: A PxyPoint is a sub class to DataObject, and PxyFileData::GetPoints() returns a DataObject where all the children are PxyPoint's. Now I would like to call a member function, PxyPoint::PutSpCode(const char*), on each of the children, like this: void put_sp_code(DataObject&, const char*); void test() { shared_ptr<PxyFileData> file(...); DataObject& points = file->GetPoints(); put_sp_code(points, "spcode"); } void put_sp_code(DataObject& points, const char* code) { std::for_each(points.begin(), points.end(), std::bind2nd(std::mem_fun(&PxyPoint::PutSpCode), code)); } This does not compile (VC 7.1): c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\algorithm(21): error C2664: 'binder2nd<_Fn2>::result_type binder2nd<_Fn2>::operator ()(binder2nd<_Fn2>::argument_type & ) const': cannot convert parameter 1 from 'DataObject' to 'binder2nd<_Fn2>::argument_type & ' with [ _Fn2=mem_fun1_t<void,TPunkt,const char *> ] and [ _Fn2=mem_fun1_t<void,TPunkt,const char *> ] A reference that is not to 'const' cannot be bound to a non-lvalue c:\projects\GEOW\V12\Test\GeoTest\Model Test\ModelTest.cpp(48): see reference to function template instantiation '_Fn1 for_each<iter,binder2nd<_Fn2> >(_InIt,_InIt,_Fn1)' being compiled with [ _Fn1=binder2nd<mem_fun1_t<void,TPunkt,const char *> >, _Fn2=mem_fun1_t<void,TPunkt,const char *>, _InIt=iter ] (error message formatted with STLTask) Is this possible with our design? I would like to be able to do this without having to create a PxyPointList, that derives from DataObject and only stores PxyPoint's (my guess is that something like that would work with this code). Thanks in advance! Regards, Daniel

3 2

Re: [Boost-users] [multi_index] non-intrusive keys
by JOAQUIN LOPEZ MU?Z 31 Oct '05

31 Oct '05

----- Mensaje original ----- De: Adi Shavit <adish(a)gentech.co.il> Fecha: Viernes, Octubre 28, 2005 4:11 pm Asunto: [Boost-users] [multi_index] non-intrusive keys > Hi, > > In my application I used a multi_map of multi_maps as a data > structure to provide indexing with 2 keys, say long strings. Access > is > logarithmic on both keys and the keys are not part of the stored > object, > thus are potentially only stored once. > > I'd like to use multi_index as a more elegant replacement. > However, I'm not clear about where the keys are stored. > > In my app, the keys are stored separately from the data, as the > keys to > maps, as part of the map data structure. > It seems that in multi_index the keys have to be inside the stored > data.In this case, 10 objects with the same key(s) will all have to > hold > copies of the keys (as members). > > Is there a way to avoid this? > I don't think you can avoid duplication of keys --if the keys are really expensive to duplicate, you might consider holding shared_ptrs to them, but this is AFAICS the furthest you can get. Take into acount that a multi_index_container with two keys is not a map of maps. These are different beasts, serving different purposes, * a map of maps applies two concatenated lookups to get to a "terminal" object, * a multi-index container with two indices applies either one of two poosible lookups to get to the object, so you might want to ask yourself whether it makes sense to try to replace your current code with Boost.MultiIndex. What are the advantages / use cases you envision? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Problems comping Boost.Iostreams on Windows with zlib support
by Adam M 31 Oct '05

31 Oct '05

Hi all, I am trying to compile Boost on my Windows 2000 box, but I need to enable the zlib support in Boost.Iostreams for the project I'm working on. I read through the "Getting Started" guide and the Boost.Iostreams docs, and I have done what it says to have zlib support installed, but it's not working. I downloaded the zlib DLL from their website and extracted it to C:/zlib Here's my bjam command line: bjam "-sNO_COMPRESSION=0 -sTOOLS=vc-7_1 -sNO_ZLIB=0 -sZLIB_BINARY=zdll -sZLIB_INCLUDE=C:/zlib/include -sZLIB_LIBPATH=C:/zlib/lib" install When I do that, bjam says: "Building Boost.Iostreams with zlib and gzip support disabled. To enable zlib and gzip, consult the Boost.Iostreams documentation." I thought maybe it was a red herring, so I let the compile finish anyway. However, there's no "libboost_zlib-*" in my Boost/lib folder. Can someone enlighten me as to what I've done wrong here? I'm stumped. Thanks, Adam

2 1

Templates Question
by Surya Kiran Gullapalli 31 Oct '05

31 Oct '05

Hi, I'm writing a templated class, and i dont want to use the class otherthan for some predetermined types, say, int, double etc. This class has no meaning for typenames other than those few. ========================= template <class T> myClass {....} ; myClass<int> intClass ; myClass<float> floatClass ; myClass<char> charClass ; ========================= The compiler should not complain for the first 2 instantiations, but should bail out at the 3rd instantiation (charClass). Is there any way i can achieve this, using standard c++ or boost. I've tried explicit template instantiation, (by passing a flag to my compiler), but in that case, i've to do that for every class suppose i try to invoke std::vector <someOtherClass> someVector; I've to instantiate this also explicitly. (which is a problem for me, because, I use a lot of standard library, and its a pain for me to instantiate every time. Also, if i do the above, i can always instantiate myClass also like this. template class myClass <someOtherClass> ; and which i want to avoid this.. to summarize my question, is there any way i can restrict the compiler to accept only few type names for my templated class (i.e., using standard c++ or boost) Thanks, Surya

4 5

Using a set with kruskal_minimum_spanning_tree
by Jeffrey Holle 30 Oct '05

30 Oct '05

I've sucessfully created an program that uses kruskal_minimum_spanning_tree. I presently give a vector container to this algorithm, which it populates in providing its answer. Now I want to optimize my program by switching to set. For vector, I use "back_inserter(m_spanningTreeEdges)". For set, I've attempted to use "inserter(m_spanningTreeEdges,m_spanningTreeEdges.end())", but this doesn't work. Can somebody tell me the correct way to code this, or tell me that it isn't possible?

1 1

downcasting shared pointer
by Faheem Mitha 30 Oct '05

30 Oct '05

Hi, I was wondering what the recommended way was to downcast shared pointers. I have a a base class, Base, and a derived class Derived. I have a Base shared pointer which points to a Derived object. shared_ptr<Base> d; As part of a unit test, I'm trying to extract the Derived object from it. *static_cast<Derived *>(d.get()); Here I'm extracting the raw pointer, downcasting it to Derived, and then taking the value. It would be nice if there was some method to downcast the shared_ptr itself. Thanks in advance. Please CC me on any reply. Faheem.

1 0

[Multi-Index] composite_key problems
by Andreas Volz 30 Oct '05

30 Oct '05

Hi, I like to build a data structure and like to access it with different keys, so I try multi_index for this. My data structure looks like this: struct learnedMeasure { // target_name + measure_name together is the composite key std::string target_name; std::string measure_name; float negative; float positive; float zero; } I like to access this data structure like this in SQL: SELECT measure, Negative, Positive, Zero from tabelle WHERE target_name='xxx' SELECT Target_name, Negative, Positive, Zero from tabelle WHERE measure_name='xxx' SELECT Negative,Positive,Zero from tabelle WHERE measure_name='xxx' AND Target_name='yyy' I hacked the basic example to get this working. My example compiles, but if I execute it, I get only warnings: probe: /usr/include/boost/multi_index/detail/index_iterator.hpp:107: typename Node::value_type& boost::multi_index::detail::index_iterator<Node, Container>::operator*() const [with Node = Container>boost::multi_index::detail::ordered_index_node<boost:: multi_index::detail::index_node_base<learnedMeasure> Container>>, Container = Container>>boost::multi_index::detail::ordered_index<boost:: multi_index::composite_key<learnedMeasure, Container>>boost::multi_index::member<learnedMeasure, std::string, Container>>&learnedMeasure::measu .... more warnings I put my example code online. Perhaps someone could take a look in it and help me to find this problem. http://cpp.sourceforge.net/?show=9550 regards Andreas

1 0

Problem compiling date_time in Boost 1.33 with STLport 1.4.6 & VC7.1 - log.txt [1/1]
by Didier Malenfant 30 Oct '05

30 Oct '05

I've attached the error log to this message. I've tried searching through the list archive for related problems but came back empty handed (although some posts seem to blame the widechar support?) Any help appreciated. -D x86\bjam.exe "-sTOOLS=vc-7_1-stlport" "-sSTLPORT_PATH=.." "-sPYTHON_ROOT=c:\Python24" ************************************************upport disabled. ECHO To enable bzip2, consul********************************************** ******************************************lib and gzip support disabled. To enable zlientation ****************************************************** Building Boost.Regex wite\build\boost_date_time.dll\vc-7_1-stlport\de of type 'boost::date_time::date_names_put<Co::operator >><Target>(InputStreamable &)' bei Target=boost::date_time::date_names_put<ource=NewSource, InputStreamable=boost::date_time::date_names_put<boost::greg_t>>>::string_type ] C:\wor.hpp(175) : see reference to function templat [ Target=boost::date_time::date_names_put<boost::gregorian::greg_facype, Config=boost::gregorian::greg_facet_config, charT=wchar_t, OutputIterator=_STL::ostreambuf_ Source=const wchar_t * class-template member function 'void boost::type &,const charT *const ) const' wt_1_33_0\libs\date_time\build\../src\gregorian\greg_month.cpp(147) : see reference to clasll_date_names_put<Config,charT>' being compilSTLport-4.6.2\stlport\stdexcept(149) : see re::basic_string<_CharT,_Traits,_Alloc>' being _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(149) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(149) : see reference to class tarT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(149) : see reference to class template i [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(149) _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(149) : see re::basic_string<_CharT,_Traits,_Alloc>' being _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : see reference to class tarT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : see reference to class template i [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : see re::basic_string<_CharT,_Traits,_Alloc>' being _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see reference to class tarT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see reference to class template i [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see re::basic_string<_CharT,_Traits,_Alloc>' being _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see reference to class tarT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see reference to class template i [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see re::basic_string<_CharT,_Traits,_Alloc>' being _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see reference to class tarT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see reference to class template i [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) : see re::basic_string<_CharT,_Traits,_Alloc>' being _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) : see reference to class tarT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) : see reference to class template i [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see re::basic_string<_CharT,_Traits,_Alloc>' being _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see reference to class tarT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see reference to class template i [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see re::basic_string<_CharT,_Traits,_Alloc>' being _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : see reference to class tarT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : see reference to class template i [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : see re::basic_string<_CharT,_Traits,_Alloc>' being _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class template instantiation '_STL::basic_string<_Cha _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexc [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(93) : '_STL::basic_string<_CharT,_Traits,_Alloc>' _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class template instantiation '_STL::basic_string<_CharT,_Traits,_Alloc>' being compor<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to cla with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class templat [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class template instantiation '_STL::basic_string<_CharT,_Traits,_Allc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see r compiled with [ 4.6.2\stlport\stdexcept(85) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class template instantiation '_STL::basic_string<_Cha _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexc [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(85) : '_STL::basic_string<_CharT,_Traits,_Alloc>' _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] "cLINK=1 -DUSE_DATE_TIME_PRE_1_33_FACET_IO -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNINITIALIZED=1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EHsc /GR /MDd /Op /wd4675 /Zc:forScope -I"bin\boos_time\build\../src/gregorian/greg_month.cpp" ped <@boost!libs!date_time!build\boost_date_t of <@boost!libs!date_time!build\boost_date_tte_time!build\boost_date_time.dll\vc-7_1-stlpte_time!build\boost_date_time.dll\vc-7_1-stlp!date_time!build\boost_date_time.dll\vc-7_1-s!date_time!build\boost_date_time.dll\vc-7_1-schar_traits<wchar_t>> ] C:\ : see reference to function template instantrget,Source>::operator >><Target>(InputStream [ Target=boost::date_time::date_names_put<boost::gregorian::greg_facet_conf Source=NewSource, InputStreamable=boost::date_time::date_names_put_STL::ostreambuf_iterator<wchar_t,_STL::char_te_names_put.hpp(175) : see reference to func with [ Target=boost::date_time::date_names_put<boost::gregori>>::string_type, Config=boost::gregorian::greg_facet_config, charT=wchar_t, OutputIterator=_STL:s<wchar_t>>, Source=const wchar_ator>::iter_type &,const charT *const ) constchar_traits<wchar_t>> ] C:\put.hpp(212) : see reference to class templatL::char_traits<wchar_t>> ] src\gregorian\greg_month.cpp(147) : see refer ..\STLport-4.6.2\stlport\stdexcept(149) : see reference to class template instant _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(149) : seeSTL::basic_string<_CharT,_Traits,_Alloc>' bei _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(149) : see referencc_string<_CharT,_Traits,_Alloc>' being compilrT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(149) : see reference to clas_CharT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(149) : see reference to class templat [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(149) : see reference to class template instant _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : seeSTL::basic_string<_CharT,_Traits,_Alloc>' bei _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : see referencc_string<_CharT,_Traits,_Alloc>' being compilrT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : see reference to clas_CharT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : see reference to class templat [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : see reference to class template instant _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(141) : seeSTL::basic_string<_CharT,_Traits,_Alloc>' bei _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see referencc_string<_CharT,_Traits,_Alloc>' being compilrT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see reference to clas_CharT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see reference to class templat [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see reference to class template instant _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : seeSTL::basic_string<_CharT,_Traits,_Alloc>' bei _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see referencc_string<_CharT,_Traits,_Alloc>' being compilrT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see reference to clas_CharT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see reference to class templat [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see reference to class template instant _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : seeSTL::basic_string<_CharT,_Traits,_Alloc>' bei _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see referencc_string<_CharT,_Traits,_Alloc>' being compilrT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see reference to clas_CharT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) : see reference to class templat [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) : see reference to class template instant _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) : seeSTL::basic_string<_CharT,_Traits,_Alloc>' bei _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) : see referencc_string<_CharT,_Traits,_Alloc>' being compilrT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) : see reference to clas_CharT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(117) : see reference to class templat [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see reference to class template instant _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : seeSTL::basic_string<_CharT,_Traits,_Alloc>' bei _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see referencc_string<_CharT,_Traits,_Alloc>' being compilrT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see reference to clas_CharT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see reference to class templat [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see reference to class template instant _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : seeSTL::basic_string<_CharT,_Traits,_Alloc>' bei _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : see referencc_string<_CharT,_Traits,_Alloc>' being compilrT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : see reference to clas_CharT,_Traits,_Alloc>' being compiled _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : see reference to class templat [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : see reference to class template instant _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(101) : seeSTL::basic_string<_CharT,_Traits,_Alloc>' bei _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class template instantiation '_STL::basicchar> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class template i [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class template instantiation '_STL::basic_string<_CharT,_Traits,_Alloc>STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see refempiled with [ .2\stlport\stdexcept(93) : see reference to cng<_CharT,_Traits,_Alloc>' being compiled r, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class template instantiation '_STL::basic_string<_CharT, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept[ _CharT=char, _Tra ..\STLport-4.6.2\stlport\stdexcept(85) : seeSTL::basic_string<_CharT,_Traits,_Alloc>' bei _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class template instantiation '_STL::basicchar> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class template i [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] EBUG -DNDEBUG -DBOOST_ALL_DYN_LINK=1 -DUSE_DATE_TIME_PRE_1_33_FACET_IO -D_STLP_USE_DYNAMIC_LIB=1 /Ogity /O2 /Gs /Ob2 /EHsc /GR /MD /Op\date_time\build\boost_date_time.dll\vc-7_1-soost_date_time.dll\vc-7_1-stlport\release\thrt_date_time-vc71-mt-p-1_33.CMD for lack of <@mt-p-1_33.CMD... ...skipped <@boost!libs!dat::string_type' (or there is no acceptable conputIterator=_STL::ostreambuf_iterator<wchar_t> ] C:\work\boost_1_33_0\boost\lexical_cast.hpp(221) : see reference to detail::lexical_stream<Target,Source>::operatled with [ Target=boost::date_time::date_names_put<boost::greambuf_iterator<wchar_t>>::string_type, Source=NewSource, Inpute ] C:\work\boost_1_33_0\boost\date_time\date_names_put.hpp(175) : see rTarget boost::lexical_cast<boost::date_time::date_names_put<Config,charT,OutputIterator>:: OutputIterator=_STL::ostreambuf1_33_0\boost\date_time\date_names_put.hpp(174Config,charT,OutputIterator>::put_string(boosputIterator=_STL::ostreambuf_iterator<wchar_t> ] C:\work\boost_1_33_0\boost\date_time\date_names_put.hpp(212) : see rst::date_time::date_names_put<Config,charT,Our_t, OutputIterator=_STL::ostreambuf_iterator<wchar_t> ] C: Config=boost::gregorian::greg_facet_config, charT=wchar_t ] ..\STLport-4.6.2\stlport\stdexcept(149\STLport-4.6.2\stlport\stdexcept(149) : see r compiled with [ 4.6.2\stlport\stdexcept(149) : see reference with [ _CharT<char>, _Alloc=_STL::allocator<cport\stdexcept(149) : see reference to class with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(149) : see reference to class template [ _CharT=char, ..\STLport-4.6.2\stlport\stdexcept(149\STLport-4.6.2\stlport\stdexcept(141) : see r compiled with [ 4.6.2\stlport\stdexcept(141) : see reference with [ _CharT<char>, _Alloc=_STL::allocator<cport\stdexcept(141) : see reference to class with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(141) : see reference to class template [ _CharT=char, ..\STLport-4.6.2\stlport\stdexcept(141\STLport-4.6.2\stlport\stdexcept(141) : see r compiled with [ 4.6.2\stlport\stdexcept(133) : see reference with [ _CharT<char>, _Alloc=_STL::allocator<cport\stdexcept(133) : see reference to class with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(133) : see reference to class template [ _CharT=char, ..\STLport-4.6.2\stlport\stdexcept(133\STLport-4.6.2\stlport\stdexcept(133) : see r compiled with [ 4.6.2\stlport\stdexcept(133) : see reference with [ _CharT<char>, _Alloc=_STL::allocator<cport\stdexcept(125) : see reference to class with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(125) : see reference to class template [ _CharT=char, ..\STLport-4.6.2\stlport\stdexcept(125\STLport-4.6.2\stlport\stdexcept(125) : see r compiled with [ 4.6.2\stlport\stdexcept(125) : see reference with [ _CharT<char>, _Alloc=_STL::allocator<cport\stdexcept(125) : see reference to class with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(117) : see reference to class template [ _CharT=char, ..\STLport-4.6.2\stlport\stdexcept(117\STLport-4.6.2\stlport\stdexcept(117) : see r compiled with [ 4.6.2\stlport\stdexcept(117) : see reference with [ _CharT<char>, _Alloc=_STL::allocator<cport\stdexcept(117) : see reference to class with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(117) : see reference to class template [ _CharT=char, ..\STLport-4.6.2\stlport\stdexcept(109\STLport-4.6.2\stlport\stdexcept(109) : see r compiled with [ 4.6.2\stlport\stdexcept(109) : see reference with [ _CharT<char>, _Alloc=_STL::allocator<cport\stdexcept(109) : see reference to class with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(109) : see reference to class template [ _CharT=char, ..\STLport-4.6.2\stlport\stdexcept(109\STLport-4.6.2\stlport\stdexcept(101) : see r compiled with [ 4.6.2\stlport\stdexcept(101) : see reference with [ _CharT<char>, _Alloc=_STL::allocator<cport\stdexcept(101) : see reference to class with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(101) : see reference to class template [ _CharT=char, ..\STLport-4.6.2\stlport\stdexcept(101\STLport-4.6.2\stlport\stdexcept(101) : see r compiled with [ 4.6.2\stlport\stdexcept(93) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class template instantiation '_STL::basic_string<_Cha _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexc [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(93) : '_STL::basic_string<_CharT,_Traits,_Alloc>' _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class template instantiation '_STL::basic_string<_CharT,_Traits,_Alloc>' being compor<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to cla with [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class templat [ _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class template instantiation '_STL::basic_string<_CharT,_Traits,_Allc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see r compiled with [ 4.6.2\stlport\stdexcept(85) : see reference ttring<_CharT,_Traits,_Alloc>' being compiled char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class template instantiation '_STL::basic_string<_Cha _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexc [ _CharT=char, _ "cl" /Zm800 -nologo /EHsc -c -DBOOST_DATE_TIME_STATIC_LINK -DUSE_DATE_TIME_PRE_1_33_FACET_IO -D_STLP_DEBUG=1 -D_STLP_DEBUG_UNte_time\build" -I"..\STLport-4.6.2\stlport" -1_33.CMD for lack of <@boost!libs!date_time!cpp C:\work\boost_1_33_0\boost\lexical_cast.ere is no acceptable conversion) witchar_t, OutputIterator=_STL::ost3_0\boost\lexical_cast.hpp(221) : see referenoost::detail::lexical_stream<Target,Source>:: compiled with [ Target=boost::date_time::date_names_put<boL::ostreambuf_iterator<wchar_t,_STL::char_trarce=NewSource, InputStreamable=b>>>::string_type ] C:\work\boost_1_33_0\boost\date_time\date_names_put.hpp(175) : see reference to function template st::date_time::date_names_put<Config,charT,Ou OutputIterator=_STL::ostreambuf_it C:\work\boost_1_33_0\boost\date_timte_time::date_names_put<Config,charT,OutputItchar_t, OutputIterator=_STL::ost3_0\boost\date_time\date_names_put.hpp(212) :n 'boost::date_time::date_names_put<Config,charT,OutputIterator>' being compiled T=wchar_t, OutputIterator=_STL:: with [ Config=boost::gregorian::greg_facet_config, charT=wchar_t ] ..\STLport-4.6.2\stlport\stdexcept(149) : see refempiled with [ .2\stlport\stdexcept(149) : see reference to with [ _CharT=ch> ] ..\STLport-4.6.2\stlport\stdexcept(149) : see reference to class temth [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexce [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(149) :Lport-4.6.2\stlport\stdexcept(149) : see refempiled with [ .2\stlport\stdexcept(141) : see reference to with [ _CharT=ch> ] ..\STLport-4.6.2\stlport\stdexcept(141) : see reference to class temth [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexce [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(141) :Lport-4.6.2\stlport\stdexcept(141) : see refempiled with [ .2\stlport\stdexcept(141) : see reference to with [ _CharT=ch> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see reference to class temth [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexce [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(133) :Lport-4.6.2\stlport\stdexcept(133) : see refempiled with [ .2\stlport\stdexcept(133) : see reference to with [ _CharT=ch> ] ..\STLport-4.6.2\stlport\stdexcept(133) : see reference to class temth [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexce [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(125) :Lport-4.6.2\stlport\stdexcept(125) : see refempiled with [ .2\stlport\stdexcept(125) : see reference to with [ _CharT=ch> ] ..\STLport-4.6.2\stlport\stdexcept(125) : see reference to class temth [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexce [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(117) :Lport-4.6.2\stlport\stdexcept(117) : see refempiled with [ .2\stlport\stdexcept(117) : see reference to with [ _CharT=ch> ] ..\STLport-4.6.2\stlport\stdexcept(117) : see reference to class temth [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexce [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(117) :Lport-4.6.2\stlport\stdexcept(109) : see refempiled with [ .2\stlport\stdexcept(109) : see reference to with [ _CharT=ch> ] ..\STLport-4.6.2\stlport\stdexcept(109) : see reference to class temth [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexce [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(109) :Lport-4.6.2\stlport\stdexcept(109) : see refempiled with [ .2\stlport\stdexcept(101) : see reference to with [ _CharT=ch> ] ..\STLport-4.6.2\stlport\stdexcept(101) : see reference to class temth [ _CharT=char, ] ..\STLport-4.6.2\stlport\stdexce [ _CharT=char, _ ..\STLport-4.6.2\stlport\stdexcept(101) :Lport-4.6.2\stlport\stdexcept(101) : see refempiled with [ .2\stlport\stdexcept(101) : see reference to with [ _CharT=ch> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class temp,_Traits,_Alloc>' being compiled wit _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class template instantiation '_STL::basic_string<_CharT,_Traits,_lloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : sert-4.6.2\stlport\stdexcept(93) : see referencc_string<_CharT,_Traits,_Alloc>' being compilrT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class template instantiation '_STL::basic_string<_ _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(93) : see reference to class template [ _CharT=char, ..\STLport-4.6.2\stlport\stdexcept(85) _CharT=char, _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class template instantiation '_STL::basic_string<_CharT,_Traits,_Alloc>' being ccator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to with [ _CharT=ch> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class temp,_Traits,_Alloc>' being compiled wit _Traits=_STL::char_traits<char>, _Alloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : see reference to class template instantiation '_STL::basic_string<_CharT,_Traits,_lloc=_STL::allocator<char> ] ..\STLport-4.6.2\stlport\stdexcept(85) : se /Zm800 -nologo /EHsc -c -DBOOST_DATE_TIME_STATIC_LINK -DUSE_DATE_TIME_PRE_1_33_FACET_IO1 -D_STLP_USE_DYNAMIC_LIB=1 /Z7 /Od /Ob0 /EH_time.lib\vc-7_1-stlport\debug\threading-multp Terminate batch job (Y/N)?

2 1

any interest in lightweight version of boost::format
by Oliver Schoenborn 30 Oct '05

30 Oct '05

I know there is a boost::format and it's great. However, I needed something faster and with more "conventional" syntax. That's the coutf library. I've been using it for a few months and it's great. Just to be clear, I'm not suggesting a replacement of boost::format, which has several features that coutf does not. However in many cases you don't need those and that's why coutf is a fair bit faster. Also the syntax is more conventional and several people have mentioned they prefer that. I know Alexandrescu has also created something similar to coutf (I think he called it Printf), but I think mine is lighter, I think most people are not too concerned about not being able to printf 45 parameters, plus it has the Fmt/FmtGuard stuff :) . Anyways the docs and code are at http://noptrlib.sf.net/utils/coutf, just did another update today. Coutf could be a good second alternative to boost::format for some people. Here are some examples of use: coutf("Program started at %s:%s:%s\n", hours, minutes, seconds); cerrf("Error: file %s, line %5s invalid\n", filename, lineNum); std::string msg = strf("Hex of %s is %04Xs", 123, 123); int count = 10; std::ofstream ff("someFile.txt"); // prints array in hex format { FmtGuard fmt(ff, "%0#4x"); for (int i=0;i<count;i++) scoutf( ff, 1 + intArray[i], '\n' ); } // print in dec format scoutf( ff, count ); BOOST_LOG(trace) << strf("File %s at line %s\n", __FILE__, __LINE__); Cheers, Oliver

5 5

64-bit Boost Regression testing.
by Nik Yevik 28 Oct '05

28 Oct '05

Hi, I have built 64-bit Boost libraries on SUSE Linux ES 9 (SLES 9)for IBM POWER/PowerPC(PPC) using gcc 3.3.3 and 3.4.4. in both 32-bit and 64-bit. Now, I also want to run Boost 1.33.0 regresion test with gcc 3.4.4 in 64-bit to see if there are any problems with 64-bit compilation. Regression test helper programs and tests themselves are being built in 64-bit OK. However, the run tests give the error message: ***************************************************** unknown location(0): fatal error in "some_test_name": signal: memory access violation *** errors detected in test suite "Some Test Suite Name"; see standard output for details EXIT STATUS: 200 ***************************************************** I enabled detailed output and here is an example of what I see during the regression test (Just one orbitrary chosen test - the rest show pretty much the same picture).: ****************************************************** MkDir1 ../bin/boost/libs/assign/test/multi_index_container.test mkdir "../bin/boost/libs/assign/test/multi_index_container.test" MkDir1 ../bin/boost/libs/assign/test/multi_index_container.test/gcc mkdir "../bin/boost/libs/assign/test/multi_index_container.test/gcc" MkDir1 ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug mkdir "../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug" MkDir1 ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64 mkdir "../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64" MkDir1 ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power mkdir "../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power" gcc-C++-action ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.o set -e "/home/nik/gcc-3.4.4-ppc-install/bin/g++" -m64 -c -Wall -ftemplate-depth-255 -g -O0 -fno-inline -mcpu=powerpc64 -m64 -I"../bin/boost/libs/assign/test" -I"/home/nik/boost_1_33_0" -I "/home/nik/boost_1_33_0" -o "../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.o" "../libs/assign/test/multi_index_container.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.o" gcc-Link-action ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container set -e LD_LIBRARY_PATH=/home/nik/gcc-3.4.4-ppc-install/lib64:/home/nik/gcc-3.4.4-ppc-install/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH "/home/nik/gcc-3.4.4-ppc-install/bin/g++" -m64 -g -m64 -o "../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container" -L"/home/nik/gcc-3.4.4-ppc-install/lib64" -L"../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc/debug/address-model-64/architecture-power" -L"/home/nik/gcc-3.4.4-ppc-install/lib" "../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.o" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc/debug/address-model-64/architecture-power/libboost_unit_test_framework.a" "../bin/boost/libs/test/build/libboost_unit_test_framework.a/gcc/debug/address-model-64/architecture-power/libboost_unit_test_framework.a" -Wl,-rpath-link,. Chmod1 ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container chmod 711 "../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container" execute-test ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.run LD_LIBRARY_PATH=/home/nik/gcc-3.4.4-ppc-install/lib64:/home/nik/gcc-3.4.4-ppc-install/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH PATH=/home/nik/gcc-3.4.4-ppc-install/lib64:$PATH export PATH ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container > ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.output 2>&1 status=$? echo >> ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.output echo EXIT STATUS: $status >> ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.output if test $status -eq 0 ; then cp -f ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.output ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.run fi verbose=1 if test $status -ne 0 ; then verbose=0 fi if test $verbose -eq 0 ; then echo ====== BEGIN OUTPUT ====== cat ../bin/boost/libs/assign/test/multi_index_container.test/gcc/debug/address-model-64/architecture-power/multi_index_container.output echo ====== END OUTPUT ====== fi exit $status ====== BEGIN OUTPUT ====== Running 1 test case... unknown location(0): fatal error in "test_multi_index_container": signal: memory access violation *** errors detected in test suite "List Test Suite"; see standard output for details EXIT STATUS: 200 ====== END OUTPUT ====== ****************************************************** Indeed, trying to execute the 64-bit executable in gdb gives something like: Error accessing memory address 0x53e00001b5a6: Input/output error. (gdb) where #0 0x000053e00000d932 in ?? () #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) I modified slightly the run-tests.sh script and gcc-tools.jam to regression test in 64-bit. RUN_TESTS.SH: diff run_tests.sh.orig run_tests.sh 18c18 < boost_root="$HOME/CVSROOTs/Boost/boost_regression" --- > boost_root="/home/nik/boost_1_33_0" 134a135 > export LD_LIBRARY_PATH="/home/nik/gcc-3.4.4-ppc-install/lib64" 136c137 < "$bjam" -sTOOLS=$toolset -sBUILD=release run --- > "$bjam" -a -d+2 -sTOOLS=$toolset -sBUILD=release run "-sBUILD=<architecture>power <address-model>64 <library-path>/home/nik/gcc-3.4.4-ppc-install/lib64" 152a154 > export LD_LIBRARY_PATH="/home/nik/gcc-3.4.4-ppc-install/lib64" 154c156 < "$bjam" -sTOOLS=$tool --dump-tests test 2>&1 | tee regress.log --- > "$bjam" -a -d+2 -sTOOLS=$tool "-sBUILD=<architecture>power <address-model>64 <library-path>/home/nik/gcc-3.4.4-ppc-install/lib64" --dump-tests test 2>&1 | tee regress.log GCC_TOOLS.JAM - added two lines: > flags gcc CFLAGS <architecture>power/<address-model>64 : -m64 ; > flags gcc LINKFLAGS <architecture>power/<address-model>64 : -m64 ; What am I missing here? What am I doing wrong? Any help would be greatly appreciated. __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

1 0

[date_time] is it possible to parse a string out from given patterns?
by Roman Morokutti 28 Oct '05

28 Oct '05

Is it possible to parse a date out from a string like this? The example below is from a java program. private static final String PLANSTART_PATTERN = "dd.MM.yyyy HH:mm"; /** * Converts a String of type 01.01.2005 to a * CDate object * @param sForcamDate * @return the converted object */ private CDate convertToCDate(String sForcamDate, String sPattern) { if (sForcamDate == null || sForcamDate.length() == 0) return null; try { SimpleDateFormat sdf = new SimpleDateFormat(sPattern, Locale.getDefault()); sdf.parse(sForcamDate); Calendar cal = sdf.getCalendar(); return new CDate(cal.getTime()); } catch (ParseException ex) { return null; } } For more information on SimpleDateFormat see: http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html

4 6

A basic interior properties question
by Gat, Yoram 28 Oct '05

28 Oct '05

Hi all, I just started using BGL and created the following program (MSVS 7.1), storing some data in an interior property and then retrieving them: #include "boost/graph/adjacency_list.hpp" struct NodeProperties { int a, b, c; }; typedef boost::adjacency_list< boost::listS,boost::listS,boost::undirectedS, boost::property<boost::vertex_all_t,NodeProperties> > Graph; typedef boost::graph_traits<Graph>::vertex_descriptor VertexDescriptor; typedef boost::property_map<Graph,boost::vertex_all_t>::type AllMap; int main(int argc, char const *argv[]) { Graph graph; AllMap allMap = get(boost::vertex_all,graph); VertexDescriptor vd = boost::add_vertex(graph); NodeProperties np; np.a = 1; np.b = 2; np.c = 3; allMap[vd] = np; NodeProperties np1 = allMap[vd]; // const AllMap::value_type &vt = boost::get(allMap,vd); // NodeProperties np1 = vt.m_value; return 0; } For which I get the following error: c:\Documents and Settings\ygat\Desktop\Work\InternalProperty\InternalProperty.cpp(24): error C2440: 'initializing' : cannot convert from 'boost::detail::vertex_property_map<Graph,PropertyTag>::Property' to 'NodeProperties' with [ Graph=Graph, PropertyTag=boost::vertex_all_t ] After some poking around, I discovered that if I replace the offending line with the two commented lines, things work. Is this the right way to retrieve the data? Why can the NodeProperties object be on the rhs but not on the lhs of an assignment to the property map? Thanks, Yoram

1 0

[multi_index] non-intrusive keys
by Adi Shavit 28 Oct '05

28 Oct '05

Hi, In my application I used a multi_map of multi_maps as a data structure to provide indexing with 2 keys, say long strings. Access is logarithmic on both keys and the keys are not part of the stored object, thus are potentially only stored once. I'd like to use multi_index as a more elegant replacement. However, I'm not clear about where the keys are stored. In my app, the keys are stored separately from the data, as the keys to maps, as part of the map data structure. It seems that in multi_index the keys have to be inside the stored data. In this case, 10 objects with the same key(s) will all have to hold copies of the keys (as members). Is there a way to avoid this? I hope I'm clear, Thanks, Adi

1 0

singleton in boost::library?
by Oliver.Kowalke＠infineon.com 28 Oct '05

28 Oct '05

Hello, why no singleton-template is available in boost?

3 2

Boost T-Shirts @ Cafe Press
by Jeff Garland 28 Oct '05

28 Oct '05

Hi All - As everyone is probably already aware, we have a new Boost logo that was created by booster Zoltan 'cad' Juhasz. As part of the final logo refinement process, the moderators asked Zoltan if he could create T-Shirts with the new logo. We also felt it was appropriate that Zoltan be the beneficiary of any proceeds associated with the T-Shirts since it was his tireless work that went into the logo and T-Shirt design. With that in mind, I'm delighted to announce that Zoltan worked out some T-Shirt designs and has set up a couple shops at Cafe Press so that people can purchase Boost T-Shirts. - http://www.cafepress.com/boostlibs - http://www.cafepress.com/boostlibsb If you have suggestions or other ideas you can find Zoltan's contact info at: http://people.inf.elte.hu/cad Jeff

1 0

result_of && VC7.1
by Richard Crossley 27 Oct '05

27 Oct '05

Hi, Experimenting with boost::result_of under VC7.1 and 8... --- template <typename T> struct A{ template <typename F> struct result; template <typename U,typename V> struct result<A(U,V)>{ typedef U type; }; template <typename U,typename V> U operator()(U const&,V const&) { return U(); } }; //typedef A<int>::result<A<int>(int,int)>::type result_; typedef boost::result_of<A<int>(float,char)>::type result; --- c:\boost\boost\utility\result_of.hpp(43) : error C2027: use of undefined type 'A<T>::result<F>' with [ T=int ] and [ F=A<int> (float,char) ] Am I actually using result_of correctly here, or have I misunderstood something? If the result_ typedef is uncommented then it behaves as I would expect. Is there a way to successfully use result_of like this with VC? Thanks, Richard.

1 0

SUN Compiler Feasibility
by Frank Boyle 27 Oct '05

27 Oct '05

Hi Folks, I'm using the sun compiler: CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-15 2003/05/14 I need to generate a high performance logging process and immediately thought of the boost filesystem service. I have downloaded boost_1_33_0. However, I'm getting a lot of compiler problems using the templates which I've since realised are common when using this compiler. i.e. errors relating to boost::iterator_core_access::equal and copious warnings: "/product/3rd_Party/boost/boost_1_33_0/boost/iterator/detail/facade_iterator_category.hpp", line 189: Where: Specialized in boost::detail::facade_iterator_category_impl<boost::bidirectional_traversal_tag, const _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>>, const _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>>&>. "/product/3rd_Party/boost/boost_1_33_0/boost/mpl/eval_if.hpp", line 41: Where: Specialized in boost::mpl::eval_if<boost::detail::is_iterator_category<boost::bidirectional_traversal_tag>, boost::mpl::identity<boost::bidirectional_traversal_tag>, boost::detail::facade_iterator_category_impl<boost::bidirectional_traversal_tag, const _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>>, const _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>>&>>. "/product/cs_common/3rd_Party/boost/boost_1_33_0/boost/iterator/detail/facade_iterator_category.hpp", line 202: Where: Specialized in boost::detail::facade_iterator_category<boost::bidirectional_traversal_tag, const _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>>, const _STL::basic_string<char, _STL::char_traits<char>, _STL::allocator<char>>&>. My question is quite simple: Is it feasible for me to use boost's filesystem utility with this version of the Sun compiler? Should I persist? Many Thanks in advance, Joe ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

2 1

storing templates in boost::mpl::vector instead of complete types
by Oliver.Kowalke＠infineon.com 27 Oct '05

27 Oct '05

Hello, is it possible to store templates instead of complete types in boost::mpl::vector? I want to compose a class out of templates: template< typename B, typename E, typename Comp > struct Scattered; template< typename B, typename E, typename Comp > struct Scattered : public mpl::deref< B >::type< Comp >, // <<== inherit from the template, Comp == Special public Scattered< typename mpl::next< B >::type, E, Comp > {}; template< typename E, typename Comp > struct Scattered< E, E, Comp > {}; template< typename Sequence, typename Comp > struct InheritScattered : public detail::Scattered< typename mpl::begin< Sequence >::type, typename mpl::end< Sequence >::type, Comp > {}; template< typename D > class ReadN { void readn() { D & d = static_cast< D & >( * this); d.some_function(); .... } }; template< typename D > class WriteN { void writen() { D & d = static_cast< D & >( * this); ... } }; temlate< typename TL > struct Basic {}; typedef BaiscX< mpl::vector< ReadN, WriteN > > Special; // <<== composing SpecialX (inherit from ReadN which is a template) Special s; s.readn(); s.writen();

2 1

Re: [Boost-users] multi-inheritance from elements of mpl::vector?==> inherit_scattered ( for Barton & Nackmann trick)
by Oliver.Kowalke＠infineon.com 27 Oct '05

27 Oct '05

>>no reply - so I found a solution by myself (used for the Barton & >> Nackmann trick)! >> template< typename D > >> struct F >> { >> std::string f() >> { return static_cast< D & >( * this).str_; } >> }; >> >> template< typename D > >> struct G >> { >> std::string g() >> { return static_cast< D & >( * this).str_; } >> }; > >That's not the B&N trick; it's simple CRTP. >The B&N trick is the one where you stick a friend function that >applies to the derived class in the base class. See the operators >library for reference. Sorry - in your book (C++ Template Metaprogramming, page 205) I can read: "The technique of using a static_cast with CRTP to reach the derived object is sometimes called the "Barton and Nackmann trick" ...". Is this wrong? So long, Oliver

3 2

filesystem library with SparcWorks compiler?
by Chris Newbold 27 Oct '05

27 Oct '05

It appears that the filesystem library and the SparcWorks compiler have some disagreements. I'm running into the same issues as reported on the regression test page here (an example of which is here: http://tinyurl.com/ey5ld) What I'm wondering is if there are any potential patches to Boost to address these problems or if there is some effort to do so. Alternatively, is the SparcWorks compiler just too busted to deal with this library? -Chris

1 0

ptr_vector problem when storing it inside a map
by Oleg Smolsky 27 Oct '05

27 Oct '05

Hi all, I've just started looking at ptr_vector<> and got stuck on the following issue: putting a boost::ptr_vector<Simple> into a map doesn't compile. See the following test case: class Simple { public: virtual ~Simple() { } void foo() { doFoo(); } protected: virtual void doFoo() { } }; void Test() { std::map<std::string, boost::ptr_vector<Simple> > map; map["key"].push_back(new Simple); } I'm using VS2005 RC1 (8.0.50727.26) and the compiler output is as follows: 1>c:\work\3rd-party\boost\include\boost-1_33\boost/ptr_container/ptr_sequence_adapter.hpp(595) : error C2248: 'boost::ptr_container_detail::reversible_ptr_container<Config,CloneAllocator>::reversible_ptr_container' : cannot access private member declared in class 'boost::ptr_container_detail::reversible_ptr_container<Config,CloneAllocator>' 1> with 1> [ 1> Config=boost::ptr_container_detail::sequence_config<Simple,std::vector<void *,std::allocator<void *>>>, 1> CloneAllocator=boost::heap_clone_allocator 1> ] 1> c:\work\3rd-party\boost\include\boost-1_33\boost/ptr_container/detail/reversible_ptr_container.hpp(294) : see declaration of 'boost::ptr_container_detail::reversible_ptr_container<Config,CloneAllocator>::reversible_ptr_container' 1> with 1> [ 1> Config=boost::ptr_container_detail::sequence_config<Simple,std::vector<void *,std::allocator<void *>>>, 1> CloneAllocator=boost::heap_clone_allocator 1> ] 1> This diagnostic occurred in the compiler generated function 'boost::ptr_sequence_adapter<T,VoidPtrSeq,CloneAllocator>::ptr_sequence_adapter(const boost::ptr_sequence_adapter<T,VoidPtrSeq,CloneAllocator> &)' 1> with 1> [ 1> T=Simple, 1> VoidPtrSeq=std::vector<void *,std::allocator<void *>>, 1> CloneAllocator=boost::heap_clone_allocator 1> ] Can anybody shed some light on the subject? Thanks, Oleg.

3 4

[ptr_container] warnings about shadowed members
by Samuel Landau 27 Oct '05

27 Oct '05

Hello, I am trying Boost 1.33 ptr_container with GCC 4.0.1 on Linux. When including a ptr_container header (say, ptr_vector.hpp), compiling code with the "-Wshadow" flag, some warnings are issued about shadowed members. I am wondering if this might be a problem, even if my snippet code compiles and seems to run fine so far for me. output example (with boost/ in current directory) : $ cat main.cpp #include <boost/ptr_container/ptr_vector.hpp> int main() {} $ g++ -I. -Wshadow main.cpp ./boost/ptr_container/detail/move.hpp: In constructor 'boost::ptr_container_detail::move_ptrs::move_source<Ptr>::move_source(Ptr&)': ./boost/ptr_container/detail/move.hpp:18: warning: declaration of 'ptr' shadows a member of 'this' ./boost/ptr_container/detail/static_move_ptr.hpp: In member function 'void boost::ptr_container_detail::static_move_ptr<T, Deleter>::check(const +boost::ptr_container_detail::static_move_ptr<TT, DD>&)': ./boost/ptr_container/detail/static_move_ptr.hpp:156: warning: declaration of 'ptr' shadows a member of 'this' ./boost/ptr_container/exception.hpp: In constructor 'boost::bad_ptr_container_operation::bad_ptr_container_operation(const char*)': ./boost/ptr_container/exception.hpp:27: warning: declaration of 'what' shadows a member of 'this' ./boost/ptr_container/exception.hpp: In constructor 'boost::bad_index::bad_index(const char*)': ./boost/ptr_container/exception.hpp:41: warning: declaration of 'what' shadows a member of 'this' ./boost/ptr_container/detail/reversible_ptr_container.hpp: In member function 'ForwardIterator +boost::ptr_container_detail::reversible_ptr_container<Config, CloneAllocator>::advance(ForwardIterator, typename Config::void_container_type::size_type)': ./boost/ptr_container/detail/reversible_ptr_container.hpp:287: warning: declaration of 'begin' shadows a member of 'this' -- Samuel Landau

2 1

[boost-users] [MPL.Math] gcd_impl improved
by Cromwell Enage 27 Oct '05

27 Oct '05

The gcd_impl specialization for integral constants is now based on the binary GCD algorithm. BOOST_STATIC_CONSTANT is now used over typedef at most intermediate steps. You should see much faster compile times, at least for the gcd_lcm test and example programs. Cromwell D. Enage __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com

1 0

Re: [Boost-users] multi-inheritance from elements of mpl::vector? ==> inherit_scattered ( for Barton & Nackmann trick)
by Oliver.Kowalke＠infineon.com 27 Oct '05

27 Oct '05

>Is there a page somewhere that describes the trick, just out of interest >like. C++ Template Metaprogramming, page 205 Modern C++ Design, somewhere AFAIK - Barton & Nackmann trick is used for class composition: template< typename Derived > struct Add { int add() { // B & N-trick: access to the Composed class D & d = static_cast< Derived & >( * this); return d.first() + d.second(); } }; struct First { int first() { return 1; } }; struct Second { int second() { return 2; } }; class Composed : inherit_scattered< vector< First, Second, Add< Composed > > > {}; void main() { Composed c; Std::cout << c.add() << std::endl; }

2 1