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

please help building boost::date_time
by Soeren.Meyer-Eppler 08 Jan '05

08 Jan '05

Hello everybody, I have some problems trying to build the date_time libraries. I'm using: boost 1.32.0 stlport 4.6.2 MSVC7.1 (on Windows of course) with the following build command line: C:\Development\boost_1_32_0>bjam "-sTOOLS=vc-7_1-stlport" "-sSTLPORT_PATH=c:/Development" "-sstlport-iostream=on" the first build error I get is the following (which causes a whole cascade to follow): [...] C:\Development\boost_1_32_0\boost\lexical_cast.hpp(150) : error C2679: binary '>>' : no operator found which takes a right-hand operand of type 'boost::date_time::date_names_put<Config,charT,OutputIterator>::string_type' (or there is no acceptable conversion) [...] All of the other boost libraries build and link fine, so I don't think it's a general problem with my setup. I'd appreciate any hints or tips. Or if someone could even send me the prebuilt 'libboost_date_time-vc71-mt-p-1_32.lib' I'd be most grateful. Thanks, Sören Meyer-Eppler -- www.BuschnicK.net

2 1

Boost1.32 VC7.0 multi_index bidirectional-map-like code wont compile...
by Dan Dimerman 08 Jan '05

08 Jan '05

Hello, I'm trying to compile code similar to (copied and pasted from) the bidirectional map example, but my VC7.0 burps some errors and then an INTERNAL COMPILER ERROR. The code looks like this: #include <boost/multi_index_container.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/key_extractors.hpp> using boost::multi_index_container; using namespace boost::multi_index; typedef unsigned long uid_t; typedef struct { uid_t _uid; vertex_descriptor _vertex; } node; struct uid {}; struct vertex {}; typedef multi_index_container < node, indexed_by< ordered_unique< tag< uid >, BOOST_MULTI_INDEX_MEMBER( node, uid_t, _uid ) >, ordered_unique< tag< vertex>, BOOST_MULTI_INDEX_MEMBER( node, vertex_descriptor, _vertex ) > > > node_set_t; and some of the errors I get are: c:\...\multi_index\detail\msvc_index_specifier.hpp(45) : error C2504: 'node_class' : base class undefined c:\...\multi_index\detail\msvc_index_specifier.hpp(45) : error C2143: syntax error : missing ',' before '<' c:\...\multi_index\detail\msvc_index_specifier.hpp(52) : error C2039: 'index_class' : is not a member of 'boost::multi_index::detail::msvc_index_specifier<IndexSpecifier>::fake_index_type<__formal>' (repeated several times) I am sure I am doing something very dumb. Any help will be greatly appreciated. Thanks Dan

1 1

Re: [Boost-users] why doesn't scoped_ptr have a custom
by tom gee 08 Jan '05

08 Jan '05

If you intention is to release the pointer, reset(0) can achieve this. The document says: "void reset(T * p = 0); // never throws Deletes the object pointed to by the stored pointer and then stores a copy of p ". With reset, you should be able assign another pointer.

5 5

bind.hpp does not compile with Metrowerks CodeWarrior
by Philippe Mori 08 Jan '05

08 Jan '05

The following line (starting at line 130 of boost/bind.hpp) does not compile: #if !( defined(__MWERKS__) && BOOST_WORKAROUND(__MWERKS__, <= 0x3003) ) template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* * pm, int) { return _mfi::dm<R, T>(*pm); } #if !BOOST_WORKAROUND(__IBMCPP__, BOOST_TESTED_AT(600)) // IBM/VisualAge 6.0 is not able to handle this overload. template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* const * pm, int) { return _mfi::dm<R, T>(*pm); } #endif #endif I got the following message: Error : ')' expected bind.hpp line 132 template<class R, class T> inline _mfi::dm<R, T> unwrap(R T::* * pm, int) (the second * is underlined) and then many more errors. If a comment out the previous lines, the file properly compile. To have this error, I just need to include <boost/bind.hpp> file in my code. I am using CodeWarrior 9.3 for Palm and the version as given by __MWERKS__ is 0x3004. If I changes 0x3003 for 0x3004 (at line 130), it compile file (so the workaround is still required). Could one boost developper make the changes? I am using boost 1.32.0.

2 1

Where can I find an example of converting a seconds into a date using boost::date_time?
by Stephen torri 08 Jan '05

08 Jan '05

I need an example of taking a time duration in seconds and converting it to a date using Boost::Date_Time. For example, 805168227 seconds (time from December 31st, 1969, at 4:00 P.M.) = approx. 25 years, 194 days, 1 hr, 50 minutes, 27 seconds = File created on 1994 June 15 5:50:27 (Conversion did not account for leap years). Stephen

2 3

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