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 Content-Type: text/plain; charset=us-ascii To: exe 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 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 | "Binaries may die WWW: | 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".