[boost] Re: mpl/loki
On Monday, July 14, 2003, at 05:18 AM, John wrote:
class nat {nat();};
How about not_a_type?
It's a little more to type, but looks much better (IMHO).
And shouldn't it be :
struct not_a_type {};
As Peter pointed out, such a class can have several uses. In some of
the contexts I've used it, I wanted to make sure that client code could
not construct an instance. Perhaps such a constraint would not be
appropriate in all use cases.
-Howard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
Peter Dimov wrote: David Abrahams wrote: But that's only true as long as void_ is being used for internal purposes. Once you "give it up to users" as you suggest, it loses that correspondence, and we'll have some other internal name which has that correspondence to void. Maybe the problems are caused by overloading void_. I haven't looked at MPL recently, but as a general observation I have identified at least three uses of a void_-like entity. 1. A type parameter used to emulate a variable argument template. I use '_missing' for this purpose (leading underscore for implementation details.) template struct F; 2. An optional parameter that, when not supplied, has a reasonable (dependent) default. I use 'unspecified'. template ... bind(F f); 3. A type that is guaranteed to be distinct from all other useful types. 'nil' is what Lisp calls it; void_ is fine, too. From my experience it's a bad idea to have one general, user-documented type that is used as a default for variable argument templates. The problem is that when a user knows the type's name and thus the type (be it called void_, nan or whatever), he might also expect to be able to work with it like with any other type. If forming a container-type (mpl::vector, ...), it should be possible to inject the type like all other types because otherwise, well, it wouldn't be a type and the user will be surprised no matter whether you document it or not. I therefore think that each library should have an internal type that the user doesn't know about and that might then be put it into a namespace detail or something and called depending on it's semantics. Makes it easier to understand the type's role inside the library, thus increases readability and maintainability and improved orthogonality of different libraries. Also, I wonder what reasons are there to create a general type for this purpose. Avoiding code duplication doesn't sound reasonable as we only replace a single line per such class with an include. Some libraries might even need a declaration-only-type, other might needs an (empty) implementation. So, what benefit would a general type give to us? Regards, Daniel -- Daniel Frey aixigo AG - financial training, research and technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: [EMAIL PROTECTED], web: http://www.aixigo.de ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
>> 3. A type that is guaranteed to be distinct from all other useful
>> types.
>> 'nil' is what Lisp calls it; void_ is fine, too.
>
>Another possible spelling for this animal is:
>
>class nat {nat();};
>
>Inspired from nan. In this case means Not A Type. It is nice and
>short which comes in handy for when there are a lot of template
>parameters to default. It is easily pronounceable, and won't be
>confused with any other type when discussed verbally.
How about not_a_type?
It's a little more to type, but looks much better (IMHO).
And shouldn't it be :
struct not_a_type {};
?
Best,
John
>
>-Howard
>
>___
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
"Peter Dimov" <[EMAIL PROTECTED]> writes: > Maybe the problems are caused by overloading void_. Clearly. > I haven't looked at MPL recently, but as a general observation I > have identified at least three uses of a void_-like entity. > > 1. A type parameter used to emulate a variable argument template. I use > '_missing' for this purpose (leading underscore for implementation details.) > > template struct F; I think this is the one that has the special correspondence with the real "void", but Aleksey wanted to change its name. > 2. An optional parameter that, when not supplied, has a reasonable > (dependent) default. I use 'unspecified'. > > template ... bind(F f); I use 'not_specified' to distinguish it from the alarming connotations of 'unspecified' behavior. > > 3. A type that is guaranteed to be distinct from all other useful types. > 'nil' is what Lisp calls it; void_ is fine, too. It depends whether it has special meaning in the library so that it can't be manipulated as all other types are. If so, you'd better not use it this way. Of course, in the case that sparked this conversation we could make our specialization on void_ behave properly, but I'm not sure if that's true in general. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
Howard Hinnant <[EMAIL PROTECTED]> writes:
| On Sunday, July 13, 2003, at 12:17 PM, Gabriel Dos Reis wrote:
|
| > Howard Hinnant <[EMAIL PROTECTED]> writes:
| >
| > | Another possible spelling for this animal is:
| > |
| > | class nat {nat();};
| > |
| > | Inspired from nan. In this case means Not A Type.
| >
| > Ahem, a class is a type, no matter how you name it.
|
| Really, I didn't know that! :-)
there was a missing smiley -- sorry.
| And a nan is still a floating point number.
No, it is not. That is why it is called "Not a Number" :-)
It is just a continuation value, i.e. a special data which is not a
floating point number.
| It just has a special bit
| pattern that alters the arithmetic rules a bit.
|
| > | It is nice and
| > | short which comes in handy for when there are a lot of template
| > | parameters to default. It is easily pronounceable, and won't be
| > | confused with any other type when discussed verbally.
| >
| > Really? Without reading the rest of your message, I thought it was a
| > short for "natural number". A matter of background I guess.
|
| I'll go back to the drawing board.
I love drawings :-D
-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
On Sunday, July 13, 2003, at 12:17 PM, Gabriel Dos Reis wrote:
Howard Hinnant <[EMAIL PROTECTED]> writes:
| Another possible spelling for this animal is:
|
| class nat {nat();};
|
| Inspired from nan. In this case means Not A Type.
Ahem, a class is a type, no matter how you name it.
Really, I didn't know that! :-)
And a nan is still a floating point number. It just has a special bit
pattern that alters the arithmetic rules a bit.
| It is nice and
| short which comes in handy for when there are a lot of template
| parameters to default. It is easily pronounceable, and won't be
| confused with any other type when discussed verbally.
Really? Without reading the rest of your message, I thought it was a
short for "natural number". A matter of background I guess.
I'll go back to the drawing board. Of all the people that I thought
might appreciate the analogy, you were at the top of my list. :-)
-Howard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
Howard Hinnant <[EMAIL PROTECTED]> writes:
| Another possible spelling for this animal is:
|
| class nat {nat();};
|
| Inspired from nan. In this case means Not A Type.
Ahem, a class is a type, no matter how you name it.
| It is nice and
| short which comes in handy for when there are a lot of template
| parameters to default. It is easily pronounceable, and won't be
| confused with any other type when discussed verbally.
Really? Without reading the rest of your message, I thought it was a
short for "natural number". A matter of background I guess.
-- Gaby
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
Howard Hinnant wrote:
> On Sunday, July 13, 2003, at 08:49 AM, Peter Dimov wrote:
>
>> Maybe the problems are caused by overloading void_. I haven't looked
>> at MPL
>> recently, but as a general observation I have identified at least
>> three uses
>> of a void_-like entity.
>>
>> 1. A type parameter used to emulate a variable argument template. I
>> use '_missing' for this purpose (leading underscore for
>> implementation details.)
>>
>> template struct F;
>>
>> 2. An optional parameter that, when not supplied, has a reasonable
>> (dependent) default. I use 'unspecified'.
>>
>> template ... bind(F f);
>>
>> 3. A type that is guaranteed to be distinct from all other useful
>> types.
>> 'nil' is what Lisp calls it; void_ is fine, too.
>
> Another possible spelling for this animal is:
>
> class nat {nat();};
>
> Inspired from nan. In this case means Not A Type. It is nice and
> short which comes in handy for when there are a lot of template
> parameters to default.
Yep. But I don't think defaulting to 'nat' is correct; defaults in this case
are 'missing'.
You can make a list of nat's, and this is not an empty list. IOW with:
template struct list;
you can't tell the difference between list<>, list, list...
In Lisp this would correspond to () (which is also nil there), (nil), (nil
nil), ...
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
On Sunday, July 13, 2003, at 08:49 AM, Peter Dimov wrote:
Maybe the problems are caused by overloading void_. I haven't looked
at MPL
recently, but as a general observation I have identified at least
three uses
of a void_-like entity.
1. A type parameter used to emulate a variable argument template. I use
'_missing' for this purpose (leading underscore for implementation
details.)
template struct F;
2. An optional parameter that, when not supplied, has a reasonable
(dependent) default. I use 'unspecified'.
template ... bind(F f);
3. A type that is guaranteed to be distinct from all other useful
types.
'nil' is what Lisp calls it; void_ is fine, too.
Another possible spelling for this animal is:
class nat {nat();};
Inspired from nan. In this case means Not A Type. It is nice and
short which comes in handy for when there are a lot of template
parameters to default. It is easily pronounceable, and won't be
confused with any other type when discussed verbally.
-Howard
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
David Abrahams wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > >> David Abrahams wrote: >>> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: >>> IMO we should just stop using 'void_' for internal purposes and give it up to users :). >>> >>> I am still unsure about 'void_' being better than 'nil' or >>> 'null' Users already have a type, 'void', which means void. >> >> ... in conventional run-time programs. Unfortunately, 'void' is not >> special for metaprograms, many of which have a need to routinely >> manipulate it along with all other built-in types. 'mpl::void_' >> addresses this issue. >> >>> There's no correspondence between void_ and void the way there is >>> between bool_ and bool. >> >> 'void_' in MPL plays a role very similar to a role of 'void' in the >> core language. So, conceptually, there is a correspondence. > > But that's only true as long as void_ is being used for internal > purposes. Once you "give it up to users" as you suggest, it loses > that correspondence, and we'll have some other internal name which > has that correspondence to void. Maybe the problems are caused by overloading void_. I haven't looked at MPL recently, but as a general observation I have identified at least three uses of a void_-like entity. 1. A type parameter used to emulate a variable argument template. I use '_missing' for this purpose (leading underscore for implementation details.) template struct F; 2. An optional parameter that, when not supplied, has a reasonable (dependent) default. I use 'unspecified'. template ... bind(F f); 3. A type that is guaranteed to be distinct from all other useful types. 'nil' is what Lisp calls it; void_ is fine, too. HTH :-) ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
Aleksey Gurtovoy <[EMAIL PROTECTED]> wrote: > David Abrahams wrote: >> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: >> >>> IMO we should just stop using 'void_' for internal purposes and give it >>> up to users :). >> >> I am still unsure about 'void_' being better than 'nil' or >> 'null' Users already have a type, 'void', which means void. > > ... in conventional run-time programs. Unfortunately, 'void' is not special > for metaprograms, many of which have a need to routinely manipulate it along > with all other built-in types. 'mpl::void_' addresses this issue. > >> There's no correspondence between void_ and void the way there is >> between bool_ and bool. > > 'void_' in MPL plays a role very similar to a role of 'void' in the core > language. So, conceptually, there is a correspondence. Personally, I > appreciate the analogy, dislike 'null'/'nil'/etc. for the lack of such, and > would like to keep the name. I agree. I used to use nil_t but since I bumped into MPL's void_, I wouldn't want to use nil_t anymore. void_ simply makes sense. My dictionary defines void as: 1) The state of nonexistence 2) An empty area or space, and nul/null as: 1) Nothing 2) A quantity of no importance. IMO, the definition of void reflects mpl::void_ a lot more. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
David Abrahams <[EMAIL PROTECTED]> wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > >> IMO we should just stop using 'void_' for internal purposes and give it >> up to users :). > > I am still unsure about 'void_' being better than 'nil' or > 'null' Users already have a type, 'void', which means void. > There's no correspondence between void_ and void the way there is > between bool_ and bool. IMO, there is. For example, the new TR1 tuples implementation (it's feature complete and in the sandbox now BTW) uses void_ as it would a void tuple element. nil_t or something would do, but we'll need to convert this to void_ simply because MPL expects void_. Admittedly, the void_ is not part of its public API and the use should not care about it, *but* you have to consider that the tuple lib *IS* a client of MPL. As such, it needs the mpl_void_ as a *public* API. Another good example is Phoenix/LL. We are using void_ much as a void argument to something. Here now, there is a direct mapping to our C++ void. Again, the void_ is not part of Phoenix's public API but then again, it *is* a client of MPL. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: >> >> > IMO we should just stop using 'void_' for internal purposes and give it >> > up to users :). >> >> I am still unsure about 'void_' being better than 'nil' or >> 'null' Users already have a type, 'void', which means void. > > ... in conventional run-time programs. Unfortunately, 'void' is not > special for metaprograms, many of which have a need to routinely > manipulate it along with all other built-in types. 'mpl::void_' > addresses this issue. > >> There's no correspondence between void_ and void the way there is >> between bool_ and bool. > > 'void_' in MPL plays a role very similar to a role of 'void' in the > core language. So, conceptually, there is a correspondence. But that's only true as long as void_ is being used for internal purposes. Once you "give it up to users" as you suggest, it loses that correspondence, and we'll have some other internal name which has that correspondence to void. > Personally, I appreciate the analogy, dislike 'null'/'nil'/etc. for > the lack of such, and would like to keep the name. Makes little sense to me, especially after the "give up", but maybe that's just me. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
David Abrahams wrote: > Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > > > IMO we should just stop using 'void_' for internal purposes and give it > > up to users :). > > I am still unsure about 'void_' being better than 'nil' or > 'null' Users already have a type, 'void', which means void. ... in conventional run-time programs. Unfortunately, 'void' is not special for metaprograms, many of which have a need to routinely manipulate it along with all other built-in types. 'mpl::void_' addresses this issue. > There's no correspondence between void_ and void the way there is > between bool_ and bool. 'void_' in MPL plays a role very similar to a role of 'void' in the core language. So, conceptually, there is a correspondence. Personally, I appreciate the analogy, dislike 'null'/'nil'/etc. for the lack of such, and would like to keep the name. Aleksey ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
Aleksey Gurtovoy <[EMAIL PROTECTED]> writes: > IMO we should just stop using 'void_' for internal purposes and give it > up to users :). I am still unsure about 'void_' being better than 'nil' or 'null' Users already have a type, 'void', which means void. There's no correspondence between void_ and void the way there is between bool_ and bool. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: mpl/loki
David Abrahams wrote:
> That's because void_ is for MPL internal use only; it's not a type
> you should manipulate
While I agree that _some_ user needs for a special unique type a
better handled by introducing a new one (otherwise you'll get yourself
into situation like we have right now, only in your own code :), I don't
agree that we should deny the occasional need for a special type in
many simpler cases - like Drazen's one. It would just make user life
unnecessary more complicated than it should be.
Besides, 'void_' _is_ a public type:
begin::type === void_
order::type === void_
and a couple of others I don't remember off hand :).
> (I think Aleksey doesn't believe me, but I'm
> about to prove it... ).
I don't _agree_ :).
>
> Observe the definition of identity (comments added for exposition
> purposes):
>
> template
> struct identity
> {
> typedef T type;
> };
>
>
> // identity is a metafunction class which makes it efficient
> // to pass mpl::identity<> where a lambda expr/metafunction class is
> // expected.
> template<>
> struct identity< void_ >
> {
> template<
> class T1, class T2 =void_, class T3 =void_, class T4 =void_, class
T5 =void_
> >
> struct apply
> : identity< T1 >
> {};
> };
>
> // specialization of lambda > for efficiency.
> template<>
> struct lambda< identity< void_ > >
> {
> typedef identity< void_ > type;
> };
IMO we should just stop using 'void_' for internal purposes and give it
up to users :).
Aleksey
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: mpl/loki
> That's because void_ is for MPL internal use only; it's not a type
> you should manipulate (I think Aleksey doesn't believe me, but I'm
> about to prove it... ).
It's quite all right - my code does not use that "other" type, I just
need a type. I could have just as well used my own "class null_type
{};", but mpl's void_ looked like good enough choice. Anyway, I want to
use "null" or "void" in the name of the type just for readability of my
code.
> Observe the definition of identity (comments added for exposition
> purposes):
[snip]
Well, what can I say - this is not visible from the header, as many
things are wrapped in macros, so reading the code is much harder. Now
that you've shown it the way it really is, I can see the problem. But
since I didn't need void_ in the first place, all is good.
Thanks,
Drazen
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
"Drazen DOTLIC" <[EMAIL PROTECTED]> writes:
> Blatant copy from your mail plus small typo (size_t_c to size_t only)
> corrected:
>
> template
> struct type_at_non_strict
> : mpl::apply_if<
> mpl::greater,N>
> , mpl::at
> , mpl::identity
> >
> {};
>
> template
> struct type_at_non_strict_c
> : type_at_non_strict >
> {};
>
> If I do not replace identity with void_ only, I get the following (nice
> VC71 elaborate error report):
That's because void_ is for MPL internal use only; it's not a type
you should manipulate (I think Aleksey doesn't believe me, but I'm
about to prove it... ).
Observe the definition of identity (comments added for exposition
purposes):
template
struct identity
{
typedef T type;
};
// identity is a metafunction class which makes it efficient
// to pass mpl::identity<> where a lambda expr/metafunction class is
// expected.
template<>
struct identity< void_ >
{
template<
class T1, class T2 =void_, class T3 =void_, class T4 =void_, class T5 =void_
>
struct apply
: identity< T1 >
{};
};
// specialization of lambda > for efficiency.
template<>
struct lambda< identity< void_ > >
{
typedef identity< void_ > type;
};
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: mpl/loki
> > Btw, VC7.1 does not seem to like identity in this (and
> David's) scenario
> > - it complains that it does not have inner typedef to type,
> even though
> > it does.
>
> Can you please post a small example which fails?
Well, your own :) from few hours ago, used something like this (btw, I
am using CVS snapshot as of, say, 2 weeks ago):
template
class Useful
{
public:
typedef typename type_at_non_strict_c::type Param1;
typedef typename type_at_non_strict_c::type Param2;
typedef typename type_at_non_strict_c::type Param3;
}
Blatant copy from your mail plus small typo (size_t_c to size_t only)
corrected:
template
struct type_at_non_strict
: mpl::apply_if<
mpl::greater,N>
, mpl::at
, mpl::identity
>
{};
template
struct type_at_non_strict_c
: type_at_non_strict >
{};
If I do not replace identity with void_ only, I get the following (nice
VC71 elaborate error report):
c:\projects\tools\boost\boost\mpl\apply_if.hpp(39) : error C2039: 'type'
: is not a member of 'boost::mpl::identity'
c:\projects\tools\boost\boost\mpl\identity.hpp(44) : see declaration of
'boost::mpl::identity'
c:\projects\mylib\MetaProgramming.h(26) : see reference to class
template instantiation 'boost::mpl::apply_if' being compiled
with
[
C=boost::mpl::greater>,boost::
mpl::size_t<1>>,
F1=boost::mpl::at,boost::mpl::size_t<1>>,
F2=boost::mpl::identity
]
c:\projects\mylib\MetaProgramming.h(34) : see reference to class
template instantiation 'type_at_non_strict' being
compiled
with
[
TypeContainer=boost::mpl::vector,
N=boost::mpl::size_t<1>
]
c:\projects\mylib\Useful.h(37) : see reference to class template
instantiation 'type_at_non_strict_c' being compiled
with
[
TypeContainer=boost::mpl::vector,
N=1
]
c:\projects\mylib\Used.h(45) : see reference to class template
instantiation 'Useful' being compiled
with
[
Result=bool,
TypeVector=boost::mpl::vector
]
I tried to replace company/project specific names with generic ones,
hope I did not ruin the example.
Drazen
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
"Drazen DOTLIC" <[EMAIL PROTECTED]> writes: >> Yes, but leor's package has been much improved and provides things >> VC7.1 does not. See http://www.bdsoft.com/dist/gccmeta-demo.txt > > I don't know if you've seen VC7.1 error reports Of course I have. I wouldn't say that STLFilt improves on it if I hadn't seen it. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
"Drazen DOTLIC" <[EMAIL PROTECTED]> writes: > > Btw, VC7.1 does not seem to like identity in this (and David's) scenario > - it complains that it does not have inner typedef to type, even though > it does. Can you please post a small example which fails? Thanks, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: mpl/loki
> Yes, but leor's package has been much improved and provides things > VC7.1 does not. See http://www.bdsoft.com/dist/gccmeta-demo.txt I don't know if you've seen VC7.1 error reports, but they look almost exactly like that example... Something like this: boost\mpl\size.hpp(36) : error C2039: 'type' : is not a member of 'boost::mpl::size_traits::algorithm' with [ Tag=boost::mpl::aux::sequence_tag_impl::result2_::typ e ] and [ Sequence=void ] OneOfMyHeaders.h(34) : see reference to class template instantiation 'boost::mpl::size' being compiled with [ Sequence=void ] AnotherOneOfMyHeaders.h(53) : see reference to class template instantiation 'Caller' being compiled with [ Result=std::wstring, TypeVector=void ] This is actually artificial example, when I don't do deliberate errors, they are much more complicated :) and compiler is VERY elaborate. Drazen ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
"Drazen DOTLIC" <[EMAIL PROTECTED]> writes: >> Might I suggest you get ahold of Leor Zolman's latest STLFilt package >> (www.bdsoft.com)? It contains some great features for formatting >> nested templates so that they are readable. > > Thanks, I knew about Leor's package and used it in the "old" days > (VC6), but since I switched to VC7.1, reading errors in SТL code > became MUCH easier. Yes, but leor's package has been much improved and provides things VC7.1 does not. See http://www.bdsoft.com/dist/gccmeta-demo.txt -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] Re: mpl/loki
> Just a note: Loki (generic programming applied to design patterns) and > MPL (C++ template metaprogramming) preally have a different focus; you > may yet find some Loki components that are useful to you. That's possible, but hasn't happened up to now. Actually, I had to replace loki with several of the boost libraries, not only mpl, but the sum of these seems to be enough :) > Uh, formatting, please! Uh, sorry, I didn't know it matters to you so much. > You have two confusion is about the way template instantiation > works. Whenever you write something of the form: > > template_name< ... >::nested_name > > The template is instantiated. Damn :), I need to brush up on my template skills. [solution for my problem, snipped] Thanks for the solution, it has given me more insight into ways in which mpl can be used. > Might I suggest you get ahold of Leor Zolman's latest STLFilt package > (www.bdsoft.com)? It contains some great features for formatting > nested templates so that they are readable. Thanks, I knew about Leor's package and used it in the "old" days (VC6), but since I switched to VC7.1, reading errors in SТL code became MUCH easier. Thanks again for the help, Drazen ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: mpl/loki
"Drazen DOTLIC" <[EMAIL PROTECTED]> writes:
> Hello,
>
> I've recently discovered that mpl provides all the functionality I was
> previously using from loki, so I decided to switch.
Just a note: Loki (generic programming applied to design patterns) and
MPL (C++ template metaprogramming) preally have a different focus; you
may yet find some Loki components that are useful to you.
> There is one small thing driving me crazy, and I was wondering if I
> missed something... I was using loki's TypeAtNonStrict "algorithm"
> to give me type from type list at a specified position, or NullType
> (loki's internal "null" class) if not found. Now, I need the same
> for mpl:vector, and I tried the following 'naïve' approach:
Uh, formatting, please!
> [TypeVector is boost::mpl::vector] enum { numParams =
> boost::mpl::size::type::value }; typedef typename
> boost::mpl::if_c<(numParams > 2), typename
> boost::mpl::at_c::type, boost::mpl::void_>::type
> Param1;
[TypeVector is boost::mpl::vector]
enum {
numParams = boost::mpl::size::type::value
};
typedef typename
boost::mpl::if_c<
(numParams > 2)
, typename boost::mpl::at_c::type
, boost::mpl::void_
>::type Param1;
> I was expecting to get Param1 to be boost::mpl::void_, but to my great
> surprise, my compiler (VC7.1) decided to fully evaluate "then" branch
> of if_c as well, even though the expression numParams > 2 was false,
> and failed.
You have two confusion is about the way template instantiation
works. Whenever you write something of the form:
template_name< ... >::nested_name
The template is instantiated.
> What would be the "right" way to express my intention?
template
struct type_at_non_strict
: mpl::apply_if<
mpl::greater,N>
, mpl::at
, mpl::identity
>
{};
template
struct type_at_non_strict_c
: type_at_non_strict >
{};
> Btw, I would like to congratulate authors of mpl on the job well
> done, I am most impressed not only with the features that mpl
> provides but also with the errors I get when something goes wrong -
> they are far more readable than most of the STL errors I am used to
> seeing.
Cool!
Might I suggest you get ahold of Leor Zolman's latest STLFilt package
(www.bdsoft.com)? It contains some great features for formatting
nested templates so that they are readable.
HTH,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com
___
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
