My instructor told me that as per latest draft explicit keyword is applicable
only to constructor and it can not be used with conversion oparators.
Can any one explain me why this restriction is put.

Class X
{
  ...
  public:
  explicit X(char);    // This is supported. Good
  explicit operator int() const;  // Latest draft does support this. Why?
}

THanks in advance for your help.

Ajay
ajay@unison.com

In article <9435715.28718@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>>    2. What is the effect of an "explicit" copy constructor?
>
>Good question.
>My guess is that it doesn't have any effect.
>
>>    3. What is the effect of an "explicit" default constructor?
>
>A default constructor is not a conversion, so I think it doesn't have
>any effect.

 Of course a copy constructor is a conversion :-) And you might
think the underlying _type conversion_ is the identity conversion,
but you might be wrong too: a copy constructor is the type conversion

 T const& --> T

which creates a new "rvalue" from a "const lvalue". If the argument
of a copy constructor is an rvalue T, then the conversion

 T --> T&

has to be applied before the copy constructor can be invoked,
and this conversion represents the formation of a temporary.
Thus the full sequence require to copy an rvalue is:

 T---1--->T&---2--->T const&---3--->T

where (1) is "temporary initisation", (2) is a reference conversion
which is normally implemented as a NOP, and (3) is the conversion
involved in executing the copy constructor. In the case:

 complex x,y;
 complex z = x+y;

the full conversion sequence is, IMHO:

 rvalue complex expression "x+y" is mapped to type "complex"
 complex --> complex&  // initialise temporary with "x+y"
  --> complex const& // type conversion only, add "const"
  --> complex  // copy constructor called
 the constructor call is used to initialise 'z', which
 has type 'complex'

In the case

 complex const& z = x + y;

the sequence is shorter:

 rvalue complex expression "x+y" is mapped to type "complex"
 complex --> complex&  // initialise temporary with "x+y"
  --> complex const& // type conversion only, add "const"
 reference z has type complex const&

Notice the first and last lines of EVERY explanation
provide an "interpretation" of the theoretical conversion sequence,
that is, a mapping from the case at hand. In fact, the sequence
itself must be interpreted (indicated in comments) to deduce
what code is generated.

I note that _some_ conversion sequences are sound theoretical
type conversions which are eliminated BY THE INTERPRETATION
because, for example, a non-const reference might be
bound to a temporary.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <D1BII3.6yC@ucc.su.OZ.AU>,
John Max Skaller <maxtal@physics.su.OZ.AU> wrote:
>In article <9435715.28718@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>>
>>>    2. What is the effect of an "explicit" copy constructor?
>>
>>Good question.
>>My guess is that it doesn't have any effect.
>>
>>>    3. What is the effect of an "explicit" default constructor?
>>
>>A default constructor is not a conversion, so I think it doesn't have
>>any effect.
>
> Of course a copy constructor is a conversion :-) And you might
>think the underlying _type conversion_ is the identity conversion,
>but you might be wrong too...

Does anyone (other than me) want to suggest to John that he consider the
purchase of some reading glasses?

The topic was *default constructors* John... not copy constructors.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
-------------------------------------------- Suites and Bullet-Proof Shoes -

In article <3dhtkf$ml2@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:
>In article <D1BII3.6yC@ucc.su.OZ.AU>,
>John Max Skaller <maxtal@physics.su.OZ.AU> wrote:
>>In article <9435715.28718@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>>>
>>>>    2. What is the effect of an "explicit" copy constructor?
>>>
>>>Good question.
>>>My guess is that it doesn't have any effect.
>>>
>>>>    3. What is the effect of an "explicit" default constructor?
>>>
>>>A default constructor is not a conversion, so I think it doesn't have
>>>any effect.
>>
>> Of course a copy constructor is a conversion :-) And you might
>>think the underlying _type conversion_ is the identity conversion,
>>but you might be wrong too...
>
>Does anyone (other than me) want to suggest to John that he consider the
>purchase of some reading glasses?
>
>The topic was *default constructors* John... not copy constructors.
>

 See point (2) above. Says "copy constructors".

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

smeyers@netcom.com (Scott Meyers) writes:

>I asked Bjarne about this at the C++ World conference last month, and my
>understanding is that "explicit" was also proposed for conversion
>operators, but somebody invoked the two-week rule, so that part of the
>proposal was tabled until the next meeting.  I also got the impression that
>Bjarne expected that "explicit" would be extended to cover conversion
>operators.  Of course, I was not at the ANSI/ISO meeting where the issue
>was discussed, I may have misunderstood Bjarne, or Bjarne's expectation may
>not come to pass.  Can anybody who was at the meeting comment on this?

I was at the meeting.  The above is all correct.
(Whether Bjarne's expectation will come to pass is not yet certain,
but it would appear likely.)

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <damian.787816819@bruce.cs.monash.edu.au>,
Damian Conway <damian@cs.monash.edu.au> wrote:
>clamage@Eng.Sun.COM (Steve Clamage) writes:
>
>>>    2. What is the effect of an "explicit" copy constructor?
>
>>No effect, as far as I can see.
>
>Well, one interpretation of the "explicit" keyword might be: "the following
>constructor cannot be used to initialize a temporary passed to a function". If
>that was the meaning, an explicit copy constructor might imply that pass by
>value of matching type was disallowed for the class (ie: only pass by value
>with casting).
>
> class NoCopy
> {
> public:
>  explicit NoCopy(const NoCopy &);
>  NoCopy(int);
>  NoCopy(void);
> };
>
> void byVal(NoCopy);
> void byRef(const NoCopy &);
>
>
> main()
> {
>  NoCopy nc;
>  int i;
>
>  byVal(nc);    // Illegal - can't init NoCopy param via copy ctor
>  byVal(i);     // Okay - calls int arg'd constructor
>
>  byRef(nc);    // Okay - no constructor called
>  byRef(i);     // Okay - calls int arg'd constructor
> }

    Well, is this really true? As I understand it, the call byVal(i) still
