In article <23uu7t$dp4@paperboy.osf.org> karl@dme3.osf.org (Karl Heuer) writes:
>In article <23ufkl$oc6@fnnews.fnal.gov> b91926@fnclub.fnal.gov (David Sachs) writes:
>>By the way you should be saying "const T" instead of "T const"
>
>This is purely a style issue, isn't it?


Yes, of course... and `T const' is actually preferable (stylistically) for
a number of reasons.

It is a pity that authors of C and C++ books seem to universally eschew
this clearer style of writing declarations.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <KENNEDY.93Aug6100039@art.intellection.com> kennedy@intellection.com (Brian M Kennedy) writes:
>Well, it appears no one is aware of committee proposals/activity to add
>template typedefs (if you know of such, I'm still interested).

Hummm... The grammar given in section 17.8 of the ARM already seems to
allow them:

 template-declaration:
  template < template-argument-list > declaration

(Note that one valid kind of `declaration' is a typedef declaration.)

I know of no semantic rules which disallow them, so they must be legal
and valid.  So what's yer beef?  (Might it just be that your compiler
vendor has yet to supply you with a fully ARM-conformant compiler yet? :-)

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCBtK8x.Jy2@netcom.com>, rfg@netcom.com (Ronald F. Guilmette) writes:
|> `T const' is actually preferable (stylistically) ...


why?

--

    I won't rest till it's the best ...
    Software Production Engineer
    Paul Jackson (pj@sgi.com), x1373

In article <KENNEDY.93Aug6100039@art.intellection.com> kennedy@intellection.com (Brian M Kennedy) writes:

If I remember right, the committee has recently voted 'in' just this
set of 'safe' pointer to const-pointer conversions that you are looking
for.  The unsafe set of conversions still cannot be done explicitly
[as one would hope].

|Is anyone aware of any C++ standardization proposals or activity centered
|around conversion of pointers-or-references to pointers?
|
|To illustrate, consider a function `print_string_array` that should take
|a pointer to an array of char* pointers.  Its job is to print out each
|string pointed to be the array.  What should its argument type be?
|Its not going to modify anything, so it should be:
|
| print_string_array(char const *const * array_of_strs);
|
|That is, it should be a pointer to a const pointers to const chars.
|Thus, print_string_array can not modify the pointers in the array,
|nor can it modify the chars in the strings referenced by the array.  Perfect.

Well, it appears no one is aware of committee proposals/activity to add
template typedefs (if you know of such, I'm still interested).
Now let me ask about another topic--

Is anyone aware of any C++ standardization proposals or activity centered
around conversion of pointers-or-references to pointers?

To illustrate, consider a function `print_string_array` that should take
a pointer to an array of char* pointers.  Its job is to print out each
string pointed to be the array.  What should its argument type be?
Its not going to modify anything, so it should be:

 print_string_array(char const *const * array_of_strs);

That is, it should be a pointer to a const pointers to const chars.
Thus, print_string_array can not modify the pointers in the array,
nor can it modify the chars in the strings referenced by the array.  Perfect.

Now, I am in a class that keeps an internal char**, names, containing its
various names.  I want to print them, so I call:

 print_string_array(names);

And the compiler replies:

 error: no standard conversion of char** to const char**.
 (n.b. cfront erroneously allows such conversions, which of course
  allows a significant type hole)

The only way to do this, then, is with a cast-to-const, or by overloading
print_string_array to take both const and non-const forms.  Ick.

Now, I agree fully with disallowing char** to const char** conversions.
However, the only way that is bad is if you modify the pointer.  That
cannot be a problem with 'char const *const *'.  Thus, there is no loss
of type safety (that I am aware of) of allowing that conversion.

Thus, I would like to see an additional trivial conversion rule that
allows:

 T**  to T const *const *
 T*&  to T const *const &

or, in general

 T**...** to T const *const *const ... *const *
 T**...*& to T const *const *const ... *const &

As long as all the intermediate pointers are const, then the conversion
should be fine (shouldn't it?).

That would allow me to stop casting and to stop writing extraneous overloadings.

Comments?  Has this been considered in committee?
(Of course, my impression from discussions and news is that only a very small
 percentage of the C++ community try to write const-correct code -- it is just
 too painful.)


Thanks,

== Brian M Kennedy <kennedy@intellection.com> ==
== Intellection, Inc.  =========================

In article <23ufkl$oc6@fnnews.fnal.gov> b91926@fnclub.fnal.gov (David Sachs) writes:
>By the way you should be saying "const T" instead of "T const"

This is purely a style issue, isn't it?

In article <23ufkl$oc6@fnnews.fnal.gov> b91926@fnclub.fnal.gov (David Sachs) writes:

> However they apparently did the wrong thing with the corresponding conversion for "volatile". Apparently they approved allowing

> T** -> volatile T * volatile *

> the actual "safe" conversion should be

> T** -> volatile T * const *

The analysis is quite tricky, but one of our members has done it
and we will probably fix this problem at the November meeting.
--
    --Andrew Koenig
      ark@research.att.com

In article <KENNEDY.93Aug6100039@art.intellection.com>, kennedy@intellection.com (Brian M Kennedy) writes:
...
|> Thus, I would like to see an additional trivial conversion rule that
|> allows:
|>
|>  T**  to T const *const *
|>  T*&  to T const *const &
|>
|> or, in general
|>
|>  T**...** to T const *const *const ... *const *
|>  T**...*& to T const *const *const ... *const &
|>
|> As long as all the intermediate pointers are const, then the conversion
|> should be fine (shouldn't it?).
|>
|> That would allow me to stop casting and to stop writing extraneous overloadings.
|>
|> Comments?  Has this been considered in committee?

According to c++ report the standards comittee approved this change recently.

However they apparently did the wrong thing with the corresponding conversion for "volatile". Apparently they approved allowing

T** -> volatile T * volatile *

the actual "safe" conversion should be

T** -> volatile T * const *

By the way you should be saying "const T" instead of "T const"