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
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,
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'
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
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
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
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
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
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.
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
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_
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
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
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
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
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
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
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),
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
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
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
Drazen DOTLIC [EMAIL PROTECTED] writes:
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
,
22 matches
Mail list logo
