RE: [boost] [MPL] Several Questions
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 would be
enough:
template< typename T >
struct intrusive_iter
{
typedef T type;
typedef intrusive_iter next;
};
template<>
struct intrusive_iter
{
};
template< typename T >
struct intrusive_list
{
typedef mpl::nested_begin_end_tag tag; // not required
typedef intrusive_iter begin;
typedef intrusive_iter end;
};
No 'begin/end' specializations needed, and the 'tag' typedef is there only
to make some deficient compilers happy (Borland, in particular).
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] mpl transform
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 typename mpl::transform<
> IteratorSeq,mpl::apply0
> >::type type;
>
> typedef zip_iterator<
> typename mpl::transform<
>IteratorSeq,mpl::next
> >::type
> > next;
>};
>
> and an operator adaptor like this one (don't know how to generalize
> this one to N arguments yet):
>
> template
> struct binop_adaptor
> : mpl::apply2<
>Op
>, typename mpl::begin::type
>, typename mpl::next::type>::type
> >
> {
> };
>
> How about that?
To finish the sketch:
template<
typename Sequences
>
struct zip_view
{
typedef typename transform< Sequences, begin<_1> >::type
first_ones_;
typedef typename transform< Sequences, end<_1> >::type last_ones_;
typedef nested_begin_end_tag tag;
typedef zip_iterator begin;
typedef zip_iterator end;
};
// corrected 'binop_adaptor'
template< typename BinaryOp >
struct apply_two_args_seq
{
template< typename Args > struct apply
: apply2<
BinaryOp
, typename at_c::type
, typename at_c::type
>
{
};
};
// user code
typedef range_c s1;
typedef range_c s2;
typedef transform_view<
zip_view< list >
, apply_two_args_seq< plus<> >
> result;
// here!
BOOST_STATIC_ASSERT((equal<
result
, filter_view< range_c, math::is_even<_> >
, equal_to<_,_>
>::type::value));
The 'zip_view' is in the CVS, as well as the rest of the sample -
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/m
pl/test/zip_view.cpp. 'apply_two_args_seq' needs generalization, so it
didn't go into a header.
Note that the sample doesn't work on all the supported compilers yet.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: boost & Borland C++ Builder 6
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 tried running > them myself, > although I would be surprised if it works given symptomatic > type_traits/lambda failures] I am not sure how these particular type_traits failuers related to the MPL status one one or another platform ;). Anyway, the latest MPL's regression results are published here - http://www.mywikinet.com/mpl/log.html. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost & Borland C++ Builder 6
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 you can see, only 6 out of 63 tests fail on Borland, so I would say it mostly works. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL + MSVC]
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 preprocessed the source, and
> verified that sure enough there *is* no apply in mpl.
That's correct (see lines 58-62 in "boost/mpl/apply.hpp"). One have to use
the numbered forms, and it's a recommended practice for writing portable MPL
code. The same with 'bind' (for slightly different reasons, but still).
> I discovered that apply1 works just fine, however. I assume
> that MSVC can't handle the full apply<> machinery,
It can, but it doesn't like the name clash between top-level 'apply'
template and nested 'apply'-s inside metafunction classes:
template< typename F, typename T >
struct apply
{
typedef T type;
};
struct her
{
template< typename T > struct apply // ICE here
{
typedef T type;
};
};
Renaming top-level 'apply' to something else (e.g. 'apply_') resolves the
conflict, but IMO it's not worth it - you can use the appropriate numbered
form to the same effect.
> but is this documented?
Now it is :). Speaking seriously, it's on my documentation to-do list.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL + MSVC]
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...
>
> typedef typename storage_policy_::type
> storage_policy;
> typedef storage_policy::pointer_type pointer_type;
>
> VC6 really doesn't like the second typedef. It says:
>
> error C2039: 'pointer_type' : is not a member of '`global
> namespace''
> error C2146: syntax error : missing ';' before identifier
> 'pointer_type'
> error C2868: 'pointer_type' : illegal syntax for
> using-declaration;
> expected qualified-name
>
Actually, the errors have little to do with MPL in general or lambda in
particular; what you are seeing is called "early template instantiation"
(ETI), a known MSVC 6.5/7.0 bug that you inevitably have to deal with as
soon as your template code grows out of the "toy samples" category. In
particular, one manifestations of the ETI is that the compiler, while
_parsing_ something like
typedef typename storage_policy_::type storage_policy;
typedef storage_policy::pointer_type pointer_type;
inside another class template definition, can choose, for its own internal
purposes, to substitute 'storage_policy' by 'int' type - and proceed with
further declarations. Naturally, in our case something like that renders the
'pointer_type' typedef ill-formed, and you get the errors you've seen.
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<> struct pointer_type
{
typedef int type;
};
#endif
typedef typename pointer_type::type pointer_type;
Well, having said that, I should note that actually MPL's lambda on MSVC
(and Borland, currently) _does_ work slightly differently from its normal
counterpart, setting up some additional pitfalls. The most ugly one, that I
cannot workaround in the library, is that "parsing" a lambda expression like
the one below on compilers without partial specialization results in
_instantiation_ of the involved templates with the placeholder arguments:
template
struct get_category
{
typedef typename Policy::policy_category type;
BOOST_MPL_AUX_LAMBDA_SUPPORT(1,get_category,(Policy))
};
...
// on MSVC 6.5/7.0 'get_category<_>' is actually
// instantiated
typedef typename mpl::find_if<
Sequence
, is_same, Category>
>::type iter_;
Since, naturally, '_' placeholder doesn't have a nested 'policy_category'
member, the above will be ill-formed as written when compiled on a
non-conforming compiler. To workaround it, you have to do something along
these lines:
template
struct get_category_impl
{
typedef typename Policy::policy_category type;
};
template
struct get_category
: mpl::if_<
mpl::is_placeholder
, mpl::identity
, get_category_impl
>::type
{
BOOST_MPL_AUX_LAMBDA_SUPPORT(1,get_category,(Policy))
};
On an aside note, in general, unless you are very intimate with particular
compiler's idiosyncrasies, it much easier to debug a complex template code
on more or less conforming compiler (Comeau, Intel C++, GCC 3.2) and then
adopt it for MSVC and Borland, than fight with the last two while catching
your own bugs.
[...]
> Thanks for any insight you can provide.
Attached is a modified 'smart_ptr.hpp' that more or less compiles on MSVC
6.5, Intel C++ 6.0, and GCC 3.2 (see the test for the details). You'll need
the latest boost CVS snapshot for that.
HTH,
Aleksey
policy_ptr.zip
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL + MSVC]
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<> struct pointer_type
> > {
> > typedef int type;
> > };
> > #endif
>
> So my understanding is if ETI instantiates the template and
> mutates it to int, this hack will prevent the compiler from
> trying to extract the nested type, by returning a bogus int
> type. And then, when the template gets *properly*
> instantiated, it will use the non-specialized version?
Yep.
> > template
> > struct get_category
> > {
> > typedef typename Policy::policy_category type;
> > BOOST_MPL_AUX_LAMBDA_SUPPORT(1,get_category,(Policy))
> > };
>
> Ok, so I see that this looks just like the policies. Since
> it is an MPL metafunction that passes through lambda, it needs
> to have the AUX macro just like the policies?
Correct.
> > Since, naturally, '_' placeholder doesn't have a nested
> > 'policy_category' member, the above will be ill-formed as
> > written when compiled on a non-conforming compiler.
>
> Yes, I noticed that. Early instantiation sure is a pain to
> work around.
Actually, ETI is irrelevant, here - it's just that without template template
parameters, the only way to extract the metafunction arguments is an
intrusive introspection mechanism hidden behind BOOST_MPL_AUX_LAMBDA_SUPPORT
macro, and, in its turn, the only way for the library to access the
information provided by the mechanism (metafunction's arity and exact
template arguments) is to look inside the metafunction - thus instantiating
it, possibly with one or more placeholder arguments. In general, it doesn't
always lead to an error; obviously, instantiating something as simple as
template< typename T1, typename T2 > struct is_same
: bool_c
{
};
template< typename T > struct is_same
: bool_c
{
};
with either T1 or T2 (or both) == mpl::arg is totally harmless. And even
this metafunction is OK:
template< typename Iterator > struct deref
{
typedef typename Iterator::type type;
BOOST_MPL_AUX_LAMBDA_SUPPORT(1,deref,(Iterator))
};
as the library makes sure that all placeholders actually _do_ have a nested
'type' typedef, specifically for this purpose (on non-conforming compilers
only, of course). What the library can't do, is to accommodate all possible
nested typenames. So if you are doing something like
template< typename Policy > struct get_category
{
typedef typename Policy::policy_category type;
};
it becomes you responsibility to handle the case when 'Policy' is a lambda
placeholder - again, only if you are using 'get_category' in lambda
expressions, and you are dealing with a deficient compiler.
>
> > [...]
> > template
> > struct get_category
> > : mpl::if_<
> > mpl::is_placeholder
> > , mpl::identity
> > , get_category_impl
> > >::type
> > {
> > BOOST_MPL_AUX_LAMBDA_SUPPORT(1,get_category,(Policy))
> > };
>
> So this is like a meta-compile-time check to avoid early
> instantiation?
Not exactly, see the above.
> And again, because get_category is a
> metafunction going through lambda, we need the AUX macro.
Yep, this one is correct.
> > On an aside note, in general, unless you are very intimate
> > with particular compiler's idiosyncrasies, it much easier
> > to debug a complex template code on more or less conforming
> > compiler (Comeau, Intel C++, GCC 3.2) and then adopt it for
> > MSVC and Borland, than fight with the last two while
> > catching your own bugs.
>
> Well, my code worked just fine on bcc and gcc before I started
> hacking it to pieces for MSVC.
Hmm, I am not sure how it could work on Borland without lambda support and
special care for placeholder arguments in 'get_category' :).
> The troubles started when MSVC didn't like 80% of what I had written for
the other compilers!
Well, now you know how to fight it!
> Thanks a lot for your help!
You are welcome!
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: [MPL + MSVC]
David B. Held wrote:
> > > > template
> > > > struct get_category
> > > > : mpl::if_<
> > > > mpl::is_placeholder
> > > > , mpl::identity
> > > > , get_category_impl
> > > > >::type
> > > > {
> > > > BOOST_MPL_AUX_LAMBDA_SUPPORT(1,get_category,(Policy))
> > > > };
> > [...]
>
> When is it better to derive from something vs. composing it
> in a typedef?
It's mostly the matter of style. Typedef is inherently more verbose:
template
struct get_category
{
typedef typename mpl::if_<
mpl::is_placeholder
, mpl::identity
, get_category_impl
>::type::type type;
BOOST_MPL_AUX_LAMBDA_SUPPORT(1,get_category,(Policy))
};
There are also cases when inheritance is preferable because it brings along
other base class' members, besides the canonical 'type' typedef:
// enables both 'is_same<...>::value' and 'is_same<...>::type'
// notations
template< typename T1, typename T2 >
struct is_same
: bool_c
{
};
> Also, we're really close on the smart pointer code. I've
> checked in the latest version to the sandbox, applying your changes.
> However, I still get 14 errors that are all in mpl/identity.hpp.
No wonder - you are including MPL headers inside the opened 'boost'
namespace (line 194) ;).
[...]
> BOOST_MPL_AUX_VOID_SPEC(1, identity)
> BOOST_MPL_AUX_VOID_SPEC(1, make_identity)
>
> Now, I notice that I'm supposed to define these for the policies under
> bcc.
That's an oversight. I am planning to fix it shortly so
BOOST_MPL_AUX_LAMBDA_SUPPORT will be self-sufficient.
HTH,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] vector of vectors
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 incomplete > type for push_back_traits: [snip code] The error is not related to the fact that you are trying to create a "vector of vectors"; if you try to 'push_back' an 'int' into a vector, you'll get the same diagnostics. Basically, what compiler is trying to say here is that 'push_back' on 'vector' is currently not implemented, - sorry! I know it differs from what the docs say, and it's on my to do list. Meanwhile, if you switch to using 'push_front' instead, everything will work just fine. Sometimes 'push'-ing backwards (i.e. at front) makes things much harder/messy than they could be, though, so let me know if that's the case here. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Possible patch to format for Borland BCB5
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 of instantiation.
> And the format library case
> wasn't a member name at all, it was an enum name, IIRC.
Looking at the errors that triggered the discussion, they don't seem to be
related to two-phase name lookup at all:
namespace boost {
namespace io {
enum format_error_bits { bad_format_string_bit = 1,
too_few_args_bit = 2, too_many_args_bit = 4,
out_of_range_bit = 8,
all_error_bits = 255, no_error_bits=0 };
} // namespace io
// ...
template< class Ch, class Tr>
basic_format& basic_format ::clear_bind(int argN)
// cancel the binding of ONE argument, and clear()
{
//
if( exceptions() & out_of_range_bit )
} // namespace boost
'out_of_range_bit' is defined in the namespace 'io', and there is no way it
can be found through a plain 'out_of_range_bit' (not
'io::out_of_range_bit'), two-phase name lookup or not :).
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [Config] Testing instructions for compiler vendors
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 check the library > - BOOST_STRICT_CONFIG - to disable some checks in > source code > - macros for any known-not-implemented features, >e.g. BOOST_NO_TEMPLATE_TEMPLATES. > > Right? As far as I understand, defining BOOST_STRICT_CONFIG only should be sufficient (for compiler tests) - given that the compiler being tested has a bumped up version number. > > 2. What about all the places we make compiler-specific checks in >Boost code? Could we define some macros which make it easier >and less error-prone to write these, and which can be globally >turned off when needed? > > # if BOOST_COMPILER_WORKAROUND(__SUNPRO_CC, <= 0x540) > ... > #else > ... > #endif > The checks for the past versions of the compiler, e.g. #if defined(BOOST_MSVC) && BOOST_MSVC <= 1300 # define BOOST_MPL_MSVC_ETI_BUG #endif are harmless for the beta-testing of the new one. As for checks for current bugs, I think it's our current convention that they should be guarded by BOOST_STRICT_CONFIG, like this: #if defined(__BORLANDC__) \ && (__BORLANDC__ <= 0x570 || !defined(BOOST_STRICT_CONFIG)) # define BOOST_MPL_BROKEN_OVERLOAD_RESOLUTION #endif so defining BOOST_STRICT_CONFIG would disable them. I am afraid it's not thoroughly enforced, though. If we come up with a way to simplify the above, personally I would be more than happy. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
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
development, pre-release, or released state - doesn't matter much. Boost
Users is a gateway for, well, Boost users that feel overwhelmed and
intimidated by the high volume and level of technical content that flows
through this list. Basically, it's a place for newbie and frequently asked
questions. If the question is highly technical - as the one I am replying to
- it belongs here.
>
> 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, I want something
> like this:
>
> template
> struct my_type_generator {
> template
> struct apply {
>typedef my_type type;
> };
> };
>
> Is there a convenient way to create this with MPL?
> I thought lambda might do the trick,
Yep, that would be intuitive, wouldn't it?
> but apparently not:
>
> typedef my_type my_type_generator;
>
> (This will be passed to an MPL algorithm so I didn't
> bother with lambda<>).
>
> This causes a static assertion in mpl::arg<2> where it
> sees a void type for V (I think).
Hmm, actually it should be something like this:
error C2039: 'type' : is not a member of
'boost::mpl::meta_fun3::apply'
but it doesn't matter much - you are right, it won't compile, currently.
>
> Is the problem that my_type doesn't contain a ::type
> member?
Yes.
> 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 one could do exactly what
you've tried to:
typedef my_type my_type_generator;
pass it to an algorithm, and it will work as expected.
> It's easy enough
> to manually define my_type_generator, but I think this
> is a pretty common pattern
Very!
> and it might be useful as a library component.
Thanks for the feedback! I would expect the feature to appear in the CVS
somewhere on the weekend.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL] Making Generators
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_type_X(T) \
> > (sizeof(test(0) == 1)
>
> This is cool. What compilers are known to support it?
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 trying out
"boost/libs/mpl/test/aux_/has_xxx.cpp" test case.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL] Making Generators
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
> > trying out "boost/libs/mpl/test/aux_/has_xxx.cpp" test case.
>
> It also works with GCC 2.95.2 with some restrictions. I don't remember
> what they are offhand. Something like that the type must be a class?
> ... that doesn't sound quite right because we could work around it
> with an is_class pre-test.
I wouldn't call it "works": it returns 'true' if the member exists,
otherwise it fails with a compilation error (whether the tested type is a
class or not). Or it would fail if we didn't #ifdef'ed it to always return
'false'.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
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 U, typename V>
> struct trivial_generator {
>typedef Base type;
> };
>
> int main(void)
> {
>typedef my_type_generator generator;
>//CT_PRINT(my_type_generator_result_is, generator::type);
>
>typedef trivial_generator t_generator;
>//CT_PRINT(trivial_generator_result_is, t_generator::type);
>
>// Try to make some generators
>typedef boost::mpl::lambda boost::mpl::_2> >::type lambda_generator;
>typedef lambda_generator::apply lg_apply_result;
>//CT_PRINT(lambda_generator_result_is, lg_apply_result::type);
>
>// Does not work
>typedef boost::mpl::lambda boost::mpl::_1, boost::mpl::_2> >::type lambda_trivial_generator;
>// g++ 3.2 claims apply doesn't exist.
>typedef lambda_trivial_generator::apply ltg_result;
>//CT_PRINT(lambda_trivial_generator_result_is, ltg_result::type);
>
>return(0);
> }
>
That's because the MPL's lambda works only with metafunctions which template
parameters are _types_, and only types:
1) a "canonical" metafunction, OK:
template< typename T > struct identity
{
typedef T type;
};
typedef lambda< identity<_> >::type f;
BOOST_MPL_ASSERT_IS_SAME(f::apply::type, int);
2) a metafunction with non-type template parameter, can't be used in lambda
expressions:
template< typename T, int i = 0 > struct identity
{
typedef T type;
};
typedef lambda< identity<_> >::type f;
BOOST_MPL_ASSERT_IS_SAME(f::apply::type, int); // error!
3) a metafunction with template template parameter, can't be used in lambda
expressions:
template< typename T > struct something;
template< typename T, template< typename > class F = something > struct
identity
{
typedef T type;
};
typedef lambda< identity<_> >::type f;
BOOST_MPL_ASSERT_IS_SAME(f::apply::type, int); // error!
Strictly speaking, (2) and (3) are not even metafunctions in MPL's
terminology.
>
> >>But I can construct a generic trivial generator:
> >>
> >>template class Base,
> >> typename T, typename U, typename V>
> >>struct trivial_generator {
> >>typedef Base type;
> >>};
> >>
> >>Then I can use MPL lambda facilities. Unfortunately, I need a
> >>trivial_generator for every arity of class template.
> >
> > Only as part of the implementation. You just need a nice
> > wrapper over the top to hide it all.
>
> Right. Can you point me to the MPL equivalent as a guide of
> how to do this?
Actually, even ignoring the aforementioned lambda issue, it's not possible
to write a single template (a wrapper or not) that would take template
template parameters of different arity - if it were, the library itself
would use the technique to implement the single 'quote/mem_fun' template
instead of providing the family of 'mem_fun1', 'mem_fun2', etc. constructs.
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: no ::type member
typedef SHAZAM > generator;
typedef generator::template apply::type my_type_inst;
but not at the user side - the library internal mechanisms needs to be made
aware of it. I considered this before, - as well as the option of directly
supporting the "reduced" metafunction form, - and the latter is currently my
preference. Will see if something changes after I actually implement it (for
one, it might slow down the lambda significantly, - but we'll see).
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [Config] Testing instructions for compiler vendors
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 > (sparked by Thomas Witt, IIRC) that when a workaround is implemented > for the most recent compiler version, no assumption should be made > that the corresponding bug will be fixed in future versions. That was probably me (http://lists.boost.org/MailArchives/boost/msg16944.php). Actually, it's not "incidentally" at all - that very thread was what triggered the introduction of BOOST_STRICT_CONFIG with the semantics John is trying to defend ;). > I don't think my macro accounts for that, and I really don't know a good way > to cope with it. I don't think we ought to add any workarounds without > at least some way to record the most-recent version where it's known > to be needed. Well, #if defined(COMPILER_VER) && (COMPILER_VER <= xxx || !defined(BOOST_STRICT_CONFIG)) is the current way to do exactly that (a verbose one, admittedly). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
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: no ::type member
> >
> > typedef SHAZAM > generator;
> >
> > typedef generator::template apply::type
> my_type_inst;
> >
> > but not at the user side - the library internal mechanisms
> > needs to be made aware of it.
Actually, I lied - on a conforming compiler you can do the following:
template< typename T, typename U, typename V >
struct my_type {}; // Note: no ::type member
// declare 'my_type' a "reduced" metafunction
REDUCED_METAFUNCTION_SPEC(3, my_type)
// test it
typedef lambda< my_type >::type f;
typedef f::apply::type t;
BOOST_STATIC_ASSERT((is_same< t, my_type >::value));
where REDUCED_METAFUNCTION_SPEC is as simple as this:
#define REDUCED_METAFUNCTION_SPEC(n, name) \
namespace boost { namespace mpl { \
template<> struct meta_fun##n< name > \
{ \
template< BOOST_PP_ENUM_PARAMS(n, typename T) > \
struct apply \
{ \
typedef my_type type; \
}; \
}; \
}} \
/**/
> > I considered this before, - as
> > well as the option of directly supporting the "reduced"
> > metafunction form, - and the latter is currently my
> > preference. Will see if something changes after I actually
> > implement it (for one, it might slow down the lambda
> > significantly, - but we'll see).
>
> 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 there yet. Please stay tuned!
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Regression test woes
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] mpl - fsm generator - compile failure
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]
> This went faster than I expected, and from a most unexpected source of
> support.
>
> I added 'using boost::mpl::_' at file scope just before the
> below mentioned template, STT_row_impl; the compile succeeded.
Oh, good!
> Should this have been necessary?
Yes. At some point the unnamed placeholder ('_') was automatically brought
into a global file scope via anonymous namespace, but that proved to be
prone to conflicts (in particular, with boost::python library), so I had to
turn it off.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: mpl - fsm generator - compile failure
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] mpl::copy_backward conflicts
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_vect_foos;
> > std_vect_foos.push_back(foo());
> >
> > When mpl::copy_backward is present (from boost/mpl/insert.hpp for
> example),
> > I get this error (gcc 3.2):
> >
> > `template >Sequence, class State, class BinaryOp> struct
> boost::mpl::copy_backward'
> > is
> >not a function,
> > conflict with `
> >template _BI2
> std::copy_backward(_BI1, _BI1,
> > _BI2)'
> > in call to `copy_backward'
> >
> > Since std::copy_backward is found via ADL, I consider this IMHO a
> stringent
> > restriction to the use of mpl::insert & mpl::erase.
>
> This is a g++ specific "feature", or rather a combination of
> two "features".
>
> First, the standard library uses unqualified calls to standard library
> algorithms.
Yep. A bug, IMO.
>
> Second, argument dependent lookup finds class names (such as
> mpl::copy_backward.)
>
> Many people consider both to be defects.
In particular, see library active issue #225
(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-active.html#225) and core
language issue #218
(http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#218).
Meanwhile, I am not sure what one can do about it besides switching to
another standard library implementation (e.g. STLPort). Well, I guess I can
"separate" MPL sequences from the algorithms by putting the later into a
nested 'impl' namespace and bringing them back through a 'using' directive
so they are not found via ADL when one mixes MPL sequences and STL:
namespace mpl {
template< typename T1 > struct vector {};
namespace impl {
template< typename Sequence, typename State, typename BinaryOp >
struct copy_backward
{
// ...
};
}
using namespace impl;
} // namespace mpl
int main()
{
std::vector > v;
v.push_back(mpl::vector()); // OK, even on GCC
}
but I am not sure how reliable that would be. Hmm, it might even work.
Thoughts?
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [Config] Testing instructions for compiler vendors
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_STRICT_CONFIG is defined. This is consistent with > > the way that the existing config system works BTW, although it > > does present a maintenance problem (lots of compiler version > > checks scattered all over the place, all of which need updating > > when a new compiler is released). Actually, they don't - as far as BOOST_STRICT_CONFIG is not defined (I wonder if anybody uses it at all), the checks will continue to work. Updating them is a strictly volunteer activity :) > > This also conflicts with your desired use case (disabling > > workarounds in cases where we know that it really is needed)! > > > > Round and round and round :-( > > OK, now I've rewritten and re-thought this email about 5 times ;-) > > I'm going to ask a controversial question: what is the point of > checking the version at all in the case above, really? If you buy my > argument that the user surely knows what he's doing when he specifies > BOOST_STRICT_CONFIG, there's no reason not to let BOOST_STRICT_CONFIG > turn off workarounds always. In that case, the test above might as > well just be: > ># if defined(__BORLANDC__) && !defined(BOOST_STRICT_CONFIG) > Well, expect that the above doesn't let you distinguish whether the bug is (was) really present in the latest known version of the compiler, or the person who wrote the above was just sloppy/careless ;). > And, it seems to me, if the presumption that the bug being worked > around is likely present in future versions is correct, this is better > because there's no associated maintenance cost (i.e. nobody has to > bump the version number). I think the current "accepted form" quoted > by you and Aleksey is theoretically interesting, but the version > number doesn't have much value other than as a comment. Hmm, looks like a 100% correct observation to me. > Wouldn't > > >#if BOOST_WORKAROUND(__BORLANDC__, != 0) // last checked at 0x569 > > or > >#if BOOST_WORKAROUND(__BORLANDC__, +0x569) >// not sure about overflow issues, so maybe not > > be just as good, or maybe even better? I am sold on this one :). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [Config] Testing instructions for compiler vendors
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) && > (symbol test)) Looks good to me. How about keeping it in a separate header, though? Personally, I am getting annoyed by having to write, for example: #include "boost/config.hpp" // for BOOST_STATIC_CONSTANT instead of #include "boost/config/static_constant.hpp" and by tracking down whether a header still needs "boost/config.hpp" include after you've removed, let's say, all BOOST_STRICT_CONFIG references. > And, I suggest > > BOOST_WORKAROUND(__BORLANDC__, |0x569) > > As the standard "comment" about the last known version where the > workaround is needed. > Agreed. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: mpl::copy_backward conflicts
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
> > > might even work.
> >
> > ...and it might not. Herb Sutter recently told me of some
> > experiments> he did which showed that GCC was doing ADL in many
> > more than just the correct "associated namespaces". It's almost
> > hilarious that so many things have conspired to make GCC so
> > problematic in this area:
> > too-liberal ADL specification in the standard, a refusal to qualify
> > internal calls to the std:: algorithms, an un-useful interpretation
> > of the standard w.r.t. looking up types vs. functions, and finally
> > outright bugs in the ADL implementation.
> >
>
> IMHO, I'd suggest to change the name to a non collision one.
Well, I would be reluctant to do so. For one, I doubt that it will all end
on this particular name ('copy_backward'). MPL is full of algorithms that
are named after their run-time counterparts, and, given the sad state of
affairs with that compiler/library combination, each of them is a potential
source of conflict, only waiting for the moment to expose itself. And I am
not going to rename them and destroy the original intent just because some
non-conforming implementation carelessly chose to reserve _all_ std
algorithm names in _all_ namespaces.
I'll try to workaround the issue, though.
> I wouldn't like to see (mpl + std) alienated with gcc.
Well, me too. Your original example now compiles on GCC 3.2 with the current
CVS sources. Please let me know if you run into more of this.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] mpl::fold
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<
> mpl::range_c
> , mpl::vector<>
> , mpl::push_front<_,_>
> >::type result;
>
> BOOST_STATIC_ASSERT(mpl::size::value == 10);
> BOOST_STATIC_ASSERT((mpl::equal< result,answer >::type::value));
>
>
> but this won't:
>
>
> namespace mpl = boost::mpl;
> using mpl::_1;
> using mpl::_2;
>
> typedef
> mpl::vector
> types;
>
> typedef mpl::fold<
> types
> , mpl::integral_c
> , mpl::if_< boost::is_float<_2>, mpl::next<_1>,_1 >
> >::type number_of_floats;
>
> typedef mpl::lambda< number_of_floats >::type func;
Just a quibble - the above line is unnecessary.
>
> BOOST_STATIC_ASSERT(( number_of_floats::value == 3 ));
^^^
An error in the docs, should be 4. Sorry!
>
> I presume that the problem is here
>
> , mpl::if_< boost::is_float<_2>, mpl::next<_1>,_1 >
> ^^^
>
> as this is a non-mpl metafunction.
Actually, it is! Try this one:
typedef lambda< boost::is_float<_1> >::type is_float;
typedef apply1< is_float, float >::type res;
BOOST_STATIC_ASSERT(res::value == true);
> Can any one tell me how to fix the above please?
BOOST_STATIC_ASSERT(number_of_floats::value == 4);
Fixed in the reference docs' sources, too.
>
> Also, what are the requirement on a metafunction to be used with
> lambda. A simple example would be useful.
On a conforming compiler, the simple form
(http://www.mywikinet.com/mpl/paper/mpl_paper.html#metafunctions.simple)
template< typename T1, ..., typename Tn >
struct f
{
typedef ... type;
};
just works "out-of-box":
template< typename T > struct identity
{
typedef T type;
};
typedef lambda< identity<_1> >::type f;
typedef apply1< f, int >::type res;
BOOST_MPL_ASSERT_IS_SAME(res, int);
HTH,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: re: Borland regression test failures
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 > 38c38 > < using mpl::bool_c; > --- > > //using mpl::bool_c; > Ouch. Fixed, thanks for tracking it down! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL] Making Tuples
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 the functionality of
'boost::tuple' except the constructors and assignment from
'std::pair'. A generator for it is as simple as this:
template< typename Types > struct tuple_gen
: fold_backward<
Types
, boost::tuples::null_type
, boost::tuples::cons<_2,_1>
>
{
};
tuple_gen< list >::type t;
See
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/m
pl/example/tuple_from_list.cpp for the complete example.
> And I still don't completely "get" inherit_linearly.
It's a synonym for 'fold< Types,Root,NodeFunc >'.
> I assume it is supposed to be something like Loki's GenLinearHierarchy.
It is capable of producing both single-base (the example you've seen) and
mutliple-base class hierarchies
(http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/boost/boost/libs/
mpl/example/inherit_multiply.cpp), the later with a help of 'inherit'
metafunction.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL] Making Tuples + minor doc-fix for MPL
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 last update, so may be I'll do it sometime this week. > > > And I still don't completely "get" inherit_linearly. I assume it is > > supposed to be something like Loki's GenLinearHierarchy. > > It seems so. More or less, see my reply to David. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
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 there yet. Please stay tuned!
Okay, from this moment MPL's lambda supports "reduced" metafunction form
directly (if detected):
template< typename T > struct her
{
// no 'type' member!
};
typedef lambda< her<_> >::type f;
typedef apply::type t;
BOOST_MPL_ASSERT_IS_SAME(t, her);
The "ordinary" metafunctions work as before.
Enjoy!
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: [MPL] Making Tuples
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: > > > > template< typename Types > struct tuple_gen > > : fold_backward< > > Types > > , boost::tuples::null_type > > , boost::tuples::cons<_2,_1> > > Wow, is cons a metafunction? A "reduced" one, yes :). > > It doesn't appear to be. I know we discussed making non-metafunctions > usable as MPL lambda-expressions, but I didn't think you would opt for > the transparent approach, with automatic detection of nested ::type. People keep writing code along the lines of 'cons<_2,_1>' and expect it to work. You can explain to them why it doesn't work, and that they can fix it easily, by writing, for instance, 'reduced< cons<_2,_1> >' instead - or, often, they realize the mistake for themselves - but for some reason that doesn't decrease the likelihood of the same mistake happening the next time they write a similar code. In other word, the experience shows that the transparent approach is more intuitive. > > I thought you were going to require some explicit wrapper > template... Explicit wrapper, something like reduced< cons<_2,_1> > is still planned, to cover all use cases (better names are welcome!). > Not that I mind this approach. > Good! :) Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] Making Generators
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
> > {
> > // no 'type' member!
> > };
> >
> > typedef lambda< her<_> >::type f;
> > typedef apply::type t;
> >
> > BOOST_MPL_ASSERT_IS_SAME(t, her);
> >
> > The "ordinary" metafunctions work as before.
>
> Ah!
>
> That answers my question...
>
> So if I want to generate a template instantiation that /happens/ to
> have a nested type (that's not identity), I can't use the reduced
> form.
Not implicitly. The 'reduced< my_func<_> >' notation will solve that.
> Interesting. You have to be a little bit careful with that reduced
> form then.
Sure :). But in majority of cases it gives you the most intuitive behavior.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] The Wonder of Tuples
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: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Reflection Framework [was Serialization and Reflection]
[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 an on-and-off project, though :). > Does anyone have other ideas on approaching this problem? Any > comments at all? Well, come to think about it, I am not sure if any information one wants to get from a reflection framework _requires_ a run-time interface. You might want to have some convenience wrappers, e.g. for conventional run-time iteration, but basically that seems to be it. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Reflection Framework [was Serialization and Reflectio n]
[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 it in GCC. It's an > > on-and-off project, though :). > > Cool. Would you care to put them in the sandbox and/or email > them to me? > I'd like to take a look at them. I'll try to put it into more or less presentable form over the weekend; I'll post the link here. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] mpl and codewarrior 8.3 (patch)
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! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] mpl and codewarrior 8.3 (patch)
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, apparently, it's a Metrowerks bug:
#include "boost/mpl/aux_/has_xxx.hpp"
#include "boost/static_assert.hpp"
BOOST_MPL_HAS_XXX_TRAIT_DEF(begin)
struct UDT {};
struct begin {};
int main()
{
BOOST_STATIC_ASSERT(!has_begin::value);
}
# Compiling: 'F:\home\depot\bugs\mw83\has_xxx.cpp'
### C:/Program Files/Metrowerks/CodeWarrior 8.0/Other Metrowerks
Tools/Command Line Tools/mwcc.exe Compiler:
#File: F:\home\depot\bugs\mw83\has_xxx.cpp
#
# 11: sizeof(::boost::STATIC_ASSERTION_FAILURE< (bool)(
!has_begin::value ) >) }
# Error:
^
# illegal use of incomplete struct/union/class
'boost::STATIC_ASSERTION_FAILURE<0>'
I reported it to their tech-support.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost regression testing of MPL on HPUX
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 > > Index: integral_c.hpp > > === > > RCS file: /cvsroot/boost/boost/boost/mpl/integral_c.hpp,v > > retrieving revision 1.10 > > diff -r1.10 integral_c.hpp > > 27c27 > > < #if defined(BOOST_STRICT_CONFIG) || !defined(__HP_aCC) || > __HP_aCC > 33900 > > --- > >> #if defined(BOOST_STRICT_CONFIG) || !defined(__HP_aCC) || > __HP_aCC > 53800 > > Should be: > >#if !BOOST_WORKAROUND(__HP_aCC, <= 53800) > > or, if you have __HP_aCC == 53800 > >#if !BOOST_WORKAROUND(__HP_aCC, BOOST_TESTED_AT(53800)) > > > 52c52 > > < || defined(__HP_aCC) && __HP_aCC <= 33900) > > --- > >> || defined(__HP_aCC) && __HP_aCC <= 53800) > > likewise, except without the '!' Applied. > > > > And finally I got stuck on following codeline : > > > > cd /home/tk/boost/boost/tools/regression/build ; bjam > > ...found 834 targets... > > ...using 1 temp target... > > ...updating 8 targets... > > ...using > > > c>exception.o... > > aCC-C++-action > > > ../../../libs/filesystem/build/bin/libfs.a/acc/release/runtime > -link-dynamic/operations_posix_windows.o > > Error 20: "/home/tk/boost/boost/boost/mpl/if.hpp", line 56 > # '::' expected > > before 'if_c'. > > typedef typename if_c< > > > > Hmm, that's silly. Looks like aCC might need full qualification here. My guess as well. One if these might work: typedef typename mpl::if_c< or typedef typename ::boost::mpl::if_c< Please report back on it, and I'll check in the appropriate fix. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] mpl and codewarrior 8.3 (patch)
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Using MPL on MSVC7
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 aforementioned page gives a pretty accurate answer to
your question, for Windows platform. In short, the library works with all of
them.
That said, unfortunately it cannot shield a user from all the bugs in
unconforming compilers; when writing your own complex template code, you
still have to have a certain amount of knowledge about the particular
compiler's idiosyncrasies. In these cases the library at least gives you
some patterns/workarounds to follow.
>
> I'm currently porting a library from Intel to GCC, MSVC7.0
> and BorlandC-5.5 and running into some problems.
Borland is probably going to be the most troublesome, here. It's known for
giving a lot of headache when one is dealing with compile-time integral
constant expression. Be sure to check John Maddock's "Coding Guidelines for
Integral Constant Expressions"
(http://www.boost.org/more/int_const_guidelines.htm), as well as MPL's
techniques to work around some of these problems.
> GCC is doing relatively okay. I'm moving from Borland-5.5 to 6.x
> soon, so I probably won't even bother with that one. So that
> leaves MSVC 7.0. However, compiling even relatively simple
> templates, I get errors pointing in the MPL source-code
> (which is a problem with MSVC, not with the actual sourcecode of
> course).
You happened to hit one of the VC 7.0 newly-introduced bugs (MSVC 6.5 is OK
in this regard), please see below.
>
> Note, I'm not even instantiating anything yet, this is just
> the first-phase compilation of a template definition.
Yep, that's a typical symptom of the problem.
> For example, consider:
>
> /*!
> \brief Meta function, returns the number of bits equal to
> 1 in a given number.
> \param N Some number. Concept: boost::mpl::integral_c
> \retval ::type boost::mpl::integral_c< size_t, Number of
> bits equal
>
>to 1 in
> N >
> */
> template < typename N >
> struct num_bits_set
> {
> private:
>
> template < typename Number >
> struct recurse
> {
>
> private:
> BOOST_STATIC_CONSTANT( typename Number::value_type,
>
> shift_right_value =
> N::value >> 1 );
> BOOST_STATIC_CONSTANT( typename Number::value_type,
>
> last_bit_set_value =
> N::value & 1 );
> typedef mpl::integral_c< size_t, last_bit_set_value >
> next_value;
>
> public:
>
> typedef typename mpl::plus<
> next_value,
> typename num_bits_set<
> mpl::integral_c<
> typename Number::value_type,
> shift_right_value > >::type
> >::type type;
> };
>
> public:
> typedef typename mpl::apply_if<
> typename mpl::equal_to<
> N,
> mpl::integral_c<
> typename N::value_type,
> 0 >
> >::type,
> mpl::integral_c< size_t, 0 >,
> recurse< N >
> >::type type;
> };
>
> Compiling this on MSVC 7.0 gives me the following errors:
[skip the errors]
Basically, the source of the problem here is that 'num_bits_set' and its
nested 'recurse' template depend on each other recursively; that, of course,
is a perfectly well-formed C++, but such recursive dependence means, in
particular, that when parsing the 'recurse' template the compiler haven't
seen the full definition for the 'num_bits_set' itself yet, and sometimes
this interacts badly with MSVC's so-called "early template instantiation"
bug (you can search the list archive to find out more about that one).
After you know what you are dealing with, the fix is simple:
#include "boost/mpl/if.hpp"
#include "boost/mpl/aux_/msvc_never_true.hpp"
#include "boost/detail/workaround.hpp"
// ...
template < typename N >
struct num_bits_set
{
private:
template < typename Number >
struct recurse
{
private:
BOOST_STATIC_CONSTANT( typename Number::value_type,
shift_right_value =
N::value >> 1 );
BOOST_STATIC_CONSTANT( typename Number::value_type,
last_bit_set_value =
N::value & 1 );
typedef mpl::integral_c< std::size_t, last_bit_set_value >
next_value;
public:
#if BOOST_WORKAROUND(BOOST_MSVC, == 1300)
typedef typename mpl::if_<
mpl::aux::msvc_never_true
, mpl::integral_c
, typename num_bits_set<
mpl::i
RE: [boost] Re: Using MPL on MSVC7
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 problems.
>
> Perhaps it is a good idea to add those missing operators to
> the MPL?
It is! They are not there only because you are the pioneer, here. The
followers will be very grateful :)
> I would be willing to do it, considering it is probably just going to
> be a copy paste and changing an operator here and there in a lot of
> boiler-plate code.
Wonderful, I only was going to suggest it! I'll be happy to work with you on
it.
> > as MPL's
> > techniques to work around some of these problems.
>
> These are not documented explicitly anywhere are they?
Nope, not yet.
> I can't seem to find more info on http://www.mywikinet.com/mpl/,
> and I'm not man enough to dive in the MPL source-code :) hehe.
It's not that frightening, but I understand :). I'll try to do something
about documenting the major workaround techniques/constructs.
> template < typename N, typename Result = mpl::integral_c<
> size_t, 0 > >
> struct num_bits_set
> {
> typedef typename mpl::apply_if<
> typename mpl::equal_to<
> N,
> mpl::integral_c< typename N::value_type, 0 >
> >::type,
>
> Result,
> num_bits_set<
> mpl::integral_c< size_t, N::value &
> (N::prior::value) >,
> typename Result::next
> >
> >::type type;
> };
>
> Definitely a lot shorter.
Personally, I would make it even more shorter by getting rid of explicit
comparison with zero:
template<
typename N
, typename Result = mpl::int_c<0>
>
struct num_bits_set
{
typedef typename mpl::apply_if<
N
, num_bits_set<
mpl::int_c< N::value & (N::prior::value) >
, typename Result::next
>
, Result
>::type type;
};
>
> I need to change my algorithms in some other places too I
> think. However, the functional style of programming and the
> associated amount of recursion does not leave much flexibility.
Some of these issues are probably caused by absence of some common
primitives in the library. If you cite your typical use cases when you have
to resort to recursion (and when that bothers you :), together we might be
able to classify them and find out if there is anything on the library side
we can do to support them better - or may be find the ways to do that with
the already existing facilities.
For instance, here's how a higher-level version of the 'bit_count' algorithm
might look like:
template< typename N >
struct bit_count
{
typedef typename for_<
pair< int_c<0>, N >
, _2
, pair<
next< _1 >
, bit_and< _2, prior< _2 > >
>
>::type type;
};
Would something like this make your life easier?
> Also, I'll need to start thinking about
> http://www.mywikinet.com/mpl/paper/mpl_paper.html#sequences.unrolling
> and http://users.rcn.com/abrahams/instantiation_speed/index.html.
The current sources implement the unrolling a little bit different; I will
be documenting it sometime in the future, meanwhile just ask when you get to
it.
> By the way, would it be worthwhile to create an 'Effective
> MPL' wiki page with some common gotchas on the different
> compilers? We could refer to the document on Integral Constant
> Expressions, we could mention the 'early template instantiation'
> and the work-around, and we could mention the lambda complications.
Very worthwhile for sure.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Using MPL on MSVC7
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 other multiple things when it > appears between <...>: > >template ::type> > > vs > >template ::type> IMO it's more a problem with the layout of template parameters than with anything else: template< typename T , typename U = typename metafunction::type > class her; In short, my motivation for using 'typename's here is that I perceive the 'class' keyword as rather high-weight, semantically loaded, and prefer to use it in its only original context - that is, for declaring/defining a user-defined type that is more than a POD. Using it in other places cheapens the word. That's all subjective, of course. Just clarifying my position :). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BOOST_PP_RANGE?
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 : ( C0 > 0 ? C0 : -1 ) ) )
;
};
So here's what I came up with:
template<
BOOST_PP_ENUM_PARAMS(BOOST_MPL_METAFUNCTION_MAX_ARITY, int C)
>
struct max_arity
{
BOOST_STATIC_CONSTANT(int,
value = BOOST_PP_LIST_FOLD_LEFT(
AUX_MAX_ARITY_OP
, -1
, (0, (1, (2, (3, (4, BOOST_PP_NIL)
)
);
};
I love everything about it except for the "(0, (1, (2, (3, (4,
BOOST_PP_NIL)" part. I would like the above to become something along
these lines:
value = BOOST_PP_RANGE_FOLD_LEFT(
AUX_MAX_ARITY_OP
, -1
, BOOST_PP_RANGE(0, 4)
)
or, better yet,
value = BOOST_PP_FOLD_LEFT(
AUX_MAX_ARITY_OP
, -1
, BOOST_PP_RANGE(0, 4)
)
where 'BOOST_PP_FOLD_LEFT' is a generic algorithm that can be used on all PP
sequences.
How hard would it be to have something like this?
I suppose it's possible to generate the code I need using BOOST_PP_WHILE,
but IMO that solution wouldn't be as conceptually nice and intuitive as the
above.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] BOOST_PP_RANGE?
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 above to become > something along > > these lines: > > > > value = BOOST_PP_RANGE_FOLD_LEFT( > > AUX_MAX_ARITY_OP > > , -1 > > , BOOST_PP_RANGE(0, 4) > > ) > > This one is certainly possible. However, "BOOST_PP_RANGE_FOLD_LEFT" > would just be a synonym for whatever folding macro operates on the > type generated by "BOOST_PP_RANGE." It would be to difficult to > make a parametizable macro that yields a sequence of numbers: > > BOOST_PP_SEQ_FOLD_LEFT( > AUX_MAX_ARITY_OP > , -1 > , BOOST_PP_SEQ_RANGE(0, 4) > ) > > Which is close to what you want. In fact, it is almost already > there: > > #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_LEFT(AUX_MAX_ARITY_OP, -1, RANGE(0, 5)) > Looks good! How efficient is it? For instance, if NUMBERS is a sequence from 0 to 255? > The only major difference is that BOOST_PP_SEQ_SUBSEQ takes > first and length operands, rather than first and last. That's no problem for me. > Which, for the zero-case is almost the same: first -> > BOOST_PP_INC(last). It wouldn't be too difficult to > bang out a variant that goes from first -> last though. Yep. > > > or, better yet, > > > > value = BOOST_PP_FOLD_LEFT( > > AUX_MAX_ARITY_OP > > , -1 > > , BOOST_PP_RANGE(0, 4) > > ) > > > > where 'BOOST_PP_FOLD_LEFT' is a generic algorithm that can > > be used on all PP sequences. > > > > How hard would it be to have something like this? > > With C99's variadic macros, fairly easy with lists vs. > sequences. Without them, impossible. The reason is simple, > without variadics I have no way of telling the difference > between (a) and (a, b), etc With variadics I can > count the arguments. > I see. Well, I guess we have to wait till variadic macros get their way into C++. Thanks for your help! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] BOOST_PP_RANGE?
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_LEFT(AUX_MAX_ARITY_OP, -1, RANGE(0, 5)) Hmm, it doesn't work on Metrowerks 8.3: the compiler chokes on preprocessing with the following diagnostics: Error : ',' expected fold_left.cpp line 19 BOOST_PP_SEQ_FOLD_LEFT(AUX_MAX_ARITY_OP, -1, RANGE(0, 5)) It seems like it doesn't like BOOST_PP_SEQ_SUBSEQ - the example from the docs fails as well: #include #define SEQ (0)(1)(2)(3)(4)(5) BOOST_PP_SEQ_SUBSEQ(SEQ, 2, 3) // expands to (2)(3)(4) Error : ',' expected subseq.cpp line 5 BOOST_PP_SEQ_SUBSEQ(SEQ, 2, 3) // expands to (2)(3)(4) Is it a known failure? It would be nice to have some tests for the SEQ stuff :). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Using MPL on MSVC7
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 = typename metafunction::type
> > >
> > class her;
>
> That doesn't do anything to reduce the confusability of the 'typename'
> keyword for me, especially not in Jaap's example:
>
>template<
>typename T
> , typename T::X N
> >
>class foo;
Well, it doesn't confuse me, FWIW.
>
> > In short, my motivation for using 'typename's here is that
> > I perceive the 'class' keyword as rather high-weight, semantically
> > loaded, and prefer to use it in its only original context - that
> > is, for declaring/defining a user-defined type that is more than
> > a POD. Using it in other places cheapens the word.
>
> As I said (and no offense is intended) these seem to be pedantic
> rather than practical reasons. I suppose you could say "aesthetic"
> instead of "pedantic",
Yes, and because of the human nature "aesthetic" often has very practical
consequences. One has to like the code she writes, most of the time, anyway.
Often the only thing you can do in such situation is to change one's
perception of one way being more aesthetically appealing than the other;
e.g. by showing her that, despite being "ugly", it's superior from
engineering point of view (easier to maintain, less error-prone, etc.,
depending on the context), so, then, when writing that "ugly" code, the
person will think: "OK, I know this is ugly, but I am doing the right thing
here, and I am an Engineer" :).
We are not close to that state, yet :).
> but the practical consequences of those choices
> outweigh the aesthetic ones for me,
For some reason the cited problems with using 'typename' in the template
parameter lists don't really ring a bell for me. May be it's just me, or may
be it's just you :). To know for sure we would need a "'typename' experience
survey" :).
> especially because in a
> metaprogramming context we will commonly use "struct" instead of
> "class"... once again because the practical consequences outweigh the
> aesthetic ones ;-)
No, that's not the reason, at least not mine :). The practical consequences
do not outweigh the aesthetic ones, they are on the same side, here. Even if
classes by default provided 'public' access to their members, so instead of
template< typename T >
class identity
{
public:
typedef T type;
};
one could write
template< typename T >
class identity
{
typedef T type;
};
I still would be using 'struct' there, because 'identity' has nothing to do
with the loaded OO-centric 'class' meaning at all.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] BOOST_PP_RANGE?
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] BOOST_PP_RANGE?
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) \ > > > /* ... */ > > > > > > #define RANGE(first, length) \ > > > BOOST_PP_SEQ_SUBSEQ( NUMBERS, first, length ) \ > > > /**/ > > > > > > BOOST_PP_SEQ_FOLD_LEFT(AUX_MAX_ARITY_OP, -1, RANGE(0, 5)) > > > > > > > Looks good! How efficient is it? For instance, if NUMBERS > > is a sequence from 0 to 255? > > It should be very efficient. The length of the input doesn't > matter, the length of the output range matters slightly. Oh, good! > Actually, if you only need a range starting from zero, you can > use BOOST_PP_SEQ_FIRST_N instead of BOOST_PP_SEQ_SUBSEQ which will > be more efficient yet. OK, will have it in mind. Thanks, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] New MPL meta-functions, and a question
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 >,
> mpl::int_c< 3 >
> >::type::value
> >
>
> has a different type than this one:
>
> mpl::minus<
> mpl::int_c< 0 >,
> mpl::int_c< 3 >
> >::type
Uhm, in fact, these are always different:
typedef mpl::int_c<
mpl::minus<
mpl::int_c< 0 >,
mpl::int_c< 3 >
>::type::value
> t1;
typedef mpl::minus<
mpl::int_c< 0 >,
mpl::int_c< 3 >
>::type t2;
BOOST_STATIC_ASSERT((!boost::is_same::value));
BOOST_STATIC_ASSERT((boost::is_same<
t2
, mpl::integral_c
>::value));
The motivation is that in ideal C++ word that has typedef templates all of
the following assertions would be true,
int_c === integral_c
bool_c === integral_c
size_t_c === integral_c
so the issue will go away by itself; another reason, of course, is that the
current semantics was the simplest to implement ;).
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:
template<
typename N1
, typename N2
>
struct plus
{
typedef typename promotion_traits::type U_;
typedef typename apply2<
plus_traits
, typename construct::type
, typename construct::type
>::type type;
};
template<>
struct plus_traits
{
template< typename N1, typename N2 > struct apply
: integral_c<
typename N1::value_type
, (N1::value + N2::value)
>
{
};
};
If we had this infrastructure in place, making 'minus< int_c<0>, int_c<3>
>::type === int_c<-3>' would be trivial.
Figuring out a reasonable way to specify the promotion rules is probably the
hardest part there...
> And now on to the good stuff...
>
> If you go to http://jaap.flipcode.com/boost/ you will find a
> file called 'bit.zip'. In it are four files called:
>
> bit_and.hpp
> bit_or.hpp
> bit_xor.hpp
> bit_shift_right.hpp
>
> I am using all of these in my own code currently, and they
> work fine there.
Wonderful!
> Considering it's mostly copy paste work from the other
> meta-functions, it shouldn't present any difficulties. I didn't
> need the bit_shift_left meta function, so I haven't written
> that one yet. Once discussions has settled, I'll be glad to add
> that one too.
>
> Open issues:
>
> 1. I don't like the 'bit_' prefix, but there are already
> logical 'and' and 'or' operators and corresponding files. One
> option is to use 'bitwise' instead, but I liked the shortness of
> 'bit'.
IMO 'bit' is perfectly OK - in fact, the standard alternative tokens for &
and | are called 'bitand' and 'bitor' correspondingly. What I am kind of
ambivalent about is where to put the underscore, in the middle ('bit_and')
or at the end ('bitand_'). I _think_ I prefer the latter, because, if
applied consistently, it makes everything easier to remember:
run-timecompile-time
voidvoid_
sizeof sizeof_
&&, and and_
||, or or_
!, not not_
&, bitand bitand_
|, bitorbitor_
BTW, I think 'bit_shift_right' should be named simply 'shift_right'; after
all, may be someone would like to "overload" it :).
>
> 2, On my PC I've placed these files in the boost/mpl/bit
> directory, just like boost/mpl/arithmetic and boost/mpl/logical
> have their own directories.
> Obviously, once dust has settled we need to make a 'bit.hpp'
> that includes all the bit_* files, and place it in the MPL root.
Actually, I was planning on bringing the content of "arithmetic", "logical",
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 directory as well.
> 3. The bit_xor and bit_or functions are really simple. The
> bit_and function however presented a problem for the default values
> of parameters 3 to 5. I'm using 0x right now, which happens
> to work on my (32 bit) platform, but obviously this is not a good
> solution. Any suggestions are welcome.
That's somewhat a part of the larger issue - on one hand, having arithmetic
metafunctions accept more than two arguments definitely simplifies complex
expressions:
plus< N, M, int_c<10> >
vs.
plus< plus< N, M>, int_c<10> >
On the other, the current way to implement it
RE: [boost] boost regression testing of MPL on HPUX
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: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] New MPL meta-functions, and a question
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 bit of pounding into > shape. The design idea was to specify a template that acts as a > lookup table keyed on the two source types and returning the correct > result type according to a two other parameters: the operation > and a parameter I'll call the "ruleset." The ruleset can be used to > provide different promotion strategies such as ANSI/ISO C++ arithmetic > rules, "keep the most information" rules and so on. > > A good example of ruleset use is the use of the "most information" > rule to implement integer divide using double types to retain > precision. > > 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 start with (besides the Blitz++'s one). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL on HPUX
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. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Using MPL on MSVC7
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 it along these lines: To reduce the notational overhead imposed by the specifics of the compile-time domain, many of MPL metafunctions, when fully-curried (provided with all arguments), directly support the interface of the Integral Constant concept: BOOST_STATIC_ASSERT(not_equal_to< int_c<5>, int_c<0> >::type::value); // OK, ordinary function invocation BOOST_STATIC_ASSERT(not_equal_to< int_c<5>, int_c<0> >::value); // also OK! This property often allows you to simplify your compile-time conditions: > > apply_if< > typename equal_to >::type > , ... > > can be written: > > apply_if< > equal_to > > , ... > Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Using MPL on MSVC7
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 mention that. I've been meaning to ask for its
> appropriateness on this list. After all, we are exposing
> implementation details in the interface which is not something
> I would recommend on a daily basis.
At least one has to be careful :). There are at least two situations when
default template parameters affect the observable library behavior:
1) adding default _non-type_ template parameters "disqualifies" a
metafunction from participating in lambda expressions:
template<
typename N
, int one_before_previous_ = 0
, int previous_ = 1
>
struct fibonacci
{
// ...
};
typedef fold<
range_c
, int_c<0>
, plus< _1, fibonacci<_2> >
>::type sum; // compilation error here!
BOOST_STATIC_ASSERT(sum::value == 88);
2) adding a default template parameter to a metafunction which number of
parameters is already equal to BOOST_MPL_METAFUNCTION_MAX_ARITY results in
the same negative effect:
// BOOST_MPL_METAFUNCTION_MAX_ARITY == 5
template<
typename N1
, typename N2
, typename N3 = integral_c
, typename N4 = integral_c
, typename N5 = integral_c
, typename result_ = integral_c
>
struct my_fun
{
// ...
};
typedef fold<
range_c
, int_c<0>
, my_fun<_1,_2>
>::type sum; // error!
Otherwise, it's more or less safe :).
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] New MPL meta-functions, and a question
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 > > start with (besides the Blitz++'s one). > > I'll see about getting it up to MPL standards over the next week. I > can't promise a timetable because I'm writing a dissertation at the > moment. :) Sure. Looking forward to it! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] [MPL] naming question
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 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)? Anyway, suggestions and opinions are welcome! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] naming question
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);
> >
> > ?
>
> I don't know. In Python, the one that takes an argument tuple is
> called "apply", and the other one is called "function call syntax" ;-)
I knew about the former, but I wondered how the second one is called :).
>
> > 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)?
> >
> > Anyway, suggestions and opinions are welcome!
>
> I'm afraid I'm stumped also.
> If you were willing to make a massive change, I'd suggest:
>
>call this one 'apply'
>call the other one 'call' or 'invoke'
>
> Though I don't particularly like it.
Me too, but thanks for the suggestion.
> Why is 'apply' more appropriate
> for this one, other than consistency with some other language?
It's not indeed.
> I think 'apply_args' sounds right, though they both let you specify
> arguments.
I thought of this one too, and had the same concern...
> Maybe 'apply_arg_sequence' is appropriate?
This one is not bad, although 'apply_arg_sequence' probably too long
for a metafunction invocation syntax. May be a shorter abbreviation of it,
'apply_arg_seq'?
Hmm, actually, come to think about it more, there is no reason to stick
arguments unfolding _and_ consequent function application into the same
metafunction. In fact, separating those two, besides conceptual clarity,
might yield some practical benefits as well - one might want to adapt a
metafunction class and just pass it on, with the invocation happening later
on, if at all.
So, instead of single 'apply_arg_seq' construct that does this
apply_arg_seq::type ==
apply::type
we can just have ordinary 'apply' + a metafunction class adaptor that
unrolls the argument sequence:
unroll_args == adapted_F
apply< unroll_args,Args >::type
== apply::type
where 'adapted_F' implements the actual unrolling:
struct adapted_F
{
template< typename Args > struct apply
: apply
{
};
};
So, now the question is, how to name the adaptor? :) Does 'unroll_args'
sound right/good enough?
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] naming question
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 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;
instead, it unrolls the sequence and passes all its elements to the
metafunction as separate arguments, all at once.
To clarify it further, here's how a run-time equivalent of that hypothetical
'apply_tuple' could look like:
template< typename F, typename Tuple >
typename result_type::type
do_apply(F f, Tuple const& args, arity<1>)
{
return f(get<0>(args));
}
template< typename F, typename Tuple >
typename result_type::type
do_apply(F f, Tuple const& args, arity<2>)
{
return f(get<0>(args), get<1>(args));
}
// ...
template< typename F, typename Tuple >
typename result_type::type
apply(F f, Tuple const& args)
{
enum { n = tuple_length::value };
return do_apply(f, args, arity());
}
void f(int, char const*);
int main()
{
apply(f, make_tuple(5, "text")); // here
}
> then "apply_to_sequence" would be an accurate name.
Thanks for clarifying the language side. Would it be still accurate for the
aforementioned semantics?
> Too bad it can't just be "apply".
Yeah, unfortunately it can't be. You have to have different notation for
invoking a function with a sequence of elements, 'cause just determining if
the first and the only argument is a sequence and unrolling it is not enough
- a (meta)function itself might expect exactly the original sequence, after
all.
Thanks,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] naming question
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"? I like the latter, but it doesn't appear to be a word; "unarize" is not a word either, but at least google finds a couple of them :). On a second thought, I am not sure if it's a good choice. Does apply< unarize, list >::type convey the discussed meaning for you? Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] naming question
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
> {
> template
> struct apply { ... }
>
> template
> struct apply { ... }
> };
>
Yes, except that I don't want to place a burden of supporting both forms on
a metafunction author. It's 'apply_tuple' that is supposed to take care of
arguments unfolding and passing them on, separately, to the metafunction
being invoked.
> And what about partial specialisation of function templates?
http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2001/n1295.htm
> Could there be a good chance to get that, as well? I guess these things
> depend much on somebody writing a formal proposal. :)
In particular.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [MPL] naming question
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 sense if a (meta)function being called is allowed to have side effects; since a pure compile-time metafunction isn't (cannot), we don't have a pure compile-time 'for_each'. Instead, we have a whole family of 'fold' algorithms (http://www.mywikinet.com/mpl/ref/Algorithms.html), e.g.: typedef fold< numbers, int_c<0>, plus<_1,_2> >::type sum; What we do have on the 'for_each' side, is a "half run-time" algorithm that invokes an ordinary function on each element of a compile-time sequence: typedef mpl::range_c numbers; std::vector v; mpl::for_each( boost::bind(&std::vector::push_back, &v, _1) ); // equivalent to // v.push_back(0); // v.push_back(1); // ... // v.push_back(9); > > Yeah, unfortunately it can't be. You have to have different > > notation for invoking a function with a sequence of elements, > > 'cause just determining if the first and the only argument is > > a sequence and unrolling it is not enough - a (meta)function > > itself might expect exactly the original sequence, after all. > > Yep. Is there no way to use function call syntax for the > 0...n args case? As a matter of fact, it is, well, kind of: invoke< f(int,long) >::type // 'f' is a metafunction class here The only problem with the above is that it doesn't support certain types of argument very well (as highlighted in here: http://www.mail-archive.com/boost@lists.boost.org/msg00705.html), so when passing const, array, or 'void' types to a metafunction invoked in this manner, one has to do something like this: invoke< f(arg,long) >::type And it's not as portable as one would wish (for instance, gcc 3.2 chokes on some of those, not to speak about the other less capable compilers out there), so the combination of these factors pretty much rules it out, at least for now. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL Lambda on MSVC 7
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 -
http://lists.boost.org/MailArchives/boost/msg39533.php? That's pretty much
all there is to it.
>
> Basically, I have the following meta function (more
> complicated in real life, but the number of parameters is the same)
>
> template< class A, class B, class C >
> struct meta_fun : mpl::plus< A, B, C > {};
>
> And I use it as follows:
>
> template< class List, class Bar >
> struct foo
> {
> typedef typename mpl::fold<
> List,
> mpl::integral_c< size_t, 0 >,
> meta_fun< mpl::_1, mpl::_2, Bar >
> >::type type;
> }
>
> Perhaps it is interesting to note that only the first and
> second parameter of the meta function are lambda'd. The last
> parameter is 'fixed' to Bar. Is this at all possible with lambda,
Sure!
> or do I need to 'bind' the third parameter to create a
> meta-function that takes two parameters? It compiles on Intel
> and GCC, so I guess it is supported.
Everything that seems intuitive is supported :). If it doesn't work, it's
most probably a bug.
But the above example _does_ compile on every platform MPL supports -
including MSVC 6.5/7.0 (assuming the latest CVS sources). Or are you using
the 1.29.0 archive?
>
> In my actual code I'm not using mpl::plus but another meta-function
> that tries to acces A::value_type and B::value_type. This works
> fine on Intel and GCC, but MSVC gets the wrong types for A and B
> because it tells me that:
>
> error C2039: 'value_type' : is not a member of
> 'boost::mpl::arg'
> with
> [
> N=2
> ]
>
> This is wrong because at the point where the error occurs I'm asking
> for the value_type member of something should be integral_c<> and not
> arg<>. I guess the fix lies in the BOOST_MPL_AUX_LAMBDA_SUPPORT and
> VOID_SPEC macros.
The former one is enough.
> But I don't really understand what these macros do (looking at their
definitions
> didn't really help either). I've tried something like:
>
> template< class A, class B, class C >
> struct meta_fun : mpl::plus< A, B, C >
> {
> BOOST_MPL_AUX_LAMBDA_SUPPORT( 3, meta_fun, (A, B, C) );
> };
That's exactly how a metafunction should be patched to become usable in
lambda expressions on deficient compilers (except for the semicolon at the
end of the macro).
> but that didn't fix it.
Hmm, works for me, even if I remove the 'plus' inheritance:
template< class A, class B, class C >
struct meta_fun
{
typedef A type;
BOOST_MPL_AUX_LAMBDA_SUPPORT( 3, meta_fun, (A, B, C) )
};
> I guess my question is: how would you define meta_fun so it supports
> lambda on MSVC 7?
I hope that all the above answers this question.
> Or if it's possible, do you have some time to give a short explanation
> on the LAMBDA macros,
BOOST_MPL_AUX_LAMBDA_SUPPORT(arity, name, params)
arity - metafunction's arity
name - metafunction's name
params - metafunction's formal template parameters, passed as PP tuple,
e.g. '(T1,T2,T3)'
> what compiler-problems they try to fix, and how they do it?
>
They are compensating the lack of partial template specialization or/and
template template parameters support by the means of introducing an
intrusive metafunction's introspection mechanism. The implementation details
are gloriously nasty, vary from compiler to compiler, and generally aren't
worth one's time.
> Any information will of course be updated in the Effective MPL wiki.
That would be very much appreciated!
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: New MPL meta-functions, and a question
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 > > directory as well. > > Yeah, that seems like a good idea because the folder-hierarchy > doesn't match the namespace-hierarchy. Are you able to do that > soon? Before the coming release for sure. > I did it with the bit-meta-functions, and also added a shift_left.hpp > and a composite bit.hpp header. Wonderful! I am going to integrate these at the same time I'll do the directory structure refactoring. I'll also add your name to the copyright notice. > > I also added a bit.cpp in boost/libs/mpl/test directory that does a > unit-test. Let me know if you wish to see more extensive testing (with > different types). > > >> Problem with bit_and > > So you can go this way, or just make everything take two operands > > only, and we'll take care of it later. > > Yeah, the new bitand_ function only supports two operands now. That's fine for now. > > Everything is located in in the zip file on > http://jaap.flipcode.com/boost/bit.zip > > Do you want me to put it in the sandbox instead? I still need > to work on my cvs skills, that's why I haven't put it there yet. The archive is OK. I'll put them into the main CVS real soon anyway. Thanks for your work, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL Lambda on MSVC 7
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_SUPPORT( 1, meta_fun_1, (T) )
> };
>
> template< class List, class T >
> struct meta_fun_2
> {
> typedef typename mpl::fold< List,
> mpl::integral_c< size_t, 0 >,
> meta_fun_1< mpl::_1 >
> >::type type;
> };
>
> The problem lies in the fact that I try to use a dependent type in
> meta_fun_1.
Yep, to be concrete, 'T::value_type'. Please see the following posts for an
explanation of the shortcoming, as well as for a technique to work around
it:
http://lists.boost.org/MailArchives/boost/msg39915.php (the relevant part
starts from "Well, having said that..." paragraph)
http://lists.boost.org/MailArchives/boost/msg39930.php (further explanation)
> I have pasted the full compiler error at the bottom of the
> message (it's rather long). The first few lines say:
>
> 'value_type' : is not a member of 'boost::mpl::arg'
> with
> [
> N=1
> ]
>
> e:\library\boost_1_29_0\boost\type_traits\is_convertible.hpp(61) : see
> reference to class template instantiation 'test::meta_fun_1' being
> compiled
> with
> [
> T=boost::mpl::_1
> ]
>
> Any suggestions? I can work-around it by using plain integers
> instead of ::value_type, but it's not as elegant.
template< class T >
struct meta_fun_1_impl
{
typedef mpl::integral_c< typename T::value_type, 0 > type;
};
template< class T >
struct meta_fun_1
: mpl::if_<
mpl::is_placeholder
, mpl::identity
, meta_fun_1_impl
>::type
{
BOOST_MPL_AUX_LAMBDA_SUPPORT( 1, meta_fun_1, (T) )
};
Or, if it's an internal/helper metafunction, just re-write it as a
metafunction class and, if you need to bind parameters to it - well, just
use 'bind':
typedef fold< types, int_c<0>, bind
>::type res;
A.
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] mpl::find_if problem on vc7 (once more)
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 just missed it. > > Problem: > mpl::find_if algorithm does not compile with vc7. > Simple inclusion of the boost/mpl/find_if.hpp > header generates a compiler error. Error occurs also on > libs/mpl/test/find_if.cpp > > Error message is following: [snip the errors] Thanks for the report! It's already fixed in the CVS. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Boost.MPL: "Superlinear unrolling" to avoid recursion depth limits
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 the inc template 262 times.
> The example code uses partial specialization, but it should not be
> extremely difficult to remove, if necessary.
Very interesting! The price for unrolling doesn't seem to be big either, for
VC 7.1, at least - ten compilation runs of "naive" 'until' implementation
are only by 2.5% faster than ten compilation runs of the unrolled version.
> I think that superlinear unrolling could be useful for avoiding
> template recursion depth limitations, but the technique needs further
> studying.
Thanks for sharing it!
[...]
> struct inc {
> template
> struct apply {
> typedef typename T::next type;
> };
> };
FYI, you can turn any MPL metafunction into a metafunction class by simply
not providing its template arguments; e.g. to get equivalent of the above
you just write 'mpl::next<>'.
>
> struct always {
> template
> struct apply {
> typedef typename mpl::bool_c type;
> };
> };
"boost/mpl/always.hpp", FYI.
> template
> struct is {
> template
> struct apply : mpl::bool_c<(T::value == X)> {
> };
> };
MPL has this one too; it's called 'eq', see
"boost/mpl/comparison/equal_to.hpp".
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Preliminary submission: command line & config fil e library
[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<
typename KeyType
, typename T
, typename Compare = std::less
>
class lexical_property_map
: private std::map< KeyType,T,Compare >
{
typedef lexical_property_mapself_t;
typedef std::map< KeyType,T,Compare > base_t;
public:
typedef typename base_t::key_type key_type;
using base_t::begin;
using base_t::end;
using base_t::empty;
using base_t::size;
using base_t::clear;
using base_t::find;
bool has_key(key_type const& a_key) const
{
return this->find(a_key) != this->end();
}
template< typename U >
self_t& put(key_type const& a_key, U const& a_value)
{
(*this)[a_key] = boost::lexical_cast(a_value);
return *this;
}
template< typename U >
U get(key_type const& a_key, U const& a_default = U()) const
{
return this->has_key(a_key)
? boost::lexical_cast( this->find(a_key)->second )
: a_default
;
}
T get(key_type const& a_key, T const& a_default = T()) const
{
return get(a_key, a_default);
}
};
int main()
{
lexical_property_map options;
options.put("delay", 50);
std::cout << options.get("delay");
}
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] type traits question
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/src/boost/boost/type_traits/is_volatile.hpp", line
> 33: error:
> identifier "is_volatile_rebind" is undefined
>
> BOOST_TT_AUX_BOOL_TRAIT_DEF1(is_volatile,T,::boost::detail::cv
> _traits_imp::is_volatile)
> ^
>
> "/u/garcia/src/boost/boost/type_traits/remove_const.hpp",
> line 56: error:
> identifier "remove_const_rebind" is undefined
> BOOST_TT_AUX_TYPE_TRAIT_DEF1(remove_const,T,typename
> detail::remove_const_impl::type)
> ^
[...]
>
> Any idea what might be causing this?
Yep. The marked line below makes the 'remove_const' definition ill-formed,
and that's what the BOOST_TT_AUX_TYPE_TRAIT_DEF1 macro expands to on
non-conforming compilers:
template< typename T > struct remove_const
{
typedef T type;
friend class remove_const_rebind;
typedef remove_const_rebind rebind; // here
};
Your KCC is the first compiler that is classified by the config system as
non-conforming (not supporting PTS/TTP), but yet complaining about the above
line :). There are several ways how I can fix the above, but before
attempting the fix I need to know answers to the foregoing questions.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] type traits question
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 supports partial template specialization.
> I don't even know the syntax for template template parameters :).
> If you give me an example of it, I can give it a try.
Actually the EDG version is enough - it doesn't.
>
> Let me know if there is any more information I can give you.
Could you test if the following compiles successfully with the latest CVS
sources?
#include "boost/mpl/aux_/has_xxx.hpp"
#include "boost/static_assert.hpp"
template< typename T >
struct remove_const
{
typedef T type;
struct rebind;
};
template< typename T >
struct remove_const::rebind
{
typedef T arg0;
};
BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF(has_rebind, rebind, false)
typedef remove_const r;
BOOST_STATIC_ASSERT(has_rebind::value);
TIA,
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] type traits question
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL usage for code generation
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 then transform the function call "my_function<_>(s)" into
> > an instantiated function object of the kind suitable for
> > mpl::for_each.
>
> I'm afraid that particular syntax won't work for this particular case,
> though. If my_function is a function template, my_function<_> is a
> function, and my_function<_>(s) calls that function.
>
> Since there are no (function template) template parameters, only
> (class template) template parameters, there doesn't appear to be any
> way to make this one particularly easy except by using the
> preprocessor to define some kind of function object.
>
> It appears to be just bad luck that higher order functional
> programming with function templates is impossible in C++.
My current understanding (which, admittedly, is not backed up by a
real-world experience) is that if you care about higher-orderness of your
generic algorithms, a preferred implementation construct for those
algorithms is not a function template, but a static _function object_ (a
technique used in FC++):
struct my_function_
{
template< typename U >
void operator()(std::string const& text, U)
{
// ...
}
} my_function; // here!
For ordinary uses, the above will act just like a plain function template
(minus ADL/explicit template arguments specification):
my_function("text", int());
and it will also allow one to do something like this:
std::string text("text");
mpl::for_each< my_types >(boost::bind(my_function, text, _1));
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL usage for code generation
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
> working through the code to see what to change.
Hmm, seem to work for me on 5.6 (__BORLANDC__ == 0x560):
>
Borland C++ 5.6 for Win32 Copyright (c) 1993, 2002 Borland
F:\cvs_main8\boost\libs\mpl\test\for_each.cpp:
Warning W8012 F:\cvs_main8\boost\libs\mpl\test\for_each.cpp 82: Comparing
signed and unsigned values in function main()
<
I don't have access to 5.6.1, so I would need some cooperation to fix it.
Off the top of my head, can you please check if changing the offending line
from
static int const value = F::arity;
to
enum { value = F::arity };
helps at all? If it doesn't, how about the one below?
static int const value = BOOST_MPL_AUX_MSVC_VALUE_WKND(F)::arity;
(you'll need to include "boost/mpl/aux_/value_wknd.hpp" for that).
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL::void_t
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL usage for code generation
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)
> {
> // ...
> }
>
> };
>
> function my_function; // here!
>
> Then:
>
> mpl::for_each< my_types >(my_function(text, _1));
This is way too cool! Now we only need to provide such free-standing forms
of all STL algorithms/member functions, and we will be living in a different
world:
std::vector v;
push_back(v, "text"); // plain call
for_each(input, push_back(v, _1)); // currying
for_each(v, for_each(_1, print_char)); // more currying
// etc.!
Breathtaking, IMO.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] BOOST_WORKAROUND question
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 same time the last checked version (so, ideally, I would like to be able to check if it's outdated). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] RE: Re: MPL usage for code generation
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 applied to an evaluation version of the
compiler (on Windows, anyway).
> > Off the top of my head, can you please check if changing the
> > offending line from
> >
> > static int const value = F::arity;
> >
> > to
> > enum { value = F::arity };
> >
> > helps at all?
>
> Making this change allows test/for_each.cpp to run correctly
Good, thank you. Fixed in the CVS now - please check if it works and report
back.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL include problem with BOOST_PP_ITERATE
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) > / header body > #ifndef BOOST_MPL_LIST_HPP_INCLUDED > #define BOOST_MPL_LIST_HPP_INCLUDED > > > Because I am using BOOST_PP_ITERATE, BOOST_PP_IS_ITERATING is defined, > and problems occur. In general, you shouldn't include any headers _inside file iteration section_ of your header - there is just no point of doing this (and, for "normal" headers, no effect, expect for possible performance degradation), unless you are doing something pretty special. If you move the "boost/mpl/list.hpp" include from the section being iterated to a "static" part of the header, everything should work fine. If it doesn't please post an example of the code that causes troubles for you. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL include problem with BOOST_PP_ITERATE
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 (and have done so > for the moment), but I don't think that I should have to. > > The way I look at it, the fact that MPL uses ITERATE in its header > files is an implementation convenience for MPL, and should not be > visible to the user. You have a point, here. I'll look into the issue tonight. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: MPL include problem with BOOST_PP_ITERATE
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 > precisely because of this type of problem. Even if you efine a > special flag macro to distinguish a certain MPL iteration from some > other iteration, you are still going to have serious problems. > Specifically, you'd have to rewrite all of it to reenter the > file-iteration mechanism in an abstract and relative way, which means > no direct references to specific iteration frames at all. This kind > of thing is the purpose of the "relative" macros, but I cannot > _evaluate_ the filename to iterate over. Therefore, I cannot > abstract the depth. OK, I see, there is no easy way to fix it. Hugo, would the BOOST_PP_ANGLED_INCLUDE() mechanism Paul referred to in another message in this thread help you to implement what you are currently trying to do with BOOST_PP_ITERATE()? If it would, let's pursue that solution, then, since your case _is_ somewhat special and apparently is in conflict with "recommended" usage of file iteration mechanism. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] integral_c on g++2.95.3
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; > #else > typedef integral_c(value + 1)> next; > typedef integral_c(value - 1)> prior; > #endif Fixed now in the CVS. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] mpl::is_sequence< incomplete_type >?
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 work. Let me know if it's important for you, and I'll move it up in my TODO list. Note that the limitation applies only to MSVC 6.5/7.0. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: some more questions on MPL and Borland
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, hopefully things will be restored soon (John?). Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: mpl::is_sequence< incomplete_type >?
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 understand that; but I was specifically interested whether _incomplete types_ are an important case here. If it's more than just a corner-case situation, I'll look into fixing it. > I could just as well tell my users > that they always have to specify an mpl::list containing a single > type instead of a type under MSVC... But 'is_sequence' does work on MSVC 7.0, in general. So, unless passing an incomplete type is a common-place situation, I would recommend just to document the pitfall itself. > P.S. While making my first serious steps with mpl yesterday, I ran > into some weird errors while trying to compile the following with > MSVC 7.0. Could this also be a limitation of my platform? It was. Fixed now in the CVS. But even on conforming compilers, the following line is currently problematic, because of the maximum arity limit on metafunctions that can participate in lambda expressions: typedef boost::mpl::transform< trans_list, boost::mpl::apply< _, Running > >::type handler_list; Since, under the cover, the main 'apply' template has BOOST_MPL_METAFUNCTION_MAX_ARITY + 1 template parameters, it fails to be properly handled by the lambda facility, causing the code to fail. A short-term workaround is to use a numbered 'apply' form instead - in your case, 'apply1'. I'll look into fixing the problem for the upcoming release. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: integral_c on g++2.95.3
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< integral_c >::type' functionality on compilers that don't support partial template specialization. Of course, on a conforming compiler, they don't have to be there. > If our interpretation is correct, next/prior would render the program > ill-formed in some usages of integral_c<> with enums, so, if it is > intended to represent 'integral constant expressions' and not just > 'integral values' I think it should have next/prior removed. That's what I'll do, for the conforming platforms. Thanks for pursuing the issue, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] [mpl] More problems with MSVC 7.0, 8-/
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 4. OK, I see the problem; fixed now in the CVS. But what I was horrified by is the way VC 7.0 masks the errors here. It's the first time I saw something like this (I don't use 7.0 in day-to-day work), and I just hope you didn't spent too much time figuring out what was happenning there. FYI, MSVC 6.5 is much more predictable and easy to work with in this regard, and since, from MPL-centric point of view, the compilers are pretty much at the the same level of standard conformance, for debugging purposes you might consider using 6.5 (if you have one, of course). > > Problem No. 2: mpl::fold produces errors similar to the ones > I had with transform yesterday > In the original file, please comment out expression 1 and uncomment > expression 2 to reproduce. Oh, this one is known - please see http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Effective_MPL , Item 5.7 But actually you don't need to implement your own 'derive' metafunction, MPL already does it for you: #include "boost/mpl/inherit.hpp" #include "boost/mpl/empty_base.hpp" // ... // was: // typedef typename mpl::fold< /* 3 */ //handler_list, empty_type, derive< _1, _2 > >::type type; typedef typename mpl::fold< handler_list, mpl::empty_base, mpl::inherit< _1, _2 > >::type type; or, shorter yet, #include "boost/mpl/inherit_linearly.hpp" // ... typedef typename mpl::inherit_linearly< handler_list , mpl::inherit<_1,_2> >::type type; The same for 'make_list' - the MPL version is called 'as_sequence', please see "boost/mpl/as_sequence.hpp". > > Luckily, I can continue with MSVC7.1 now, so these bugs have > low priority. Nonetheless, they are fixed in the CVS now :). Thanks for the reports, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: mpl::is_sequence< incomplete_type >?
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/listinfo.cgi/boost
RE: [boost] Re: integral_c on g++2.95.3
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 >::type'
> > functionality on compilers that don't support partial template
> > specialization.
>
> However, if we agree that when having autonomous next/prior we will
> only use them to access next/prior< .. >::type and that the user
> *must* specialize them for everything else
Nope, we don't. This should work out-of-box:
struct her_iterator
{
typedef /* unspecified */ next;
};
typedef mpl::next::type t;
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Request for non_copyable.hpp
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 split "utility.hpp" header a long time ago, and there was a general agreement, but it was postponed until the release is out, and I never got to doing it after that - even although Beman posted a reminder about it (http://lists.boost.org/MailArchives/boost/msg18289.php). I'll do it sometime this week. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] MPL's gcc ADL fixes
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 the upcoming release. Thanks for getting back with it! Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] 'optional' - request for extension
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_lock();
};
and you want to write a semantic equivalent to the following
boost::scoped_ptr lock( cond ? new RAII_lock(entity) : 0 );
// ...
expect for the dynamic allocation part. How would you do it?
IMO the following seems only natural:
boost::optional lock( cond, entity );
// ...
The only problem with the above is that currently you cannot write something
like this. It would be nice if we could, IMO.
Thoughts?
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] 'optional' - request for extension
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/locker which unconditionally
> > does its job:
> >
> > struct RAII_lock
> > : boost::noncopyable
> > {
> > RAII_lock(entity& e);
> > ~RAII_lock();
> > };
> >
> > and you want to write a semantic equivalent to the following
> >
> > boost::scoped_ptr lock( cond ? new
RAII_lock(entity) : 0 );
> > // ...
> >
> > expect for the dynamic allocation part. How would you do it?
> >
> > IMO the following seems only natural:
> >
> > boost::optional lock( cond, entity );
> > // ...
> >
> > The only problem with the above is that currently you cannot
> > write something like this. It would be nice if we could, IMO.
> >
> > Thoughts?
>
> * Firstly, this would require optional to be able hold
> non-copy-constructible types, whereas the current requirement
> say "T must be CopyConstructible".
>
> You could drop the "CopyConstructible" requirement if you said that
> boost::optional is only itself CopyConstructible/Assignable/
> Swappable if T is CopyConstructible.
Yep, that's what I would argue for.
> However, this leaves the
> question of how to get the value in there in the first place; the
> answer to which is ...
>
> * Secondly, you would need a templated constructor to allow T
> to be constructed using another type.
Correct, that's what I am hoping to pursue :).
>
> Or you could initialize it with optional, since
> this template constructor does already exist, and already does
> the "right thing".
Hmm, that's an interesting idea. In my case, 'entity' is already
exist, though, (and is noncopyable itself) so it should be
'optional' instead. Still interesting.
But, of course, that still wouldn't work with the current 'optional'
(for one, operators * and -> would have a reference-to-reference
problem). If the CopyConstructible requirement is changed as
outlined the above, it should though, shouldn't it? Fernando?
>
> * Thirdly, you would need a special custom constructor which
> takes a conditional.
Yep. I think it's entirely reasonable. After all, 'optional' does have a
bool inside itself, and the conditional is going to map into that one
directly.
>
> You could get round it like below:
>
> boost::optional optionalEntity;
> if(cond)
> optionalEntity.reset(entity);
>
> // if optionalEntity is not initialized, neither is lock
> // else lock is constructed using the conversion constructor
> boost::optional lock(optionalEntity);
>
> You can do this with the current implementation, since the
> CopyConstructible requirement isn't actually verified with a concept
> check, but you'd have to get the requirement dropped if you were to
> rely on it
I could if not the reference-to-reference problem, but thanks for the
suggestion.
> (which would probably mean implementing templated
> constructor/reset/operator= to avoid _having_ to use an optional
> to initialize your optional)
Yes, I would prefer the use case to be supported with the minimal
verboseness on the user side. Otherwise I might as well write
'optional_lock' with the required semantics - which is an option.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] 'optional' - request for extension
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 pointed out, reset() _needs_
> to use T::T(T const&) in order acquire its own copy of the object;
> but in this case is noncopyable, so the above won't compile.
Yep.
[...]
> > * Secondly, you would need a templated constructor to allow T to be
> > constructed using another type.
> >
> Exactly.
> One possibility would be add additional templated ctor and reset
> that just forward the arguments to T's contructor (optional's interface
> could use a trailing tag to differentiate these).
>
> A problem with this is that the Argument Forwarding problem is burried
> into optional's itself.
I think it's more of a language problem than anything else. I mean, there is
nothing conceptually wrong with allowing 'optional' to support something
like 'opt.construct(a1,...,an)', IMO; only implementation ugliness.
> Another approach would be to create a generic delay-factory
> object and just let optional use it:
>
> Something like:
>
> template
> struct in_place_factory0
> {
> in_place_factory0 ( A0& a0_ ) : a0(a0_) {}
>
> T* operator() ( void* address ) const { return new
> (address) T(a0) ; }
>
> A0& a0 ;
> } ;
>
> template
> in_place_factory0 in_place ( A0& a0 ) { return
> in_place_factory0(a0) ; }
>
> which requires the following changes in optional<>:
>
> template
> class optional
> {
> public :
>
>
>
> template
> explicit optional ( Factory f )
> :
> m_initialized(false)
> {
> construct_inplace(f);
> }
>
> ...
>
> private :
>
> template
> void construct_inplace ( Factory f )
>{
> f(m_storage.address());
> m_initialized = true ;
>}
> } ;
>
> The above would allow something like this:
>
> optional l( in_place(entity) );
>
> If the same in-place idiom is used on reset(), the complete
> solution will look, following optional<>'s way:
>
> boost::optional lock;
> if ( cond )
> lock.reset( in_place(entity) );
>
> What do you think?
Well, it's a little too verbose and un-idiomatic than I would hope for.
May be my original desire to re-use 'optional' in this context was
ill-conceived, and what I really need is a separate 'optional_lock' class -
which, although definitely similar, will be significantly simpler than
'optional' itself. Although
boost::optional lock(cond, entity);
definitely seemed so intuitive and close.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] suggest a "select" in mpl
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 cover all our
use cases, till now.
> "select" is used to apply some function to a specified element in a
> sequence(the case in the FSM example, not each element). So it could
> be used to generate codes like the "if-else/switch" structure. Here's
> an example.
[snip the code]
Hmm, interesting. So, basically, the "select" has the semantics of
"mixed" (half run-time, half compile-time) 'find_if' - it takes
a compile-time sequence and a run-time predicate, and iterates the
former until the predicate is satisfied (or it reaches the end of the
sequence). We can "return" the search result by passing another
function object that will be called when something is found:
// untested!
template< typename T, long N >
struct pred
{
pred(T (&a)[N], T const& value)
: a_(a)
, value_(value)
{
}
template< typename I >
bool operator()(I index) const
{
return this->a_[index] == this->value_;
}
T (&a_)[N];
T const& value_;
};
template< typename T, long N >
T*
find(T (&a)[N], T const& value)
{
// here:
long i = N;
mpl::find_if_< mpl::range_c >(
pred(a, value)
, ll::var(i) = _1
);
return &(a[i]);
}
int main()
{
double X[5] = { 1.0, 2.1, 3.5, 6.6, 5.4 };
std::cout << *find(X, 3.5);
}
Does it make sense to you?
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] tuples::apply
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 main()
{
char const* text = "text";
tuples::apply(f, make_tuple(5, text)); // here
}
For those who knows Python, it's an equivalent of Python's built-in 'apply'
function.
IMO it's one of the fundamental tuple facilities, and I would love to
contribute it to the Boost.Tuple library, if it's welcome. Jaakko?
Aleksey
apply.hpp
Description: Binary data
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: Re: Re: is_class
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're trying to make? > > I have the impression that the type-traits can and should be > improved. I don't have a complete solution for everything at once > and I prefer evolution over revolution. Thus I tried to start by > suggesting a new is_class implementation. I was disappointed to see > only bashing on details instead of a discussion of the "big picture". What is a "big picture" here? Looking at your original posting, it's all seems to be about the details. Anyway, I would understand your frustration if you've proposed a drop-in replacement for the current 'is_class' implementation that passes all the current tests and is better, in at least one way, than what we have now - and it was ignored. But that's not what happened, is it? If you start the discussion by posting an incomplete and large enough amount of code be ignored by most of the skimming readers, and leave it to the library maintainers to figure out what they can take out of it, if anything, there is a huge possibility that it will progress in the way it did in this case. I don't think there is anything wrong with it. If you want a different kind of discussion, try a different approach. E.g. post a drop-in replacement for 'is_class', motivate why it is better, and I am sure John will happily accept it. > The basic point was (IMHO) never answered. That is ...? > I tried to clean up the implementation by providing a closed > implementation of is_class for more compilers. This should decrease > the coupling of all the different parts. I think that this is a > better design than the current one. The example I gave which I > thought might show the local problem was wrong. My fault, granted. > But does it speak against cleaning up the code? No, it doesn't. But, in general, you cannot expect the maintainers to follow through the course of your experiments, however interesting those are. They might sometimes, when they have resources, but if you want the concrete results, try to post the concrete (and, if it's possible, complete) proposals. > > As far as I learned right now, boost is not meant to provide a clean > implementation, instead, it provides a good documentation and an > implementation that "just works". That's just not true. When possible, we do strike for a clean implementation. It's the sorry state of current compilers that often forces one to sacrifice the internal beauty for usefulness in the real world. > But even the documentation confused me several times. is_scalar > doesn't mention enum, is_member_function_pointer is not a secondary > type category, Patches are always welcome! > the mixture of utility functions and a framework and > primary type categories are implemented using secondary type > categories. Even if it works, it is IMHO still bad code. If you have a vision of how to improve it, the best way to change the status quo is to post a proof in the form of working code. HTH, Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost::bind question
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, _2));
> |
> | mycrew.add( ?? 9 10 ?? );
> | mycrew.add( ?? 42 10 ?? );
> | mycrew.add( ?? 29232 10 ?? );
> |
> | // do work
> | mycrew.dowork(); // STILL calls x.f(9, 10), x.f(42,10),
> x.f(29232,10)b
> `
>
>
> Where obviously I have to do something special to package up the
> arguments to the function object that's been created.
>
>
> Is it possible without a huge amount of coding?
I was doing something like it recently, so, sure:
#include "boost/function.hpp"
#include "boost/bind.hpp"
#include "boost/tuple/tuple.hpp"
#include "boost/tuple/apply.hpp"
#include
using namespace boost;
template >
class work_crew {
std::list queue_;
FunctionType engine_;
public:
work_crew(FunctionType const& tocall);
void add(DataType d) { queue_.push_front(d); };
void dowork()
{
typedef typename std::list::iterator iterator_t;
for (iterator_t iter = queue_.begin(); iter != queue_.end(); ++iter)
tuples::apply(this->engine_, *iter); // here
};
};
struct X {
bool f(int a, int b);
};
X x;
int main()
{
work_crew< tuples::tuple, boost::function2 >
mycrew(bind(&X::f, &x, _1, _2));
mycrew.add( tuples::make_tuple(9, 10) );
mycrew.add( tuples::make_tuple(42, 10) );
mycrew.add( tuples::make_tuple(29232, 10) );
// do work
mycrew.dowork(); // STILL calls x.f(9, 10), x.f(42,10), x.f(29232,10)b
}
With a little bit more of coding and Boost.MPL, you can do even better on
work_crew< tuples::tuple, boost::function2 >
mycrew(bind(&X::f, &x, _1, _2));
line:
work_crew< mpl::list > mycrew(bind(&X::f, &x, _1, _2));
but I am not sure if you want to dive into it from the beginning.
The only caveat to the above is that "tuple/apply.hpp" header is not a part
of the Boost yet. Please see
http://www.mail-archive.com/boost@lists.boost.org/msg05246.html for the
source.
We still have a chance to have the facility in 1.30 release, though (it's a
pure extension of Boost.Tuple library) - but I need to hear from Jaakko on
this one.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] boost::bind question
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()
> > {
> >typedef typename std::list::iterator iterator_t;
> >for (iterator_t iter = queue_.begin(); iter !=
> queue_.end(); ++iter)
> > tuples::apply(this->engine_, *iter); // here
> > };
> >};
>
> Question: does the above work even if my work_crew is still the
> vanilla:
>
> work_crew< int, boost::function > vanillaCrew();
>
> or would I need
>
> work_crew< tuples::tuple, boost::function
> > closeToVanillaCrew();
>
Not as I wrote it. It's a relatively easy to achieve, though -
void dowork()
{
this->do_work(is_tuple());
};
void dowork(mpl::false_c)
{
typedef typename std::list::iterator iterator_t;
for (iterator_t iter = queue_.begin(); iter != queue_.end(); ++iter)
this->engine_(*iter);
}
void dowork(mpl::true_c)
{
typedef typename std::list::iterator iterator_t;
for (iterator_t iter = queue_.begin(); iter != queue_.end(); ++iter)
tuples::apply(this->engine_, *iter);
};
... except that you would have to implement 'is_tuple' yourself. Not a big
deal, but definitely an inconvenience; should be in the library.
>
> - I ask b/c of the 'tuples::apply(...)' portion.
> At first glance, it's not clear that
>
>int i;
>tuples::apply(this->engine_, i)
>
> would not work (b/c i is not a tuple).
It wouldn't, as it is. It's an interesting question if it should. IMO a
separate function, let's say 'as_tuple' (analogous to MPL's 'as_sequence')
would be a cleaner solution here,
int i;
tuples::apply(this->engine_, tuples::as_tuple(i)); // OK
tuple ti;
tuples::apply(this->engine_, tuples::as_tuple(ti)); // OK, too
since there are other places there one would like to have this machinery. Of
course, 'tuples::apply' still can do this 'as_tuple' call internally. Right
now I don't have a strong opinion whether it should or not.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: More metaprogramming problems with MSVC7.0
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:
>
> d:\Data\StopWatch\StopWatch.cpp(58) : error C2516:
> 'state_base_type::type' : is not
a
> legal base class
>
> According to the docs this error is reported when you try to inherit from
> built-in types like int.
> If you then remove the 3 first characters of the lines marked with // ***
> here ***, the program compiles and you can see in the debugger that the
> result returned by the metafunction state_base_type is quite a legal base
> class (see type of pWhatever).
>
> Has anyone else ever encountered similar problems with either 7.0 or 6.5?
Yep, it's a known bug called "early template instantiation" (ETI). It's
briefly described here -
http://lists.boost.org/MailArchives/boost/msg39915.php.
> Are there any workarounds?
Sure. In your case, it would be as simple as this:
#include
...
template< class Derived,
class Context,
class Transitions = empty_list,
class InnerInitial = empty_list >
class simple_state : public mpl::aux::msvc_eti_base< typename
state_base_type<
//
Derived, Context, Transitions, InnerInitial >::type >::type {};
You will need the latest CVS for that, though.
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: partial<> proposal
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: More metaprogramming problems with MSVC7.0
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 ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: Re: Re: partial<> proposal
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) 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 > > ___ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
