Alberto Ganesh Barbati wrote:
> David Abrahams ha scritto:
> > AlbertoBarbati@libero.it (Alberto Ganesh Barbati) writes:

> >> Is there something we could do to fix the situation (in
> >> case there someone else that agree with me that the current
> >> definition is kind of "wrong")?

> > You know, bring proposals to the standard committee.

> The only thing that comes to my mind is to introduce #pragma
> notations as C does, for example:

> #pragma STDCPP FUNCTIONAL_CAST_IS_STATIC [on/off]

> Such approach might also be considered as a general framework
> for enforcing minor (but possibly breaking) behaviour changes,
> such as disallowing the deprecated string literal to non-const
> char* conversion.

> >> For example that could be achieved by deprecating (without
> >> removing) the reinterpret_cast-ness of the idiom, thus
> >> allowing compiler vendors to issue a warning without
> >> breaking existing code.

> > Compiler vendors are allowed to issue any warnings they like
> > without deprecations.

> Yes, but sometimes an official encouragement can be useful ;)

If you want to fiddle with the definitions of casts, I'd suggest
extending C style casts to allow them to be used for everything
the functional notation does, i.e. '(MyClass)( x, y, z )', etc.,
then deprecating the functional style casts completely.  Once
people start using the parentheses around the type
systematically, and something like:

    std::vector< int > v( (std::istream_iterator< int >)( fIn ),
                          (std::istream_iterator< int >)() ) ;

is the only non-deprecated way to write it, we've eliminated one
embaressing surprise that newbies (and all to often not so
newbies) encounter.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

David Abrahams wrote:
> AlbertoBarbati@libero.it (Alberto Ganesh Barbati) writes:

> > Do you know the rationale why the standard has defined
> > function-style casts that way?

> No; I'd check D&E if I was curious.

Even without checking D&E: function-style casts existed long
before the new cast syntax was invented.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ 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.comeaucomputing.com/csc/faq.html                      ]

David Abrahams ha scritto:
>     class Foo {};
>
>     Foo x = Foo("hello"); // error, as desired
>     int x = int("hello"); // no error
>

In fact I always wondered why function style casts are defined that way.
In practice 5.2.3 says that

   int(expr)

is equivalent to

   (int)(expr)

According to the least astonishing principle, it should have been
equivalent to

   static_cast<int>(expr)

instead... With this definition, int("hello") would be ill-formed. Do
you know the rationale why the standard has defined function-style casts
that way? Is there something we could do to fix the situation (in case
there someone else that agree with me that the current definition is
kind of "wrong")? For example that could be achieved by deprecating
(without removing) the reinterpret_cast-ness of the idiom, thus allowing
compiler vendors to issue a warning without breaking existing code.

Ganesh

---
[ 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.comeaucomputing.com/csc/faq.html                      ]

AlbertoBarbati@libero.it (Alberto Ganesh Barbati) writes:


> Do you know the rationale why the standard has defined
> function-style casts that way?

No; I'd check D&E if I was curious.

> Is there something we could do to fix
> the situation (in case there someone else that agree with me that
> the current definition is kind of "wrong")?

You know, bring proposals to the standard committee.

> For example that could
> be achieved by deprecating (without removing) the
> reinterpret_cast-ness of the idiom, thus allowing compiler vendors
> to issue a warning without breaking existing code.

Compiler vendors are allowed to issue any warnings they like without
deprecations.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.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.comeaucomputing.com/csc/faq.html                      ]