In article <COLIN.94Sep10175330@rafferty.rafferty.com>, colin@rafferty.com (Colin Owen Rafferty) writes:
|> In article <KANZE.94Sep9174258@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
|> > In article <530@dawes.win.net> beman@dawes.win.net (Beman Dawes) writes:
|>
|> > |> There has been a formal proposal, 94-0090/N0477, Preventing Implicit
|> > |> Conversions via one-argument Constructors, by Nathan Myers.  My
....
|>
|> I think that it would be a bad idea, because it is not necessary.  It is
|> very simple to get around the problem by using a helper class as the
|> single argument to the constructor.
|>
|>   class NoConvertInt {         // Helper class for argument
|>       int value;
|>     public:
|>       NoConvert(int arg) : value(arg) {}
|>       operator int() { return value; }
|>   };
|>
|>   class NoConvert {
|>     public:
|>       NoConvert(NoConvertInt nci);
|>       ...
|>   };
|>
|> Then, if I have function f(NoConvert), if I call f(3), it will not
|> construct a NoConvert, but I can still create a NoConvert object with an
|> int (since the in will implicitly be converted to a NoConvertInt):
[...]

Hello,
it's nice to prevent unwanted conversion in that way if you deal
with simple cases.
But in my opinion this method has some disatvantages:

 -> Are you sure, that you'll always recognice all the side effects
    of the implicit conversions large progams /libaries ?

 -> Suppose you want to write a library using templates und various
    single argument constructors and to avoid implicit type conversions.
    Then you'll have to spoil your code with a lot of NonConvertType classes.
    You may have a lot of different single argument contsructors for each class!

 -> Since I've spent ages to find errors due to implicit type conversions
    in FORTRAN-programs of fellow students, I suppose that a lot progammers
    aren't aware of this problem and there should be an obvios way to
    avoid this problem.

 -> In my opinion constructors without type conversion are more logical
    than a Non-converting-auxiliary-class-construction.

Besides I do not miss 'while{}' and 'do{}while' loops, allthough 'for(..;..;..)'
loops are sufficient.

Regards
      Peter Schmitteckert

P.S.
If you're interested I will mail you a short program, which I've posted here
in Janauary. It's an implementation of non-commuting variables (a*b == -b*a ).
You're invited to extend this source using templates
(anti<double> , anti<int>, anti<char>, anti<matrix_class> ...)
and to proof, that the source is easier to read with
a Non-converting-auxiliary-class-construction than with 'contructors without
typeconversions'.

P.P.S. You wrote "a very simple way ....".
     When I posted this problem in January first in comp.lang.c and then
     in comp.std.c++ and I got some mails telling me, that there's no
     way to avoid this problem. So your "simple way" is not obvious for
     everybody. :-)

In article <KANZE.94Sep9113122@slsvhdt.us-es.sel.de>, James Kanze US/ESC 60/3/164 #71425 (kanze@us-es.sel.de) writes:

>There has also been some discussion recently of introducing some way
>of allowing the user to disallow the use of certain constructors for
>type conversion.  A typical example is the case of an array of int
>which takes a single int parameter specifying the length of the array.
>It is typically an error to use this constructor for type conversion:
>the semantics are not what one wants for this use.
>
>If the committee finally does adapt something along these lines (not
>really very likely, since the current status is just vague discussion,
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>and not yet even a formal proposal), then there will be a distinct
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>difference:

That is not quite correct.

There has been a formal proposal, 94-0090/N0477, Preventing Implicit
Conversions via one-argument Constructors, by Nathan Myers.  My
understanding is that it is being worked on by Tom Plum's core group
rather than the extensions working group.

This is a well thought out proposal which deserves very careful
consideration, IMHO.  It preserves the current form of
constructors as is, including their use as conversions, and adds a
new form of constructor, prefixed with a new keyword "constructor"
which does not act as an implicit conversion.

-- Beman.

In article <530@dawes.win.net> beman@dawes.win.net (Beman Dawes)
writes:

|> In article <KANZE.94Sep9113122@slsvhdt.us-es.sel.de>, James Kanze US/ESC 60/3/164 #71425 (kanze@us-es.sel.de) writes:

|> >There has also been some discussion recently of introducing some way
|> >of allowing the user to disallow the use of certain constructors for
|> >type conversion.  A typical example is the case of an array of int
|> >which takes a single int parameter specifying the length of the array.
|> >It is typically an error to use this constructor for type conversion:
|> >the semantics are not what one wants for this use.

|> >If the committee finally does adapt something along these lines (not
|> >really very likely, since the current status is just vague discussion,
|>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> >and not yet even a formal proposal), then there will be a distinct
|>  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|> >difference:

|> That is not quite correct.

|> There has been a formal proposal, 94-0090/N0477, Preventing Implicit
|> Conversions via one-argument Constructors, by Nathan Myers.  My
|> understanding is that it is being worked on by Tom Plum's core group
|> rather than the extensions working group.

|> This is a well thought out proposal which deserves very careful
|> consideration, IMHO.  It preserves the current form of
|> constructors as is, including their use as conversions, and adds a
|> new form of constructor, prefixed with a new keyword "constructor"
|> which does not act as an implicit conversion.

Thanks for the correction.  My printed copies of the mailings are
bundled up due to moving at present, so I could not check.  (Probably
could have kept my mouth shut.)  So I was just exterpolating from what
I remembered from the email conversations.

I remember thinking at the time that it might not be a bad idea.  I
too have a number of classes where I don't want the constructor to be
used for conversions.
--
James Kanze      Tel.: (+33) 88 14 49 00     email: kanze@lts.sel.alcatel.de
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In article <KANZE.94Sep9174258@slsvhdt.us-es.sel.de> kanze@us-es.sel.de (James Kanze US/ESC 60/3/164 #71425) writes:
> In article <530@dawes.win.net> beman@dawes.win.net (Beman Dawes) writes:

> |> There has been a formal proposal, 94-0090/N0477, Preventing Implicit
> |> Conversions via one-argument Constructors, by Nathan Myers.  My
> |> understanding is that it is being worked on by Tom Plum's core group
> |> rather than the extensions working group.

> |> This is a well thought out proposal which deserves very careful
> |> consideration, IMHO.  It preserves the current form of
> |> constructors as is, including their use as conversions, and adds a
> |> new form of constructor, prefixed with a new keyword "constructor"
> |> which does not act as an implicit conversion.

> I remember thinking at the time that it might not be a bad idea.  I
> too have a number of classes where I don't want the constructor to be
> used for conversions.

I think that it would be a bad idea, because it is not necessary.  It is
very simple to get around the problem by using a helper class as the
single argument to the constructor.

  class NoConvertInt {         // Helper class for argument
      int value;
    public:
      NoConvert(int arg) : value(arg) {}
      operator int() { return value; }
  };

  class NoConvert {
    public:
      NoConvert(NoConvertInt nci);
      ...
  };

Then, if I have function f(NoConvert), if I call f(3), it will not
construct a NoConvert, but I can still create a NoConvert object with an
int (since the in will implicitly be converted to a NoConvertInt):

    NoConvert nc(3);

All that this does is add an extra name to the namespace for each class
that you don't want to have an implicit conversion for, but that's no
big deal.
--
<a href="http://rafferty.com/~colin/">Colin Rafferty</A>
--
"Where do these people come from?  Is there an agency out there that reads
 the Net and says "oops, not enough morons on this newsgroup" and then
 assigns some slack-jawed inbred grit-eatin' stooge to gum up the works?"
        --Jim Cowling