So it sounds to me like the :blat is *not* part of the extension. It
sounds like the NT file name is made up of three parts: name, extension
and "stream".
In which case I think it is fine to have functions extension() and
change_extension() - they just should not report or modify the stream par
Mike Conley <[EMAIL PROTECTED]> writes:
> David Abrahams <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
>> Further, suppose I write a metafunction:
>>
>> template
>> struct is_const_and_int_convertible
>>: and_<
>> is_const
>>
David Abrahams <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> Further, suppose I write a metafunction:
>
> template
> struct is_const_and_int_convertible
>: and_<
> is_const
>, is_convertible
> >
> {};
>
"Justin M. Lewis" <[EMAIL PROTECTED]> writes:
> I don't think it's reasonable to compare how things are done in the standard
> library to how things are done in actual code.
I didn't make that comparison. Most of my code is not in the standard
library.
> The standard library is STANDARD, we a
David Abrahams wrote:
> "Edward Diener" <[EMAIL PROTECTED]> writes:
>
>>> I browsed the article (I confess to not having read everything, so
>>> please correct any misapprehensions). My sense is that the
>>> technique
>>> is oriented towards detecting programmer errors and responding via
>>> an ex
Mike Conley <[EMAIL PROTECTED]> writes:
> David Abrahams <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
>> This one is sticky.
>>
>> class Y : X { true_type f() { return is_convertible::type();
>> } }; false_type x = is_convertible::type();
>>
>
> I'm not sure I see the pr
> Can you show me a better example? This is not a challenge. Really,
> if this ENFORCE idea is a useful one I want to understand it.
I extensively using assert-like production time enforcements to validate
user input/order of actions. I like the idea presented in article. Though I
am curently us
I don't think it's reasonable to compare how things are done in the standard
library to how things are done in actual code. The standard library is
STANDARD, we all KNOW what it does, and how it behaves, and it's documented
all over the place.
My code on the other hand, it's not standard, you hav
David Abrahams <[EMAIL PROTECTED]> wrote in
news:[EMAIL PROTECTED]:
> This one is sticky.
>
> class Y : X { true_type f() { return is_convertible::type();
> } }; false_type x = is_convertible::type();
>
I'm not sure I see the problem here. If is_convertible is a built in
compile
>From: "David Abrahams" <[EMAIL PROTECTED]>
> "Edward Diener" <[EMAIL PROTECTED]> writes:
>
> >> I browsed the article (I confess to not having read everything, so
> >> please correct any misapprehensions). My sense is that the technique
> >> is oriented towards detecting programmer errors and res
"Edward Diener" <[EMAIL PROTECTED]> writes:
>> I browsed the article (I confess to not having read everything, so
>> please correct any misapprehensions). My sense is that the technique
>> is oriented towards detecting programmer errors and responding via an
>> exception.
>
> I don't think ENFORC
"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
>> I browsed the article (I confess to not having read everything, so
>> please correct any misapprehensions). My sense is that the technique
>> is oriented towards detecting programmer errors and responding via an
>> exception.
>
> No.
Please co
David Abrahams wrote:
> "Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
>
>> By the way, I believe what would be more interesting for Boost is the
>> recent article (http://www.cuj.com/experts/2106/alexandr.htm),
>> written by Petru Marginean and myself. (Warning - the article has
>> recently bee
"David Abrahams" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> "Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
>
> > By the way, I believe what would be more interesting for Boost is the
> > recent article (http://www.cuj.com/experts/2106/alexandr.htm), written
by
> > Petru Margin
Reece Dunn wrote:
> > In the file:
> >spirit/wave/wave/cpplexer/slex/cpp_slex_lexer.hpp
> > I have noticed two points that may be bugs (but have not verified
> > through compilation.)
> >
> > <1> line 335:
> >
> > [332] // C++ only token definitions
> > [333] template
> > [334] typename le
"Justin M. Lewis" <[EMAIL PROTECTED]> writes:
> You're missing the point. Personally I see the need for out and
> in/out params. While some of you may not like them, I use them, as
> do others. The question then becomes, when reading my code, would
> you rather see
>
> f(x,y,z);
> or
> f(out(x)
Mike Conley <[EMAIL PROTECTED]> writes:
> Actually, there is another advantage, which (I think) is at least as
> important as the ones you cite. Namely, it is possible to define a built
> in operator such that is_convertible returns false for
>
> class X{};
> class Y : X {};
This one is s
"Andrei Alexandrescu" <[EMAIL PROTECTED]> writes:
> By the way, I believe what would be more interesting for Boost is the
> recent article (http://www.cuj.com/experts/2106/alexandr.htm), written by
> Petru Marginean and myself. (Warning - the article has recently been
> updated.)
>
> We have good
18 matches
Mail list logo
