delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1999/01/20/18:05:21

From: fjh AT cs DOT mu DOT OZ DOT AU (Fergus Henderson)
Subject: Re: B20: typedef bug?
20 Jan 1999 18:05:21 -0800 :
Message-ID: <19990120234520.08907.cygnus.gnu-win32@mundook.cs.mu.OZ.AU>
References: <000701ba00e6$4826f260$9d6b1581 AT d110-1007 DOT rit DOT edu>
Mime-Version: 1.0
To: exe <Geed AT kong DOT net>
Cc: gnu-win32 AT cygnus DOT com

This has nothing to do with Cygwin.
Please ask such questions (and direct any follow-ups)
to the newsgroup comp.lang.c++.moderated.

On 02-Apr-1995, exe <Geed AT kong DOT net> wrote:
> typedef char bmp_t[480][640];
> 
> void main() {
>   bmp_t*bmp=new bmp_t;
> }
> 
> results in...
> 
> test.cc: In function `int main(...)':
> test.cc:4: initialization to `char (*)[480][640]' from `char (*)[640]'
> 
> This occures in 3 different compilers (including non gnu-cpp), so mabey typedef was not intended to be used this way.
> It does appear to be a bogus error though.

You can argue about the merits of the language design, but
the compiler is correctly following the ISO C++ standard.
When you allocate an array using `new', it returns a pointer to
the first element.  This is true whether or not you use a typedef.

> the only good workaround I found is to create a macro that typecasts
> another type

A simpler alternative is

	bmp_t *bmp = new bmp_t[1];

However, you need to remember to deallocate it using

	delete [] bmp;

rather than just

	delete dmp;

Another alternative is to wrap the array inside a struct.

-- 
Fergus Henderson <fjh AT cs DOT mu DOT oz DOT au>  |  "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh>  |   but source code lives forever"
PGP: finger fjh AT 128 DOT 250 DOT 37 DOT 3        |     -- leaked Microsoft memo.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019