🚀 go-pugleaf

In article <ejalbert-8448C2.14083019102000@nntp.stanford.edu>, Eric 
Albert <ejalbert@stanford.edu> wrote:
> I'm by no means an expert on automatic type conversions or const-ness in 
> C++, but I have some code that compiled without warnings or errors on 
> Pro 5.3 and now doesn't compile on Pro 6, and I'm wondering why.

The implicit conversion from 'char **' to 'const char **' is prohibited 
in C++; the simplest example I could come up with for this is:

  char **ary;
  const char **ary2;

  void test(void)
  {
     ary = ary2;  // fails (can't get rid of 'const' implicitly)
     ary2 = ary;  // fails (prohibited by standard)
  }

The standard explains it this way.  Consider the following sequence:

  const char c = 'c';                // a const char
  char *pc;                          // a pointer to a (non-const) char
  const char** pcc = &pc;            // *** PROHIBITED BY STANDARD ***
  *pcc = &c;                         // now pc points at c
  *pc = 'C';                         // this would modify a 'const' char

I'm not sure I fully understand the rationale here, but basically it 
seems that by turning the 'char **' into a 'const char **', you open an 
opportunity for assign a 'const char *' into a 'char *'....

Blecch.

> 1) What did Pro 6 change here that would make the promotion of a char 
> *[] to a const char *[] illegal?

  Looks like they follow the spec more closely now.

> 2) Why does a static cast to const char *[] fail while a static cast to 
> const char ** succeed?

  I'm not sure, but you probably want to use a const_cast here anyway 
since you're only affecting constness.

> 3) Why does the compiler think that the signature of AppendCStringArray 
> has a const char ** as the second parameter instead of a const char *[]?

  Because a function parameter of type "array of T" is converted to a 
parameter of type "pointer to T" when computing the signature of a 
function (section 8.3.5, paragraph 3).

  -- Anton

-- 
This is an unauthorized communication.  "The statements and opinions
expressed herein are my own and do not necessarily represent those of Adaptec."