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.) templateclass A1 = _missing, class A2 = _missing, ... struct F; 2. An optional parameter that, when not supplied, has a reasonable (dependent) default. I use 'unspecified'. templateclass R = unspecified, class F ... 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
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.)
templateclass A1 = _missing, class A2 = _missing, ... struct F;
2. An optional parameter that, when not supplied, has a reasonable
(dependent) default. I use 'unspecified'.
templateclass R = unspecified, class F ... 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
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.)
templateclass A1 = _missing, class A2 = _missing, ... struct F;
2. An optional parameter that, when not supplied, has a reasonable
(dependent) default. I use 'unspecified'.
templateclass R = unspecified, class F ... 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:
templateclass A1 = nat, class A2 = nat, ... struct list;
you can't tell the difference between list, listnat, listnat, nat...
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
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
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:
| 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
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:
beginnon-sequence-type::type === void_
orderSet,non-existing-key::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... wink).
I don't _agree_ :).
Observe the definition of identity (comments added for exposition
purposes):
templatetypename T = void_
struct identity
{
typedef T type;
};
// identityvoid_ 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 lambdaidentity 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
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
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... wink).
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
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
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 SL code became MUCH easier. Thanks again for the help, Drazen ___ 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):
templatetypename Result, TypeVector
class Useful
{
public:
typedef typename type_at_non_strict_cTypeVector, 0::type Param1;
typedef typename type_at_non_strict_cTypeVector, 1::type Param2;
typedef typename type_at_non_strict_cTypeVector, 2::type Param3;
}
Blatant copy from your mail plus small typo (size_t_c to size_t only)
corrected:
template class S, class N
struct type_at_non_strict
: mpl::apply_if
mpl::greatermpl::sizeS,N
, mpl::atS,N
, mpl::identitympl::void_
{};
template class S, std::size_t N
struct type_at_non_strict_c
: type_at_non_strictS, mpl::size_tN
{};
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::identityboost::mpl::void_'
c:\projects\tools\boost\boost\mpl\identity.hpp(44) : see declaration of
'boost::mpl::identityboost::mpl::void_'
c:\projects\mylib\MetaProgramming.h(26) : see reference to class
template instantiation 'boost::mpl::apply_ifC,F1,F2' being compiled
with
[
C=boost::mpl::greaterboost::mpl::sizeboost::mpl::vectorbool,boost::
mpl::size_t1,
F1=boost::mpl::atboost::mpl::vectorbool,boost::mpl::size_t1,
F2=boost::mpl::identityboost::mpl::void_
]
c:\projects\mylib\MetaProgramming.h(34) : see reference to class
template instantiation 'type_at_non_strictTypeContainer,N' being
compiled
with
[
TypeContainer=boost::mpl::vectorbool,
N=boost::mpl::size_t1
]
c:\projects\mylib\Useful.h(37) : see reference to class template
instantiation 'type_at_non_strict_cTypeContainer,N' being compiled
with
[
TypeContainer=boost::mpl::vectorbool,
N=1
]
c:\projects\mylib\Used.h(45) : see reference to class template
instantiation 'UsefulResult,TypeVector' being compiled
with
[
Result=bool,
TypeVector=boost::mpl::vectorbool
]
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
