- Boost-users - lists.boost.org

[mpl] how to find out whether a function is implemented
by Zeljko Vrba 05 Aug '05

05 Aug '05

I hope the MPL label is right. At least the question has *some* relevance to metaprogramming. Basically, I need to find out whether a certain function F over a certain type is defined, and if yes, take its address. Input: the type T, and function NAME F. Output: pointer to F if Ret F(T, T& or T const&; or two arguments) is defined, 0 otherwise. The function can return anything, including void. Variations in input: - the function may take T, T&, or T const& - if possible, the method should work for user-defined operators (my C++ is a bit rusty in this area - is it at all possible to take an address of an overloaded operator?) I guess the F would then be named, e.g. 'operator<' ? If the general case is hard to work out, it's OK to have the solution just for Ret F(T const&) and Ret F(T const&, T const&). I hope the question is clear enough :) Thanks for your time and answers.

2 3

question: boost::array does not have compile time checked access
by gast128 05 Aug '05

05 Aug '05

Dear all, I was wondering why boost::array did not offer compile time checked access to its contents, something like a.get<1>(), a similar interface like tuple. Otherwise I see not much enhancement compared to an ordinary std::vector. Wkr, me

4 5

Question concerning boost::tuples::length (1.32)
by Daniel Krügler 05 Aug '05

05 Aug '05

(OK, this is my third try. I got problems with (re)subscriptions **although** I am subscribed since years...) Dear Boosters, its quite a while that I could participate in this newsgroup, so maybe my request is ol' stuff and has been answered 100 times. In case of that I apologize for the following question: I observe that boost::tuple::length in version 1.32 exist two template specializations for empty tuples, namely template<> struct length<tuple<> > { BOOST_STATIC_CONSTANT(int, value = 0); }; template<> struct length<null_type> { BOOST_STATIC_CONSTANT(int, value = 0); }; which lead to the unexpected effect that e.g. typedef const tuple<> ConstEmptyTuple; int k = length<ConstEmptyTuple>::value; (modulo namespace issues) does not compile. The reason is obvious, because deduction of boost::tuples::length<ConstEmptyTuple> extracts "const tuple<>", which leads to the generic template definition: template<class T> struct length { BOOST_STATIC_CONSTANT(int, value = 1 + length<typename T::tail_type>::value); }; which does not compile in this case, because const oost::tuples::tuple<> has no tail_type. Similar situations arise for const null_type arguments and corresponding volatile variants thereof. To my humble opinion tuples::length should work independent of cv qualification of the template arguments, but this route should of course be gone in accordance to similar situations of "template predicates" in boost::mp/type_traits. One further indirection and usage of boost::remove_cv<T> could simply resolve the described problem, such as: // Define length_impl + 2 specialisation for tuple<> and null_type as // currently done for length namespace details { template <typename T> struct length_impl { .. // as before; }; template <> struct length_impl<null_type> { .. // as before; }; template <> struct length_impl<tuple<null_type, ...> > { .. // as before; }; } // One single - not specialized - length template handling all cases: template <typename T> struct length { static const int value = details::length_impl< typename ::boost::remove_cv<T>::type >::value; }; What do you think? Greetings from Bremen, Daniel Krügler

1 0

Re: [Boost-users] Question concerning boost::tuples::length (1.32)
by Douglas Gregor 05 Aug '05

05 Aug '05

On Aug 5, 2005, at 4:39 AM, Daniel Kruegler wrote: > Dear newsgroup, > > can you please explain me, **which** mailing list I can post to? > > According to a previous mail of Gmane Autoauthorizer I was > supposed to reply to your answer of my initial mail to get posting > access. > The posting said: > > "You are now authorized to post to the > gmane.comp.lib.boost.user newsgroup." You'll also need to sign up for the mailing list itself: http://lists.boost.org/mailman/listinfo.cgi/boost-users Once you've done that, you can turn off mail delivery and read/post through GMane. Doug

1 0

