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

compile error
by Eyal Inbar 28 Mar '05

28 Mar '05

Hello I download boost to window2000 OS and run the quick_tour.cpp on VC++ 6 without trouble. But when i run it on linux with KDevelop i get /usr/local/include/boost/iterator/iterator_adaptor.hpp:218: template instantiation exceeds maximum of 17 (use -ftemplate-depth-NN to increase the maximum) instantiating 'struct boost::mpl::eval_if<boos::is_convertible<random_access_itarator_tag, boost::incrementable_traversal_tag>,boost::mpl::identity<random_access_iterator_tag>, boost::detail::old_category_to_traversal<random_access_iterator_tag> >' help! eyal

2 1

boost/config.hpp: No such file or directory in 1.32
by Ross Boylan 25 Mar '05

25 Mar '05

With boost 1.32, but not 1.31, I get the following errors g++ -I /home/ross/peter/R/mspath/src -I/usr/lib/R/include -std=c++98 -Wall -I/usr/lib/R/include -MMD -MF /home/ross/peter/R/mspath/src/depends/ConstrainedCoefficients.d -MP -g -O2 -c -o ConstrainedCoefficients.o /home/ross/peter/R/mspath/src/trueSrc/ConstrainedCoefficients.cc In file included from /home/ross/peter/R/mspath/src/boost/smart_container/ptr_map_adapter.hpp:22, from /home/ross/peter/R/mspath/src/boost/smart_container/ptr_map.hpp:23, from /home/ross/peter/R/mspath/src/trueSrc/ScratchPad.h:7, from /home/ross/peter/R/mspath/src/trueSrc/ScratchDataProducer.h:5, from /home/ross/peter/R/mspath/src/trueSrc/ConstrainedCoefficients.h:9, from /home/ross/peter/R/mspath/src/trueSrc/ConstrainedCoefficients.cc:2: /home/ross/peter/R/mspath/src/boost/smart_container/detail/map_iterator.hpp:22:28: warning: boost/config.hpp: No such file or directory /home/ross/peter/R/mspath/src/boost/smart_container/detail/map_iterator.hpp:23:31: warning: boost/operators.hpp: No such file or directory In file included from /home/ross/peter/R/mspath/src/boost/smart_container/ptr_map_adapter.hpp:22, from /home/ross/peter/R/mspath/src/boost/smart_container/ptr_map.hpp:23, from /home/ross/peter/R/mspath/src/trueSrc/ScratchPad.h:7, from /home/ross/peter/R/mspath/src/trueSrc/ScratchDataProducer.h:5, from /home/ross/peter/R/mspath/src/trueSrc/ConstrainedCoefficients.h:9, from /home/ross/peter/R/mspath/src/trueSrc/ConstrainedCoefficients.cc:2: /home/ross/peter/R/mspath/src/boost/smart_container/detail/map_iterator.hpp:34: error: parse error before `<' token /home/ross/peter/R/mspath/src/boost/smart_container/detail/map_iterator.hpp:39: error: syntax error before `;' token etc. This is using a pre-release version of the smart container (now indirect iterator, I think) library. 1.31 was current at the time of the pre-release. I've searched the list other places, but haven't found any clues to what's going on. Does anyone have any ideas? This is on Debian; is it possible these files have been inadvertently deleted? My /usr/include/boost/ directory does not have operators.hpp, though it is in some subdirectories (e.g., lambda/detail/). -- Ross Boylan wk: (415) 502-4031 530 Parnassus Avenue (Library) rm 115-4 ross(a)biostat.ucsf.edu Dept of Epidemiology and Biostatistics fax: (415) 476-9856 University of California, San Francisco San Francisco, CA 94143-0840 hm: (415) 550-1062

4 4

smart_ptr and self-referencing objects?
by edA-qa mort-ora-y 25 Mar '05

25 Mar '05

