- Boost-users - lists.boost.org

Ignore my last email!
by Jim Lear 08 Jan '05

08 Jan '05

-- Jim Lear

2 1

Guide to using serialization macro BOOST_CLASS_EXPORT
by Bill Lear 07 Jan '05

07 Jan '05

I am having some trouble understanding just where I am supposed to put BOOST_CLASS_EXPORT macros for classes I write --- in class headers (.h), in class implementation files (.cc), in applications that plan to save/load through base pointers? I have base class B, from which I derive lots of classes. I tried putting the BOOST_CLASS_EXPORT in the header files of each class, but soon found that this resulted in link-time errors due to multiple definitions. So, I moved the macro to an implementation (.cc) file, creating it if necessary, with the form: #include "Derived.h" BOOST_CLASS_EXPORT(Derived); The problem with this is that I have an application that does this: #include "Base.h" #include "Derived.h" // fails with or without this void foo() { Base* b = load("file.xml"); } Now, since no instance of Derived is appearing in my application, the linker apparently does not pull in the (expanded) macro, and when I run the application, I get an unregistered class exception. So, I removed all of the macros from the implementation files and put them in a header (again), that is designed for applications that may want to serialize (any) of my derived classes: #include "Base.h" #include "Derived.h" #include "BoostExports.h" void foo() { Base* b = load("file.xml"); } and this works fine. So my question is this: is this what other people do, or are there other solutions that people prefer? The problem with the above is that if I have 20 derived classes and put all the macro exports in BoostExports.h, even if my application may only be interested in a smaller subset, I have to pull in 20 header files each time, and I had hoped to avoid that. This is not a terrible thing, I just wondered what other approaches there might be. Bill

3 4

Re: [sigc] Re: [Boost-users] Signals & Slots
by Doug Gregor 07 Jan '05

07 Jan '05

On Jan 7, 2005, at 9:06 AM, Carl Nygard wrote: > On Fri, 2005-01-07 at 08:19 -0500, Douglas Gregor wrote: >> On Jan 7, 2005, at 6:12 AM, Murray Cumming wrote: >>> 3. In "Slot Binders" >>> Can you expand on this question: "TODO: answer questions: a) What's >>> up >>> with the No Clue entry, anyone?", please. In fact, please just ask >>> your >>> TODO questions on this mailing list. >> >> So the intent of retype() and retype_return() is to allow casting of >> the argument and return types of a function. Are these also required >> when performing implicit conversions? For instance, will the following >> work? >> >> long Func3(double val, string str); >> >> sigc::signal<int, float, string> sig; >> sig.connect(sigc::ptr_fun(&Func3)); >> >> If I'm right in assuming that the code will not compile (because the >> signatures do not match exactly), then the "No Clue" could be replaced >> by "Not Applicable", because >> Signals performs all of the implicit conversions. > > In that case, it's supported in Boost.Bind, so retype/retype_return() > is > included with sigc::bind/compose/hide/group. Correct? Implicit conversions are handled in both Boost.Bind and in Boost.Signals. I don't know enough about sigc::bind/compose/hide/group to answer the rest. >> - About ptr_fun/mem_fun: you can use them in either library, if >> you'd >> like to be more explicit. > > I couldn't find docs on boost.org for ptr_fun, just mem_fun. What am I > missing? Well, there's std::ptr_fun, and you could always wrap it in bind() if you wanted. ptr_fun really is just syntactic (de-?)sugar. >> - About bind: bind is now in the C++ Library TR (an addendum to the >> standard, which should be approved in the near future), so we're >> forced >> to build on it to create any signals & slots library for the standards >> committee. (We'll have a long, uphill battle if we try to introduce >> our >> own special binders and don't support bind). > > Do you have a link to the TR? There is a draft here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1711.pdf If you're familiar with Boost.Function/Boost.Bind, you'll be familiar with the TR versions. Very little has changed. Doug

1 0

Why using boost::function with lambda requires RTTI?
by Philippe Mori 07 Jan '05

07 Jan '05