Re: [Boost-users] optional + serialize
by Jasper, Alexander 05 Aug '05

05 Aug '05

Hi Robert! thanks for the reply. I've to agree with you that my solution to problem was an ugly hack. It certainly is very inefficient and not exception safe. Furthermore it requires T::operator=. I took a look at the file you mentioned. But unfortunately I lack the knowledge of boost internals and, more important, I'm unfamiliar with the highly advanced c++ stuff, like inplace new or however the collection stuff is done. Therefore I, unfortunately, cannot suggest a better solution. I guess I've to bear with that performance hit, for now. I hope s.o. with better boost knowledge than me will address this issue in a future version. kind regards Alex > -----Ursprüngliche Nachricht----- > Von: boost-users-bounces(a)lists.boost.org > [mailto:boost-users-bounces@lists.boost.org]Im Auftrag von > Robert Ramey > Gesendet: Donnerstag, 4. August 2005 01:49 > An: boost-users(a)lists.boost.org > Betreff: Re: [Boost-users] optional + serialize > > > > a) I've read your post > b) I see your point that the serialization of optional > doesn't handle types > without default constructors > c) I agree that it should be fixed. > d) don't like the way you fixed it. I'm sure should work but > I don't like > the usage of the heap. For a better way to do this take a look at > collections_load_imp.hpp which adderss this problem in a > different context. > > Its too late to fixe for 1.33. > > Robert Ramey > > Jasper, Alexander wrote: > > Hi Jeff, All! > > > > thanks a lot for the reply. I assume the bug fix is in 1.33? > > > > I'm still having issues with boost.optinal and boost.serialize > > working together (in 1.32). > > Is for deserialization of boost::optional<T> T required to have > > default ctor?. > > > > This prevents boost::optional<boost::posix_time::time_period> from > > being serialized. The extraction code fails to compile. I would an > > ugly way around this (please see my last email). Does anybody have > > ideas for better solutions? > > > > I've attached a modified version of #include > > <boost/serialization/optional.hpp> to this email, that contains code > > changes to make to work with types w/o T having a default ctor. But > > I'm really unhappy with that solution and I don't know what I broke > > with this change... > > > > thanks in advance > > > > Alex > > > >> -----Ursprüngliche Nachricht----- > >> Von: boost-users-bounces(a)lists.boost.org > >> [mailto:boost-users-bounces@lists.boost.org]Im Auftrag von > >> Jeff Garland > >> Gesendet: Freitag, 29. Juli 2005 15:40 > >> An: boost-users(a)lists.boost.org > >> Betreff: Re: [Boost-users] questions concerning optional + > date_time > >> +serialize > >> > >> > >> On Fri, 29 Jul 2005 15:21:38 +0200, Jasper, Alexander wrote > >>> ... > >>> Another thing is that I'm unable to serialize not_a_date_time > >>> ptimes. The extractions fails here. I'm using the binary > >> archive. Is > >>> that supported? The documentation of date time only states > >>> compatibility with text and XML archive... > >> > >> There was a recent (jun 21) bug-fix in date-time that was > >> preventing correct > >> serialization of special values -- even with text archives -- > >> so it's likely > >> that's what you are seeing. I haven't tried the binary > >> archive, but there's > >> no reason it shouldn't work. I believe you should be able to > >> just pickup the > >> latest version of gregorian/greg_serialize.hpp and > >> posix_time/time_serialize.hpp to try it out. > >> > >> Jeff > >> _______________________________________________ > >> Boost-users mailing list > >> Boost-users(a)lists.boost.org > >> http://lists.boost.org/mailman/listinfo.cgi/boost-users > >> > > > > > > > > > >> _______________________________________________ > >> Boost-users mailing list > >> Boost-users(a)lists.boost.org > >> http://lists.boost.org/mailman/listinfo.cgi/boost-users > > > >

1 0

Re: [Boost-users] program options config file format?
by Lawry, Brian 05 Aug '05

05 Aug '05

