Chris McClelland wrote:
>
> I understand your concern, Pete.
>
> I think the justification for support of explicit casts is partly
> exactly the same as that for explicit construction, but also, since
> explicit construction is already part of the language, symmetry
> arguments provide further justification.

But that's a false analogy. A single argument constructor does two
distinct things: it creates objects (in the same way as a multi-argument
constructor) and it converts values. If you don't want both, you use
explicit to eliminate the latter. The sole reason for having a
conversion operator is to convert values. Explicit conversion operators
are simply a mechanism for requiring casts.

>
> In a language as large and complex as C++, it helps understandability
> if the feature set is symmetric - having features which are included
> in one context and not in another (for no good reason) is just one
> more syntactic rule to learn about the language. Add to that the
> ever-increasing importance of templates and generic programming, and
> symmetry becomes not only desirable, but actually vital - the addition
> (to ISO14882) of default constructors for fundamental types is a case
> in point.
>

A couple of people have mentioned templates as a reason for having
explicit conversion operators, but so far I haven't seen anyone explain
what this means. How do templates benefit from someone being able to say
"if you want this conversion you must write a cast"?

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3C3F961A.AFDD9708@acm.org>, Pete Becker <petebecker@acm.org>
writes
>A couple of people have mentioned templates as a reason for having
>explicit conversion operators, but so far I haven't seen anyone explain
>what this means. How do templates benefit from someone being able to say
>"if you want this conversion you must write a cast"?

I think you have it the wrong way round. There are times where we need
conversion (via conversion operators) for templates. Conversion
functions do not cut it because there is no uniform naming convention
for them. OTOH I do not want to allow the compiler to use my conversion
operator elsewhere for all the many reasons that we know that conversion
operators are often poor design.


--
Francis Glassborow
The Seasons best wishes to you and yours. May 2002 be better for all of us than
2001 was for some.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> writes:

> A couple of people have mentioned templates as a reason for having
> explicit conversion operators, but so far I haven't seen anyone explain
> what this means. How do templates benefit from someone being able to say
> "if you want this conversion you must write a cast"?

One motivation is writing "smart pointer" classes, e.g. the nested
pointer type for a user-defined allocator.

There are pairs of pointer types T1 and T2 with the property that
(1) A value of type T1 can be converted to T2 with static_cast; and
(2) There is no automatic conversion from T1 to T2.

I'm unaware of any way to achieve this behavior for user-defined
types.  That's one of the reasons that, as the quip goes, "they may be
smart, but they're not pointers".


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
>
> In article <3C3F961A.AFDD9708@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >A couple of people have mentioned templates as a reason for having
> >explicit conversion operators, but so far I haven't seen anyone explain
> >what this means. How do templates benefit from someone being able to say
> >"if you want this conversion you must write a cast"?
>
> I think you have it the wrong way round. There are times where we need
> conversion (via conversion operators) for templates. Conversion
> functions do not cut it because there is no uniform naming convention
> for them. OTOH I do not want to allow the compiler to use my conversion
> operator elsewhere for all the many reasons that we know that conversion
> operators are often poor design.
>

So you the solution is a construct that requires use of a cast, despite
the many reasons that we know that code that requires casts are often
poor design.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Matthew Austern wrote:
>
> Pete Becker <petebecker@acm.org> writes:
>
> > A couple of people have mentioned templates as a reason for having
> > explicit conversion operators, but so far I haven't seen anyone explain
> > what this means. How do templates benefit from someone being able to say
> > "if you want this conversion you must write a cast"?
>
> One motivation is writing "smart pointer" classes, e.g. the nested
> pointer type for a user-defined allocator.
>
> There are pairs of pointer types T1 and T2 with the property that
> (1) A value of type T1 can be converted to T2 with static_cast; and
> (2) There is no automatic conversion from T1 to T2.
>