I am in the process of converting a library of ours (which used a Refcounting mechanism for shared objects) to be buildable on top of the boost smart_ptr library*. What feature I am having the most difficulty with is the ability for an object to refer to itself and be properly shared. That is, by quick example: ///////////////////////////// class A { void Do( B* b ) { b->Add( this ); } //trouble line } class B { vector::shared_ptr<A> items; void Add( A* a ) { items.push_back( a ); } } ... shared_ptr<A> a( new A() ); shared_ptr<B> b( new B() ); a->Do( b ); //hidden problems /////////////////////////////// In the trouble line I am having a problem since I need to refer to this, but it will not be referring to the shared_ptr wrapper on the object. Thus it will end up being delete'd twice. Since I already need to derive from shared_ptr to implement additional features I do have some possible options (such as each object containing a weak reference to itself), but they all have particular drawbacks. Is there a good method for resolving this problem? *I'm doing this since I have no more interest in maintaining the cross-platform aspects of our own library (though it works with PThreads and Win32). And because I don't want to have to instrument my objects with their own ref-counting (one of my solutions to the above however requires this instrumenting nonetheless, but not on all objects). -- edA-qa mort-ora-y Idea Architect http://disemia.com/

4 3

[signals] Compiler warnings with BOOST_ALL_DYN_LINK
by Klaus Nowikow 25 Mar '05

25 Mar '05

Hello, I have a problem using Boost.Signals. With this test program: <code> // See the previous thread regarding // "[regex] Unresolved external symbols under VC7.1 w/ dynamic linking #define BOOST_ALL_DYN_LINK #include <boost/signals.hpp> int main(int argc, char* argv[]) { return 0; } </code> I get some compiler warnings under MSVC 7.1 / Boost 1.32. Is there something I can do about it? Here is the compiler output I get: c:\dev\Libraries\Boost\include\boost-1_32\boost\signals\connection.hpp(111) : warning C4251: 'boost::signals::connection::con' : class 'boost::shared_ptr<T>' needs to have dll-interface to be used by clients of class 'boost::signals::connection' with [ T=boost::signals::detail::basic_connection ] c:\dev\Libraries\Boost\include\boost-1_32\boost\signals\trackable.hpp(55) : warning C4251: 'boost::signals::trackable::connected_signals' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::signals::trackable' with [ _Ty=boost::signals::connection ] c:\dev\Libraries\Boost\include\boost-1_32\boost\signals\slot.hpp(51) : warning C4251: 'boost::signals::detail::slot_base::data' : class 'boost::shared_ptr<T>' needs to have dll-interface to be used by clients of class 'boost::signals::detail::slot_base' with [ T=boost::signals::detail::slot_base::data_t ] c:\dev\Libraries\Boost\include\boost-1_32\boost\signals\detail\named_slot_map.hpp(100) : warning C4251: 'boost::signals::detail::named_slot_map_iterator::impl_' : class 'boost::scoped_ptr<T>' needs to have dll-interface to be used by clients of class 'boost::signals::detail::named_slot_map_iterator' with [ T=boost::signals::detail::named_slot_map_iterator::impl ] c:\dev\Libraries\Boost\include\boost-1_32\boost\signals\detail\named_slot_map.hpp(129) : warning C4251: 'boost::signals::detail::named_slot_map::impl_' : class 'boost::scoped_ptr<T>' needs to have dll-interface to be used by clients of class 'boost::signals::detail::named_slot_map' with [ T=boost::signals::detail::named_slot_map::impl ] c:\dev\Libraries\Boost\include\boost-1_32\boost\signals\detail\signal_base.hpp(40) : warning C4251: 'boost::signals::detail::call_notification::impl' : class 'boost::shared_ptr<T>' needs to have dll-interface to be used by clients of class 'boost::signals::detail::call_notification' with [ T=boost::signals::detail::signal_base_impl ] c:\dev\Libraries\Boost\include\boost-1_32\boost\signals\detail\signal_base.hpp(114) : warning C4251: 'boost::signals::detail::signal_base_impl::combiner_' : class 'boost::any' needs to have dll-interface to be used by clients of class 'boost::signals::detail::signal_base_impl' c:\dev\Libraries\Boost\include\boost-1_32\boost\any.hpp(22) : see declaration of 'boost::any' c:\dev\Libraries\Boost\include\boost-1_32\boost\signals\detail\signal_base.hpp(120) : warning C4275: non dll-interface class 'boost::noncopyable_::noncopyable' used as base for dll-interface class 'boost::signals::detail::signal_base' c:\dev\Libraries\Boost\include\boost-1_32\boost\noncopyable.hpp(22) : see declaration of 'boost::noncopyable_::noncopyable' c:\dev\Libraries\Boost\include\boost-1_32\boost\signals\detail\signal_base.hpp(120) : see declaration of 'boost::signals::detail::signal_base' c:\dev\Libraries\Boost\include\boost-1_32\boost\signals\detail\signal_base.hpp(150) : warning C4251: 'boost::signals::detail::signal_base::impl' : class 'boost::shared_ptr<T>' needs to have dll-interface to be used by clients of class 'boost::signals::detail::signal_base' with [ T=boost::signals::detail::signal_base_impl ] Best, Klaus -- Klaus Nowikow DECOMSYS - Dependable Computer Systems Development Engineer Stumpergasse 48/14, A-1060 Wien, Austria Phone: +43 1 59983-31 Fax: +43 1 59983-731 http://www.decomsys.com