requires the copy constructor (conceptionally) to copy the temporary object
NoCopy(i) into the actual parameter.

    This means that in the context of argument passing, an explicit copy ctor
would have the same effect as a private one. Another `interesting'
consequence would be

 NoCopy nc;
 NoCopy nc2(nc);  // OK, `explicit' use of copy ctor
 NoCopy nc3(0);  // OK, int ctor used
 NoCopy nc4 = nc; // illegal, implies implicit call to copy
    // ctor (conceptionally)  ARM 12.6.1
 NoCopy nc5 = 0;  // dito


    Now for the default constructor. Declaring it "explicit" would - with my
intuition - have some similarities to making it private as well:

 struct NoDefault
 {
  explicit NoDefault();
 };

 NoDefault nd;   // illegal
 NoDefault nd2 = NoDefault(); // ok

(Note that you cannot write

 NoDefault nd2();

because that's a function declaration - one of the things I strongly dislike
about the C++ declaration syntax.)

    And:

 struct Struct
 {
  NoDefault nd;

  Struct() {};   // illegal
  Struct(): nd() {}  // ok
 };

 struct Derived: NoDefault
 {
  Derived() {}   // illegal
  Derived(): NoDefault() {} // ok
 };

This could be useful.

    Are my `intuitive' interpretations the actual semantics? Or is the
"explicit" keyword silently ignored for default and copy ctors? IMHO, to avoid
the subtlety AND have clean rules, it probably should be prohibited to specify
the copy dtor "explicit".

    My personal conclusion is: I suppose I don't like explicit. After all, it
encourages the use of casts (since the constructor call syntax is equivalent
to the cast syntax - maybe that should be abandoned).


 - Andreas Rossberg

ti953017@rzcipa01.rz.tu-bs.de (Andreas Rossberg) writes:

>clamage@Eng.Sun.COM (Steve Clamage) writes:
>
>> That's because it was voted on in the Nov 1994 meeting. Adding the
>> keyword in front of a constructor means that the constructor will
>> not be used as an implicit type conversion:
[...]
>I would like to know three more things about "explicit":
>
>    1. May it be used with conversion operators as well? If not, is there a
>       a rational for not allowing that?

Not yet.  But it is likely to be added at the next meeting.
The rationale for not adding it at the last meeting was that we weren't yet
sure of the full implications.  (For example, how exactly does it interact
with inheritance?)

>    2. What is the effect of an "explicit" copy constructor?

Good question.
My guess is that it doesn't have any effect.

>    3. What is the effect of an "explicit" default constructor?

A default constructor is not a conversion, so I think it doesn't have
any effect.

(I don't have the proposal that we voted on handy, so I can't check what
it says.)

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <3d21nu$7i5@engnews2.eng.sun.com>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>
>ti953017@rzcipa01.rz.tu-bs.de (Andreas Rossberg) writes:
>
>>I would like to know three more things about "explicit":
>
>>    1. May it be used with conversion operators as well? If not, is there a
>>       a rational for not allowing that?
>
>No. Not needed. If you don't want implicit conversion, don't write the
>operator function. Write a named function instead, like "str()" in
>class ostrstream. You don't have that option with constructors.

  But I would like to have a uniform syntax for specifying (explicit)
conversions. Using named functions here isn't symmetric.

  BTW, I think you have a similar option with constructors: write a private
constructor and a friend named function to call it. This may be a bit more
verbose, but simple enough.

  So IMHO, specifying explicit conversions should either be allowed in each
direction, or not at all (too late for that I guess :-).

 - Andreas Rossberg

clamage@Eng.Sun.COM (Steve Clamage) writes:

>>    2. What is the effect of an "explicit" copy constructor?

>No effect, as far as I can see.

Well, one interpretation of the "explicit" keyword might be: "the following
constructor cannot be used to initialize a temporary passed to a function". If
that was the meaning, an explicit copy constructor might imply that pass by
value of matching type was disallowed for the class (ie: only pass by value
with casting).

 class NoCopy
 {
 public:
  explicit NoCopy(const NoCopy &);
  NoCopy(int);
  NoCopy(void);
 };

 void byVal(NoCopy);
 void byRef(const NoCopy &);


 main()
 {
  NoCopy nc;
  int i;

  byVal(nc);    // Illegal - can't init NoCopy param via copy ctor
  byVal(i);     // Okay - calls int arg'd constructor

  byRef(nc);    // Okay - no constructor called
  byRef(i);     // Okay - calls int arg'd constructor
 }


Can't really see a use for such an interpretation, but it's plausible.

damian
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  who: Damian Conway                 email: damian@bruce.cs.monash.edu.au
where: Dept. Computer Science        phone: +61-3-565-5184
       Monash University               fax: +61-3-565-5146
       Clayton 3168                  quote: "A pessimist is never disappointed."
       AUSTRALIA

ti953017@rzcipa01.rz.tu-bs.de (Andreas Rossberg) writes:

>In article <3d21nu$7i5@engnews2.eng.sun.com>,
>Steve Clamage <clamage@Eng.Sun.COM> wrote:
>>
>>ti953017@rzcipa01.rz.tu-bs.de (Andreas Rossberg) writes:
>>
>>>I would like to know three more things about "explicit":
>>
>>>    1. May it be used with conversion operators as well? If not, is there a
>>>       a rational for not allowing that?
>>
>>No. Not needed. If you don't want implicit conversion, don't write the
>>operator function. Write a named function instead, like "str()" in
>>class ostrstream. You don't have that option with constructors.

>  But I would like to have a uniform syntax for specifying (explicit)
>conversions. Using named functions here isn't symmetric.

You can supply your own uniform syntax if you like:
 int to_int();
 double to_double();
 Wit to_Wit();
 Woo to_Woo();
For types without a simple name (e.g., char*) you need a typedef.
If this isn't good enough, see if you can get someone on the C++
Committee to champion an extension to the "explicit" extension.
This forum is as good as any to ask about that.

>  BTW, I think you have a similar option with constructors: write a private
>constructor and a friend named function to call it. This may be a bit more
>verbose, but simple enough.

The semantics aren't the same. For example:
 class X { ... X(int); friend X make_X(int); ... };
 X x(3);
 X x = make_X(3);
With the constructor, one object is constructed at x.
With make_X, one object is constructed and copied into x. The compiler
cannot optimize away the copy as it can with similar-looking code like
 X x = X(3);
Constructors are special. Type conversion operators are only special
in being invoked implicitly or with cast syntax. There is no difference
in semantics between a type conversion operator and a named function.

--
Steve Clamage, stephen.clamage@eng.sun.com

In article <3d21nu$7i5@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM (Steve Clamage) writes:
| >    1. May it be used with conversion operators as well? If not, is there a
| >       a rational for not allowing that?
|
| No. Not needed. If you don't want implicit conversion, don't write the
| operator function. Write a named function instead, like "str()" in
| class ostrstream. You don't have that option with constructors.

I asked Bjarne about this at the C++ World conference last month, and my
understanding is that "explicit" was also proposed for conversion
operators, but somebody invoked the two-week rule, so that part of the
proposal was tabled until the next meeting.  I also got the impression that
Bjarne expected that "explicit" would be extended to cover conversion
operators.  Of course, I was not at the ANSI/ISO meeting where the issue
was discussed, I may have misunderstood Bjarne, or Bjarne's expectation may
not come to pass.  Can anybody who was at the meeting comment on this?  I
don't mind spreading rumors, but I'd prefer that they not be totally
unfounded.

FWIW, I think "explicit" should apply equally to both constructors and
conversion operators (if it applies to either).  We just don't need another
non-orthogonality in this language, really we don't.

Scott

In article <smeyersD1390C.D1B@netcom.com> smeyers@netcom.com (Scott Meyers) writes:

> I asked Bjarne about this at the C++ World conference last month, and my
> understanding is that "explicit" was also proposed for conversion
> operators, but somebody invoked the two-week rule, so that part of the
> proposal was tabled until the next meeting.

Actually, someone noted that it was far from clear what should be the
right interaction between `explicit' and inheritance.  Suppose you have
a conversion operator marked explicit in a derived class and not in a
base class.  Does that mean it's OK to call the base class conversion
operator implicitly even though the derived class conversion operator
is a better match?