I don't see what you're getting at. Where does the requirement come from
that the conversion can only be done with an explicit cast?

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Francis Glassborow wrote:
>
> In article <3C3F961A.AFDD9708@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >A couple of people have mentioned templates as a reason for having
> >explicit conversion operators, but so far I haven't seen anyone explain
> >what this means. How do templates benefit from someone being able to say
> >"if you want this conversion you must write a cast"?
>
> I think you have it the wrong way round.

That is, you think that the part of my message that you snipped, which
contains the argument that you are objecting to, has it the wrong way
round. I didn't make that argument, I replied to it. Regardless,
newsgroup discussions should be about the logic of the argument, not
about the person who presented it.

> There are times where we need
> conversion (via conversion operators) for templates. Conversion
> functions do not cut it because there is no uniform naming convention
> for them. OTOH I do not want to allow the compiler to use my conversion
> operator elsewhere for all the many reasons that we know that conversion
> operators are often poor design.
>

There is no uniform naming convention for many things that we do inside
templates. The solution is to specify requirements for the types that
the template is instantiated on, such as having a conversion function
with a particular name and calling convention. If class designers choose
to require conversion operators, knowing that they provide the wrong
semantics, then they've made a mistake. There is no need to change the
language definition to "fix" this.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3C438122.60DA25CE@acm.org>, Pete Becker <petebecker@acm.org>
writes
>> I think you have it the wrong way round. There are times where we need
>> conversion (via conversion operators) for templates. Conversion
>> functions do not cut it because there is no uniform naming convention
>> for them. OTOH I do not want to allow the compiler to use my conversion
>> operator elsewhere for all the many reasons that we know that conversion
>> operators are often poor design.
>>
>
>So you the solution is a construct that requires use of a cast, despite
>the many reasons that we know that code that requires casts are often
>poor design.

Note that you quite correctly wrote 'often' which is definitely
different from 'always'. :-) And yes, there are several places where
casts are desirable and may even, IMHO, indicate thoughtful
design/implementation (think of the usage of const_cast to ensure const
correctness when writing C++ implementations of such functions as
strrchr. )


--
Francis Glassborow
The Seasons best wishes to you and yours. May 2002 be better for all of us than
2001 was for some.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

francis.glassborow@ntlworld.com (Francis Glassborow) wrote (abridged):
> There are times where we need conversion (via conversion operators)
> for templates. Conversion functions do not cut it because there is
> no uniform naming convention for them. OTOH I do not want to allow
> the compiler to use my conversion operator elsewhere for all the
> many reasons that we know that conversion operators are often
> poor design.

Would a member template do?

    class MyClass {
    public:
        template <typename U>
        U convert_to() const;

        // In lieu of operator int().
        template <>
        int convert_to() const { return 42; }

    };

    template <typename T, typename U>
    void demo( T t ) {
        U u = t.convert_to<U>();
        //...
    }

This requires prior cooperation from the class, but so would an operator
int(). (I may not have the syntax quite right - I don't often use template
specialisation but I presume it works for members.)

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon@cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:l37caCEh31Q8Ew+G@robinton.ntlworld.com...
> In article <3C3F961A.AFDD9708@acm.org>, Pete Becker <petebecker@acm.org>
> writes
> >A couple of people have mentioned templates as a reason for having
> >explicit conversion operators, but so far I haven't seen anyone explain
> >what this means. How do templates benefit from someone being able to say
> >"if you want this conversion you must write a cast"?
>
> I think you have it the wrong way round. There are times where we need
> conversion (via conversion operators) for templates. Conversion
> functions do not cut it because there is no uniform naming convention
> for them.

If the standard library included Sean Parent's std::explicit_cast template,
then there would be a de facto standard naming convention.

--
Richard Smith


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Dave Harris" <brangdon@cix.co.uk> wrote in message
news:memo.20020115204109.57495H@brangdon.madasafish.com...
> francis.glassborow@ntlworld.com (Francis Glassborow) wrote (abridged):
> > There are times where we need conversion (via conversion operators)
> > for templates. Conversion functions do not cut it because there is
> > no uniform naming convention for them. OTOH I do not want to allow
> > the compiler to use my conversion operator elsewhere for all the
> > many reasons that we know that conversion operators are often
> > poor design.
>
> Would a member template do?

Sometimes.

>     class MyClass {
>     public:
>         template <typename U>
>         U convert_to() const;
>
>         // In lieu of operator int().
>         template <>
>         int convert_to() const { return 42; }
>
>     };

You cannot specialize member templates within the class definition, they
must be in the enclosing namespace (14.7.3p2):

template<> int MyClass::convert_to<int>() const {return 42}

>     template <typename T, typename U>
>     void demo( T t ) {
>         U u = t.convert_to<U>();

U u = t.template convert_to<U>(); // see 14.2p4

>         //...
>     }
>
> This requires prior cooperation from the class, but so would an operator
> int(). (I may not have the syntax quite right - I don't often use template
> specialisation but I presume it works for members.)

This isn't permitted if MyClass is itself a template --- members templates
cannot be explicitly specialized unless their enclosing template is also
explicitly specialized. See 14.7.3p18 and the example that follows.

Anthony
--
Anthony Williams
Software Engineer, Nortel Networks Optical Components Ltd
The opinions expressed in this message are not necessarily those of my
employer





---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Pete Becker <petebecker@acm.org> wrote in message news:<3C443846.C1742C70@acm.org>...
> Francis Glassborow wrote:
> > There are times where we need
> > conversion (via conversion operators) for templates. Conversion
> > functions do not cut it because there is no uniform naming convention
> > for them. OTOH I do not want to allow the compiler to use my conversion
> > operator elsewhere for all the many reasons that we know that conversion
> > operators are often poor design.
> >
>
> There is no uniform naming convention for many things that we do inside
> templates. The solution is to specify requirements for the types that
> the template is instantiated on, such as having a conversion function
> with a particular name and calling convention. If class designers choose
> to require conversion operators, knowing that they provide the wrong
> semantics, then they've made a mistake. There is no need to change the
> language definition to "fix" this.

In this case, however, we have an uniform naming convention:
static_cast<T>(). Unfortunately we can't use it.

We can say

Base * pb;
Derived * pd = static_cast<Derived *>(pb);

but not

smart_ptr<Base> pb;
smart_ptr<Derived> pd = static_cast< smart_ptr<Derived> >(pb);

--
Peter Dimov
Multi Media Ltd.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Matthew Austern <austern@research.att.com> writes:

| Pete Becker <petebecker@acm.org> writes:
|
| > A couple of people have mentioned templates as a reason for having
| > explicit conversion operators, but so far I haven't seen anyone explain
| > what this means. How do templates benefit from someone being able to say
| > "if you want this conversion you must write a cast"?
|
| One motivation is writing "smart pointer" classes, e.g. the nested
| pointer type for a user-defined allocator.
|
| There are pairs of pointer types T1 and T2 with the property that
| (1) A value of type T1 can be converted to T2 with static_cast; and
| (2) There is no automatic conversion from T1 to T2.

I'm unclear about exactly what problem the requested feature will
solve in your specific example.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Interesting.

I'd like to be able to use explicit on cast operators, to force an
explicit cast. Like this:

class X {
public:
  X(float val) {...}
  explicit operator float() {...}
};

int main() {
    float a = 10.3f;
    X b = a;  // Fine. Use X(float)
    float c = b;  // Error!!
    float d = static_cast<float>(b);  // Fine...
    float e = (float)b;  // Also fine...
}

Sean Parent has provided a nice workaround for those of us who have
the luxury of standard-compliant compilers:
http://groups.google.com/groups?q=explicit+cast&hl=en&selm=B718ED17.1502D%25sparent%40adobe.com&rnum=3

- Chris