2 1

Partial template specialization of template functions
by Davi de Castro Reis 24 Mar '05

24 Mar '05

Hi all, I am trying to specialize some (non-trivial) function templates, but I am getting a lot of unexpected compile errors. These are functions with a template parameter that can not be inferred by parameters types and needs to be explicitly set at the function call. Can someone give me some light? Read on for a more in-depth explanation. Below we have a traditional partial specialization. This compiles and works fine. //Generic function template <class T, class U> void f(T a, U b) {} //Partial specialization template <class U> void f(int a, U p) {} int main(int argc, char **argv) { long a, b; int c; f(a, b); //call the generic function f(c, b); //call the partial specialization } So the code above is ok. Now let us create a "template function", one where you can not infer one of the template parameter just by the parameters types: //Generic "template function" template<class X, class T, class U> void f(T a, U b) {} int main(int argc, char **argv) { long a, b; int c; f<long>(a, b); //calls generic "template function" f<long>(a, c); //calls generic "template function" } The code above also works fine. Now I want to mix both things, and this is where the problem arises. See the code: //Generic "template function" template<class X, class T, class U> void f(T a, U b) {} //"template function" partial specialization template<class X, class U> void f(int a, U b) {} int main(int argc, char **argv) { long a, b; int c; f<long>(a, b); //calls generic "template function" f<long>(c, b); //should call "template function" specialization } But the second function call above, surprisingly, does not compile: g++ test2.cc test2.cc: In function `int main(int, char**)': test2.cc:19: error: call of overloaded `f(int&, long int&)' is ambiguous test2.cc:8: error: candidates are: void f(T, U) [with X = long int, T = int, U = long int] test2.cc:12: error: void f(int, U) [with X = long int, U = long int] Same results using intel compiler: davi@supermaquina cxx4ever $ icc -w test2.cc test2.cc(19): error: more than one instance of overloaded function "f" matches the argument list: function template "f<X,T,U>(T, U)" function template "f<X,U>(int, U)" argument types are: (int, long) f<long>(c, b); //should call "template function" partial specialization ^ So, what is happening here? I do agree that this is ambiguous, but the most specific case should be chosen, as it happens with the traditional template specialization (which is also ambiguous until you choose the more specific code). What makes me think that I am missing something is that both compilers says that f() is overloaded. But it should not be. This should be a partial specialization, not an overload. Well, that is it. Some tips? Thanks in advance, Davi de Castro Reis

2 1

[rational] Announcing new maintainer -- call for feature requests
by Jonathan Turkanis 24 Mar '05

24 Mar '05