We felt that was a question better answered between meetings.
--
    --Andrew Koenig
      ark@research.att.com

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: In article mmr@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John Carson) writes:
: >
: >  However, as a manager who is
: >worried about software quality, it might be reasonable for me to assume
: >that someone who is calling a function with a double rather than an int
: >has made some type of error.  If it was a reasonable call, they could
: >explicitly cast it to an int so show they truely intended this to
: >happen.

: Casts are dangerous. Suppose the function was later changed to take a long
: or a float or a double. How would you find casts that now incorrectly
: and perhaps dangerously truncate doubles to int before implicit reconversion
: to the correct wider type? More to the point, would the idea of looking for
: such casts even occur to the person who changed the function?

If "explicit" worked with arguments, then the case would now be
considered a syntax error and easily detected.

: >
: >I figure any way I can have the compiler detect an error or potential
: >error saves me much money in the long run.

: Yes. That's why some compilers warn about "narrowing" conversions.
: I think it's the best that can be done. (My template example was meant to
: be facetious.) Personally, I like to turn on compiler warnings, and fix
: my code so that none get generated.
I completely agree except when the warnings make not sense as some do.

: ---
: Steve Clamage, stephen.clamage@eng.sun.com

John C.

In article <3co3q5$m0e@engnews2.Eng.Sun.COM>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>In article fuj@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John Carson) writes:
>>Pete Becker (pete@borland.com) wrote:
>>: >You could use the explicit keyword in the function declaration such as:
>>: >
>>: >int foo (int a, explicit int b);
>>: >
>>: >Where conversions could be applied to the first argument, but not to the
>>: >second.  Promotions would be allowed, but not conversions.  This would
>>: >not break code and allow those who wish to be picky about how functions
>>: >are called.
>>
>>:  The compiler I use warns me when I do this. I don't see any need
>>: to formalize this warning with a language extension.
>>:  Further, this particular suggestion puts the information in the
>>: wrong place. The implementor of foo() shouldn't care at all how I figured
>>: out what value to pass to it. foo()'s operation isn't affected by that in
>>: any way, so foo() has no business telling me that I can't use implicit
>>: conversions in calling it.
>>:  -- Pete
>>
>>If you put it in the prototype then the users can decide as you want.  I
>>agree a warning message should be sufficient, but in a large project
>>warnings get ignored and I don't believe there is any requirement that a
>>warning gets generated.
>
>No, Pete is quite right. It doesn't make any sense to put it on the
>prototype. The function expects to get an int, and it gets an int.
>
>On what basis can you as the author of the function decide what kinds
>of conversions are acceptable to create the int? You have no knowledge
>of the context in which the value was created, and no way to find out.
>
>Either the language supports implicit conversions from "wider" to "narrower"
>types, or it doesn't. Some languages don't. C does, for good or evil or no
>reason, and C++ inherits that behavior.
>
>I see only two choices if you are unhappy with the status quo:
>
>1. Disallow implicit "narrowing" conversions in the language. This will
>break a lot of existing code which is nonetheless valid. (It will also
>break some programs with invalid code, doubtless.)
>
>2. Lobby your compiler vendor to provide diagnostics for such conversions.
>You can then protect yourself and your projects against accidental
>dangerous conversions. Some compilers already provide such diagnostics,
>so this step may have already been done for you.
>
>Aside: You can sort of provide this protection already, if you want to:
>
> inline int zzyzz(int& i) { return i; } // dummy function
>
> template <class T> inline void foo(int a, T b) {
>  zzyzz(b); // compile-time error if T is a not an int
> }
> // specializations to prevent template instantiation
> void foo(int a, int b) { ... } // as above
> inline void foo(int a, short b) { foo(a, (int) b); }
> inline void foo(int a, char b) { foo(a, (int) b); }
> // and signed char, unsigned char, unsigned short
>
>I can't imagine why you would want to bother with this, however.
>
>---
>Steve Clamage, stephen.clamage@eng.sun.com
>
>

