[boost] Re: Challenge: persistence/typeid lib

From: Alex Radeski (alexr_at_[hidden])
Date: 2002-04-21 00:11:44

I am interested in this project on a number of fronts. I think standardized naming builtin
into boost is a good idea because as you stated its the foundations for all sorts of
persistence related extensions to C++.

As I am new to boost (the mailing list not as a user of boost) I am not entirely sure
where to start??

Alex

>-----Original Message-----
>From: boost-admin_at_[hidden] [mailto:boost-admin_at_[hidden]]On
>Behalf Of boost-request_at_[hidden]
>Sent: Friday, 19 April 2002 01:02
>To: boost_at_[hidden]
>Subject: Boost digest, Vol 1 #83 - 12 msgs
>
>
>Send Boost mailing list submissions to
>	boost_at_[hidden]
>
>To subscribe or unsubscribe via the World Wide Web, visit
>	http://lists.boost.org/mailman/listinfo.cgi/boost
>or, via email, send a message with subject or body 'help' to
>	boost-request_at_[hidden]
>
>You can reach the person managing the list at
>	boost-admin_at_[hidden]
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Boost digest..."
>
>
>The boost archives may be found at: http://lists.boost.org/MailArchives/boost/
>
>Today's Topics:
>
>   1. Re: Re: Re: Optimization of compilation time and consumed memory (David Abrahams)
>   2. RE: Re: Intrusive smart pointer (hollp)
>   3. Re: Smart pointers (boost or not): const-checking, polymorphism (Peter Dimov)
>   4. Re: Re: Challenge: persistence/typeid lib (David Abrahams)
>   5. Re: Re: Re: Re: loki::type_list == boost::mpl::list_node (Peter Dimov)
>   6. Re: Boost meeting Sunday at 1 PM in Curacao (Jeremy Siek)
>   7. Re: Preprocessor Library - ATTN:  David Abrahams (Vesa Karvonen)
>   8. Re: Re: Intrusive smart pointer (Fernando Cacciola)
>   9. Re: Re: Re: loki::type_list == boost::mpl::list_node (Hamish Mackenzie)
>  10. Extend preprocessor tuples with this perl script (John Harris (TT))
>  11. Re: Challenge: persistence/typeid lib (Nicola Musatti)
>  12. Re: Re: Intrusive smart pointer (Peter Dimov)
>
>--__--__--
>
>Message: 1
>From: "David Abrahams" <david.abrahams_at_[hidden]>
>To: <boost_at_[hidden]>
>Subject: Re: [boost] Re: Re: Optimization of compilation time and consumed memory
>Date: Thu, 18 Apr 2002 10:21:14 -0500
>Reply-To: boost_at_[hidden]
>
>
>----- Original Message -----
>From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
>
>
>> "David Abrahams" <david.abrahams_at_[hidden]> wrote in message
>> news:008401c1e692$d409cbb0$6501a8c0_at_boostconsulting.com...
>
>> All right, so that's /compiler's/ problem. Is this implying that newer
>> compilers will render at least parts of MPL obsolete?
>
>Sure, as with many of our libraries, if you drop support for broken
>compilers, parts of the implementation can also be dropped.
>
>> > Also, I don't think that simple traversals of 50 element lists
>> really
>> > begins to describe the potential complexity of metaprograms. When
>> you
>> > start designing new domain-specific languages, it's easy to create
>> > scenarios where a lot of non-trivial processing happens.
>>
>> I believe that that processing can be performed with reasonable
>> efficiency. Again, there are languages that foster the same
>> computation model, with which you can do very complex tasks with
>> reasonable efficiency.
>
>Absolutely agreed. As I said before, most of these template engines
>weren't designed with metaprogramming in mind.
>
>-Dave
>
>
>
>--__--__--
>
>Message: 2
>Date: Thu, 18 Apr 02 10:31:12 -0500
>From: hollp <hollp_at_[hidden]>
>To: boost_at_[hidden]
>Subject: RE: [boost] Re: Intrusive smart pointer
>Reply-To: boost_at_[hidden]
>
>Here Here! Me too! I also have stayed away from shared_ptr for many of the
>reasons listed below.
>
>Some other advantages of intrusive reference counting:
>
>- smart pointer implementation becomes much simpler than shared_ptr - no
>worries about exception safety because you can safely assume that AddRef and
>Release do not throw (I can't think of any implementations that would need to
>be able to throw exceptions). This is also a consequence of the fact that the
>memory allocation is done in a single step rather than the reference count
>being kept separately.
>- smart pointer implementation doesn't need to worry about thread safety -
>this is up to how AddRef/Release are implemented
>- It's often useful to be able to implement addRef and release
>polymorphically. For example, contained objects can forward the methods to
>their parent object rather than keeping a separate reference count themselves
>(this is often a useful way around the "circular reference" problem):
>
>// Wheel object knows that it is owned by Car object
>class Wheel
>{
>   Car *car_;
>   void AddRef() { car_->AddRef(); }
>   void Release() { car_->Release(); }
>   RefPtr<Car> getCar() { return car_; }
>   // etc.
>}
>
>The key advantage is that the object itself gets to decide where the memory it
>uses comes from - which is essential for instances that come from different
>DLLs (as he said).
>
>One possible disadvantage is that you do have to decide up front whether your
>object is to be thread safe, which I believe Herb Sutter/Jim Hyslop have said
>is the wrong division of responsibilities:
>"The third, like it, is this: Thou shalt not make objects thread-safe; it is a
>perversion. "
>- http://www.cuj.com/experts/2004/hyslop.htm?topic=experts.
>
>Anyway, on WIN32 the overhead of this particular thread safe implementation
>usually isn't much of an issue because InterlockedIncrement/Decrement are very
>efficient.
>
>Of course, I too am biased by my COM background ;-) I just wanted to add my
>vote to the pool of people saying that shared_ptr is not enough.
>
>Paul
>http://PaulHollingsworth.com
>
>>A couple of comments:  I, like you, need to create smart pointers from this
>>frequently, and I also dislike the separate allocation of the reference
>>count. In fact, I've stayed away from boost::shared_ptr entirely for those
>>reasons & instead rolled my own intrusive ref-counted pointer several times.
>>
>>One thing I'd change, although this does come with a cost, is to make the
>>objects self-deleting.  This requires making the destructor of ref_counted
>>virtual, and putting a "delete this;" in ref_counted::release().  I know
>>some (many?) people dislike this idiom because 'delete this' feels so wrong,
>>but it's actually a very good idiom, especially in environments where it's
>>possible to have multiple heaps in a single program.  In such situations,
>>it's essential that the delete expression use the heap from which the object
>>was created.  To complete the pattern, I always use a factory (function,
>>class, whatever) with such classes, and make both the constructor(s) and
>>destructor private.
>>
>>Maybe it's just my COM background influencing me... but this strategy has
>>worked very well for me in many large projects.
>>
>>-cd
>>
>
>
>
>--__--__--
>
>Message: 3
>From: "Peter Dimov" <pdimov_at_[hidden]>
>To: "Andrew R. Thomas-Cramer" <artc_at_[hidden]>
>Cc: "Boost List" <boost_at_[hidden]>
>Date: Thu, 18 Apr 2002 18:45:34 +0300
>Organization: Multi Media Ltd.
>Subject: [boost] Re: Smart pointers (boost or not): const-checking, polymorphism
>Reply-To: boost_at_[hidden]
>
>From: "Andrew R. Thomas-Cramer" <artc_at_[hidden]>
>> Thanks very much for your response.
>>
>> I think these two particular implicit conversions are very important to
>most
>> programmers. Support for the conversion from shared_ptr<T> to
>shared_ptr<const
>> T> was not obvious to me. Perhaps the smart pointer documentation could
>> explicitly refer to these conversions, and provide examples?
>
>Yes, you are right, the documentation doesn't mention the conversions. We'll
>need to update the introduction paragraph to explain that shared_ptr<T> can
>convert to shared_ptr<U> whenever T* can convert to U*. Thanks for the
>feedback. (I've CCed the boost list.)
>
>--
>Peter Dimov
>Multi Media Ltd.
>
>> ----- Original Message -----
>> From: "Peter Dimov" <pdimov_at_[hidden]>
>> Newsgroups: comp.lang.c++.moderated
>> Sent: Wednesday, April 17, 2002 3:09 AM
>> Subject: Re: Smart pointers (boost or not): const-checking, polymorphism
>>
>>
>> > "Andrew R. Thomas-Cramer" <artc_at_[hidden]> wrote in message
>> news:<3cbb189d$0$30311$272ea4a1_at_[hidden]>...
>> > > I'm considering the use of some reference-counting smart pointer
>classes for
>> > > an existing company library. I'm aware of boost::shared_ptr, and will
>> > > probably either use it directly or as the representation of
>library-specific
>> > > smart-pointer classes.
>> > >
>> > > Let shared_ptr<T> be some reference-counting smart pointer type,
>either in
>> > > the boost namespace or not.
>> > >
>> > > With raw pointers, I can const-qualify the pointer:
>> > >     int foo( const T * p );
>> >
>> > It is not the pointer being const-qualified in the above example, but
>> > the pointed-to type. A const-qualified pointer would be "T * const."
>> >
>> > > How should this be done in a similar method accepting a smart pointer?
>> >
>> > shared_ptr<T const>.
>> >
>> > > Let class U extend T. With raw pointers, I can pass a single pointer
>to both
>> > > these methods:
>> > >     int foo( const T * p );
>> > >     int bar( const U * p );
>> > > How should this be done in similar methods accepting smart pointers?
>> >
>> > boost::shared_ptr<U> automatically converts to boost::shared_ptr<T>.
>> >
>> >       [ Send an empty e-mail to c++-help_at_[hidden] for info ]
>> >       [ about comp.lang.c++.moderated. First time posters: do this! ]
>>
>>
>
>
>--__--__--
>
>Message: 4
>From: "David Abrahams" <david.abrahams_at_[hidden]>
>To: <boost_at_[hidden]>
>Subject: Re: [boost] Re: Challenge: persistence/typeid lib
>Date: Thu, 18 Apr 2002 10:44:04 -0500
>Reply-To: boost_at_[hidden]
>
>
>----- Original Message -----
>From: "Nicola Musatti" <objectway_at_[hidden]>
>
>> David Abrahams wrote:
>> [...]
>> > I'm afraid you're wrong. XTI is essentially a compiler which
>produces a
>> > representation of the interfaces and types that a program declares.
>It
>> > doesn't give you a replacement for RTTI. For example, it can't help
>you
>> > produce a representation of the type identifier for a derived class
>of a
>> > polymorphic base.
>>
>> also be possible.
>
>What does that mean?
>
>> By the way, this appears to be the same set of slides
>> BS presented at the ACCU conference:
>> http://www.klid.dk/arrangementer/XTI_kbh.pdf
>
>Thanks,
>Dave
>
>
>--__--__--
>
>Message: 5
>From: "Peter Dimov" <pdimov_at_[hidden]>
>To: <boost_at_[hidden]>
>Subject: Re: [boost] Re: Re: Re: loki::type_list == boost::mpl::list_node
>Date: Thu, 18 Apr 2002 18:49:02 +0300
>Organization: Multi Media Ltd.
>Reply-To: boost_at_[hidden]
>
>From: "David Abrahams" <david.abrahams_at_[hidden]>
>> Let's just assume we're working only with dot-typelist-like structures
>> for the time being. It's fairly easy to abstract out the head, tail,
>> etc.
>>
>> template <class T> struct head;
>> template <class T,class U> struct head<tuple_node<T,U> > {
>>     typedef T type;
>> };
>
>Or you could rename 'head' as 'front' and 'tail' as 'rest', making the list
>a container. Or you could use 'dereference' and 'next', making it an
>iterator. Or both. Wonders of modern technology.
>
>
>--__--__--
>
>Message: 6
>To: boost_at_[hidden]
>From: Jeremy Siek <jsiek_at_[hidden]>
>Date: 18 Apr 2002 10:42:47 -0500
>Subject: [boost] Re: Boost meeting Sunday at 1 PM in Curacao
>Reply-To: boost_at_[hidden]
>
>
>Great, see you then!
>
>Beman Dawes <bdawes_at_[hidden]> writes:
>
>> Boost will hold a meeting Sunday, April 21, at the Marriott in Curacao.
>>
>> There will be a meeting room available (thanks to Randy Marques), but we
>> don't know the exact location.  Ask at the desk if it isn't obvious.
>>
>> Topics to be covered include discussion of how to better distribute the
>> Boost administrative workload, plans for the week, and any technical issues
>> developers want feedback on.
>>
>> While the heart of Boost is the discussion conducted on the mailing lists,
>> the meetings do give Boosters a chance to share thoughts in person.
>>
>> --Beman
>
>
>--
>----------------------------------------------------------------------
> Jeremy Siek                          http://php.indiana.edu/~jsiek/
> Ph.D. Student, Indiana Univ. B'ton   email: jsiek_at_[hidden]
> C++ Booster (http://www.boost.org)   office phone: [phone]
>----------------------------------------------------------------------
>
>
>
>--__--__--
>
>Message: 7
>To: boost_at_[hidden]
>From: "Vesa Karvonen" <vesa_karvonen_at_[hidden]>
>Date: Thu, 18 Apr 2002 18:57:37 +0300
>Subject: [boost] Re: Preprocessor Library - ATTN:  David Abrahams
>Reply-To: boost_at_[hidden]
>
>"Paul Mensonides":
>[...]
>> Good. :) My conclusions are that the BPL should include functionality
>like this
>> for the purposes of debugging and error messages, etc..
>[...]
>> Ideally, you would like some things to be macro recursive (which always
>ends up
>> on one line) and some things to be file iterative (which always ends up
>on
>> different lines).
>
>If I understand correctly, then file iteration has the following benefits:
>- it can be faster on EDG based compilers.
>- it expands stuff on separate lines, which may make debugging easier.
>
>At the present, I don't know how readable the technique can be made, or
>how generic it is. I'd like to see the "chaos" library headers, that
>support the technique (I don't recall if they were available somewhere).
>Anyway, I think that this technique might be worth including in the
>preprocessor library or perhaps in some other library. If we decide to
>provide such support, then I'd certainly like Paul to compose a submission
>of some sort.
>
>...
>
>It seems to me that file based iteration can only provide functionality
>similar to BOOST_PP_REPEAT(), but not functionality like BOOST_PP_FOR().
>BOOST_PP_REPEAT(COUNT,MACRO,DATA) repeats the given MACRO(INDEX,DATA) like
>this:
>
>  MACRO(0,DATA) MACRO(1,DATA) ... MACRO(COUNT-1,DATA)
>
>As you can see, the DATA is passed, as is, to MACRO, but INDEX ranges from
>0 to COUNT-1.
>
>On the other hand, BOOST_PP_FOR(STATE,PRED,OP,MACRO) makes it possible to
>evolve the STATE using the OP macro (the following is slightly
>simplified):
>
>  MACRO(          STATE    )
>  MACRO(       OP(STATE)   )
>  MACRO(    OP(OP(STATE))  )
>  MACRO( OP(OP(OP(STATE))) )
>  ...
>
>The repeated application of OP() to STATE is actually done incrementally.
>So, there will be only a linear amount of OP() applications. The
>incremental evolution of STATE allows many interesting repetitions to be
>performed in O(N) time instead of O(N*N) time. Of course, BOOST_PP_FOR()
>can do many things that are not possible with BOOST_PP_REPEAT().
>
>...
>
>I investigated the arg_tuple_size.h header, which uses the preprocessor
>library, and found out that the reason why it is expanded so slowly, even
>with g++, was that BOOST_MPL_TEMPLATE_PARAMETERS() uses BOOST_PP_ADD(), in
>such a way that the time complexity of
>BOOST_MPL_TEMPLATE_PARAMETERS(first, last, param) is
>O((last-first)*(last-first)). This is because the time complexity of
>BOOST_PP_ADD(X,Y) is currently O(Y).
>
>When BOOST_PYTHON_MAX_ARITY is increased significantly, the time taken by
>BOOST_PP_ADD() grows quickly. Because there are O(N*N) parameters, and the
>expansion of a single parameter takes O(N) time, it takes O(N*N*N) time to
>expand arg_tuple_size.h for large N.
>
>Currently, a simple way to reduce time taken by BOOST_PP_ADD(X,Y) is to
>make sure that Y < X. In this case it can be achieved simply by swapping
>the order of parameters to BOOST_PP_ADD() in the macro
>BOOST_MPL_AUX_TEMPLATE_PARAMETER(). This changes the time complexity of
>BOOST_MPL_TEMPLATE_PARAMETERS(first, last, param) to O(first *
>(last-first)), which, in this case, is much smaller than
>O((last-first)*(last-first)). On g++, preprocessing time was reduced from
>about 2 minutes to 8 seconds when BOOST_PYTHON_MAX_ARITY was 50.
>
>There are many ways in which BOOST_PP_ADD(X,Y) could be implemented in
>logarithmic time (without huge amounts of macro definitions, that is).
>Unfortunately, my earlier attempts on this suggest that it only speeds
>things up when the parameters X and Y become rather large (too large to be
>really useful). I think I'll spend some more time on this when I get some
>time.
>
>...
>
>I think that a long term solution, to avoid performance problems like
>this, would be to drop BOOST_PP_REPEAT() and use BOOST_PP_FOR() based
>solutions. In most cases, BOOST_PP_FOR() makes it possible to perform
>repetition so that preprocessing time is O(N), where N is the number of
>tokens produced.
>
>For example, the time complexity of the recently added macro
>BOOST_PP_REPEAT_FROM_TO(FIRST,LAST,MACRO,DATA) is O(FIRST*(LAST-FIRST)).
>Using BOOST_PP_FOR(), it would be possible to provide a similar primitive
>whose time complexity would be the optimal O(LAST-FIRST).
>
>On the other hand, the use of BOOST_PP_FOR() means that the R parameter
>needs to be passed around explicitly by the user, which is a nuisance. I
>think I'll write up implementations of the BOOST_PP_ENUM and
>BOOST_PP_REPEAT macros using BOOST_PP_FOR and post them on the list for
>discussion.
>
>
>
>
>
>
>--__--__--
>
>Message: 8
>From: "Fernando Cacciola" <fcacciola_at_[hidden]>
>To: <boost_at_[hidden]>
>Subject: Re: [boost] Re: Intrusive smart pointer
>Date: Thu, 18 Apr 2002 12:59:49 -0300
>Organization: SIERRA S.R.L.
>Reply-To: boost_at_[hidden]
>
>
>----- Original Message -----
>From: "Peter Dimov" <pdimov_at_[hidden]>
>To: <boost_at_[hidden]>
>Sent: Thursday, April 18, 2002 11:47 AM
>Subject: Re: [boost] Re: Intrusive smart pointer
>
>
>> From: "Carl Daniel" <cpdaniel_at_[hidden]>
>> > "David B. Held" <dheld_at_[hidden]> wrote in message
>> > news:a9limo$9jc$1_at_main.gmane.org...
>> > > I have uploaded
>> > http://groups.yahoo.com/group/boost/files/intrusive_ptr.hpp,
>> > > which is an implementation of an intrusive reference-counted
>> > > smart pointer that was shamelessly copied from boost::shared_ptr.
>> >
>> > One thing I'd change, although this does come with a cost, is to make
>the
>> > objects self-deleting. [...]
>>
>> IMO, there is no "standard" intrusive pointer. The variations are (at
>> least):
>>
>> * type of count: public variable, accessor functions, base class;
>> * name of count/accessors (addref, AddRef, addRef, attach);
>> * initial value of the reference count (zero or one.)
>> * delete in the pointer or self-delete in release.
>>
>Still, boost could define at least one of these variations.
>
>Off the top of my head:
>
>Define a new class: shared_object, which fixes some of the possible
>semantics.
>
>Modify shared_ptr<T>  et.al. to automatically select between two
>implementations, one based on shared_object and the other as it is now (with
>a external count).
>
>The effect would be that *only* classes derived from shared_object would
>automatically make shared_ptr behave intrusively.
>
>Fernando Cacciola
>Sierra s.r.l.
>fcacciola_at_[hidden]
>www.gosierra.com
>
>
>
>--__--__--
>
>Message: 9
>Subject: Re: [boost] Re: Re: loki::type_list == boost::mpl::list_node
>From: Hamish Mackenzie <hamish_at_[hidden]>
>To: boost_at_[hidden]
>Date: 18 Apr 2002 16:10:06 +0100
>Reply-To: boost_at_[hidden]
>
>
>--=-B6hKWg7LX7+p6HGVSId2
>Content-Type: text/plain
>Content-Transfer-Encoding: 7bit
>
>On Wed, 2002-04-17 at 09:34, Aleksey Gurtovoy wrote:
>> The 'aux::unrolling_size' template then would return -1 by default, and
>> would be specialized for specific sequence types (e.g. list##i) for which we
>> can determine the size at O(1).
>
>Am I correct in thinking aux::unrolling_size needs to work on list_node
>as well as list##i?
>
>On GCC the fastest implementation of size I have found so far is the one
>I posted earlier so I will use this for unrolling_size.
>
>To get an idea of the overhead of the the approach you have suggested I
>implemented size in the same way (in fact as size is based on distance I
>have implemented do_distance)
>
>Here are the results (times in seconds)
>TEST_N	N	TEST1	TEST2	TEST3
>1	10	13.89	1.83	1.85
>2	20	30.70	1.85	1.88
>3	30	51.98	1.86	1.90
>6	60	158.63	1.88	2.26
>10	100	?	2.06	3.43
>20	200	?	3.43	13.39
>30	300	?	6.80	39.23
>40	400	?	13.23	88.76
>
>TEST_N = N/10
>N = size of list
>TEST1 = Result using existing MPL
>TEST2 = Top level recursion
>TEST3 = unrolling_size/do_distance
>
>g++ -v
>Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.1/specs
>Configured with: ../gcc-20020415/configure
>Thread model: single
>gcc version 3.1 20020415 (prerelease)
>
>Obviously we would not use do_distance for size if unroll_size was not
>-1 so these results should be take with a pinch of salt.
>
>I'll have a crack at count_if next.
>
>Hamish
>
>
>--=-B6hKWg7LX7+p6HGVSId2
>Content-Disposition: attachment; filename=size.cpp
>Content-Transfer-Encoding: quoted-printable
>Content-Type: text/x-c++; name=size.cpp; charset=ANSI_X3.4-1968
>
>#include <iostream>
>
>#include <boost/mpl/integral_c.hpp>
>
>#include <boost/mpl/list.hpp>
>
>#ifdef TEST1
>#include <boost/mpl/size.hpp>
>#endif
>
>#include <boost/static_assert.hpp>
>
>#include "pp.h"
>
>namespace boost{ namespace mpl {
>
>#if defined( TEST1 )
>=09
>
>#elif defined( TEST2 )
>
>template< typename Sequence >
>struct size;
>
>#define BOOST_MPL_PP_SIZE_OPT_DEPTH 8
>#define BOOST_MPL_PP_SIZE_OPT_STEP 8
>
>#define BOOST_MPL_PP_SIZE_OPT1( i, op ) \
>  template< BOOST_MPL_PP_PARAMS( 0, i, typename H ) > \
>  struct size< BOOST_MPL_PP_NUMBER_RECURSE( list_node<, H, 0, i, null_node,=
> > ) > \
>  { \
>    typedef integral_c< unsigned long, i > type; \
>  }; \
>/**/
>
>BOOST_PP_REPEAT_2ND( BOOST_MPL_PP_SIZE_OPT_DEPTH, BOOST_MPL_PP_SIZE_OPT1, (=
>unused) )
>
>template< BOOST_MPL_PP_PARAMS( 0, BOOST_MPL_PP_SIZE_OPT_STEP, typename H ),=
> class Tail >
>struct size< BOOST_MPL_PP_NUMBER_RECURSE( list_node<, H, 0, BOOST_MPL_PP_SI=
>ZE_OPT_STEP, Tail, > ) >
>{
>	typedef typename size< Tail >::type tail_size;
>        typedef integral_c< unsigned long, tail_size::value + BOOST_MPL_PP_=
>SIZE_OPT_STEP > type;
>};
>
>#elif defined( TEST3 )
>
>namespace aux {
>
>template< typename Sequence >
>struct unrolling_size;
>
>#define BOOST_MPL_PP_SIZE_OPT_DEPTH 8
>#define BOOST_MPL_PP_SIZE_OPT_STEP 8
>
>#define BOOST_MPL_PP_SIZE_OPT1( i, op ) \
>  template< BOOST_MPL_PP_PARAMS( 0, i, typename H ) > \
>  struct unrolling_size< BOOST_MPL_PP_NUMBER_RECURSE( list_node<, H, 0, i, =
>null_node, > ) > \
>  { \
>    typedef integral_c< unsigned long, i > type; \
>  }; \
>/**/
>
>BOOST_PP_REPEAT_2ND( BOOST_MPL_PP_SIZE_OPT_DEPTH, BOOST_MPL_PP_SIZE_OPT1, (=
>unused) )
>
>template< BOOST_MPL_PP_PARAMS( 0, BOOST_MPL_PP_SIZE_OPT_STEP, typename H ),=
> class Tail >
>struct unrolling_size< BOOST_MPL_PP_NUMBER_RECURSE( list_node<, H, 0, BOOST=
>_MPL_PP_SIZE_OPT_STEP, Tail, > ) >
>{
>	typedef typename unrolling_size< Tail >::type tail_size;
>        typedef integral_c< unsigned long, tail_size::value + BOOST_MPL_PP_=
>SIZE_OPT_STEP > type;
>};
>
>template<
>      typename First
>    , typename Last
>    , long Size
>    >
>struct do_distance;
>
>} // namespace aux
>
>template<
>      typename Sequence
>    >
>struct size
>    : public aux::do_distance<
>          typename begin<Sequence>::type
>        , typename end<Sequence>::type
>        , aux::unrolling_size< Sequence >::type::value
>        >
>{
>};
>
>// #define BOOST_MPL_SIZE_UNROLLING_LIMIT BOOST_MPL_UNROLLING_LIMIT
>#define BOOST_MPL_SIZE_UNROLLING_LIMIT 8
>
>namespace aux {
>
>#define BOOST_MPL_PP_DO_DISTANCE_AUX( i, op ) \
>  typedef typename BOOST_PP_CAT( iter, i ) ::next \
>      BOOST_PP_CAT( iter, BOOST_PP_ADD( i, 1 ) ); \
>
>#define BOOST_MPL_PP_DO_DISTANCE( i, op ) \
>template< \
>      typename First \
>    , typename Last \
>    > \
>struct do_distance<First,Last,i> \
>{ \
>    typedef First iter0; \
>    typedef integral_c<unsigned long,i> type; \
>    BOOST_PP_REPEAT( i, BOOST_MPL_PP_DO_DISTANCE_AUX, unused ) \
>    typedef BOOST_PP_CAT( iter, i ) last_iterator; \
>}; \
>/**/
>
>BOOST_PP_REPEAT_2ND( BOOST_PP_ADD( BOOST_MPL_SIZE_UNROLLING_LIMIT, 1 ), BOO=
>ST_MPL_PP_DO_DISTANCE, unused )
>
>
>// specialization for sequences with unknown size
>template<
>      typename First
>    , typename Last
>    >
>struct do_distance<First,Last,-1>
>{
>    // implement unsophisticated version
>    // ...
>    BOOST_STATIC_ASSERT( false );
>};
>
>// specialization for sequences with known size which
>// exceeds BOOST_MPL_SIZE_UNROLLING_LIMIT
>template<
>      typename First
>    , typename Last
>    , long Size
>    >
>struct do_distance
>{
>    typedef do_distance<
>          First
>        , Last
>        , BOOST_MPL_SIZE_UNROLLING_LIMIT
>        > first_segment_;
>
>    typedef do_distance<
>          typename first_segment_::last_iterator
>        , Last
>        , Size - BOOST_MPL_SIZE_UNROLLING_LIMIT
>        > rest_;
>
>    typedef typename integral_c<
>          unsigned long
>        , first_segment_::type::value + rest_::type::value
>        >::type type;
>};
>
>} // namespace aux
>
>#endif
>
>} }
>
>class a;
>
>#define TEST_LIST_ITEM1( i, op ) \
>  list_node< a, \
>  list_node< a, \
>  list_node< a, \
>  list_node< a, \
>  list_node< a, \
>  list_node< a, \
>  list_node< a, \
>  list_node< a, \
>  list_node< a, \
>  list_node< a, \
>/**/
>
>#define TEST_LIST_ITEM2( i, op ) \
>  > \
>  > \
>  > \
>  > \
>  > \
>  > \
>  > \
>  > \
>  > \
>  > \
>/**/
> =20
>int main()
>{
>	using boost::mpl::list_node;
>	using boost::mpl::null_node;
>	using boost::mpl::size;
>=09
>	typedef size<=20
>		BOOST_PP_REPEAT( TEST_N, TEST_LIST_ITEM1, unused ) null_node=20
>		BOOST_PP_REPEAT( TEST_N, TEST_LIST_ITEM2, unused ) >::type result;
>
>	std::cout << result::value << std::endl;
>=09
>	return 0;
>}
>
>
>--=-B6hKWg7LX7+p6HGVSId2--
>
>
>--__--__--
>
>Message: 10
>From: "John Harris (TT)" <john.harris_at_[hidden]>
>To: "'boost_at_[hidden]'" <boost_at_[hidden]>
>Date: Thu, 18 Apr 2002 11:37:18 -0500
>Subject: [boost] Extend preprocessor tuples with this perl script
>Reply-To: boost_at_[hidden]
>
>I love the BOOST_PP_TUPLE* macros, but the limit of 16 is restrictive.
>
>I wrote a script to generate the code that should be added to tuple/eat.hpp,
>tuple/elem.hpp, and tuple/to_list.hpp for an arbitrary limit.
>
>Uh, and here it is:
>
>$start=17;  # start at 17, boost 1.27.0 defines up to 16
>$end = 100; # you might want something less :-)
>
>print "// extend tuple/eat.hpp\n";
>for($j = $start; $j <= $end; ++$j)
>{
>    print "#define BOOST_PP_TUPLE${j}_EAT(";
>    for($i=0;$i<$end;++$i) { printf( "%sP%3.3d", ($i ? "," : ""), $i); }
>    print ")\n";
>}
>
>print "\n// extend tuple/elem.hpp\n";
>for($j = $start; $j <= $end; ++$j)
>{
>    for($k = 0; $k < $j; ++$k)
>    {
>        print "#define BOOST_PP_TUPLE${j}_ELEM${k}(";
>        for($i=0;$i<$j;++$i) { printf( "%sP%3.3d", ($i ? "," : ""), $i); }
>        printf ") P%3.3d\n", $k;
>    }
>    print "\n";
>}
>
>print "\n// extend tuple/to_list.hpp\n";
>for($j = $start; $j <= $end; ++$j)
>{
>    print "#define BOOST_PP_TUPLE${j}_TO_LIST(";
>    for($i=0;$i<$j;++$i) { printf( "%sP%3.3d", ($i ? "," : ""), $i); }
>    print ") \\\n    ";
>    for($i=0;$i<$j;++$i) { printf( "(P%3.3d,", $i); }
>    print "(_,_,0)";
>    for($i=0;$i<$j;++$i) { print ",1)"; }
>    print "\n";
>}
>
>Regards,
>
>john harris
>trading technologies
>
>
>--__--__--
>
>Message: 11
>To: boost_at_[hidden]
>From: Nicola Musatti <objectway_at_[hidden]>
>Date: Thu, 18 Apr 2002 18:38:30 +0200
>Organization: ObjectWay S.p.A.
>Subject: [boost] Re: Challenge: persistence/typeid lib
>Reply-To: boost_at_[hidden]
>
>
>
>David Abrahams wrote:
>>
>> ----- Original Message -----
>> From: "Nicola Musatti" <objectway_at_[hidden]>
>>
>> > David Abrahams wrote:
>> > [...]
>> > > I'm afraid you're wrong. XTI is essentially a compiler which
>> produces a
>> > > representation of the interfaces and types that a program declares.
>> It
>> > > doesn't give you a replacement for RTTI. For example, it can't help
>> you
>> > > produce a representation of the type identifier for a derived class
>> of a
>> > > polymorphic base.
>> >
>> > also be possible.
>>
>> What does that mean?
>
>Apparently one line got sliced off my message; it was supposed to read:
>
>also be possible.
>
>Cheers,
>Nicola Musatti
>
>
>
>--__--__--
>
>Message: 12
>From: "Peter Dimov" <pdimov_at_[hidden]>
>To: <boost_at_[hidden]>
>Subject: Re: [boost] Re: Intrusive smart pointer
>Date: Thu, 18 Apr 2002 19:37:39 +0300
>Organization: Multi Media Ltd.
>Reply-To: boost_at_[hidden]
>
>From: "Fernando Cacciola" <fcacciola_at_[hidden]>
>> > IMO, there is no "standard" intrusive pointer. The variations are (at
>> > least):
>> >
>> > * type of count: public variable, accessor functions, base class;
>> > * name of count/accessors (addref, AddRef, addRef, attach);
>> > * initial value of the reference count (zero or one.)
>> > * delete in the pointer or self-delete in release.
>> >
>> Still, boost could define at least one of these variations.
>
>Sure. Which one? How many complaints will we get that _that one_ was more
>appropriate?
>
>
>
>
>--__--__--
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>End of Boost Digest
>