"Sektor van Skijlen" <sektor@spam-buffer.aldec.com> wrote in message news:<a1hsph$p4k$1@news.tpi.pl>...
> For now, the "explicit" keyword allows a type CONSTRUCTOR to
> disallow implicit conversions into this type. This keyword could be
> also used to signify, that this implicit conversion is not allowed for
> the object initialization. For example:
>
> int x = 'c'; // allowed
> explicit int x = 'c'; // not allowed!
> explicit int x = int( 'c' ); // allowed
>
> This feature could be mostly used in a situation, where the implicit
> conversion, granted by standard, is a disadvantage in some cases.
> For example, one of std::string's constructors take two arguments,
> which mean an amount of characters and a character. The
> disadvantage is that the compiler won't see any error if you pass
> arguments in wrong order. This will be passed, because there
> will be ALLOWED conversion from char to size_t and in reverse.
> This bug is always hard to detect.
>
> Using this feature you can state:
>
> string( size_t size, explicit char ch );
>
> And then this:
>
> string s( 'c', 12 );
>
> won't compile, because "12" can't be implicitly converted to char.
> However it can be worked around:
>
> string s( 'c', char( 12 ) );
>
>
> Regards,
> --
> ((
>  )) ektor
>
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Chris McClelland wrote:
>
> Interesting.
>
> I'd like to be able to use explicit on cast operators, to force an
> explicit cast. Like this:
>
> class X {
> public:
>   X(float val) {...}
>   explicit operator float() {...}
> };
>
> int main() {
>     float a = 10.3f;
>     X b = a;  // Fine. Use X(float)
>     float c = b;  // Error!!
>     float d = static_cast<float>(b);  // Fine...
>     float e = (float)b;  // Also fine...
> }
>

What benefit does a mandatory cast have over a function call?

float e = b.to_float();

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3C3DE3E6.F27385B2@acm.org...
> Chris McClelland wrote:
> >
> > Interesting.
> >
> > I'd like to be able to use explicit on cast operators, to force an
> > explicit cast. Like this:
> >
> > class X {
> > public:
> >   X(float val) {...}
> >   explicit operator float() {...}
> > };
> >
> > int main() {
> >     float a = 10.3f;
> >     X b = a;  // Fine. Use X(float)
> >     float c = b;  // Error!!
> >     float d = static_cast<float>(b);  // Fine...
> >     float e = (float)b;  // Also fine...
> > }
> >
>
> What benefit does a mandatory cast have over a function call?
>
> float e = b.to_float();

I think the biggest one would be the possibility to use it in templates.
That is to make the source type a template parameter.

Assuming we want assigmenets marked A to be valid for classes where the
cast operator is not marked explicit (inluding of course all classes so
far developed and predefined types) but fail for classes we develop with
the explicit mark on the cast operator, while cases marked B should be
always valid, you see the difference in templated code like:

float e1,e2;
T b;
e1 = b;    // A
e2 = static_cast<float>(b); // B

and

float e1,e2;
T b;
e1 = b;    // A
e2 = b.to_float(); // B

Of course B does not work in the second case for any type that is
already there.

As Chris noted a brilliant but partial solution (does not account for
existing algorithms) is the explicit_cast<> template by Sean Parent.

Note: Im not defending any extension of the meaning of "explicit". I've
not given it sufficient brain time-slices to take position pro or versus
it. I'm trying to answer your question on potential benefits of the
mandatory cast syntax over the conversion function.

--

Andrea Ferro

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Andrea Ferro wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3C3DE3E6.F27385B2@acm.org...
> > Chris McClelland wrote:
> > >
> > > Interesting.
> > >
> > > I'd like to be able to use explicit on cast operators, to force an
> > > explicit cast. Like this:
> > >
> > > class X {
> > > public:
> > >   X(float val) {...}
> > >   explicit operator float() {...}
> > > };
> > >
> > > int main() {
> > >     float a = 10.3f;
> > >     X b = a;  // Fine. Use X(float)
> > >     float c = b;  // Error!!
> > >     float d = static_cast<float>(b);  // Fine...
> > >     float e = (float)b;  // Also fine...
> > > }
> > >
> >
> > What benefit does a mandatory cast have over a function call?
> >
> > float e = b.to_float();
>
> I think the biggest one would be the possibility to use it in templates.
> That is to make the source type a template parameter.
>
> Assuming we want assigmenets marked A to be valid for classes where the
> cast operator is not marked explicit (inluding of course all classes so
> far developed and predefined types) but fail for classes we develop with
> the explicit mark on the cast operator, while cases marked B should be
> always valid, you see the difference in templated code like:
>