I agree with Pete and Steve on this issue.  I would rather that
compiler vendors support a compiler option to disallow "implicit
narrowing".  This would provide the support necessary for many
with out adding to the language complexity.

I have never been a fan of "implicit narrowing".  However, if I
write a function expecting an "int", what legitimate reasons would
I have for caring about how a parameter achieves "int"-ness?

Some vendors would unnecessarily apply this "explicit" usage to
their libraries (possiblly for the sake of using the most current
language features; you know who you are!) and others would not.

Some FORTRAN advocates would probably request an "implicit" variable
scheme based on extensions like that described by the posters above.
This type of language extension would be dissatisfying, as I am sure
most will agree.

-----------------------------------------------------------------------------
| James Scalio          | I speak only for myself.  AT&T retains professional
| james.scalio@att.com  | spokespersons for speaking on behalf of the company.
-----------------------------------------------------------------------------

ucecb09@ucl.ac.uk (Mr Robert Byrne) writes:

>carson@gwis2.circ.gwu.edu (John Carson) writes:

>>Steve Clamage (clamage@Eng.Sun.COM) wrote:

>>: I don't know of any formal proposal to eliminate even some of the
>>: implicit conversions from the language.

>>You could use the explicit keyword in the function declaration such as:

>>int foo (int a, explicit int b);

>I was given the impression that the explicit keyword would be used
>*in front* of a constructor. Is this also a valid use ?

No. Carson was suggesting an extension (to the new extension).
--
Steve Clamage, stephen.clamage@eng.sun.com

-J.SCALIO (scalio@hogpf.ho.att.com) wrote:
: In article <3co3q5$m0e@engnews2.Eng.Sun.COM>,
: Steve Clamage <clamage@Eng.Sun.COM> wrote:
: >In article fuj@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John Carson) writes:

Loads of stuff deleted

: I agree with Pete and Steve on this issue.  I would rather that
: compiler vendors support a compiler option to disallow "implicit
: narrowing".  This would provide the support necessary for many
: with out adding to the language complexity.

This would work too and would be perfectly.  Prohibit unsafe conversions,
etc.  I would just like a way, either in the language or compiler, to
catch potential errors of this type.  Since they can be caught this way,
why not do it.  Of course, this concern should be optional as some don't
feel it is a serious problem.

: I have never been a fan of "implicit narrowing".  However, if I
: write a function expecting an "int", what legitimate reasons would
: I have for caring about how a parameter achieves "

As a function author I wouldn't be concerned either.  This is not the
problem.  As a manager of someone calling the function I might well be
concerned about someone passing a double to a function requiring any
<int>.  Ever try to debug a problem caused by this?  If it can be
eliminated, then my project can't make that mistake.  If we put it in the
prototype, then the option can be with the project, not the author of the
function.  Granted they will supply an include file with a prototype, but
that can be altered by the project QA team.

: Some vendors would unnecessarily apply this "explicit" usage to
: their libraries (possiblly for the sake of using the most current
: language features; you know who you are!) and others would not.

I would hope not.  I would advocate leaving that issue up to the USERS,
not the author.

: Some FORTRAN advocates would probably request an "implicit" variable
: scheme based on extensions like that described by the posters above.
: This type of language extension would be dissatisfying, as I am sure
: most will agree.

: -----------------------------------------------------------------------------
: | James Scalio          | I speak only for myself.  AT&T retains professional
: | james.scalio@att.com  | spokespersons for speaking on behalf of the company.
: -----------------------------------------------------------------------------
John Carson

In article <3csjql$cjr@engnews2.Eng.Sun.COM>
           clamage@Eng.Sun.COM "Steve Clamage" writes:

>
> In article mmr@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John Carson)
>  writes:
> >
> >  However, as a manager who is
> >worried about software quality, it might be reasonable for me to assume
> >that someone who is calling a function with a double rather than an int
> >has made some type of error.  If it was a reasonable call, they could
> >explicitly cast it to an int so show they truely intended this to
> >happen.
>
> Casts are dangerous. Suppose the function was later changed to take a long
> or a float or a double. How would you find casts that now incorrectly
> and perhaps dangerously truncate doubles to int before implicit reconversion
> to the correct wider type? More to the point, would the idea of looking for
> such casts even occur to the person who changed the function?
>

 You could implement the (original) overload for the narrower type as a