Dear All, Several months ago I became the official maintainer of Boost.Rational, and am just now getting around to considering proposed modifications to the library. I would like to know: 1. Do people use Boost.Rational, and if so, what is it used for, and with what template parameters? 2. What changes or additions would people like to see? Here are the changes that have been proposed: A. [me and others] Make int_type (and possibly param_type) public. This will be done. B. [Andras Erdei] Make rational more usable with limited precision integral types by providing automatic rounding when the result of a computation can not be represented exactly, or by asserting or throwing an exception in such cases. C. [Andras Erdei] Provide automatic selection of the underlying int_type which would be fastest for representing rational arithmetic with a specified precision. ---- Proposal B Andras's original proposal, if I understood it correctly, was to use a form of rounding which could be computed as the natural side-effect of the existing algorithm to compute a rational arithmetic operation, in the case that the actual result could not be represented exactly using the underlying int_type. At the time, I questioned whether it would be acceptable to change the current behavior of rational, since some current users may be relying on it. This is partly why I am asking question 1) above. A more general solution would be to add an optional template parameter representing a rounding policy, which could - implement no rounding, silently resulting garbage in some cases (this is the current implementation) - implement Andras's rounding method - throw an exception if rounding would be required - assert if rounding would be required, or - (possibly) implement some other rounding algorithm The reason I qualified the last option with "possibly" is that implementing alternate rounding policies may require completely different algorithms for the basic operations, meaning that the implementations of the basic operations would have to be moved into the rounding policy, which I'm reluctant to do. Andras, please let me know if I have misrepresented your ideas. For background, see these threads: http://lists.boost.org/MailArchives/boost/msg76375.php http://lists.boost.org/MailArchives/boost/msg80121.php ---- Jonathan

1 0

Boost.Thread: how to query the state of a thread
by Malte Starostik 24 Mar '05

24 Mar '05

{to moderator: sorry, picked the wrong sender address last time, this one is subscribed} Hi, looking through the docs I can't seem to find a way to query boost::thread whether it's still running or has terminated and if so if it's still joinable. Is that information available somehow or do I need to keep track myself? TIA, Malte

2 1

Finding member offset in compile time
by Davi de Castro Reis 24 Mar '05

24 Mar '05

Hi all, The question I have is not boost specific (maybe not even boost related), so if you think it is not appropriate to ask it here, please, please just tell me. So, here it goes. Is it possible to find the offset of a class member in compile time? In runtime, I can get the offset of member m1 in class A with the code offset = ((A *)0)->m1 But I want this value in compile time to use in some template metaprogramming. Is this possible? Since sizeof() is compile time, I suspect there is a way to do it. This would come very in hand for a metaprogramming based serialization library I am working on. Thanks in advance, Davi de Castro Reis If it is not appropriate to ask such questions here, could someone point me a C++ list where I could ask some advanced questions?

4 5

[typeof] submission updated
by Arkadiy Vertleyb 24 Mar '05

24 Mar '05

Hi all, My mail client seems to fail to CC this here, so I am re-posting: The typeof submission in the Boost sandbox file vault has been updated to include a fix allowing faster compiles with GCC (in emulation mode), as well as a workaround for what seems to be remains of ETI bug in VC71. Please take it at: http://boost-sandbox.sourceforge.net/vault/, typeof.zip. Regards, Arkadiy

1 0

BGL: remove_edge fails under certain circumstances
by Jean Utke 24 Mar '05

24 Mar '05

Hi, I noticed that with boost 1.32 under gcc 3.4.3 there are cases when remove_edge fails to remove the edge in question. I put this with all kinds of details on bugtracker under http://sourceforge.net/tracker/index.php?func=detail&aid=1166401&group_id=7… In short the problem appears to be the use of std::equal_range in the code for remove_edge. With a certain order of the vertex and edge creation it happens that equal_range returns an (end_of_list,end_of_list) pair instead of the range that includes the edge in question. I believe this is due to the list not being ordered according to the same "<" operator that std::equal_range invokes. So equal_ranges logic doesn't find the proper range, and remove_edge simply returns without warning and without removing the edge in question. There is more detail in the bug report mentioned above. I am just wondering about a good workaround. Currently I am considering to replace the equal_range call in my copy of the source but there may be a better way. ? Jean -- Jean Utke Argonne National Lab./MCS utke(a)mcs.anl.gov phone: 630 252 4552 cell: 630 363 5753

2 3