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

Boost.Test - problems overriding main
by ramonpadilla1＠yahoo.co.uk 10 Sep '15

10 Sep '15

I want to provide my own main function while using Boost.Test. So I have included the following macros: #define BOOST_TEST_ALTERNATIVE_INIT_API #define BOOST_TEST_NO_MAIN In my main function I have a call to: ::boost::unit_test::unit_test_main(&registering_all_tests, argc, argv) but this gives me the following error when build on OS X using Xcode 6: Undefined symbols for architecture x86_64: "boost::unit_test::unit_test_main(bool (*)(), int, char**)", referenced from: _main in main.o I found out that including the following file: #include <boost/test/included/unit_test.hpp> resolves this problem but I'm confused about the implications. The description of this file states that it uses the included (vs. linked) version of Unit Test Framework. The Boost getting started guide states that: > Boost.Test can be used in “header-only” or “separately compiled” mode,> although **separate compilation is recommended for serious use**. I have built the library separately. The Boost doc also states: > Including the UTF directly into your test module> > If you prefer to avoid the standalone library compilation you can> either include all files that constitute the static library in your> test module's makefile or include them as a part of a test module's> source file. To facilitate the later variant the UTF presents the> single-header usage variant. In either case no special build options> or macro definitions are required to be added to your compilation> options list by default. But the same flags that can be used for the> standalone library compilation are applicable in this case. Though,> obviously, neither BOOST_TEST_DYN_LINK nor BOOST_TEST_NO_LIB are> applicable. This solution may not be the best choice in a long run,> since it requires the UTF sources recompilation for every test module> you use it with and for every change of a test module you are working> on. In a result your testing cycle time may increase. If it become> tiresome, I recommend switching to one of the prebuilt library usage> variants. It seems that by choosing to include the included (vs. linked) version of Unit Test Framework I am dong the wrong thing. Can someone please clarify the correct approach. The examples of overriding main don't mention the need to do this.

2 4

Boost serializing abstract base class
by John King 08 Sep '15

08 Sep '15

I'm having trouble serializing a few classes with boost serialization. I've looked through different documentation and I've found it pretty confusing. Some say that you have to include certain libraries in a certain order, others say you have to use BOOST_SERIALIZATION_BASE_OBJECT_NVP, others boost::serialization::base_object, etc. I've also seen some use BOOST_CLASS_EXPORT() but I don't want to have to list every single possible derived class... The code: *main.cpp:* #include <iostream> #include <memory> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <fstream> #include "model.h" #include "c1.h" int main() { std::shared_ptr<C1> c1 = std::make_shared<C1>(); Model m(c1); std::cout << "TYPE: " << m.which_type_in_use() << std::endl; std::ofstream out_stream("test.bin", std::ios::out | std::ios::binary | std::ios::trunc); boost::archive::binary_oarchive oar(out_stream); oar << (m); Model m2; std::ifstream in_stream("test.bin", std::ios::in | std::ios::binary); boost::archive::binary_iarchive iar(in_stream); iar >> (m2); std::cout << "TYPE: " << m2.which_type_in_use() << std::endl; } *p1.h:* #ifndef P1_H_ #define P1_H_ #include <string> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> class P1 { protected: int size = 100; std::string type; public: int get_size() { return size; } virtual std::string get_type() = 0; friend class boost::serialization::access; template<typename Archive> void serialize(Archive &ar, const unsigned int version) { ar & size; ar & type; } }; #endif *c1.h:* #ifndef C1_H_ #define C1_H_ #include "p1.h" #include <string> #include <boost/serialization/serialization.hpp> class C1 : public P1 { public: bool is_child = true; C1() { int r = 10; } std::string get_type(); template<typename Archive> void serialize(Archive &ar, const unsigned int version) { ar & is_child; ar & boost::serialization::base_object<P1>(*this); } }; #endif *c1.cpp:* #include "c1.h" std::string C1 :: get_type() { return "c1"; } *model.h:* #ifndef MODEL_H_ #define MODEL_H_ #include <memory> #include <boost/archive/binary_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include "p1.h" class Model { public: bool is_model = true; //int *nums; std::shared_ptr<P1> p; Model(std::shared_ptr<P1> p1); Model() = default; std::string which_type_in_use(); template<typename Archive> void serialize(Archive &ar, const unsigned int version); }; #endif *model.cpp:* #include "model.h" Model :: Model(std::shared_ptr<P1> p1) : p(p1) { //nums = (int*)malloc(10*sizeof(int)); //nums[5] = 123; } std::string Model :: which_type_in_use() { return p->get_type(); } template<typename Archive> void Model :: serialize(Archive &ar, const unsigned int version) { ar & is_model; ar & p; }

