- Boost - lists.boost.org

shared_ptr to self while in constructor
by Dave 13 Jan '05

13 Jan '05

Hello all, A direct call to shared_from_this() does not work in a constructor. Is there any way that I may obtain a shared_ptr to myself while under construction? Thanks, Dave

4 3

questions re the Vault
by Robert Ramey 13 Jan '05

13 Jan '05

I can't remember where the new vault is. I was hoping I could get to it from the main boost page www.boost.org . Could this be updated? I guess there's no simple way to move the stuff in the old vault into the new vault. I would really like to save that "old stuff". I just know I'll need that numeric to roman numeral converter as soon as its deleted. Robert Ramey

4 9

uBLAS regressions/unsupported compilers
by Aleksey Gurtovoy 13 Jan '05

13 Jan '05

Folks, If all the compilers that currently show up as uBLAS regressions on http://www.meta-comm.com/engineering/boost-regression/developer/summary.html are indeed not supported, could somebody please mark them up correspondingly in "status/explicit-failures-markup.xml" (http://cvs.sourceforge.net/viewcvs.py/boost/boost/status/explicit-failures-…) ? Thanks! -- Aleksey Gurtovoy MetaCommunications Engineering

3 5

'configure' problem on Solaris 9 - patch enclosed
by Timo Geusch 13 Jan '05

13 Jan '05

I'm still playing about, trying to get boost to compile on my Solaris 9 box with the 5.5 SUN compiler. As there is no compiler configuration yet for the 5.5 compiler I tried to run 'configure' in libs/config/tools to generate a user.hpp file. Unfortunately the installed configure assumes that 'tr' knows how to handle character classes. The one on the Solaris 9 box I've got at work doesn't, so trying to use configure to create a user/compiler specific configuration does produce no meaningful output as all the tests fail. The attached patch to boost_1_32_0/libs/config/tools/configure.in fixes that problem for the price of dumbing down the tr invocation. A 'configure' patched along the same lines (the box doesn't have autoconf installed) produced the desired output which will hopefully allow me to get a bit further building boost on the 5.5 compiler. Regards, Timo

3 4

Help me! Where is the file "libboost_regex-vc6-mt-sgd-1_32.lib"?
by 海洋 13 Jan '05

13 Jan '05

I am using Windows XP + VC6. My compiler complained about "LINK : fatal error LNK1104: cannot open file "libboost_regex-vc6-mt-sgd-1_32.lib" when using "Debug Multithreaded" run-time library! I alos got a similar error with "Multithreaded" run-time library, but OK with other types of run-time librares. What is the matter? plase help me. Thank you very much!!

2 1

Re: Patterns (was Singleton)
by Dave Handley 13 Jan '05

13 Jan '05

Jeff Garland wrote: > > Well, my feedback is going to be fairly shallow since I don't have lots of > time to look it over, but what I see looks pretty good. Both of the > composite > and visitor stuff would be nice additions. > Thanks :-) > One interesting question on composite is whether a boost::tree would > really be > all that's needed and might be a more general component that could be used > to > implement composite. Of course, you are really depending on pointer > semantics > and the clone, so it wouldn't be a minor change of course to go down that > path... > I'm pretty sure that the implementation I have of the composite would also work as a tree if you didn't use CRTP. I've not tested this, but just browsing my own code convinces me of it! I personally think that improvements could be made to the composite by incorporating some policies. I've not given this much thought, but options could include a memory management policy that allowed you to choose between: the current model with pointers and clone; a single type in the tree that used copy and value semantics; a smart_ptr based model. > I think instead of trying to create a 'patterns' library I would make 2 > standalone libraries: vistor and composite. The fact that these are > 'patterns' (ie: well known designs) isn't really strong enough to bind > them > together. > My reason for wanting to create a patterns library is actually from a desire to try and create a Loki equivalent in boost (with some additions). The inter-play between certain patterns is such that I think they could sit in the same library. For example, the work I've done on visiting composite trees, or the fact that an abstract factory is often a singleton, etc. Having said that, I would not be averse to them being different libraries if that was preferred. Dave

1 0

Re: Interesting Boost Implementation Details?
by Arkadiy Vertleyb 13 Jan '05

13 Jan '05

David Abrahams wrote: > * The way that Boost.MPL uses partial specialization on template > template parameters to peel apart lambda expressions and turn them into > metafunction classes. I thought I understand how it's done, but now that I am trying to apply this to my own problem, it seems that default template parameters may be a showstopper in applying this technique, at least in some compilers. For example if I have: template<class T> struct do_something; template<template<class> class T, class P0> struct do_something<T<P0> > {}; template<template<class, class> class T, class P0, class P1> struct do_something<T<P0, P1> > {}; GCC 3.4.2 can't figure out which specialization to use for, e.g., std::vector. At the same time VC71 is fine with this, and chooses the one with 2 parameteres. Unfortunately I am unable to find my way around the MPL source to figure out what's really done... Can you clarify this? Thanks in advance, Arkadiy

4 6

[MPL] unlambda primitive (was [Boost-users] [MPL] map question)
by Daniel Wallin 13 Jan '05

13 Jan '05

Aleksey Gurtovoy wrote: > Daniel Wallin writes: > >>>>I'm sorry if I'm being thick here, but I can't grasp this. To me protect >>>> looks exactly like what is needed here. I have always thought of >>>>protect as delaying the placeholder substitution one step, > >> >> >> Well, again, it's not what it does. If we are to talk about introducing >> another primitive that would cover the OP use case, then it's another >> discussion (which should be taken to the developers list). Well OK, let's do that. What are your thoughts about adding something like this? template< typename BOOST_MPL_AUX_NA_PARAM(T) > struct unlambda { template< typename X = na BOOST_MPL_PP_NESTED_DEF_PARAMS_TAIL(1, typename X, na) > struct apply { typedef T type; }; typedef unlambda type; }; ... /// special case for 'unlambda' template< typename T, typename Tag > struct lambda< mpl::unlambda<T>,Tag, int_<1> > { typedef true_ is_le; typedef mpl::bind0<mpl::unlambda<T> > result_; typedef result_ type; }; -- Daniel Wallin

5 14

[rangelib]RFE: iterable range tuple to flatten tree?
by Larry Evans 13 Jan '05

13 Jan '05

A recent thread in c.l.c++.m: http://groups-beta.google.com/group/comp.lang.c++.moderated/browse_frm/thre… illustrates the general problem of flattening a tree-like structure to iterate over the leaves. Could iterable ranges be extended to do this sort of thing. I'm thinking that if the depth of the tree, D, were known in advance, then a tuple of iterator ranges could be used. i.e. for tuple, t, t.get<0> is a range over leaves of the tree, and t.get<1> is a range over the next level branch in the tree, until t.get<D-1> is the iterator over the branches in the root of the tree. I've currently a need for this; hence, I would be interested in knowing if there any plans for extending rangelib in this direction.

1 1

Access to protected member functions
by Alexander Nasonov 12 Jan '05

12 Jan '05

Hello Boosters, I know it's really BAD idea but sometimes ... especially if you ABSOLUTELY sure ... you may access protected member functions of an object without touching a class of that object. Two steps are required. First, at global scope in .cpp file (never in a header!) you should declare all functions you want to access later in this file: DECLARE_ACCESS_PROTECTED_FUNCTIONS( (foo)(bar) ) and, then you can access them: X x; // you want to access x's protected function bar. No problem: long r1 = ACCESS_PROTECTED_FUNCTION(X, x, bar, (4, 5, 6) ); Please, don't use if you're not sure. You've been warned! -- Alexander Nasonov

1 0