I am using CodeWarrior 9.3 for Palm OS development and I was looking at the possibility of using boost::function class in my code. Because my application is big and the data segment is already almost full (even if I uses extended mode), I do not want to uses RTTI (at all, if possible). When I compile the code I get the following warning "RTTI option is disabled" at the line with the following macro call BOOST_FUNCTION_COMPARE_TYPE_ID in function boost::detail::function::functor_manager::manage(). Also, a lambda function like (((1.0 * _1 + 2.0) * _1 + 3.0) * _1 + 4.0) * _1 + 5.0 cause my data segment to increase of 6K which is huge when the limit is 64K... Using a static function (and not using boost::lambda) instead does not cause such increase of the use of the data segment. Another thing that I have noticed is that the compiler get very slow as I am starting to uses some boost libraries like that (a few more seconds per file). Philippe

3 2

Re: [sigc] Re: [Boost-users] Signals & Slots
by Douglas Gregor 07 Jan '05

07 Jan '05

On Jan 7, 2005, at 6:12 AM, Murray Cumming wrote: > 3. In "Slot Binders" > Can you expand on this question: "TODO: answer questions: a) What's up > with the No Clue entry, anyone?", please. In fact, please just ask your > TODO questions on this mailing list. So the intent of retype() and retype_return() is to allow casting of the argument and return types of a function. Are these also required when performing implicit conversions? For instance, will the following work? long Func3(double val, string str); sigc::signal<int, float, string> sig; sig.connect(sigc::ptr_fun(&Func3)); If I'm right in assuming that the code will not compile (because the signatures do not match exactly), then the "No Clue" could be replaced by "Not Applicable", because Signals performs all of the implicit conversions. > 4. Some of the "-ed" comments seem outdated now. It would be nice to > clean these up. Replying to some of the -ed comments: - Regarding implementing the preferred syntax from Boost.Signals in libsigc++: it should be trivial, although support for writing function types is not as portable as we'd like. - Regarding bloat factors: they're probably about the same in both libraries. The only thing we know to do to improve the situation is use function pointers instead of virtual functions, and to try to be careful about factoring our templates properly. - About ptr_fun/mem_fun: you can use them in either library, if you'd like to be more explicit. - About bind: bind is now in the C++ Library TR (an addendum to the standard, which should be approved in the near future), so we're forced to build on it to create any signals & slots library for the standards committee. (We'll have a long, uphill battle if we try to introduce our own special binders and don't support bind). - Regarding libsigc++'s specialization for T_accumulator=nil: We don't need to discuss this in a standards proposal, because it's entirely a quality-of-implementation issue. - Regarding Signals and Function: They don't play well together, but we're going to have to deal with this one way or another because Function is also part of the C++ Library TR. And one minor quibble: if we're going to explicitly qualify Boost.Signals by saying that it was strongly influenced by the work of Karl Nelson (that's true), I think it's only fair to point out that libsigc++-2.0's interface was influenced by Boost.Signals. Doug

1 0

Re: B is_convertible to A<T> for some T
by Perepelitsa Roman 07 Jan '05

07 Jan '05

> Hello, > > how do I express through template metaprogramming or in a similar > way that a class is convertible to a template class for some T1? > I.e., the condition: "There exists some T1 such that B is > convertible to A<T1>". I guess all you need is boost::lambda::detail::is_instance_of_1<B, A>. Best regards.

1 0

Problem using boost program_options on HP-UX
by suresh.t＠philips.com 07 Jan '05

07 Jan '05

hi, I am using the boost/program_options and i had no problem when using with Linux (and gcc). I switched to HP-UX ( using gcc 3.2.2) and the boost part fails to compile. I get a error from "boost/program_options/detail/convert.hpp" related to wstring and wchar_t usage. If someone uses program_options on HP with gcc already , could you please let me know what needs to be done to get it working. Thanks in advance --------------------------------------------------------------------------------------------------------- Suresh

1 0

Serialization demo.cpp: "Undefined reference to boost::archive::detail::basic_iarchive::load_object"
by Maximilian Wilson 07 Jan '05

07 Jan '05

I'm using gcc v 3.3, Red Hat Linux (not sure what version), and Boost 1.32. I'm trying to learn the serialization library, using the demo program from http://boost.org/libs/serialization/example/demo.cpp . I have had a little bit of trouble figuring out the boost install procedure for this library but I think I finally did it with: bjam "-sTOOLS=gcc" install --libdir=/home/max/boost --includedir=/home/max/boost -with-serialization But when I execute "g++ -I/home/max/boost/boost-1_32 -L/home/max/boost demo.cpp demo.o" I get a bunch of linker errors. I'm pretty sure I've messed up this install procedure somewhere, and the Boost docs have tentalizing references to serialization not having "automatic linking," but I can't figure out where to go next. What am I doing wrong? Max Wilson -- Ubi solitudinem faciunt, pacem appellant. They make a desert and call it peace. -Tacitus

3 3

Re: bind (excessive?) argument copying
by Trent Hill 06 Jan '05

06 Jan '05

Hi Peter, Peter Dimov wrote: <snip> >> Four copies - I had hoped to only see a single copy. Logically, there >> doesn't seem to be a need for more than one copy. Is there an >> implementation issue that requires this many copies? > > > Not really, but eliminating the unnecessary copies is (relatively) hard, > at least with the current code base (it has been developed with > portability in mind and supports VC6, among others). The specification > requires one copy. One more is almost unavoidable. The other two can be > eliminated, in theory. But... Ok, thanks. Out of interest, is there a simple explanation for why one more is almost unavoidable. <snip> > ... please note that the copies occur at bind time. In a typical > scenario you bind once and call O(N) times (or bind and store in a > function<> with the associated dynamic memory allocation), so this isn't > usually a problem. And, as others have pointed out, there's always > ref(). ;-) Yes I understand. I guess I'm not using bind typically ;-) FYI and for those suggesting boost::ref, the actual case is using bind for message passing between threads. I have a polymorphic wrapper for bind something like this: class bind_wrapper { public: virtual void execute() = 0; }; template <typename binder_t> class bind_wrapper_impl : public bind_wrapper { public: bind_wrapper_impl(const binder_t &binder_a) : binder_m(binder_a) { } virtual void execute() { binder_m(); } private: binder_t binder_m; }; template <typename binder_t> std::auto_ptr<bind_wrapper> make_bind_wrapper(const binder_t &binder_a) { return std::auto_ptr<bind_wrapper>( new bind_wrapper_impl<binder_t>(binder_a)); } Now the idea is that certain functions transparently transfer work to a worker thread. So for such a function "foo", there would be an internal implementation function: void foo_impl(const std::string &string_a) { // do stuff } and a public proxy that requests foo_impl to be called on the worker thread: future foo_async(const std::string &arg_a) { std::auto_ptr<bind_wrapper> message_l( make_bind_wrapper(boost::bind(&foo_impl, arg_a))); // add message_l to message queue and return future to allow // rendezvous ... } The worker thread will collect this message and call execute(), something like: void worker_thread() { // retrieve from message queue and execute std::auto_ptr<bind_wrapper> message_l = ... message_l->execute(); } So, in this case: 1. Yes, a copy is required - boost::ref is not appropriate. 2. Each bind corresponds to a single call (not O(N) calls) We have a home grown solution (less general than bind of course) requiring only a single copy. I was hoping to replace it with bind but it's hard to justify adding the extra argument copies. Thanks for the info though, Cheers, Trent.

1 0

preprocessor library, unique token for each translational unit
by Sean Kelly 06 Jan '05

06 Jan '05

Hello All, I'm trying to figure out if it is possible to use the preprocessor library to generate a unique token for a given translational unit suitable for use in a variable definition. __FILE__ doesn't work for obvious reasons. The motivation is use the template below to generate a unique function scope static "verbosity" for each translation unit. The extern is necessary to give the non-type template par external linkage but also requires a unique variable name. thanks for any help. -Sean #define INIT_VERBOSITY extern const char BOOST_PP_CAT(file,UNIQUE_TOKEN)[] filename = __FILE__; #define VERBOSITY VerbosityLookup<BOOST_PP_CAT(file,UNIQUE_TOKEN)>::get() template<const char* STR> class VerbosityLookup { static int get() { static int verbosity = initialize(STR); return verbosity; } }

2 1