1 0

[test] upgrading from 1.58 to 1.59
by Mathieu Champlon 07 Sep '15

07 Sep '15

Hello, Prior to boost 1.59 I had code using the floating point comparisons of Boost.Test as in if( boost::test_tools::check_is_close( v1, v2, boost::test_tools::percent_tolerance( tolerance ) ) ) ... if( boost::test_tools::check_is_close( v1, v2, boost::test_tools:: Snippet fraction_tolerance( tolerance ) ) ) ... As these seem to have been replaced/generalized starting with boost 1.59 I need to upgrade my code. Surely this involves using boost::test_tools::tolerance() but I'm getting a bit lost in the internals of Boost.Test. Could someone shed some light ? Thanks ! MAT.

2 3

Static linking program_options on ARM
by Pau Garcia i Quiles 07 Sep '15

07 Sep '15

Hello, I am having trouble when linking Boost::Program_Options statically on Linux ARM 32-bit: it spits an error about a duplicate symbol for a guard-variable. It works fine on Linux ARM 32-bit (same compiler) if using shared libraries, and also on Linux x86-64 both with static and shared libraries. I can reproduce the problem with the examples included in the libs/program_options/examples: real.cpp and custom_syntax.cpp compile and run fine but first.cpp, multiple_sources.cpp options_description.cpp, option_groups.cpp and regex.cpp fail: $ armv7a-openelec-linux-gnueabi-g++ -std=c++11 -o option_groups option_groups.cpp -L $SYSROOT/usr/lib -lboost_program_options /tmp/cch3i9Yf.ltrans0.ltrans.o:(.bss._ZGVZN5boost15program_options10validators17get_single_stringIcEERKSbIT_St11char_traitsIS3_ESaIS3_EERKSt6vectorIS7_SaIS7_EEbE5empty[_ZGVZN5boost15program_options10validators17get_single_stringIcEERKSbI T_St11char_traitsIS3_ESaIS3_EERKSt6vectorIS7_SaIS7_EEbE5empty]+0x0): multiple definition of `guard variable for std::basic_string<char, std::char_traits<char>, std::allocator<char> > const& boost::program_options::validators::get_single_ string<char>(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool)::empty' /tmp/ccORpK3T.o:(.bss._ZGVZN5boost15program_options10validators17get_single_stringIcEERKSbIT_St11char_traitsIS3_ESaIS3_EERKSt6vectorIS7_SaIS7_EEbE5empty[_ZGVZN5boost15program_options10validators17get_single_stringIcEERKSbIT_St11char_trai tsIS3_ESaIS3_EERKSt6vectorIS7_SaIS7_EEbE5empty]+0x0): first defined here /tmp/cch3i9Yf.ltrans0.ltrans.o:(.bss._ZZN5boost15program_options10validators17get_single_stringIcEERKSbIT_St11char_traitsIS3_ESaIS3_EERKSt6vectorIS7_SaIS7_EEbE5empty[_ZZN5boost15program_options10validators17get_single_stringIcEERKSbIT_St 11char_traitsIS3_ESaIS3_EERKSt6vectorIS7_SaIS7_EEbE5empty]+0x0): multiple definition of `std::basic_string<char, std::char_traits<char>, std::allocator<char> > const& boost::program_options::validators::get_single_string<char>(std::vecto r<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool)::empty' /tmp/ccORpK3T.o:(.bss._ZZN5boost15program_options10validators17get_single_stringIcEERKSbIT_St11char_traitsIS3_ESaIS3_EERKSt6vectorIS7_SaIS7_EEbE5empty[_ZZN5boost15program_options10validators17get_single_stringIcEERKSbIT_St11char_traitsIS 3_ESaIS3_EERKSt6vectorIS7_SaIS7_EEbE5empty]+0x0): first defined here collect2: error: ld returned 1 exit status Compiling Boost with or without C++11 does not affect either (it happens on both cases). Has anyone faced something like this? Thank you -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)

