Pro 6, const, and type conversions

Thread View: comp.sys.mac.programmer.codewarrior

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Eric Albert Thu, 19 Oct 2000 00:00

#1374

Author: Eric Albert
Date: Thu, 19 Oct 2000 00:00

70 lines
2975 bytes

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.

In newsession.cp, I have this:
extern char *cursorShapeStrings[] = {
   "Block",
   "Underscore",
   "Vertical Bar"
};

And in newsession.h, this:
extern char *cursorShapeStrings[];

I also have this method in MenuUtils.h:
static SInt16 AppendCStringArray(LMenuController *controller, const char 
*strings[], short length);

And I'm calling it like this from another class that #includes 
newsession.h:
MenuUtils::AppendCStringArray(button, cursorShapeStrings, 
NUM_CURSOR_SHAPES);

where button is an LPopupButton * (a subclass of LMenuController) and 
NUM_CURSOR_SHAPES is #defined as 3.

Pro 5.3 does the type conversion from char *[] to const char *[] just 
fine, and the call to AppendCStringArray compiles and works.  In Pro 6, 
I get this error:
---
Error   : function call 'AppendCStringArray(LPopupButton *, char *[], 
int)' does not match
'MenuUtils::AppendCStringArray(LMenuController *, const char **, short)'
---

I find that strange to begin with, since I'd expect the char *[] to be 
promoted to a const char *[] without any problems, and that a const char 
*[] would be equivalent to a const char ** (at least for parameter 
passing).

Making things more interesting, if I change the method call to this:
---
MenuUtils::AppendCStringArray(button, static_cast<const char 
*[]>(cursorShapeStrings), NUM_CURSOR_SHAPES);
---
I get this error:
---
Error   : illegal explicit conversion from 'char **' to
'const char *[]'
SettingsDialog.cp line 191   tils::AppendCStringArray(button, 
static_cast<const char*[]>(cursorShapeStrings), NUM_CURSOR_SHAPES);
---
but casting to a const char ** instead of a const char *[] works.

It also compiles if I change cursorShapeStrings to be const.

So I'm confused about three things:
1) What did Pro 6 change here that would make the promotion of a char 
*[] to a const char *[] illegal?
2) Why does a static cast to const char *[] fail while a static cast to 
const char ** succeed?
3) Why does the compiler think that the signature of AppendCStringArray 
has a const char ** as the second parameter instead of a const char *[]?

Thanks in advance,
Eric

-- 
Eric Albert         ejalbert@stanford.edu
http://www.stanford.edu/~ejalbert/

Re: Pro 6, const, and type conversions

#1378

Author: Anton Rang
Date: Fri, 20 Oct 2000 00:00

55 lines
3202 bytes

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."

Re: Pro 6, const, and type conversions

#1380

Author: Eric Albert
Date: Fri, 20 Oct 2000 00:00

21 lines
1387 bytes

In article <rang-927714.15311220102000@news.visi.com>, Anton Rang 
<rang@trillium.adaptec.com> wrote:

> 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: [two examples snipped]

That makes some sense to me.  Thanks for the explanation.

-Eric

-- 
Eric Albert         ejalbert@stanford.edu
http://www.stanford.edu/~ejalbert/

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads