>
> The purpose of the defect report was to raise the issue of qualification
> conversions of pointers to arrays, and that still stands.
> The proposed resolution might need removal of "reference to" as a valid type
> for P0, but this shouldn't affect the bulk of the DR itself.

You've lost me.  (And the beginning of the thread seems to be gone
from my server).

Both cases you've shown are not permitted by the existing standard.
What exactly are you proposing needs fixing, again?

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Ron Natalie wrote in message <3C348FC0.9784F2BB@sensor.com>...
>Roger Orr wrote:
>>
>> Artem Livshits wrote ...
>> [snip]
>>
>> I've just re-posted the text as defect report.
>
>I don't think it's a defect.

Sorry, I was not terribly clear about _which_ text I posted :)

The purpose of the defect report was to raise the issue of qualification
conversions of pointers to arrays, and that still stands.
The proposed resolution might need removal of "reference to" as a valid type
for P0, but this shouldn't affect the bulk of the DR itself.

>It's not permitted because
>the converted value of int* to const int* in p1 isn't
>an rvalue and should not be allowed to initialize a
>non-const reference.

Good, so the reference case is already covered and Borland/MSVC are just
incomplete.
I assume you're referring to 8.5.3 - or are there other relevant sections?

Roger Orr
--
MVP in C++ at www.brainbench.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.research.att.com/~austern/csc/faq.html                ]

Artem Livshits wrote ...
[snip]

I've just re-posted the text as defect report.

>Speaking about P0 being a reference, I keep in mind an example like this:
>
>// ---- begin program ---------
>
>#include <stdio.h>
>
>extern const int x;
>
>int main()
>{
>   int * p1 = 0;
>   const int * &p2 = p1; // should be illegal
>   p2 = &x;
>   *p1 = 20;
>
>   printf("x = %d\n", x);
>}
>
>const int x = 10;
>
>// ---- end program -----------
>
>It, by the way, compiles well on Borland 5.5 and MSVC++ 6.x, but clearly
>produces undefined behaviour.

Although IMHO I agree that the code appears to comply with
the standard :)
I find www.comeaucomputing.com/tryitout gives:-

"16362.c", line 8: error: a reference of type "const int *&" (not
          const-qualified) cannot be initialized with a value of type "int
*"
     const int * &p2 = p1; // should be illegal                       ^
1 error detected in the compilation of "16362.c".

which is a good catch by comeau, but I don't know what part of the standard
makes this fail to compile !

Roger.
--
MVP in C++ at www.brainbench.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.research.att.com/~austern/csc/faq.html                ]

Roger Orr wrote:
>
> Artem Livshits wrote ...
> [snip]
>
> I've just re-posted the text as defect report.

I don't think it's a defect.  It's not permitted because
the converted value of int* to const int* in p1 isn't
an rvalue and should not be allowed to initialize a
non-const reference.

The Sun compiler complains.

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

"Roger Orr" <rogero@howzatt.demon.co.uk> wrote in message
news:1009579554.28138.0.nnrp-14.9e98aa01@news.demon.co.uk...
 > Artem Livshits wrote in message ...
 > >"Rani Sharoni" <rani_sharoni@hotmail.com> wrote in message
 > [snip]
 > >> Can anyone tell (and justify) why the third assignment in the
 > >> following code isn't allowed in C++
 > >>
 > >> int
 > >> main()
 > >>
 > >
 > >>     double *array2D[2][3];
 > >>
 > >>     double       *       (*array2DPtr1)[3] = array2D;     // Legal
 > >>     double       * const (*array2DPtr2)[3] = array2DPtr1; // Legal
 > >>     double const * const (*array2DPtr3)[3] = array2DPtr2; // Illegal -
 > >> why?
 > [snip]
 > >I think so. IMHO, there is no difference (in the sense of qualification
 > >conversions) between your example and the following:
 > >
 > >int main()
 > >{
 > >  double *array[2];
 > >  double       *       *ppd1 = array; // legal
 > >  double       * const *ppd2 = ppd1;  // legal
 > >  double const * const *ppd3 = ppd2;  // certainly legal (4.4/4)
 > >
[snip]
 >   double* array[2][3];
 >   typedef double* (slice)[3];
 >
 >   slice *arrayPtr1 = array; // Ok
 >   slice const *arrayPtr2 = arrayPtr1; // Ok
 >
 >   typedef double const * (c_slice)[3];
 >   c_slice const *arrayPtr3 = arrayPtr2; // Fails
 >
 > c_slice and slice differ by more than simple const-ness.
 >
 > Technically the pointed to types are unrelated since nothing in the
relevant
 > section of the standard covers it - 4.4 does not mention converting the
type
 > "cv array of N pointer to T" into "cv array of N pointer to cv T"
 >
 > I agree that there is no 'real' difference in terms of qualification
 > conversions between the original example and your simplified one.
 > However 4.4/4 is written solely in terms of pointers and so has nothing to
 > say about the case where an intermediate type is an array.
 >
 > Have we missed anything, or should this become a defect report?

I suppose if the definition of "similar" pointer types in 4.4/4 was
rewritten like this:

T1 is cv1,0 P0 cv1,1 P1 ... cv1,n-1 Pn-1 cv1,n T
and
T2 is cv1,0 P0 cv1,1 P1 ... cv1,n-1 Pn-1 cv1,n T

where Pi is either a "pointer to" or a "pointer to an array of Ni"; besides
P0 may be also a "reference to" or a "reference to an array of N0" (in the
case of P0 of T2 being a reference, P0 of T1 may be nothing).

it would address the problem.

In fact I guess Pi in this notation may be also a "pointer to member", so
4.4/{4,5,6,7} would be nicely wrapped in one paragraph.

Speaking about P0 being a reference, I keep in mind an example like this:

// ---- begin program ---------

#include <stdio.h>

extern const int x;

int main()
{
   int * p1 = 0;
   const int * &p2 = p1; // should be illegal
   p2 = &x;
   *p1 = 20;

   printf("x = %d\n", x);
}

const int x = 10;

// ---- end program -----------

It, by the way, compiles well on Borland 5.5 and MSVC++ 6.x, but clearly
produces undefined behaviour.


Artem Livshits
Brainbench MVP for C++
http://www.brainbench.com



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ 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.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]