2 2

testing boost version
by Mathieu Champlon 05 Sep '15

05 Sep '15

Hello, I have a library supposed to work with several versions of Boost. It uses features from Boost.Test which API has changed between 1.58 and 1.59 I naively tried to use Snippet BOOST_PP_LESS to test BOOST_VERSION (e.g. Snippet 105900) but it only accepts values up to BOOST_PP_LIMIT_MAG (e.g. 256). What would be the best way to solve my problem ? Thanks a lot ! MAT.

1 1

Boost.Signals2 - if slot (functor of lambda) destructs the signal, calling the slot itself -> safe for functor?
by nice sw123 04 Sep '15

04 Sep '15

Hi there, If I connect a signal to a slot (functor or lambda), and the signal is then run, it calls the slot. What if the slot now has code that causes the signal to destruct? Will this "self-destruct" the slot (functor or lambda), by calling it's destructor BEFORE the slot-call has finished executing??? This would be a disaster! But it seems like is is safe. It seems: Even if the signal is destructed (from it's own slot-call), the slot destructor does not yet get called, until the slot-call has finished. Which would be safe. (Code example below) But is this really the case? Is this always safe? (If so: how does this roughly work?) Thanks. ///////////////////////////////////////////////////////////////////// #include <iostream> #include <string> #include <boost/signals2.hpp> #include <functional> #include <map> using namespace std; using FuncSig = void(); class BaseWrapper { public: BaseWrapper() { cout << "BaseWrapper() " << ++mm[""] << endl; } BaseWrapper(const string &n) : name{n} { cout << "BaseWrapper() " << name << ' ' << ++mm[name] << endl; } BaseWrapper(const BaseWrapper &other) : name{other.name} { cout << "BaseWrapper(const BaseWrapper &other) " << name << ' ' << ++mm[name] << endl; } virtual ~BaseWrapper() { cout << "~BaseWrapper() " << name << ' ' << mm[name]-- << endl; } private: static map<const string, int> mm; // static counter const string name; }; map<const string, int> BaseWrapper::mm; class MySig : BaseWrapper, public boost::signals2::signal<FuncSig> { }; using Sig = MySig; //boost::signals2::signal<FuncSig>; class A { public: A() {} boost::signals2::connection add_listener(const string &str, const Sig::slot_type &slot) { //my_map.emplace(str, Sig{}); auto x = my_map.emplace(std::piecewise_construct, std::forward_as_tuple(str), std::forward_as_tuple()); return x.first->second.connect(slot); } void remove_listener(const string &str) { auto it = my_map.find(str); if (it != my_map.cend()) { my_map.erase(it); } } void call(const string &str) { auto it = my_map.find(str); if (it != my_map.cend()) { it->second(); } } private: map<const string, Sig> my_map; }; class Functor : BaseWrapper { public: Functor(A *a_, int x_) : BaseWrapper{"Functor"}, a{a_}, x{x_} {} void operator()() const { cout << " this == " << this << endl; cout << " x == " << x << endl; a->remove_listener("hello"); cout << " this == " << this << endl; cout << " x == " << x << endl; } private: A *a; int x; }; int main() { A a; { Functor fun{&a, 4}; a.add_listener("hello", fun); } a.call("hello"); std::cout << "end" << endl; return 0; } /////////////////////////////////////////////////////////////////////

1 2

[Chrono] IO formatting doc minimal/ missing/ appears not to match the actual code base
by Hickman, Steve (AdvTech) 04 Sep '15

04 Sep '15

