- Boost - lists.boost.org

Re: Multiton
by Dave Handley 28 Jan '05

28 Jan '05

Jason Hise wrote: > > I agree entirely... which is why I plan to make multiton a sibling class > instead of making the singleton support it with additional policies. It > will live in the same namespace and possibly be able to utilize some of > the same policies that the singleton does (for instance any allocator > that doesn't restrict creation to one instance) Excellent... > Almost. The key passed in to GetInst would be templated, and Child > would be the multiton itself. However, upon further meditation I wonder > if having Child a separate type would be preferable. I guess the > question at hand is how important it is to enforce that there can only > be instances that correspond to a key. With your model, anyone could > easily instantiate a Child. > What I was essentially thinking about was a class that IS actually a singleton, then a class which you inherit off to generate the "multiton" using CRTP in a similar way to the singleton. Essentially your classes would be something like (with slightly better names than my last attempt of Child and multiton): template <class M> class multiton_factory_impl : public singleton<multiton_factory_impl<M> > {}; and class my_multiton : public multiton<my_multiton> {}; template <class M> class multiton { typedef typename multiton_factory_impl<M> multiton_factory public: static M* GetInst( int number ) { return multiton_factory::GetInst()->GetInst( number ); } // All the usual private constructors to force creation through here // along with appropriate friending to support it }; This is slightly better than my last suggestions because the GetInst function is actually in the real multiton, rather than in the singleton. Anyway, I look forward to seeing your implementation. Dave Handley

2 3

Re: Problem Linking to Serialization Libs
by Jared McIntyre 28 Jan '05

28 Jan '05

> Are you including libboost-serialzation.lib (or ?) in your project? > > Robert Ramey Yes, specifically the version I built with multithreaded debug dll (otherwise there are a number of duplicate definition errors). I was trying to use the wide version of the xml archive earlier and was therefore linking to both libboost_serialization.lib and libboost_wserialization.lib, but was running into several more linking failures, so I went to the standard version in hopes of reducing some of the complexity. I forgot to mention in the previous email that these are the static library builds. Jared

1 0

Problem Linking to Serialization Libs
by Jared McIntyre 28 Jan '05

28 Jan '05

I'm having difficult linking to the serailization libraries. Here is the basic setup: Visual Studio 7.1 Boost 1.32 Aerialization libraries built using runtime library : Multithreaded Debug DLL using xml_oarchive & xml_iarchive I'm getting the following linking errors: BusBuild.obj : error LNK2019: unresolved external symbol "public: void __thiscall boost::archive::xml_oarchive_impl<class boost::archive::xml_oarchive>::save(class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > const &)" (?save@?$xml_oarchive_impl@Vxml_oarchive@archive@boost@@@archive@boost@@QAEXABV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z) referenced in function "public: static void __cdecl boost::archive::save_access::save_primitive<class boost::archive::xml_oarchive,class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > >(class boost::archive::xml_oarchive &,class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > const &)" (??$save_primitive@Vxml_oarchive@archive@boost@@V?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@save_access@archive@boost@@SAXAAVxml_oarchive@12@ABV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z) BusBuild.obj : error LNK2019: unresolved external symbol "public: void __thiscall boost::archive::xml_iarchive_impl<class boost::archive::xml_iarchive>::load(class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > &)" (?load@?$xml_iarchive_impl@Vxml_iarchive@archive@boost@@@archive@boost@@QAEXAAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z) referenced in function "public: static void __cdecl boost::archive::load_access::load_primitive<class boost::archive::xml_iarchive,class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > >(class boost::archive::xml_iarchive &,class std::basic_string<unsigned short,struct std::char_traits<unsigned short>,class std::allocator<unsigned short> > &)" (??$load_primitive@Vxml_iarchive@archive@boost@@V?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@load_access@archive@boost@@SAXAAVxml_iarchive@12@AAV?$basic_string@GU?$char_traits@G@std@@V?$allocator@G@2@@std@@@Z) Any ideas of how to get around this?

2 1

devel ML archive stuck again
by Gennadiy Rozental 28 Jan '05

28 Jan '05

Is there direct mal I could use to notify when it happends? Gennadiy

2 1

serialization lib minor suggestion (to Robert Ramey)
by Sergey Skorniakov 28 Jan '05

28 Jan '05

Hello, Robert! I've got a couple of linker error with std::wostream & operator<<(std::wostream &os, const char t) and std::wostream & operator<<(std::wostream &os, const char *t) when defining custom archives and explicitly instantiating them in separate library. Can you declare these operators as inline - its would be more convenient for anyone performing same task? With best regards, Sergey.

2 3

boost::mem_fn
by John Maddock 28 Jan '05

28 Jan '05

Am I right in thinking that boost::mem_fn: 1) Does not inherit from std::unary_function or std::binary_function when it should (as per the TR)? 2) Does not support volatile qualified member functions? Many thanks, John.