> Matthias Kaeppler wrote: >> Hi, >> the program_options reference talks about >> being able to parse config files, but >> doesn't mention a thing about its layout. >> No examples are shown how a file has to >> look like to be parsable by program_options. Example layout: ..\libs\program_options\example\multiple_sources.cfg (used by multiple_sources.cpp in same directory). >> Any ideas? Besides the layout, which characters >> are treated as comments? > Anyone? > Matthias Kaeppler The only character I've found that indicates a comment is the '#' (pound/hash/sharp). One other thing I've noticed is that the option names are case-sensitive, at least by default. HTH. Brian Lawry Mfg Software Engineer Compressor Controls Corp blawry(a)cccglobal.com

2 1

Re: [Boost-users] Fw: shared_array EXC_BAD_ACCESS
by Christopher Hunt 05 Aug '05

05 Aug '05

Hi Rene/Peter, I'm happy to report that 1.33rc1 solves the EXC_BAD_ACCESS problem I was having on Mac OS X and does not require me to ensure that boost/config.hpp is included prior to any Carbon includes. Misc. comments on the build: (i) There are a lot of warnings re. "use of `long double' type; its size may change in a future release". May I suggest either fixing the problem or disabling the warning for gcc using the -Wno-long-double. Personally I dislike seeing any warnings come up as a user of boost or any other library. As a user, I'm only really interested in errors. Perhaps there should be a "developer" build option that shows warnings which is not the default. (ii) The following was reported duing my build (I'm installing alongside 1.32) - is this ok? ...failed updating 22 targets... ...skipped 26 targets... ...updated 4318 targets... I'll continue using 1.33rc1 to see if anything else comes up. Thanks for a great library and please let me know if there is anything else I can do for you guys. Cheers, -C On 03/08/2005, at 5:18 AM, boost-users-request(a)lists.boost.org wrote: > Rene Rivera wrote: >> Peter Dimov wrote: >>> I'm forwarding the following post from boost-users >>> >>> http://lists.boost.org/boost-users/2005/08/12938.php >>> >>> since it describes a pretty severe configuration problem on Mac OS X >>> that apparently leads to inconsistent definitions of >>> BOOST_HAS_THREADS and all kinds of interesting ODR violations. >> >> I think that problem is fixed. The original post doesn't mention the >> Boost version so it's hard to be sure. The checks for threading and >> the type of target getting built is considerably more complicated now >> than just the TARGET_CARBON check :-) >> >> It would be awesome if the original poster could test with 1.33 to >> make sure it's fixed.

1 0

Question about traversing mpl vectors
by Stephen Gross 05 Aug '05

05 Aug '05

Let's say I've got some mpl::vector. If I grab a begin iterator on it, and increment that iterator past the elements in the vector, what happens? For instance: ================================================== using boost; typedef mpl::vector<int, char> t; typedef mpl::begin<t>::type element0; // Should deref to 'int' typedef mpl::next<element0>::type element1; // Should deref to 'char' typedef mpl::next<element1>::type element2; // What happens? typedef mpl::next<element2>::type element3; // " typedef mpl::next<element3>::type element4; // " ================================================== Will boost let me iterate past the 'end' of an mpl::vector? Am I supposed to take care of bounds checking? Thanks, --Steve Stephen Gross Case Western School of Medicine Cleveland, OH "By Grabthar's hammer, by the sons of Worvan, you shall be avenged." - Dr. Lazarus

2 1

C++ Template Metaprogramming Book
by Eduardo Bezerra 05 Aug '05

05 Aug '05

I'm reading the C++ Template Metaprogramming book and I'm not understanding the following code from page 65-66: template <class T> struct param_type : mpl::eval_if < typename boost::is_scalar<T>::type , mpl::indentity<T> , boost::add_reference<T const> > {}; template <class T> struct param_type : mpl::eval_if < boost::is_scalar<T> --> ^^^^^^^^^^^^^^^^^^^^^^^ <-- , mpl::indentity<T> , boost::add_reference<T const> > {}; After reading again and again the explanation I still don't get why we don't need to use typename ....::type anymore. The text explains that all Boost's integral metafunctions suply a nested ::value, but how it is used in this context ? Any help would be greatly appreciated. Best regards, Eduardo