As of at least Boost 1.58 / 1.59 (possibly earlier), the documentation for Boost.Chrono V2 IO appears to be out of synch with the actual libraries in the following ways: 1) Header file names to include as described in the doc don't match the file names actually available to include. I was unable to find <boost/chrono/io/ios_state.hpp>. I did find <boost/chrono/io/ios_base_state.hpp> but it appears to include things not described in the doc for <boost/chrono/io/ios_state.hpp>. 2) Some format tags are listed as 'unsupported', but there is no description of what that means. Does it mean they are ignored? Does a string still match (which means the input reader will move past those bytes)? 3) I was able to find some examples in chrono\test\io . It would be nice if the tutorial made reference to these as a source of additional info. 4) There appear to be a number of interfaces whose doc appears to consist only of what is embedded in the header files (or I just didn't find the doc for them): time_point_get, etc. Not being familiar with how facets work, I'm not certain if I should be using these directly or not. It would be *really nice* if this were updated. More doc is always better. :) Steve Hickman System Architect, Flight Deck of the Future 480-236-8367

2 3

Re: [Boost-users] [boost] Boost.Fiber mini-review September 4-13
by Nat Goodspeed 04 Sep '15

04 Sep '15

On Fri, Sep 4, 2015 at 2:10 PM, Giovanni Piero Deretta <gpderetta(a)gmail.com> wrote: > - Boost.Fiber is yet another library that comes with its own future > type. For the sake of interoperability, the author should really > contribute changes to boost.thread so that its futures can be re-used. > > - In theory Boost.Thread any_condition should be usable out of the box. > > This probably should lead to a boost wide discussion. There are a few > boost (or proposed) libraries abstract hardware and OS capabilities, > for example boost.thread, boost.asio, boost.filesystem, > boost.iostream, boost.interproces (which also comes with its own > mutexes and condition variables) and of course the proposed afio and > fiber. At the moment they mostly live in separated, isolated worlds. > It would be nice if the authors were to sit down and work out a shared > design. Or more practically at least added some cross library > interoperability facilities. This is C++, generalization should be > possible, easy and cheap. The problem is this: what does it mean to "suspend"? There is no existing facility that can suspend exactly the calling fiber -- which means passing control to the fiber manager, leaving the current thread running to resume another fiber. You're right: if we had a pluggable notion of a suspend operation, we could reuse all Boost.Thread synchronization primitives -- as well as normal "blocking" I/O functions. I would like to see that happen. But it requires that all such libraries be reimplemented in terms of the pluggable suspend. I have a vague notion that this concept is tied to the use of executors, which are themselves a work in progress. Meanwhile -- Fiber requires its own set of synchronization primitives because only those primitives can permit other fibers to continue running on the same thread.

2 1

Re: [Boost-users] [TypeErasure] Reference of forward declared type requires complete type
by Yuan Yao 04 Sep '15

04 Sep '15