4 3

Interfaces Library (structural subtyping)
by christopher diggins 28 Jan '05

28 Jan '05

Several people have told me the technique which I referred to as "retroactive polymorphism" is more correctly labelled "structual subtyping". Christopher Diggins Object Oriented Template Library (OOTL) http://www.ootl.org

1 0

boost/bind.hpp patch (was Re: Compiling boost on tru64 (Richard Hadsell))
by Kevin Wheatley 28 Jan '05

28 Jan '05

Peter Dimov wrote: > Mark Helzer wrote: > > Kewl, that works, I got a little further down the path. Next problem: > > > > cxx: Error: /adp/local/src/boost_1_32_0/boost/bind.hpp, line 206: #266 > > "value" is ambiguous > > Can you please try adding _bi:: in front of value and see if this fixes the > problem? The following patch (against 1.32) certainly allows the MIPS Pro compiler to compile that file without the two ambiguity errors. Kevin -- | Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this | | Senior Technology | My employer for certain | | And Network Systems Architect | Not even myself | --- /tmp/bind.hpp.orig Fri Jan 28 10:56:34 2005 +++ /data/RnD/3rdPartyLibraries/www.boost.org/boost_1_32_0/boost/bind.hpp Fri Jan 28 10:55:52 2005 @@ -203,9 +203,9 @@ A1 operator[] (boost::arg<1> (*) ()) const { return a1_; } - template<class T> T & operator[] (value<T> & v) const { return v.get(); } + template<class T> T & operator[] (_bi::value<T> & v) const { return v.get(); } - template<class T> T const & operator[] (value<T> const & v) const { return v.get(); } + template<class T> T const & operator[] (_bi::value<T> const & v) const { return v.get(); } template<class T> T & operator[] (reference_wrapper<T> const & v) const { return v.get(); }

1 0

[any] ostream inserter
by Sérgio Pace 28 Jan '05

28 Jan '05

Hi, I was playing with the any.hpp library trying to add a generic inserter to an ostrem. To acomplish that I created a pure virtual method print in the placeholder: class placeholder { ... virtual void print(std::ostream& out) const = 0; ... } implemented it in the template holder template<typename ValueType> class holder : public placeholder { ... virtual void print(std::ostream& out) const { out<<held; } ... }; and last but not least I implemented the inserter i the any class: class any { ... friend std::ostream& operator<<(std::ostream& out, const any& data) { data.content->print(out); return(out); }; ... }; this was my first attempt and I expected it to work fine, but to limit the use of any to classes that implement inserters, but I had a nice surprise to find out that as long I don´t actually invoke the inserter on non inserter implementing contained objects everything work fine, at least in bcc 5.5 and gcc(mingw) 3.4.2. when I do use the inserert operator for a nom implementing contained object I get a stack overflow exception, it seens like the inserter operator call the print method and print invoke the any inserter instead of the contained object inserter. Beeing able to strem out a unknow object is a huge plus in my current project and I thing it will be a great addition to the library, but I´m wondering how portable (standard compliant?) is my solution and why this recursive call happens with non inserter objects. Sorry if my explanation was not very clear or bad english, this is my first post in this mailing list and english is not my native language. just mail any need for clarifications. Sérgio

5 8

Is this a legal approach to template definition separation
by JOAQUIN LOPEZ MU?Z 28 Jan '05

28 Jan '05

This is not strictly related to Boost, but its motivation comes from an effort to reduce compilation times for a Boost library, so I'll risk posting the question. Consider the following: // *************** some_class_template.hpp *************** #ifdef INCLUDE_DEFINITION # define BODY_INCLUDED 1 #else # define BODY_INCLUDED 0 #endif #define BODY_DEFINITION(body) BOOST_PP_IF(BODY_INCLUDED,body,;) template<typename ...> class some_template_class { ... void f(...) BODY_DEFINITION(( { // implementation of f goes here } )) ... }; // *************** foo.hpp *************** #include "some_class_template.hpp" class foo { void bar(); private: some_class_template<...> m; }; // *************** foo.cpp *************** #define INCLUDE_DEFINITION #include "user.hpp" void foo::bar() { m.f(); // f is defined, OK to use it. } Well, the idea is to generate in a simple way a declaration only header of a template class from the full definition, for those situations when the definitions are not needed. The purpose is to reduce compilation times in those translations units including foo.hpp, as they won't be using the class template directly. Other, more conventional approaches, like having the definitions of the class template out of line in a separate file, are harder to maintain and proved to be problematic with buggy compilers (MSVC++ 6.5.) Yet another alternative is to use the pimpl idiom, but this has a runtime penalty. My question is: is this ODR compliant? Anyone sees a problem with this approach? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3