private member of the class, but, as you say, whos going to think of this?

e.g.
 class Snafu {
  public:
     void foo( int bar );
 }
 ...
 Snafu x;
 double d = 0.0;
 x.foo((int)(d));

becomes:

 class Snafu {
  private:
     void foo( int bar );
  public:
     void foo( double bar );
 }
 ...
 Snafu x;
 double d = 0.0;
 x.foo((int)(d));   // Should fail...unless the compiler widens
                    // the narrowed int!


[snip]
> Personally, I like to turn on compiler warnings, and fix
> my code so that none get generated.

 I agree totally...unfortunatly, this usually involves inserting casts
that one would rather not have :-(

Regards,
 Andy
--
=============================================================================
| Andy Sawyer                Internet (Personal) : andys@thone.demon.co.uk  |
|                          Compu$erve (Business) : 100432,1713              |
=============================================================================
|The opinions expressed above are my own, but you are granted the right to  |
|use and freely distribute them. I accept no responsibility for any injury, |
|harm or damage arising from their use.                --   The Management. |
=============================================================================

ti953017@rzcipa01.rz.tu-bs.de (Andreas Rossberg) writes:


>clamage@Eng.Sun.COM (Steve Clamage) writes:

>> That's because it was voted on in the Nov 1994 meeting. Adding the
>> keyword in front of a constructor means that the constructor will
>> not be used as an implicit type conversion:

>[example deleted]


>I would like to know three more things about "explicit":

>    1. May it be used with conversion operators as well? If not, is there a
>       a rational for not allowing that?

No. Not needed. If you don't want implicit conversion, don't write the
operator function. Write a named function instead, like "str()" in
class ostrstream. You don't have that option with constructors.

>    2. What is the effect of an "explicit" copy constructor?
>    3. What is the effect of an "explicit" default constructor?

No effect, as far as I can see.

--
Steve Clamage, stephen.clamage@eng.sun.com

Much stuff deleted.

: No, Pete is quite right. It doesn't make any sense to put it on the
: prototype. The function expects to get an int, and it gets an int.

: On what basis can you as the author of the function decide what kinds
: of conversions are acceptable to create the int? You have no knowledge
: of the context in which the value was created, and no way to find out.

: Either the language supports implicit conversions from "wider" to "narrower"
: types, or it doesn't. Some languages don't. C does, for good or evil or no
: reason, and C++ inherits that behavior.

: I see only two choices if you are unhappy with the status quo:

: 1. Disallow implicit "narrowing" conversions in the language. This will
: break a lot of existing code which is nonetheless valid. (It will also
: break some programs with invalid code, doubtless.)

: 2. Lobby your compiler vendor to provide diagnostics for such conversions.
: You can then protect yourself and your projects against accidental
: dangerous conversions. Some compilers already provide such diagnostics,
: so this step may have already been done for you.

: Aside: You can sort of provide this protection already, if you want to:

:  inline int zzyzz(int& i) { return i; } // dummy function

:  template <class T> inline void foo(int a, T b) {
:   zzyzz(b); // compile-time error if T is a not an int
:  }
:  // specializations to prevent template instantiation
:  void foo(int a, int b) { ... } // as above
:  inline void foo(int a, short b) { foo(a, (int) b); }
:  inline void foo(int a, char b) { foo(a, (int) b); }
:  // and signed char, unsigned char, unsigned short

: I can't imagine why you would want to bother with this, however.

: ---
: Steve Clamage, stephen.clamage@eng.sun.com

I agree: choice 1 is not reasonable.  However, as a manager who is
worried about software quality, it might be reasonable for me to assume
that someone who is calling a function with a double rather than an int
has made some type of error.  If it was a reasonable call, they could
explicitly cast it to an int so show they truely intended this to
happen.  As someone who teaches programming I find a significant number
of errors occuring when students make assumptions (guesses) about
arguments.  For example, someone might call abs(x) with a double thinking
it would give the absolute value of the double but it first converts the
double to an <int>.

All I'm looking for is to allow QA people the ability to create more
cautious prototypes that outlaw automatic conversions.  The second method
you recommended is very tedious but will do the job but is probably
impractical.

I figure any way I can have the compiler detect an error or potential
error saves me much money in the long run.

John C.

In article <3co3q5$m0e@engnews2.eng.sun.com>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>In article fuj@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John Carson) writes:
>>Pete Becker (pete@borland.com) wrote:
>>: >You could use the explicit keyword in the function declaration such as:
>>: >
>>: >int foo (int a, explicit int b);
>>: >
>>: >Where conversions could be applied to the first argument, but not to the
>>: >second.  Promotions would be allowed, but not conversions.  This would
>>: >not break code and allow those who wish to be picky about how functions
>>: >are called.
>>
>>:  The compiler I use warns me when I do this. I don't see any need
>>: to formalize this warning with a language extension.
>>:  Further, this particular suggestion puts the information in the
>>: wrong place. The implementor of foo() shouldn't care at all how I figured
>>: out what value to pass to it. foo()'s operation isn't affected by that in
>>: any way, so foo() has no business telling me that I can't use implicit
>>: conversions in calling it.
>>:  -- Pete
>>
>>If you put it in the prototype then the users can decide as you want.  I
>>agree a warning message should be sufficient, but in a large project
>>warnings get ignored and I don't believe there is any requirement that a
>>warning gets generated.
>
>No, Pete is quite right. It doesn't make any sense to put it on the
>prototype. The function expects to get an int, and it gets an int.
>
>On what basis can you as the author of the function decide what kinds
>of conversions are acceptable to create the int? You have no knowledge
>of the context in which the value was created, and no way to find out.
>
>Either the language supports implicit conversions from "wider" to "narrower"
>types, or it doesn't. Some languages don't. C does, for good or evil or no
>reason, and C++ inherits that behavior.
>
>I see only two choices if you are unhappy with the status quo:
>
>1. Disallow implicit "narrowing" conversions in the language. This will
>break a lot of existing code which is nonetheless valid. (It will also
>break some programs with invalid code, doubtless.)
>