On 2015-09-03 23:36:03, Steven Watanabe wrote: > > <snip> > > > > struct Type; > > > > BOOST_TYPE_ERASURE_MEMBER((HasTest), Test, 1) > > > > <snip> > > HasTest<void(Type&)>, > > <snip> > > ================================================ > > > > However, the compiler (e.g. clang) complains about incomplete type: > > > > ================================================ > > /usr/local/include/boost/type_traits/is_base_and_derived.hpp:228:42: > > error: incomplete type 'Type' used in type trait expression > > BOOST_STATIC_CONSTANT(bool, value = (BOOST_IS_BASE_OF(B,D) && ! > > ::boost::is_same<ncvB,ncvD>::value)); > > ================================================ > > > > Replacing Type& with Type* can fix the problem. Is this a bug? > > > > Probably. Is boost::type_erasure::is_placeholder in > the instantiation backtrace? Yes. And the following is the full error message: ================================================ In file included from main.cpp:1: In file included from /usr/local/include/boost/type_erasure/any.hpp:36: In file included from /usr/local/include/boost/type_erasure/detail/normalize.hpp:30: In file included from /usr/local/include/boost/type_erasure/detail/get_placeholders.hpp:25: In file included from /usr/local/include/boost/type_erasure/is_placeholder.hpp:15: /usr/local/include/boost/type_traits/is_base_and_derived.hpp:228:42: error: incomplete type 'Type' used in type trait expression BOOST_STATIC_CONSTANT(bool, value = (BOOST_IS_BASE_OF(B,D) && ! ::boost::is_same<ncvB,ncvD>::value)); ^ /usr/local/include/boost/type_traits/intrinsics.hpp:189:53: note: expanded from macro 'BOOST_IS_BASE_OF' # define BOOST_IS_BASE_OF(T,U) (__is_base_of(T,U) && !is_same<T,U>::value) ^ /usr/local/include/boost/config/suffix.hpp:394:72: note: expanded from macro 'BOOST_STATIC_CONSTANT' # define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment ^ /usr/local/include/boost/type_traits/is_base_and_derived.hpp:237:25: note: in instantiation of template class 'boost::detail::is_base_and_derived_impl<boost::type_erasure::placeholder, Type>' requested here , (::boost::detail::is_base_and_derived_impl<Base,Derived>::value) ^ /usr/local/include/boost/type_traits/detail/bool_trait_def.hpp:74:30: note: expanded from macro 'BOOST_TT_AUX_BOOL_TRAIT_DEF2' BOOST_TT_AUX_BOOL_C_BASE(C) \ ^ /usr/local/include/boost/type_traits/detail/bool_trait_def.hpp:55:81: note: expanded from macro 'BOOST_TT_AUX_BOOL_C_BASE' # define BOOST_TT_AUX_BOOL_C_BASE(C) : public ::boost::integral_constant<bool,C> ^ /usr/local/include/boost/type_erasure/is_placeholder.hpp:27:25: note: in instantiation of template class 'boost::is_base_and_derived<boost::type_erasure::placeholder, Type>' requested here struct is_placeholder : ::boost::is_base_and_derived<placeholder, T> {}; ^ /usr/local/include/boost/mpl/aux_/nested_type_wknd.hpp:27:7: note: in instantiation of template class 'boost::type_erasure::is_placeholder<Type>' requested here : T::type ^ /usr/local/include/boost/mpl/not.hpp:41:11: note: in instantiation of template class 'boost::mpl::aux::nested_type_wknd<boost::type_erasure::is_placeholder<Type> >' requested here BOOST_MPL_AUX_NESTED_TYPE_WKND(T)::value ^ /usr/local/include/boost/mpl/aux_/nested_type_wknd.hpp:38:24: note: expanded from macro 'BOOST_MPL_AUX_NESTED_TYPE_WKND' ::boost::mpl::aux::nested_type_wknd<T> \ ^ /usr/local/include/boost/mpl/aux_/nested_type_wknd.hpp:27:7: note: in instantiation of template class 'boost::mpl::not_<boost::type_erasure::is_placeholder<Type> >' requested here : T::type ^ /usr/local/include/boost/mpl/aux_/preprocessed/gcc/or.hpp:51:11: note: (skipping 17 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all) BOOST_MPL_AUX_NESTED_TYPE_WKND(T1)::value ^ /usr/local/include/boost/mpl/aux_/nested_type_wknd.hpp:38:24: note: expanded from macro 'BOOST_MPL_AUX_NESTED_TYPE_WKND' ::boost::mpl::aux::nested_type_wknd<T> \ ^ /usr/local/include/boost/mpl/eval_if.hpp:38:22: note: in instantiation of template class 'boost::mpl::fold<boost::mpl::vector<HasTest<void (Type &), boost::type_erasure::_self>, boost::type_erasure::destructible<boost::type_erasure::_self>, boost::type_erasure::relaxed, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::mpl::s_item<boost::mpl::vector<HasTest<void (Type &), boost::type_erasure::_self>, boost::type_erasure::destructible<boost::type_erasure::_self>, boost::type_erasure::relaxed, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::mpl::set0<mpl_::na> >, boost::type_erasure::detail::collect_concepts<mpl_::arg<2>, boost::mpl::map0<mpl_::na>, mpl_::arg<1> > >' requested here typedef typename f_::type type; ^ /usr/local/include/boost/type_erasure/detail/normalize.hpp:388:36: note: in instantiation of template class 'boost::mpl::eval_if<boost::mpl::is_sequence<boost::mpl::vector<HasTest<void (Type &), boost::type_erasure::_self>, boost::type_erasure::destructible<boost::type_erasure::_self>, boost::type_erasure::relaxed, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na> >, boost::mpl::fold<boost::mpl::vector<HasTest<void (Type &), boost::type_erasure::_self>, boost::type_erasure::destructible<boost::type_erasure::_self>, boost::type_erasure::relaxed, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::mpl::s_item<boost::mpl::vector<HasTest<void (Type &), boost::type_erasure::_self>, boost::type_erasure::destructible<boost::type_erasure::_self>, boost::type_erasure::relaxed, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::mpl::set0<mpl_::na> >, boost::type_erasure::detail::collect_concepts<mpl_::arg<2>, boost::mpl::map0<mpl_::na>, mpl_::arg<1> > >, boost::mpl::identity<boost::mpl::s_item<boost::mpl::vector<HasTest<void (Type &), boost::type_erasure::_self>, boost::type_erasure::destructible<boost::type_erasure::_self>, boost::type_erasure::relaxed, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::mpl::set0<mpl_::na> > > >' requested here typedef typename ::boost::mpl::eval_if< ::boost::mpl::is_sequence<Concept>, ^ /usr/local/include/boost/type_erasure/any.hpp:65:49: note: in instantiation of template class 'boost::type_erasure::detail::collect_concepts<boost::mpl::vector<HasTest<void (Type &), boost::type_erasure::_self>, boost::type_erasure::destructible<boost::type_erasure::_self>, boost::type_erasure::relaxed, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::mpl::map0<mpl_::na>, boost::mpl::set0<mpl_::na> >' requested here typename ::boost::type_erasure::detail::collect_concepts< ^ /usr/local/include/boost/type_erasure/any.hpp:132:43: note: in instantiation of template class 'boost::type_erasure::detail::compute_bases<boost::type_erasure::any<boost::mpl::vector<HasTest<void (Type &), boost::type_erasure::_self>, boost::type_erasure::destructible<boost::type_erasure::_self>, boost::type_erasure::relaxed, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>, boost::mpl::vector<HasTest<void (Type &), boost::type_erasure::_self>, boost::type_erasure::destructible<boost::type_erasure::_self>, boost::type_erasure::relaxed, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>' requested here public ::boost::type_erasure::detail::compute_bases< ^ main.cpp:17:10: note: in instantiation of template class 'boost::type_erasure::any<boost::mpl::vector<HasTest<void (Type &), boost::type_erasure::_self>, boost::type_erasure::destructible<boost::type_erasure::_self>, boost::type_erasure::relaxed, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, boost::type_erasure::_self>' requested here Any obj; ^ main.cpp:4:8: note: forward declaration of 'Type' struct Type; ^ 1 error generated. ================================================

1 0

[TypeErasure] Reference of forward declared type requires complete type
by Yuan Yao 04 Sep '15

04 Sep '15

Hi all, I try to use boost.type_erasure (boost 1.59) with forward declared type as shown below: ================================================ #include <boost/type_erasure/any.hpp> #include <boost/type_erasure/member.hpp> struct Type; BOOST_TYPE_ERASURE_MEMBER((HasTest), Test, 1) using Any = boost::type_erasure::any < boost::mpl::vector < HasTest<void(Type&)>, boost::type_erasure::destructible<>, boost::type_erasure::relaxed > >; int main() { Any obj; } ================================================ However, the compiler (e.g. clang) complains about incomplete type: ================================================ /usr/local/include/boost/type_traits/is_base_and_derived.hpp:228:42: error: incomplete type 'Type' used in type trait expression BOOST_STATIC_CONSTANT(bool, value = (BOOST_IS_BASE_OF(B,D) && ! ::boost::is_same<ncvB,ncvD>::value)); ================================================ Replacing Type& with Type* can fix the problem. Is this a bug?

2 1