Hi,
I'm starting to explore mpl a bit and I ran into a roadblock.
If I have a template that takes an argument that can be
a sequence (e.g. mpl::vector) or a regular old type, is
there any way, short of specialization, to determine whether
the parameter is a sequence? I'd like to avoid specializin
Aleksey Gurtovoy wrote:
there any way, short of specialization, to determine whether
the parameter is a sequence?
"is_sequence::value", please expect it to appear in the CVS in a day or
two :).
Oh, fabulous! Just what I ws looking for.
Given 'is_sequence', it will be as simple as this:
Gennadiy Rozental wrote:
1. merge the sequences.
That's easy.
2. Eliminate the duplicates (for example like Loki is doing)
That's hard to do efficiently. My MC++D book is packed away
at the moment. Can you refresh my memory as to the solution
there? Is it better then O(n^2)?
Aleksey Gurtovoy wrote:
Ok, but what if I don't want to alter first, second and third?
That is, I have some set of classes that define types like this
but they were never originally intended to represent a sequence.
It just happens that I want to maipulate a set of these types
formed by the typed
Is it possible to have an MPL vector of MPL vectors? When I
try this, the compiler (g++ 3.2) complains about an incomplete
type for push_back_traits:
#include
#include
#include
int main(void)
{
typedef boost::mpl::vector<> vec;
typedef boost::mpl::push_back<
vec,
boost::mpl::vect
[Posted to boost because MPL is not yet released. At what
point should these questions go to boost-users?]
Say I have a type my_type:
template
struct my_type { ... }
Now let's say I want to create a generator that
binds T to some type but leaves U and V free to
be filled in later. Basically,
David Abrahams wrote:
template
struct my_type_generator {
template
struct apply {
typedef my_type type;
};
};
Looks good to me.
Is there a convenient way to create this with MPL?
You want it to be more convenient than that?!
Perhaps "convenient" is the wrong word. There a
David Abrahams wrote:
template
struct my_type_generator
{
typedef my_type type;
};
lambda does it
Oops, I meant
lambda >
of course!
Ok, that makes more sense now. :)
, unless of course your compiler
needs BOOST_MPL_AUX_LAMDA_SUPPORT. I don't think it's much of
David Abrahams wrote:
Your correction above makes everything clear to me now.
So do you feel you need an additional library feature? ;-)
I suppose not. What I really wanted was the ability to take a
regular old template class and create a generator out of it:
template
struct my_type { ...
David Abrahams wrote:
I suppose not. What I really wanted was the ability to take a
regular old template class and create a generator out of it:
template
struct my_type { ... } // Note: no ::type member
typedef SHAZAM > generator;
typedef generator::template apply::type my_type_inst;
I want
Aleksey Gurtovoy wrote:
my_type is not a metafunction so maybe it just
can't be used conveniently with mpl.
Not now. However, I constantly keep finding more and more use cases to be
inclined to provide a built-in library support for this particular
metafunction's form - in particular, so that
Aleksey Gurtovoy wrote:
That's because the MPL's lambda works only with metafunctions which template
parameters are _types_, and only types:
That's what I suspected.
3) a metafunction with template template parameter, can't be used in lambda
expressions:
Again, what I suspected.
It _is_ p
Roland Richter wrote:
I would like to announce that I finally imported the first set
of Boost.View classes to the Boost-Sandbox CVS.
> + What is it?
> A view is a light-weight, immutable decorator to some existing data.
> Usually, it will provide the same interface as a STL container.
Does th
Fernando Cacciola wrote:
- Original Message -
From: "David A. Greene" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, November 05, 2002 5:10 PM
Subject: [boost] Compile-time print
Hi gang,
Has anyone come across a compile-time print metafuncti
Roland Richter wrote:
Does this mean a view is mutable? For example, using Boost.View,
can I write a bounded that automatically drops the
last element on push_front if size() is at some upper limit value
before adding the new element? This is the sort of thing I
No. A view is not mutable; s
What's the easiest way of converting an MPL sequence into a
tuple type? I seem to recall Dave Abrahams needed this
functionality as well. Do I need to construct a bare cons
list?
-Dave
--
"Some little people have music in them, but Fats, he was all music,
and you know
Gennadiy Rozental wrote:
What's the easiest way of converting an MPL sequence into a
tuple type? I seem to recall Dave Abrahams needed this
functionality as well. Do I need to construct a bare cons
list?
Use inherit_linearly like in it's example.
Which example is that? Is inherit_linearly
Over the weekend I realized just what strange and wonderful things
tuples are. This message is as much to get my thoughts recorded as it
is a request for discussion about the various classes and bits of
code presented within. Some of this stuff may be useful for Boost and
some may not. I'd like
Rozental, Gennadiy wrote:
Which example is that? Is inherit_linearly documented somewhere?
-Dave
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/libs/mpl/example/
inherit_linearly.cpp?rev=1.1&content-type=text/vnd.viewcvs-markup
Well, that's not creating a
Rozental, Gennadiy wrote:
Over the weekend I had a bit of free time so I wrote up a
spanning_iterator based on the iterator_adaptors framework. To throw
in a bit more complication, I wanted something generic enough that I
could span different kinds of container. There should be a way to
While
Roland Richter wrote:
David A. Greene wrote:
The fundamental problem is that it's inconvenient to iterate through a
tuple. All we have is the get<> template to access tuple elements.
Iterating is again conceptually simple -- just increment an index.
But the fact that get<&
Aleksey Gurtovoy wrote:
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.
Has any discussion taken
Aleksey Gurtovoy wrote:
That's not to say that it should stay this way. Ideally, to support true
mixed-type arithmetic, e.g. 'plus< rational<1,10>, int_c<5> >', the current
MPL primitives such as 'plus', 'minus', 'multiply', etc. need a major
re-write, to become something along these lines:
t
Aleksey Gurtovoy wrote:
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 needs a b
David Abrahams wrote:
thought, I am not sure if it's a good choice. Does
apply< unarize, list >::type
convey the discussed meaning for you?
No, but I'm not sure that unroll_args does either.
unroll_args doesn't, in fact, unroll arguments. It's a metafunction
adapter. "Unroll" is usually
Vladimir Prus wrote:
I have one policy that I forgot to mention: chain_lookup_policy. It's
work
is based on Chain of responcibilities Design pattern. In this case Every
parameter knows how to parse itelf out of input. And this
identification may
not be the name at all.
I would say that it's a
Jaap Suter wrote:
Try turning off debug symbols; GCC spends a long time and a lot of
disk generating them.
Thanks, works excellent! In fact, my GCC object files and executables are
the smallest now.
Yep, I came to the same conclusion. Unfortunately, it does not help
much when you need to deb
27 matches
Mail list logo