How about using explicit as a type modifier to say that no implicit narrowing
is done on this type?

For instance:
    explicit double d=2.1;
    int i=x;                      // error, implicit narrowing forbidden
    int j=int(d);                 // ok

One can also define the rule that the explicit attribute is preserved during
arithmetic operations.
So that:
    explcit int x;
    int y=21;
    char z    = 21*(y+x);         // error, implicit narrowing forbidden
    char z1   = char(21*(y+x));   // ok
    char z2   = 21*(y+char(x));   // ok


Of course, there are a lot of other cases to take care of. For instance,
given that different machines have different sizes for different types,
should the nature of explicit be system dependent? I mean, if we have the
following:
    explicit unsigned maxu=UINT_MAX;
    long l=maxu;                      // error???
If effectively long==int on the machine, we can potentially be performing
a narrowing operation. Personally, I'd be in favour of this system dependence
(it would definitely help find potential porting problems) but it would be a
break from the rest of the language and I'm not sure how that would go over
with the rest of the C++ community.


>Steve Clamage, stephen.clamage@eng.sun.com
>

Take care
    Robert

--
/----------------------------------+------------------------------------------\
| Robert N. Deviasse               |"If we have to re-invent the wheel,       |
| EMAIL: g2devi@cdf.utoronto.ca    |  can we at least make it round this time"|
+----------------------------------+------------------------------------------/

>>: In article 5ne@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John
>Carson) writes:
>>: >Is there any way to turn off the "C" automatic
>>: >conversions involved with function calls.

>In article <3cj7jv$82h@cronkite.seas.gwu.edu>, carson@gwis2.circ.gwu.edu says
>>int foo (int a, explicit int b);

In article <D0rDMw.G8E@borland.com>, Pete Becker <pete@borland.com> wrote:
>Further, this particular suggestion puts the information in the wrong
>place....  foo()'s operation isn't affected by that in any way, so foo() has
>no business telling me that I can't use implicit conversions in calling it.

Indeed, I think the most desirable solution would be for compiler
technology to advance to the point that one can create custom classes
analogous to the built-in types which are as efficient as the built-ins.
That is, if one could write

    class Int {
      int i;
      /* explicit copy ctors and conversions */
    };

and have the Int be as efficient as an int, then the above proposed
extension would be unnecessary.  However, achieving this level of
optimization appears to be very difficult (but I am no expert).

-ccwf

carson@gwis2.circ.gwu.edu (John Carson) writes:

>Steve Clamage (clamage@Eng.Sun.COM) wrote:
>: In article 5ne@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John Carson) writes:

>: >Is there any way to turn off the "C" automatic
>: >conversions involved with function calls.  Example, doubles being
>: >converted to integers to match a function signature.  Some people would
>: >consider that an error and not a feature.

>: I don't know of any formal proposal to eliminate even some of the
>: implicit conversions from the language.

>You could use the explicit keyword in the function declaration such as:

>int foo (int a, explicit int b);

I was given the impression that the explicit keyword would be used
*in front* of a constructor. Is this also a valid use ?


>Where conversions could be applied to the first argument, but not to the
>second.  Promotions would be allowed, but not conversions.  This would
>not break code and allow those who wish to be picky about how functions
>are called.

Further, in the case of ctors it is the promotions one *dosen't* want.
That's  my understanding of Steve(en)s explanation.

Rob

clamage@Eng.Sun.COM (Steve Clamage) writes:

> That's because it was voted on in the Nov 1994 meeting. Adding the
> keyword in front of a constructor means that the constructor will
> not be used as an implicit type conversion:

[example deleted]


I would like to know three more things about "explicit":

    1. May it be used with conversion operators as well? If not, is there a
       a rational for not allowing that?

    2. What is the effect of an "explicit" copy constructor?

    3. What is the effect of an "explicit" default constructor?

Thanks.

 - Andreas Rossberg

In article mmr@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John Carson) writes:
>
>  However, as a manager who is
>worried about software quality, it might be reasonable for me to assume
>that someone who is calling a function with a double rather than an int
>has made some type of error.  If it was a reasonable call, they could
>explicitly cast it to an int so show they truely intended this to
>happen.

Casts are dangerous. Suppose the function was later changed to take a long
or a float or a double. How would you find casts that now incorrectly
and perhaps dangerously truncate doubles to int before implicit reconversion
to the correct wider type? More to the point, would the idea of looking for
such casts even occur to the person who changed the function?

>
>I figure any way I can have the compiler detect an error or potential
>error saves me much money in the long run.

Yes. That's why some compilers warn about "narrowing" conversions.
I think it's the best that can be done. (My template example was meant to
be facetious.) Personally, I like to turn on compiler warnings, and fix
my code so that none get generated.
---
Steve Clamage, stephen.clamage@eng.sun.com