Saying "I could write this code" doesn't support adding the feature
unless you also demonstrate that the resulting code is easier to write,
or cleaner, or better in some other way because of having mandatory
casts. Otherwise it's just doing parlor tricks. So, again, what's the
benefit from having mandatory casts?

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <bQm%7.65$dd2.1604@nreader3.kpnqwest.net>, Andrea Ferro says...
>
>"Pete Becker" <petebecker@acm.org> wrote in message
>news:3C3DE3E6.F27385B2@acm.org...

>> Chris McClelland wrote:
>> > I'd like to be able to use explicit on cast operators, to force an
>> > explicit cast. Like this:
>> >
>> > class X {
>> > public:
>> >   X(float val) {...}
>> >   explicit operator float() {...}
>> > };

>> What benefit does a mandatory cast have over a function call?
>>
>> float e = b.to_float();
>
>I think the biggest one would be the possibility to use it in templates.
>That is to make the source type a template parameter.

I don't get it - you could still have b.to<float> cq. b.to<TemplateParam>
(That's destination type, of course. But the source type is always
determined by the type of the expression casted. )

The main problem for templates in libraries is knowing which names
to use. For a container C, they can guess C.begin() and C.end(), and
C::iterator. For converting type T to U, U u(T()) is the logical
expression. But how many templates will ever need to cast T's to U's
knowing that U u(T()) doesn't work ? And guess the name T::to<U> ?

If I were faced with such an unlikely problem, I'd add a template
parameter U(*)(T const&) so the template user, knowing T and U, can
me how to get from a T to a U.

Regards,

--
Michiel Salters
Consultant Technical Software Engineering
CMG Trade, Transport & Industry
Michiel.Salters@cmg.nl

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I understand your concern, Pete.

I think the justification for support of explicit casts is partly
exactly the same as that for explicit construction, but also, since
explicit construction is already part of the language, symmetry
arguments provide further justification.

In a language as large and complex as C++, it helps understandability
if the feature set is symmetric - having features which are included
in one context and not in another (for no good reason) is just one
more syntactic rule to learn about the language. Add to that the
ever-increasing importance of templates and generic programming, and
symmetry becomes not only desirable, but actually vital - the addition
(to ISO14882) of default constructors for fundamental types is a case
in point.

- Chris


> Saying "I could write this code" doesn't support adding the feature
> unless you also demonstrate that the resulting code is easier to write,
> or cleaner, or better in some other way because of having mandatory
> casts. Otherwise it's just doing parlor tricks. So, again, what's the
> benefit from having mandatory casts?
>
> --
> Pete Becker
> Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

For now, the "explicit" keyword allows a type CONSTRUCTOR to
disallow implicit conversions into this type. This keyword could be
also used to signify, that this implicit conversion is not allowed for
the object initialization. For example:

int x = 'c'; // allowed
explicit int x = 'c'; // not allowed!
explicit int x = int( 'c' ); // allowed

This feature could be mostly used in a situation, where the implicit
conversion, granted by standard, is a disadvantage in some cases.
For example, one of std::string's constructors take two arguments,
which mean an amount of characters and a character. The
disadvantage is that the compiler won't see any error if you pass
arguments in wrong order. This will be passed, because there
will be ALLOWED conversion from char to size_t and in reverse.
This bug is always hard to detect.

Using this feature you can state:

string( size_t size, explicit char ch );

And then this:

string s( 'c', 12 );

won't compile, because "12" can't be implicitly converted to char.
However it can be worked around:

string s( 'c', char( 12 ) );


Regards,
--
((
 )) ektor


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]