- Boost-users - lists.boost.org

[C++ Template Metaprogramming] Selected Answers Posted
by David Abrahams 28 Mar '05

28 Mar '05

Ariel Badichi has generously established a wiki page containing his answers to many of the exercises in the book "C++ Template Metaprogramming: Concepts, Tools, and Techniques from Boost and Beyond" by me and Aleksey Gurtovoy. Please see the book's home page at http://www.boost-consulting.com/metaprogramming-book.html for details. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 1

RE: [Boost-users] compile error
by Eyal Inbar 28 Mar '05

28 Mar '05

Thanks But how and where can i changed the flag in g++ ? eyal -----Original Message----- From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org]On Behalf Of Malte Starostik Sent: Monday, March 28, 2005 5:37 AM To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] compile error Eyal Inbar schrieb: > 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) ^^^^^^^^^^^^^^^^^^^ here... > 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> >' ...it tells you what to do. The C++ standard speficies a limit of 17 for recursively nested template instantiations. To have g++ accept deeper nested templates, add sth. like -ftemplate-depth-20 (or more than 20 as needed) to the compile command (CXXFLAGS). Now I wonder whether "recursively nested" applies only to a< a< a< a< ... > > > > or also to a< b< c< d< ... > > > > and g++ misinterpreted that... HTH, Malte _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

2 1

[mpl] instantiating long_<MAX_LONG> generates warning on VC7.1/.NET
by Yariv Tal 28 Mar '05

28 Mar '05

On Visual Studio.NET / VC7.1 the following code: #include <boost/mpl/long.hpp> #include <climits> boost::mpl::long_<LONG_MAX> lll; Gives the following warning: ...\boost_1_32_0\boost\mpl\aux_\integral_wrapper.hpp(72) : warning C4307: '+' : integral constant overflow ...\main.cpp(39) : see reference to class template instantiation 'boost::mpl::long_<N>' being compiled with [ N=2147483647 ] Obviously, the compiler is right about the overflow, and, IMHO, the same holds for using any maximal/minimal value for a specific type. Is this a known issue? Does it cause any actual problems? (in other words: can I ignore the warning? always? sometimes? never?) Thanks, Yariv Tal.

1 0

Boost.program_options config files
by Sean DeNigris 28 Mar '05

28 Mar '05

Is there an easy way to work with Boost.program_options config files? I want to be able to write option values to the file programmatically.

2 1

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