James Kanze wrote:
>
<snip>
> with specializations for the built-in types.  The problem with this
> solution is that it is not standardized: my code (and templates) uses
> asInt, yours uses as_int, someone elses castToInt, and so forth.
>

You have stated in much clearer language my original complaint with
c_str().
It is easy for me to remember that string can convert to a const char*.
It is more difficult to remember if the method is c_str(), cStr(),
asCStr(), etc.  The cast provides the "standard" method name.  However,
implicitly called casts are sometimes (often?) not a good idea.  Thus
the motivation for the explicit qualifier.

-Howard
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

danm@ziplink.net (Dan Muller) writes:

|>  In article <rf5lo78jpn3.fsf@vx.cit.alcatel.fr>, james-
|>  albert.kanze@vx.cit.alcatel.fr says...
|>  > It is not unreasonable for a template to request that a type "be
|>  > convertable to int"; the STL does it in certain cases, to.
|>
|>  I have never encountered this in the STL. Are you sure?

Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  Howard E. Hinant wrote:
|>  >
|>  > I like the explicit modifier that you can give to single argument
|>  > constructors.  In fact I think its such a good idea, that it should be
|>  > extended to conversion operators:
|>  >
|>  > class A {
|>  > public:
|>  >    explict A(int);
|>  >    explict operator int() const;
|>  > };
|>
|>  It is needed for ctors because otherwise you can't use single
|>  argument ctor in some context; it is not with convertion
|>  operator because you are not forced to use a convertion operator.
|>
|>  > The meaning is that A will convert to int, but only if you explicity
|>  > cast it.  This would solve problems like the c_str method in string.
|>  > c_str is a problem because it is another method name to remember.  If I
|>  > could instead say (const char*)string to achive the same thing, I no
|>  > longer have to remember c_str().
|>
|>  I prefer a clear name; there are enought meaning for casts
|>  in C++. If you can't remember a name, will you be able to
|>  remember its meaning ?

I agree in general, and have long argued exactly the same.  The more I
work with templates, however, the more I doubt.

It is not unreasonable for a template to request that a type "be
convertable to int"; the STL does it in certain cases, to.  It is also
not unreasonable to have a class which will not convert *implicitly* to
int, only explicitly.  Outside of templates, it is not unreasonable --
IMHO, it is even preferable -- for the explicit conversion to be written
"asInt", or whatever.  Within templates, however, this causes a problem;
"long" is a "class" which converts to int, but the conversion function
is called "static_cast< int >", and not "asInt".

On the other hand, one could suppose a global template function:

 template< class T >
 int
 asInt( T const& v )
 {
  return v.asInt() ;
 }

with specializations for the built-in types.  The problem with this
solution is that it is not standardized: my code (and templates) uses
asInt, yours uses as_int, someone elses castToInt, and so forth.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <rf5lo78jpn3.fsf@vx.cit.alcatel.fr>, james-
albert.kanze@vx.cit.alcatel.fr says...
> It is not unreasonable for a template to request that a type "be
> convertable to int"; the STL does it in certain cases, to.
>

I have never encountered this in the STL. Are you sure?

--
Dan Muller   danm@ziplink.net
http://www.ziplink.net/~danm
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

danm@ziplink.net (Dan Muller) writes:

> In article <rf5lo78jpn3.fsf@vx.cit.alcatel.fr>, james-
> albert.kanze@vx.cit.alcatel.fr says...
> > It is not unreasonable for a template to request that a type "be
> > convertable to int"; the STL does it in certain cases, to.
> >
>
> I have never encountered this in the STL. Are you sure?

"Convertible to bool" shows up in many places.  The function object
argument to sort(), for example, must have an operator()() whose
return type is convertible to bool.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I like the explicit modifier that you can give to single argument
constructors.  In fact I think its such a good idea, that it should be
extended to conversion operators:

class A {
public:
   explict A(int);
   explict operator int() const;
};

The meaning is that A will convert to int, but only if you explicity
cast it.  This would solve problems like the c_str method in string.
c_str is a problem because it is another method name to remember.  If I
could instead say (const char*)string to achive the same thing, I no
longer have to remember c_str().

I know that there are to be no more changes to the draft, but if others
think this is a good idea, perhaps it could make it into the next
standard.

-Howard
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Howard E. Hinant" <heh@beamtech.DOTcom> wrote:

>I like the explicit modifier that you can give to single argument
>constructors.  In fact I think its such a good idea, that it should be
>extended to conversion operators:

> ...

>I know that there are to be no more changes to the draft, but if others
>think this is a good idea, perhaps it could make it into the next
>standard.

>-Howard

I think this is an excellent idea. It would be more consistent and, as
well as being useful in the case of dangerous conversions such as
c_str(), would also allow those who dislike implicit conversions (not
me) to code in a style requiring explicit casts.

,Brian Parker (bparker@gil.com.au)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Howard E. Hinant wrote:
>
> I like the explicit modifier that you can give to single argument
> constructors.  In fact I think its such a good idea, that it should be
> extended to conversion operators:
>
> class A {
> public:
>    explict A(int);
>    explict operator int() const;
> };

It is needed for ctors because otherwise you can't use single
argument ctor in some context; it is not with convertion
operator because you are not forced to use a convertion operator.

> The meaning is that A will convert to int, but only if you explicity
> cast it.  This would solve problems like the c_str method in string.
> c_str is a problem because it is another method name to remember.  If I
> could instead say (const char*)string to achive the same thing, I no
> longer have to remember c_str().

I prefer a clear name; there are enought meaning for casts
in C++. If you can't remember a name, will you be able to
remember its meaning ?

For example with string the semantic of c_str is return a
pointer to zero-terminated char array valid until destruction
or reallocation of string; it's IMO really easier to remember
the name c_str than these restrictions.

Please note that, unlike some people, I'm not against implicit
conversions in general, but c_str has to be explicit (at least
it's the intent; I'm for the implicit conversion to const char*)
and (const char*) str is not very clear.

Also what do you do with (char*) str ? You would have to
make detailed rules about all the cases.

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]