In article <3dcp8c$h9i@news.iastate.edu>, guthrie@miu.edu writes:
[..]
|> Why can't we allow "const" as a type modifyer, i.e. it can
|> incrementally modify a type, without re-declaring the full specifier.
|> After all, it is independent of all other type specifications. Of
|> course this is important mostly for call-by-reference (CBR).
|>
|> E.g.
|>    int i;
|>
|>    fun( const(i) );      // protect argument against CBR modifications
|>
|>    fun( (const int)i);   // long-winded version..
|>
|> This is better in that it is shorter, and more semantically
|> appropriate, i.e. one only says what one means; in this case
|> that: whatever type i is, force it to be const, before considering any
|> conversions in passing as a parameter.
|>
|> This is one of those features that is probably "too late", but IMHO
|> would be a useful addition, and infact reduce complexity of usage by
|> decoupling const-ness from other type info.

You are talking about the new const_cast<>.

 fun( const_cast<const int> i );

Note, that the compiler checks that you are not modifying the type
but ONLY the constness (add/remove const/volatile-qualifiers).
Yes it would be shorter to allow obmission of the type:

 fun( const_cast<const> i );

but that would make it less general. const_cast<> can also be used
for composed types:

 int **i;
 fun( const_cast<const int*const*const> i );

 const int * const * const j;
 fun( const_cast<int**> i );

How would you do that and how would you _remove_ constness with
your example-notation?

Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Institut f   r Informatik, Technische Universit   t M   nchen.
email: schuenem@informatik.tu-muenchen.de

In article <schuenem@Informatik.TU-Muenchen.DE> writes:
> In article <3dcp8c$h9i@news.iastate.edu>, guthrie@miu.edu writes:
> [..]
> |> Why can't we allow "const" as a type modifyer, i.e. it can
> |> incrementally modify a type, without re-declaring the full
specifier.
> |> E.g.
> |>   int i;
> |>   fun( const(i) );  // protect argument against CBR modifications
> |>   fun( (const int)i);  // long-winded version..
> |>
> |> This is better in that it is shorter, and more semantically
> |> appropriate, i.e. one only says what one means; in this case
> |> that: whatever type i is, force it to be const, before considering
any
> |> conversions in passing as a parameter.
> |>... reduce complexity of usage by
> |> decoupling const-ness from other type info.
>
> You are talking about the new const_cast<>.
> Yes it would be shorter to allow omission of the type:
>
>  fun( const_cast<const> i );
>
> but that would make it less general.
>
> How would you do that and how would you _remove_ constness with
> your example-notation?
I wouldn't.
Thanks for the information.
I wish there was some group that published these new [proposed]
features!

Yes, the dynamic casting feature is more general, but it seems like 90%
of the cases is CBR protection, i.e. adding const'ness, and although
the ability only at the outermost level is indeed not as general,
doesn't it seem like this is the most frequent case, and that indeed
adding such a (const) cast would be useful, and not opposed to the more
general (and verbose) const_cast feature.

Gregory Guthrie

schuenem@Informatik.TU-Muenchen.DE (Ulf Schuenemann) writes:

>guthrie@miu.edu writes:
>[..]
>|> Why can't we allow "const" as a type modifyer, i.e. it can
>|> incrementally modify a type, without re-declaring the full specifier.
[...lots elided...]
>How would you do that and how would you _remove_ constness with
>your example-notation?

You'd cast to (~const), of course! ;-)

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

> <<The simple C rule that
> <<calling a function will not modify your variables, unless you pass
an
> <<address ...)

> ... but the point about the C++ subversion
> of C's guarantee about not mucking with your parameters, is well
taken, and is
> (IMHO) a serious defect.

Why can't we allow "const" as a type modifyer, i.e. it can
incrementally modify a type, without re-declaring the full specifier.
After all, it is independent of all other type specifications. Of
course this is important mostly for call-by-reference (CBR).

E.g.
   int i;

   fun( const(i) );      // protect argument against CBR modifications

   fun( (const int)i);   // long-winded version..

This is better in that it is shorter, and more semantically
appropriate, i.e. one only says what one means; in this case
that: whatever type i is, force it to be const, before considering any
conversions in passing as a parameter.

This is one of those features that is probably "too late", but IMHO
would be a useful addition, and infact reduce complexity of usage by
decoupling const-ness from other type info.