Pete Becker (pete@borland.com) wrote:
: In article <3cj7jv$82h@cronkite.seas.gwu.edu>, carson@gwis2.circ.gwu.edu
: says...
: >
: >Steve Clamage (clamage@Eng.Sun.COM) wrote:
: >: In article 5ne@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John
: Carson) writes:
: >
: >: >Is there any way to turn off the "C" automatic
: >: >conversions involved with function calls.  Example, doubles being
: >: >converted to integers to match a function signature.  Some people
: would
: >: >consider that an error and not a feature.
: >
: >: Personally I don't like implicit "narrowing" conversions like double
: >: to int. But removing all such from the language would break far too
: >: much code.  Some compilers warn about the conversions.
: >
: >: I don't know of any formal proposal to eliminate even some of the
: >: implicit conversions from the language.
: >
: >: ---
: >: Steve Clamage, stephen.clamage@eng.sun.com
: >
: >You could use the explicit keyword in the function declaration such as:
: >
: >int foo (int a, explicit int b);
: >
: >Where conversions could be applied to the first argument, but not to the
: >second.  Promotions would be allowed, but not conversions.  This would
: >not break code and allow those who wish to be picky about how functions
: >are called.
: >

:  The compiler I use warns me when I do this. I don't see any need
: to formalize this warning with a language extension.
:  Further, this particular suggestion puts the information in the
: wrong place. The implementor of foo() shouldn't care at all how I figured
: out what value to pass to it. foo()'s operation isn't affected by that in
: any way, so foo() has no business telling me that I can't use implicit
: conversions in calling it.
:  -- Pete

If you put it in the prototype then the users can decide as you want.  I
agree a warning message should be sufficient, but in a large project
warnings get ignored and I don't believe there is any requirement that a
warning gets generated.

Douglas Clinton (dec@gsl.com) wrote:
: In article <3ci96a$5ne@cronkite.seas.gwu.edu>, carson@gwis2.circ.gwu.edu (John Carson) writes:
: |> : >I heard a vague statement about an "excplicit" keyword being added to the
: |> : >language.  Can anyone clue me in about this?  I didn't see it in the 20
: |> : >Sept. 1994 working paper.
: |>
: |> : That's because it was voted on in the Nov 1994 meeting. Adding the
: |> : keyword in front of a constructor means that the constuctor will
: |> : not be used as an implicit type conversion:
: |>
: |> Sounds helpful to me.  Is there any way to turn off the "C" automatic
: |> conversions involved with function calls.  Example, doubles being
: |> converted to integers to match a function signature.  Some people would
: |> consider that an error and not a feature.

: Interesting idea. You could have something like this:

: void foo(explicit int i);

: This would mean that only an actual int, and not something implicitly
: convertible to int, would match this function.

: Doug

: --
: Douglas Clinton,  Greycourt Software Ltd, London, England
: Voice: +44 81 743 4578       Fax: +44 81 746 0982
: dec@gsl.com        (or dec@gcourt.demon.co.uk)
I guess I would accept that to prevent a double from being used.

In article fuj@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John Carson) writes:
>Pete Becker (pete@borland.com) wrote:
>: >You could use the explicit keyword in the function declaration such as:
>: >
>: >int foo (int a, explicit int b);
>: >
>: >Where conversions could be applied to the first argument, but not to the
>: >second.  Promotions would be allowed, but not conversions.  This would
>: >not break code and allow those who wish to be picky about how functions
>: >are called.
>
>:  The compiler I use warns me when I do this. I don't see any need
>: to formalize this warning with a language extension.
>:  Further, this particular suggestion puts the information in the
>: wrong place. The implementor of foo() shouldn't care at all how I figured
>: out what value to pass to it. foo()'s operation isn't affected by that in
>: any way, so foo() has no business telling me that I can't use implicit
>: conversions in calling it.
>:  -- Pete
>
>If you put it in the prototype then the users can decide as you want.  I
>agree a warning message should be sufficient, but in a large project
>warnings get ignored and I don't believe there is any requirement that a
>warning gets generated.

No, Pete is quite right. It doesn't make any sense to put it on the
prototype. The function expects to get an int, and it gets an int.

On what basis can you as the author of the function decide what kinds
of conversions are acceptable to create the int? You have no knowledge
of the context in which the value was created, and no way to find out.

Either the language supports implicit conversions from "wider" to "narrower"
types, or it doesn't. Some languages don't. C does, for good or evil or no
reason, and C++ inherits that behavior.

I see only two choices if you are unhappy with the status quo:

1. Disallow implicit "narrowing" conversions in the language. This will
break a lot of existing code which is nonetheless valid. (It will also
break some programs with invalid code, doubtless.)

2. Lobby your compiler vendor to provide diagnostics for such conversions.
You can then protect yourself and your projects against accidental
dangerous conversions. Some compilers already provide such diagnostics,
so this step may have already been done for you.

Aside: You can sort of provide this protection already, if you want to:

 inline int zzyzz(int& i) { return i; } // dummy function

 template <class T> inline void foo(int a, T b) {
  zzyzz(b); // compile-time error if T is a not an int
 }
 // specializations to prevent template instantiation
 void foo(int a, int b) { ... } // as above
 inline void foo(int a, short b) { foo(a, (int) b); }
 inline void foo(int a, char b) { foo(a, (int) b); }
 // and signed char, unsigned char, unsigned short

I can't imagine why you would want to bother with this, however.

---
Steve Clamage, stephen.clamage@eng.sun.com