3 2

Mac OSX 10.4, Carbon.h, boost::shared_ptr, and BOOST_HAS_PTHREADS
by Rush Manbert 05 Aug '05

05 Aug '05

Hi all, I am writing all of this down because I was only able to find cryptic references to this problem in the Boost archives, and in the Apple Xcode-Users archives. I also want to ask whether my solution to the problem makes sense. I am developing a cross platform static library on OSX 10.4.2 using Xcode 2.1. The Xcode IDE includes a mechanism for unit testing that I am using. The unit test target is setup by Xcode, and one of the things it does is to include Carbon.h as a "prefix include". This means that the compiler command line includes "-include <path>/Carbon.h" and this header file is read BEFORE anything else. Everything had been going great until I wrote a test using boost::shared_ptr. I began to see all sorts of strange behaviors. After a while I turned on Guard Malloc in the debugger. That was when it started catching bad access errors in pthread_mutex_init, which was being called as a result of creating a boost:shared_ptr. It turns out that in the constructor for: template<class P, class D> shared_count(P p, D d) it executes this: pi_ = new sp_counted_base_impl<P, D>(p, d); Class sp_counted_base_impl is derived from sp_counted_base, and sp_counted_base has a data member declared as: #if defined(BOOST_HAS_THREADS) || defined(BOOST_LWM_WIN32) mutable mutex_type mtx_; #endif In the constructor for sp_counted_base, the constructor for mutex_type (lightweight_mutex) was being called. It in turn called pthread_mutex_init, passing the address of its mutex member, which is a 44 byte buffer. The memory access problem, though, is that when operator new called malloc, it did so as if sp_counted_base did NOT contain the mutex data member. This means that the 44 byte buffer wasn't allocated, and because Guard Malloc is very clever, the access outside of the allocated space was caught. I searched around and found messages where people said they saw problems like this because the Carbon headers were included before the Boost headers. This certainly fit my situation. I managed to change the order of header inclusion and everything started working. The class memory was allocated including space for mtx_ and the mutex init worked. This is really a lousy solution, though, so I kept poking around. I put things back so that Carbon.h was included on the command line, and assumed I would need to live with that. I added -DBOOST_HAS_THREADS to my compiler flags. The test still failed because the mutex memory had not been allocated. Because of this, I looked for anywhere where BOOST_HAS_THREADS could be #undef-ed. I found two possibilities, both in boost/config/suffix.hpp. It appeared that in my case BOOST_HAS_PTHREADS was not defined. This led me to boost/config/macos.hpp. I found this little code snippet: // // BSD runtime has pthreads, sigaction, sched_yield and gettimeofday, // of these only pthreads are advertised in <unistd.h>, so set the // other options explicitly: // # define BOOST_HAS_SCHED_YIELD # define BOOST_HAS_GETTIMEOFDAY # define BOOST_HAS_SIGACTION I tried including <unistd.h> ahead of shared_ptr.hpp, but that still failed the same way. I edited macos.hpp and added a fourth #define to this section: # define BOOST_HAS_PTHREADS When I built with the modified header, everything worked as expected. The mutex space was allocated. I don't want to change the Boost headers, though, so undid the change to macos.hpp. I went back to my test target in Xcode and changed the compiler flag -DBOOST_HAS_THREADS to -DBOOST_HAS_PTHREADS. I rebuilt my test code and everything works perfectly. So it *appears* that defining BOOST_HAS_PTHREADS on the compiler command line is the general case solution for this problem, but I'm looking for opinions more expert than mine. If this is indeed true, then does anyone know why the macro isn't just defined in boost/config/platform/macos.hpp? Have I opened myself up to other problems by doing this? Any help would be appreciated. - Rush

2 4