David A. Greene wrote:
> I do need to be able to start at various points within the sequence.
> Your second solution fleshes out the design I had in mind, but I
> was out of town over the weekend so you beat me to the punch. :)
Actually, I wrote too much code in that "solution" ;). Just this woul
David Abrahams wrote:
> Well I hope that was all instructive, but it was probably way more
> complicated than neccessary. I think it would actually be far superior
> to build a solution around an mpl iterator adaptor like this one:
>
>template struct zip_iterator
>{
> typedef type
Alisdair Meredith wrote:
> You can see the result of the 'standard' boost regression tests here:
>
> http://boost.sourceforge.net/regression-logs/cs-win32-diff.html
>
> As you can see, there is only one test for the BGL and BCB6
> fails it :¬
> (
> [Don't see the MPL tests there, and I haven't t
vladimir josef sykora wrote:
> Any experiences using boost-libs with Borland Builder 6,
> specially BGL and MPL? Already performed or anyone attempted
> some Regression Tests?
The results of the tonight's MPL regression tests are available from here -
http://www.mywikinet.com/mpl/log.html.
As
David B. Held wrote:
> In this code,
>
> template
> struct apply_lambda
> {
> typedef typename mpl::lambda::type f_;
> typedef typename mpl::apply::type type;
> };
>
> MSVC reports that there is no "apply" in "mpl". I thought
> it was being stupid, so I preproce
David B. Held wrote:
> Now, for a real stumper. It seems to me that VC6 is only
> pretending to compile MPL::Lambda. The reason being that it refuses
> to recognize nested types that have passed through lambda. Here's
> what I think is the relevant code:
[snip]
> Now, inside smart_ptr...
>
David B. Held wrote:
> > Fortunately, once you know what's happening, the bug is easy to
> workaround:
> >
> > template< typename T > struct pointer_type
> > {
> > typedef typename T::pointer_type type;
> > };
> >
> > #if defined(BOOST_MPL_MSVC_ETI_BUG)
> > template<> st
David B. Held wrote:
> > > > template
> > > > struct get_category
> > > > : mpl::if_<
> > > > mpl::is_placeholder
> > > > , mpl::identity
> > > > , get_category_impl
> > > > >::type
> > > > {
> > > > BOOST_MPL_AUX_LAMBDA
David A. Greene wrote:
> Is it possible to have an MPL vector of MPL vectors?
Sure. MPL sequences are polymorphic regarding their elements; everything
that is a type can be put into a sequence, and everything in MPL is a type
:).
> When I try this, the compiler (g++ 3.2) complains about an inco
Beman Dawes wrote:
> Hum... I'll take your word for it, but to tell the truth I
> have trouble understanding what either ``this->member_name''
> or `BaseClass::member_name'' adds.
It makes 'member_name' identifier a dependent name (14.6.2, [temp.dep]),
thus deferring its resolution to the point
David Abrahams wrote:
> I'm trying to come up with instructions for compiler vendors who want
> to use Boost to test their compilers. What preprocessor symbols do
> they need to define? So far, it looks like:
>
> - BOOST_NO_COMPILER_CONFIG
> - BOOST_NO_STDLIB_CONFIG - if they want to c
David A. Greene wrote:
> [Posted to boost because MPL is not yet released. At what
> point should these questions go to boost-users?]
It's mainly the content of the message that determines whether it should be
posted here or to the Boost Users list; the status of the library - is it in
developm
David B. Held wrote:
> > In "C++ Templates: The Complete Guide" (Recommended), they give
> > this example on pages 106-107:
> >
> > typedef char RT1;
> > typedef struct {char a[2];} RT2;
> > template RT1 test(typename T::X const*);
> > template RT2 test(...);
> >
> > #define type_has_member_ty
David Abrahams wrote:
> > MPL's implementation ("boost/mpl/aux_/has_xxx.hpp") is
> > known to work on Comeau, Intel (all versions), MSVC (all versions),
> > Metroweks 8.3/8.2 and GCC 3.2. There is no known way to make it
> > work on Borland. You can test it against any other compiler by
> > tryi
David A. Greene wrote:
> But consider this testcase:
>
> //#define CT_DEBUG
>
> //#include "ct_print.hh"
> #include
> #include
>
> template
> struct my_type {
> };
>
> template
> struct my_type_generator {
>typedef my_type type;
> };
>
> template class Base,
>typename T, typename
David Abrahams wrote:
> > 2) We don't recognise the compiler: assume that it is standard
> > conforming and disable all workarounds.
>
> Is this a different case from "we recognize the compiler, but not the
> compiler version"?
>
> Incidentally, I think we had some kind of agreement a while back
David A. Greene wrote:
> Aleksey Gurtovoy wrote:
> > It _is_ possible to implement a single template along the
> > lines of the SHAZAM template you've mentioned early in the
> > thread:
> >
> > template
> > struct my_type { ... } // Note:
David Abrahams wrote:
> > Second, with VC++ large numbers of warnings are now
> > appearing for many type traits headers.
>
> Which version? I can't reproduce these problems with 6, 7, or 7.1.
I can't either, but I fixed it anyway :).
Aleksey
___
Un
Virgilio, Vincent wrote:
> Has anybody successfully compiled Aleksey Gurtovoy's state
> machine generator with gcc 3.2 over Boost 1.29 (which includes the mpl)?
The version in the CVS (libs/mpl/example/fsm) compiles succesfully on Intel
C++ 6.0/7.0, GCC 3.2/2.95.3, and VC 7.1.
[from a follow-up]
Virgilio, Vincent wrote:
> I apologize for the incompleteness of my last message:
>
> In addition to a successful compile of the fsm generator, the 'player'
> example works as well.
>
> Thank you for such high quality software,
My pleasure, and thanks!
Aleksey
__
Peter Dimov wrote:
> From: "vladimir josef sykora" <[EMAIL PROTECTED]>
> > template
> > struct foo {
> > };
> >
> > // usage example :
> > typedef boost::mpl::vector<...> types;
> > typedef foo foo_types;
> > std::vector std_ve
David Abrahams wrote:
> "John Maddock" <[EMAIL PROTECTED]> writes:
> > In theory the way to do that is (for example):
> >
> > #if defined(__BORLANDC__) && ((__BORLANDC__ < 0x570) ||
> > !defined(BOOST_STRICT_CONFIG))
> >
> > which enables the workaround for all Borland versions, unless
> > BOOST_ST
David Abrahams wrote:
> > I agree completely, and I'll even promise not to change my
> > mind for at least a week :-)
>
> Good! You, Aleksey and I all agree. So shall we go with this
> definition of BOOST_WORKAROUND from Gennaro Prota?
>
>#define BOOST_WORKAROUND(symbol, test) ((symbol != 0
vladimir josef sykora wrote:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> > > but I am not sure how reliable that would be. Hmm, it
>
Iain K.Hanson wrote:
> I'm having a problem using fold with the example from the reference
> page. I can get the following example from copy to comile as fold
>
> namespace mpl = boost::mpl;
> using mpl::_;
>
> typedef mpl::vector10_c answer;
>
> typedef mpl::fold<
> mp
Hugo Duncan wrote:
> On Fri, 13 Dec 2002 20:16:18 GMT, Hugo Duncan
> <[EMAIL PROTECTED]> wrote:
> > This gets rid of most of the failures
> >
>
> oops, cut and paste error. try this
>
> RCS file: /cvsroot/boost/boost/boost/mpl/bool_c.hpp,v
> retrieving revision 1.3
> diff -r1.3 bool_c.hpp
> 38
David A. Greene wrote:
> Well, that's not creating a boost::tuple. :) I could certainly use
> mpl::fold or some similar algorithm to create boost::tuple boost::tuple<...> > > > but I'm not sure that "really" a boost::tuple
> either. cons > > > might be closer.
Yep, the later will give you all t
Terje Slettebø wrote:
> By the way, when making the above, I found that the docs for at/at_c
> specifies , while the library has .
> Could this be fixed?
It's fixed in the sources, but I need to re-generate the static version to
put it public. There've been quite a few fixes in the docs since the
Aleksey Gurtovoy wrote:
> David A. Greene wrote:
> > Thanks for considering this. I think it will be quite
> > useful. I look forward to seeing what you come up with!
>
> Well, it turned out to be a little bit more complicated than
> I had foreseen, so it's not
David Abrahams wrote:
> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> > Yep, the later will give you all the functionality of
> > 'boost::tuple' except the constructors and assignment from
> > 'std::pair'. A generator for it is as simple as this
David Abrahams wrote:
> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> > Okay, from this moment MPL's lambda supports "reduced"
> > metafunction form directly (if detected):
> >
> > template< typename T > struct her
> > {
>
David A. Greene wrote:
> The fundamental problem is that it's inconvenient to iterate through a
> tuple.
'tuple_ext' ("tuple extensions") make it easier -
http://groups.yahoo.com/group/Boost-Users/message/704.
Aleksey
___
Unsubscribe & other changes:
[EMAIL PROTECTED] wrote:
> Finally, is there anyone interested in working on a
> reflection framework?
I've been recently drafting some interfaces for purely compile-time
reflection framework. It will clearly need a compiler support to implement;
the current plan is to prototype it in GCC. It's a
[EMAIL PROTECTED] wrote:
> On Tue, 17 Dec 2002, Aleksey Gurtovoy wrote:
>
> > I've been recently drafting some interfaces for purely compile-time
> > reflection framework. It will clearly need a compiler support to
> > implement; the current plan is to prototype i
Russell Yanofsky wrote:
> A preprocessor bug in codewarrior 8.3 causes various parts of the mpl
> library to fail to compile.
Hmm, not with the current sources in the CVS... oh, I see, you are using
1.29.0 distribution. It's already fixed in the CVS' main trunk.
Thanks for the patch, though!
Al
David Abrahams wrote:
> Hum, hum.
> I *am* seeing one error from the MPL regressions with cwpro8.3:
[snip "as_sequence.cpp" test errors]
>
> However, it doesn't look like it's preprocessor-related.
Yep, it's not. It's a known failure, which I didn't have time to track down
yet... hmm, apparentl
David Abrahams wrote:
> Toon Knapen <[EMAIL PROTECTED]> writes:
> > No regression status pages are available yet as I don't
> > succeed in compiling the necessary libraries for the reporting
> > tools ;(
> >
> > So in my quest to compile the reporting tools I modified
> > integral_c.hpp
> > Inde
Russell Yanofsky wrote:
> It would be helpful if you had this information in the
> documentation at
>
> http://www.mywikinet.com/mpl/
> http://www.boost.org/libs/mpl/doc/
>
> since both of those pages say the "latest sources" are on the
> v2 branch.
Done.
Aleksey
_
Jaap Suter wrote:
> what's the current status on using MPL on different
> compilers? I have looked
> at http://www.mywikinet.com/mpl/log.html but it seems not all
> meta-functions are listed there.
I would say that currently the tests cover about 80% of library
functionality, so the aforemention
Jaap Suter wrote:
> parameters. I did this in a few places for operators that MPL doesn't
> implement (left shift, bitwise or, etc.).
> Now I'm putting them in a seperate static constant first, and
> then using that constant as a template parameter. That really
> solves a _lot_ of my MSVC problem
David Abrahams wrote:
> Lastly, I know that Aleksey will argue with me about this,
Yep, I will :).
> but I have a strong preference for "class" rather than "typename" in
template
> parameter lists. Aside from the fact that it's longer, "typename" is
> visually confusable because it can mean oth
I am going to use our wonderful Preprocessor library to generate a
metafunction that basically looks like this:
template<
int C0, int C1, ..., int Cn
>
struct max_arity
{
static int const value = Cn > 0 ? Cn : ( Cn-1 > 0 ? Cn-1 :
... ( C1 > 0 ? C1
Paul Mensonides wrote:
> Hi Aleksey,
Hi Paul,
>
> > I am going to use our wonderful Preprocessor library to generate a
> > metafunction that basically looks like this:
>
> [...]
>
> > I love everything about it except for the "(0, (1, (2, (3, (4,
> > BOOST_PP_NIL)" part. I would like the a
Paul Mensonides wrote:
> #include
> #include
>
> #define NUMBERS \
> (0)(1)(2)(3)(4)(5)(6)(7)(8)(9) \
> (10)(11)(12)(13)(14)(15)(16)(17)(18)(19) \
> /* ... */
>
> #define RANGE(first, length) \
> BOOST_PP_SEQ_SUBSEQ( NUMBERS, first, length ) \
> /**/
>
> BOOST_PP_SEQ_FOLD_L
David Abrahams wrote:
> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
> > IMO it's more a problem with the layout of template
> > parameters than with anything else:
> >
> > template<
> > typename T
> > , typename U = ty
Paul Mensonides wrote:
> > For the time being, try BOOST_PP_SEQ_FIRST_N. If that
> > doesn't work for now, I'll get on it immediately.
>
> Both of these were broken, but I fixed them.
Yep, it works now. Thanks, Paul!
> Let me know if you encounter any other problems.
Sure :)
Aleksey
Paul Mensonides wrote:
> - Original Message -
> From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]>
>
> > > #define NUMBERS \
> > > (0)(1)(2)(3)(4)(5)(6)(7)(8)(9) \
> > > (10)(11)(12)(13)(14)(15)(16)(17)(18)(19) \
> &g
Jaap Suter wrote:
> Hi,
Hi Jaap,
> I've written some MPL meta-functions that might be useful. But first a
> question though...
>
> Is it possible that (under certain conditions) the following line:
>
> mpl::int_c<
> mpl::minus<
> mpl::int_c< 0 >,
>
Toon Knapen wrote:
> Finally I found out that aCC has a problem with the typename
> mixed with the template spec. So if I write the construct like
> this it works. Could you apply this patch ?
>
Sure, done.
Aleksey
___
Unsubscribe & other changes: ht
David A. Greene wrote:
> Aleksey Gurtovoy wrote:
> > Figuring out a reasonable way to specify the promotion
> > rules is probably the hardest part there...
>
> I actually did some work on this in the past but it's been sitting
> on the shelf for a while and probably
Toon Knapen wrote:
> Apparently with the introduction of BOOST_WORKAROUND, an
> __HP_aCC__ got warped into __IBMCPP__ (while the aCC version
> number is still correct).
Err, sorry, copy & paste error.
> So Aleksey if you could apply this patch (or if you want me to do it ?)
Sure, go ahead.
A
David Abrahams wrote:
> Second thing: you can save yourself lots of typenames by taking
> advantage of the way MPL lets you pass an uninstantiated metafunction,
> without getting its nested ::type member, wherever a bool_c<...> is
> expected:
Uhm, that's not exactly correct. I would re-formulate i
Jaap Suter wrote:
> > Nifty! You're using one of my favorite metaprogramming tricks, the
> > default template parameter which allows you to avoid creating a
> > separate implementation template. I almost forgot about that one,
> > it's been so long since I've been able to use it.
>
> Funny you m
David A. Greene wrote:
> >>Does this sound at all interesting?
> >
> > Very!
> >
> >>The implementation is complex (didn't have MPL at the time) but can
> >>probably be cleaned up some. It may be too flexible for your needs.
> >
> > Even if so, it would give us some interesting prior art to
Hi all,
How would you call an 'apply' counterpart that takes a metafunction class
and a _sequence_ of arguments, i.e.:
typedef list_c args;
typedef apply_tuple< plus<>, args >::type sum; // this one
BOOST_STATIC_ASSERT(sum::value == 5);
?
If it was run-time C++, I would be happy wit
David Abrahams wrote:
> > How would you call an 'apply' counterpart that takes a
> > metafunction class and a _sequence_ of arguments, i.e.:
> >
> > typedef list_c args;
> > typedef apply_tuple< plus<>, args >::type sum; // this one
> > BOOST_STATIC_ASSERT(sum::value == 5);
> >
> > ?
>
Greg Colvin wrote:
> > If it was run-time C++, I would be happy with 'apply_tuple',
> > but in MPL domain "tuple" isn't really the right word, and I
> > don't like 'apply_seq' or, worse yet, 'apply_sequence'. Or
> > should it be 'seq_apply' (from an English language standpoint)?
>
> If this co
David Abrahams wrote:
> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes:
>
> >
> > So, now the question is, how to name the adaptor? :) Does
> > 'unroll_args' sound right/good enough?
>
> Neat idea! How about "unary" or "unaryize"
Terje Slettebø wrote:
> I guess this is another good argument for class template
> overloading. Does anyone know if this has been "formally"
> proposed for C0x?
AFAIK, no.
> A quick search at Google Groups turned up nothing.
>
> With it, you might have used:
>
> template<>
> struct plus
> {
Greg Colvin wrote:
> > > If this construct applies a metafuntion to a sequence
> >
> > It does and it doesn't :). Sorry if I wasn't clear about the
> > semantics; it does not apply a metafunction to every element
> > of a sequence;
>
> That would be for_each ?
Almost - 'for_each' only makes s
Jaap Suter wrote:
> Hi,
Hi Jaap,
> I need some help with providing lambda support for my own
> meta functions. I think this has to do with the following thread:
>
> http://aspn.activestate.com/ASPN/Mail/Message/1387917
>
> but I can't really figure out what to do.
Have you seen this one -
Jaap Suter wrote:
> > Actually, I was planning on bringing the content of "arithmetic",
> > "logic" and "comparison" directories to "boost/mpl" root (still
> > preserving the corresponding composite headers). In that light,
> > I would suggest putting the new headers directly into the root
> > d
Jaap Suter wrote:
> So I tried to come up with the actual smallest example that
> doesn't compile, even
> with the LAMBDA_SUPPORT macro. It looks as follows:
>
> template< class T >
> struct meta_fun_1
> {
> typedef mpl::integral_c< typename T::value_type, 0 > type;
> BOOST_MPL_AUX_LAMBDA
Pavol Droba wrote:
> Hi,
Hi Pavol,
> I have sent a problem report on the list, recently, regarding
> mpl::find_if algorithm on vc7 platform. I'm using 1.29 release
> not current cvs snapshot.
>
> I assume, that description was not good enough so I haven't
> got any response.
Sorry, I think I
Vesa Karvonen wrote:
> Hi,
Hi Vesa,
>
> The following is an example of using "superlinear unrolling".
> It compiles with
>
> gcc version 2.95.4 20011002 (Debian prerelease)
>
> using the default settings (max template recursion depth should be
> 17). The example code essentially applies th
[EMAIL PROTECTED] wrote:
> I do not expect from the cla framework to do the parsing for me, it
> should return strings associated with keys (which are strings too)
> from different locations (cla, cfg file, registry etc.).
... through something like lexical property map:
template<
Ronald Garcia wrote:
> Howdy. I am trying to use KCC in strict mode to compile some
> code that depends on type traits.
Which version? Does it support partial template specialization/template
template parameters?
> I am getting a large quantity of errors along these lines:
>
> "/u/garcia/sr
Ronald Garcia wrote:
> Here's the version blurb:
>
> Edison Design Group C/C++ Front End, version 2.43.1 (Jan 16
> 2001 11:20:19)
> Copyright 1988-1999 Edison Design Group, Inc.
>
> KAI C++ 4.0d (KCC) -- Jan 16 2001 -- (C) Copyright 1994-2000 Kuck &
> Associates,
> Inc.
Thanks!
>
> AFAIK It s
Ronald Garcia wrote:
> The code you posted compiles under KCC both with and without
> the --strict command-line parameter.
Good, check out the latest CVS sources, then - the issue should be fixed
now.
> Hope this helps, and thank you.
You are welcome!
Aleksey
David Abrahams wrote:
> Terje Slettebø <[EMAIL PROTECTED]> writes:
> > Perhaps it might be possible to do some compile-time/run-time lambda
> > (similar to Boost.Lambda for runtime, and MPL's lambda), so you
> > could do something like:
> >
> > mpl::for_each(my_function<_>(s));
> >
> > It would th
Hugo Duncan wrote:
> Including for_each.hpp on bcc561 gives
>
> Error E2230
> c:\usr\boost\boost/mpl/aux_/preprocessed/bcc/template_arity.hp
> p 20: In-line data member initialization requires an integral
> constant expression
>
> Any chance of finding a fix for this? I am having problems
> w
Joel de Guzman wrote:
> Hi,
Hi Joel,
> Question why is mpl::void_t an incomplete type?
I suppose we are talking about 'mpl::void_'. Since we have a use case for it
now, just go ahead and make it complete! (A short comment would be nice, too
:).
Aleksey
_
Joel de Guzman wrote:
> Here's the Phoenix version:
>
> struct my_function_
> {
>
> template
> struct result { typedef void type; };
>
> template< typename U >
> void operator()(std::string const& text, U)
> {
> // ...
> }
>
>
What would be an equivalent of the following #fief, if I want to re-writte
it using our new BOOST_WORKAROUND macro?
// last checked with 0x561
#if defined(__BORLANDC__) && __BORLANDC__ >= 0x561 &&
!defined(BOOST_STRICT_CONFIG)
Here, "0x561" is the first version requiring the workaround and at the
Hugo Duncan wrote:
> On Fri, 24 Jan 2003 09:17:00 -0600, Aleksey Gurtovoy
> <[EMAIL PROTECTED]> wrote:
> > I don't have access to 5.6.1, so I would need some cooperation to
> > fix it.
>
> 5.6.1 is 5.6 with patch 2 applied.
Yeah, only the patch cannot be
Hugo Duncan wrote:
> I think I have found a problem with boost/mpl/list.hpp
>
> I am including files using BOOST_PP_ITERATE. One of the files
> that I include happens itself to include boost/mpl/list.hpp.
>
>
> boost/mpl/list.hpp begins
>
> #if !defined(BOOST_PP_IS_ITERATING)
> / heade
Hugo Duncan wrote:
> Maybe my use of ITERATE is slightly different, in that I am using
> it to include a LIST of files. The LIST provides a single
> integration point. Hoisting all the includes reduces the utility
> of using ITERATE.
OK, I see the problem now.
>
> I can hoist the include of (
Paul Mensonides wrote:
> - Original Message -
> From: "Aleksey Gurtovoy" <[EMAIL PROTECTED]>
> > You have a point, here. I'll look into the issue tonight.
>
> Don't bother. What Hugo is doing is a "sketchy" use of the mechanism
>
Joel de Guzman wrote:
> I'm not sure if you are aware of this but g++ 2.95.3 cannot
> handle the casts:
[snip errors]
> and I must revert to:
>
> #elif defined(__GNUC__) && (__GNUC__ < 3)
> // g++ 2.95.3 cannot take the casts,
> typedef integral_c next;
> typedef integral_c prior;
>
Andreas Huber wrote:
> Hi there
Hi Andreas,
> I tried to use mpl::is_sequence<> on an incomplete type and ran into
> errors suggesting that the argument must not be incomplete (I'm using
> MSVC 7.0). I assume this cannot be fixed, right?
It might be possible to fix it, but it will require some
Joel de Guzman wrote:
> Yaiks! I hope it gets fixed soon. Spirit has been committed to
> the boost CVS now and I just switched to MPL so Spirit relies
> on MPL now.
If you look at the errors more closely, you'll see that it's not MPL,
but 'is_convertible' that is broken, for Borland 5.5.1; yes, ho
Andreas Huber wrote:
> > It might be possible to fix it, but it will require some work. Let
> > me know if it's important for you, and I'll move it up in my TODO
> > list.
>
> Well, it is not that important since mpl::is_sequence<> is only used
> to provide some syntactic sugar.
Yep, I understa
Fernando Cacciola wrote:
> I was suspicious of next/prior in integral_c<> from the beggining...
> That's why I asked what was the intended role of integral_c<>,
> and why does it feature next/prior.
It has 'next'/'prior' members because it's the easiest/most efficient
way to implement 'next/prior
Andreas Huber wrote:
> The attached code works like a dream on MSVC 7.1, but MSVC 7.0 again
> has its problems:
>
> Problem No. 1: Expression 1 does not seem to work, because
> Derived is an incomplete type:
> To reproduce, you might want to comment-out expression 3 and
> uncomment expression
Andreas Huber wrote:
> In my application the argument passed to is_sequence is _never_ a
> complete type. See below for reasons.
OK, understood. The issue is fixed in the CVS.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listi
Gennaro Prota wrote:
> On Thu, 6 Feb 2003 06:05:23 -0600, Aleksey Gurtovoy
> <[EMAIL PROTECTED]> wrote:
> > It has 'next'/'prior' members because it's the easiest/most
> > efficient way to implement 'next/prior< integral_c >::typ
Gustavo Guerra wrote:
> On the same spirit, I would like to request that boost::non_copyable
> be also moved to a separate header "boost/non_copyable.hpp" or
> "boost/utility/non_copyable", so we don't have to include the whole
> "boost/utility.hpp"
Uhmm, that's actually my fault. I proposed to s
vladimir josef sykora wrote:
> Hello Aleksey,
Hi Vladimir,
> Encapsulating algorithms with a _new_ namespace, and later injecting
> it into the ::mpl via 'using', solves fine gcc's ADL conflicts. Could
> you apply BOOST_MPL_AUX_AGLORITHM_NAMESPACE patch to other algorithms?
Sure, will do for t
The following is a sketch of a potential use case for the newly-accepted and
already very useful 'optional' class.
Suppose you have a pure RAII guard/locker which unconditionally does its
job:
struct RAII_lock
: boost::noncopyable
{
RAII_lock(entity& e);
~RAII_lo
Anthony Williams wrote:
> Aleksey Gurtovoy writes:
> >
> > The following is a sketch of a potential use case for the
> > newly-accepted and already very useful 'optional' class.
> >
> > Suppose you have a pure RAII guard/loc
Fernando Cacciola wrote:
> OK, I can see the motivation: We can have a noncopyable class
> and need an optional object of it.
> Following optional semantics, it would be spelled:
>
> boost::optional lock;
> if ( cond )
> lock.reset( RAII_lock(entity) ) ;
>
> But there is a probem: as William poi
Jonathan Wang wrote:
> Hi,
Hi Jonathan,
>
> The "for-each" in mpl is used to generate codes, which apply some
> function to each element in a sequence. Well, I wonder if there
> could be more generators, "select"(a better name?) for example.
Easily, 'for_each' is just the one that happened to
Attached is an implementation of 'boost::tuples::apply' function template,
providing one with a possibility of function application on a tuple of
arguments:
#include "boost/tuple/tuple.hpp"
#include "boost/tuple/apply.hpp"
using namespace boost;
void f(int, char const*);
int
Daniel Frey wrote:
> >> I won't try to fix any of these anymore. I neither understand the
> >> documentation nor the implementation of boost's type-traits. I
> >> tried to make the code better but AFAICS there is no interest in
> >> improvment.
> >
> > Does anyone understand what improvement you
Trey Jackson wrote:
> Just started using boost::bind, like it a lot.
> I'm playing around with a little work crew,
> which just queues up data, then calls the function
> on them later.
[...]
> I'd like to be able to do something like:
> ,
> | work_crew mycrew(bind(&X::f, &x, _1, _
Trey Jackson wrote:
> >template boost::function1 >DataType> >
> >class work_crew {
> > std::list queue_;
> > FunctionType engine_;
> >public:
> > work_crew(FunctionType const& tocall);
> > void add(DataType d) { queue_.push_front(d); };
> > void dowork()
> > {
> >t
Andreas Huber wrote:
> Hi Aleksey & all other metaprogramming gurus
Hi Andreas,
>
> The attached code compiles just fine with MSVC7.1 but MSVC7.0 once more
has
> its problems. This time I'm quite sure it has nothing to do with MPL,
> instead VC7.0 seems to get confused and reports the following:
Andreas Huber wrote:
> P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms (on
> conforming compilers I'd expect it to "call" mpl::identity) or should I
> #ifdef my way around it?
Yep, it's intentionally written in the way so that you don't have to #ifdef
in your code.
Aleksey
Andreas Huber wrote:
> P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms (on
> conforming compilers I'd expect it to "call" mpl::identity) or should I
> #ifdef my way around it?
Yep, it's intentionally written in the way so that you don't have to #ifdef
in your code.
Aleksey
Sorry for confusion, the reply below obviously belongs to a different
thread.
Aleksey Gurtovoy wrote:
> Andreas Huber wrote:
> > P.S. Is it a good idea to use mpl::aux::msvc_eti_base on all platforms
(on
> > conforming compilers I'd expect it to "call" mpl::identity)
1 - 100 of 242 matches
Mail list logo