: >I heard a vague statement about an "excplicit" keyword being added to the
: >language.  Can anyone clue me in about this?  I didn't see it in the 20
: >Sept. 1994 working paper.

: That's because it was voted on in the Nov 1994 meeting. Adding the
: keyword in front of a constructor means that the constuctor will
: not be used as an implicit type conversion:

: class string {
: public:
:    string(const char*);
:  explicit string(int size);
:  ...
: };

: extern void foo(string);

: foo("hello"); // ok, implicit conversion from char* to string
: foo(2);  // error, no implicit conversion from int to string
: foo(X(2)); // ok, if that is what you want to do

: Under current rules, one-argument constructors are dangerous, since
: you can silently get unintended type conversions. The new keyword
: makes them safe.
: --
: Steve Clamage, stephen.clamage@eng.sun.com
Sounds helpful to me.  Is there any way to turn off the "C" automatic
conversions involved with function calls.  Example, doubles being
converted to integers to match a function signature.  Some people would
consider that an error and not a feature.

John C.

In article 5ne@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John Carson) writes:

>Is there any way to turn off the "C" automatic
>conversions involved with function calls.  Example, doubles being
>converted to integers to match a function signature.  Some people would
>consider that an error and not a feature.

Personally I don't like implicit "narrowing" conversions like double
to int. But removing all such from the language would break far too
much code.  Some compilers warn about the conversions.

I don't know of any formal proposal to eliminate even some of the
implicit conversions from the language.

---
Steve Clamage, stephen.clamage@eng.sun.com

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: In article 5ne@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John Carson) writes:

: >Is there any way to turn off the "C" automatic
: >conversions involved with function calls.  Example, doubles being
: >converted to integers to match a function signature.  Some people would
: >consider that an error and not a feature.

: Personally I don't like implicit "narrowing" conversions like double
: to int. But removing all such from the language would break far too
: much code.  Some compilers warn about the conversions.

: I don't know of any formal proposal to eliminate even some of the
: implicit conversions from the language.

: ---
: Steve Clamage, stephen.clamage@eng.sun.com

You could use the explicit keyword in the function declaration such as:

int foo (int a, explicit int b);

Where conversions could be applied to the first argument, but not to the
second.  Promotions would be allowed, but not conversions.  This would
not break code and allow those who wish to be picky about how functions
are called.

John C.

carson@gwis2.circ.gwu.edu (John Carson) writes:

>I heard a vague statement about an "excplicit" keyword being added to the
>language.  Can anyone clue me in about this?  I didn't see it in the 20
>Sept. 1994 working paper.

It's a way of specifying that a single-argument constructor is only a
constructor, not also an implicit conversion.

 class Array {
 public:
  explicit Array(int); // "explicit" constructor - does not
     // act as an implicit conversion
 };

 Array x(3); // ok
 x = 3;  // error

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

It is implemented in g++.  The next major release of gcc will have it.

In article <3cfhr2$sug@cronkite.seas.gwu.edu>,
John Carson <carson@gwis2.circ.gwu.edu> wrote:
>I heard a vague statement about an "excplicit" keyword being added to the
>language.

In article <3cj7jv$82h@cronkite.seas.gwu.edu>, carson@gwis2.circ.gwu.edu
says...
>
>Steve Clamage (clamage@Eng.Sun.COM) wrote:
>: In article 5ne@cronkite.seas.gwu.edu, carson@gwis2.circ.gwu.edu (John
Carson) writes:
>
>: >Is there any way to turn off the "C" automatic
>: >conversions involved with function calls.  Example, doubles being
>: >converted to integers to match a function signature.  Some people
would
>: >consider that an error and not a feature.
>
>: Personally I don't like implicit "narrowing" conversions like double
>: to int. But removing all such from the language would break far too
>: much code.  Some compilers warn about the conversions.
>
>: I don't know of any formal proposal to eliminate even some of the
>: implicit conversions from the language.
>
>: ---
>: Steve Clamage, stephen.clamage@eng.sun.com
>
>You could use the explicit keyword in the function declaration such as:
>
>int foo (int a, explicit int b);
>
>Where conversions could be applied to the first argument, but not to the
>second.  Promotions would be allowed, but not conversions.  This would
>not break code and allow those who wish to be picky about how functions
>are called.
>

 The compiler I use warns me when I do this. I don't see any need
to formalize this warning with a language extension.
 Further, this particular suggestion puts the information in the
wrong place. The implementor of foo() shouldn't care at all how I figured
out what value to pass to it. foo()'s operation isn't affected by that in
any way, so foo() has no business telling me that I can't use implicit
conversions in calling it.
 -- Pete

I heard a vague statement about an "excplicit" keyword being added to the
language.  Can anyone clue me in about this?  I didn't see it in the 20
Sept. 1994 working paper.

Thanks in advance,

John C.

carson@gwis2.circ.gwu.edu (John Carson) writes:

>I heard a vague statement about an "excplicit" keyword being added to the
>language.  Can anyone clue me in about this?  I didn't see it in the 20
>Sept. 1994 working paper.

That's because it was voted on in the Nov 1994 meeting. Adding the
keyword in front of a constructor means that the constuctor will
not be used as an implicit type conversion:

class string {
public:
   string(const char*);
 explicit string(int size);
 ...
};

extern void foo(string);

foo("hello"); // ok, implicit conversion from char* to string
foo(2);  // error, no implicit conversion from int to string
foo(X(2)); // ok, if that is what you want to do

Under current rules, one-argument constructors are dangerous, since
you can silently get unintended type conversions. The new keyword
makes them safe.
--
Steve Clamage, stephen.clamage@eng.sun.com