C / C++ / MFC

13-Jan-05 16:25

I'm writing a class to read in a bitmap file, background information for your consumption. I'm trying to implement this but I get the errors:

...\489gui\bitmapFile.h(45): warning C4200: nonstandard extension used : zero-sized array in struct/union
...\489gui\bitmapFile.h(46): error C2229: class 'bitmapFile' has an illegal zero-sized array
...\489gui\bitmapFile.h(46): warning C4200: nonstandard extension used : zero-sized array in struct/union
        Cannot generate copy-ctor or copy-assignment operator when UDT contains a zero-sized array
...\489gui\bitmapFile.h(48): error C2229: class 'bitmapFile' has an illegal zero-sized array
...\489gui\bitmapFile.h(45): warning C4200: nonstandard extension used : zero-sized array in struct/union
...\489gui\bitmapFile.h(46): error C2229: class 'bitmapFile' has an illegal zero-sized array
...\489gui\bitmapFile.h(46): warning C4200: nonstandard extension used : zero-sized array in struct/union
        Cannot generate copy-ctor or copy-assignment operator when UDT contains a zero-sized array
...\489gui\bitmapFile.h(48): error C2229: class 'bitmapFile' has an illegal zero-sized array

Here is the code it's referring to...

(45) RGBQuad				aColors[];<br />
(46) BYTE				aBitmapBits[];<br />
(47)<br />
(48) bool endOfBitmap;<br />

I know what it says but I can't define the array sizes at compile time because they will change depending on information in the header. What can I do to get this working? Thanks in advance.

Member 211821713-Jan-05 20:59

Member 2118217

13-Jan-05 20:59

try to use pointer the and assign memory at runtime.

KaЯl14-Jan-05 1:51

KaЯl

14-Jan-05 1:51

LighthouseJ wrote:
RGBQuad aColors[];
You can't do that in C, this syntax isn't allowed. You should use a dynamically allocated array.

Define a pointer to point your future array:

RGBQuad *pMyArray;

Allocate it when you know the size:

<br />
pMyArray = (RGBQuad *)calloc(iSize, sizeof(RGBQuad));<br />

Reallocate it if needed

<br />
pMyArray = (RGBQuad *)realloc(iNewSize, sizeof(RGBQuad));<br />

Free the array when you don't need it anymore

<br />
free(pMyArray);<br />

You should have a look in MSDN or other sources for the different functions I mention, and perhaps take time to study memory managment with C.

HTH,

K.

Fold With Us!
Sie wollen mein Herz am rechten Fleck
Doch seh ich dann nach unten weg
Da schlägt es links

LighthouseJ14-Jan-05 3:41

14-Jan-05 3:41

I see what you mean and it makes sense but that seems to only allocate one element instead of more than one. The calloc line looks like:
bmpPallette = (RGBQuad *)calloc(palletteCount, sizeof(RGBQuad));
palletteCount is 0x100 (256) which is what it should be. It looks like it's simply allocating a new RGBQuad instead of an array of 256 RGBQuad's which is what it should do when I look at the calloc command.

KaЯl14-Jan-05 3:52

KaЯl

14-Jan-05 3:52

From MSDN[^]:
"The calloc function allocates storage space for an array of num elements, each of length size bytes. Each element is initialized to 0."

calloc(num, size) is similar to malloc(num * size)

LighthouseJ wrote:
It looks like it's simply allocating a new RGBQuad instead of an array of 256 RGBQuad's
How can you say that? Confused | :confused:

Fold With Us!
Sie wollen mein Herz am rechten Fleck
Doch seh ich dann nach unten weg
Da schlägt es links

LighthouseJ14-Jan-05 3:58

14-Jan-05 3:58

Because Visual Studio identifies it when I go to write code as a simple pointer to a single RGBQuad's instead of a pointer to 256 RGBQuad's. Maybe it's actually working but I don't know how to address it properly because I've never used a pointer to an array. I have that calloc page in my Visual Studio helpfile already and it made sense of what calloc does.

VC6 - bug - I desparately need advice

KaЯl14-Jan-05 4:17

KaЯl

14-Jan-05 4:17

Don't worry, it's working.

bmpPallette is a pointer (IMHO, it would be a good idea to have something in its name to identify it as a pointer, as pBmpPallette). A pointer is just an address, right? calloc will return the address of the first element of the array it allocates. bmpPalette points then on the first element of the array. Once the array allocated, you may access the different elements using bmpPallette[0], bmpPallette[1],...,bmpPallette[size-1].

For example:

bmpPallette[0].rgbRed = 255;
bmpPallette[0].rgbGreen = 0;
bmpPallette[0].rgbBlue = 128;

Disclaimer: In C, you have to take care of everything when it is about memory managment. I only mention there some of the basics. You really should have a look to a good tutorial, as http://www.le.ac.uk/cc/tutorials/c/ccccpont.html#PA[^]

Fold With Us!
Sie wollen mein Herz am rechten Fleck
Doch seh ich dann nach unten weg
Da schlägt es links

Installation Packege

Aqueel13-Jan-05 16:06

Aqueel

13-Jan-05 16:06

Thanks Budric, Blake, David, and Micheal! for helping me. I have another problem. Is there any option in "Microsoft Visual C++" compiler to create an "installation packege" of my project i.e. to install project on a pc? if not then please tell me how can i do this?

We Believe in Excellence

Re: Installation Packege

Toni7813-Jan-05 17:28

Toni78

13-Jan-05 17:28

I would suggest Inno Setup which is a very good tool and furthermore it's free. You can download it from this website http://www.jrsoftware.org/isinfo.php[^]

// Afterall, I realized that even my comment lines have bugs

If the sun were to blow up, it would take us 7-8 minutes to realize it. - Spacecast

Re: Installation Packege

Aqueel13-Jan-05 17:55

Aqueel

13-Jan-05 17:55

Thank you friend...

We Believe in Excellence

peterchen13-Jan-05 12:39

peterchen

13-Jan-05 12:39

Read my story, I desparately need advice.

Spent the last 8 hours extracting a nasty release build problem from a huge app to a standalone project, reproducing the problem in ca. 40 lines of code (Whew!)

Despite all my trust in Compiler and knowledge of C++ language pitfalls, and with all my debugging assembly experience I would say semi-proudly it is a bug in the optimizer.

The problem
- occurs only in Release Builds
- occurs with various optimization settings (including the release-default)
- with SP5 or SP6 installed
- on 3 different Developer PC's
- exposes an identical pattern of register misuse in all the iterations I took in isolating it
- does NOT occur when no SP is installed (don't have other SP's avail)
- does NOT occur on Standard edition (where no optimizer is included), independent of Service Pack
- it is straightforward code (no templates, but a few classes ond some basic COM stuff
is involved)

I have an workaround for the one place I isolated, but we have multiple problems with identical occurence pattern. They all revolve around a central data class.

Going back? They all surfaced not to long ago, but (a) I cannot safely determine the point of breakage, and (b) to many "pressing changes" have been included since. (Yes, we delayed finding these. Shame on us.)

The repro code still relies on _com_ptr_t, and some (arbitrary) COM object. With all my C++ power I cannot see anything wrong with the code.

options I see:
- disabling optimizations (YUCK. SLOW is not an option)
- going back to no service pack (I Don't want to)
- MS Support indident (I will do, but I don't expect much as this is VC6)
Any experiences with that?
- Disabling optimizations while moving to VC7.1 (messy, no time, wanted to wait for VC 2005)

Thank you for listening. Wish me Luck.

I never really know a killer from a savior
boost your code || Fold With Us! || sighist | doxygen

Ryan Binns13-Jan-05 12:59

Ryan Binns

13-Jan-05 12:59

Are you able to post those 40 lines of code that cause the problem. Perhaps another set of eyes can find something you missed (unlikely I know, but possible).

Man, you really confused me when I replied and found your post had disappeared Poke tongue | ;-P

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

peterchen13-Jan-05 13:17

peterchen

13-Jan-05 13:17

Someone considered it a programming question it seems Smile | :)

Well, I'm to tired to argue with anyone.

I'll poke some other eyes and sticks on the code tomorrow. My main problem is that fixing that one place doesn't help me, and I don't expect another patch from Microsoft either :-/

OK, tomorrow. tired. cat wants food.

I never really know a killer from a savior
boost your code || Fold With Us! || sighist | doxygen

IsaacLitingjun13-Jan-05 16:30

IsaacLitingjun

13-Jan-05 16:30

Best Wishes... Wink | ;)

- - - - - - - - - - - - - - - - - - - - - - - -
Many nights we've prayed with no proof anyone could hear, we were moving moutains long before we knew we could !
Yet now i'm standing here, although we know there's much to fear, hope seemed like summer bird too swiftly flown away ...

There can be miracles! When you believe, though hope is frail, it's hard to kill !
Who knows what miracles, you can achieve! When you believe, somehow you will ...

YOU WILL WHEN YOU BELIEVE

Ryan Binns13-Jan-05 17:32

Ryan Binns

13-Jan-05 17:32

peterchen wrote:
My main problem is that fixing that one place doesn't help me

No, but it might reveal the construct that is causing the problem and a way to get around it. I've had situations where the compiler has simply crashed trying to compile moderately complex logic, and it took forever to isolate where the problem was. I've also had "Internal Compiler Error"s when I've accidentally used bitwise rather than logical operators in conditional expressions.

Are you able to isolate which line of code (or near enough, considering the optimisation) causes the incorrect instructions?

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"

Stephen Muccione14-Jan-05 1:52

Stephen Muccione

14-Jan-05 1:52

Try disabling optimizations using pragma's and sucessively narrow down the area where optimizations are disabled until you can isolate the line that the problem is on... then either fix the issue by re-writing the line or simply leave optimizations disabled for that specific line.

steve

pointer declaration

Oriented13-Jan-05 12:38

Oriented

13-Jan-05 12:38

1. what are the differences among:
CString* str;
,
CString *str;
and
(CString*) str;
?!
2. what are LPVOID,LPCTSTR,LPTSTR,LPARAM...
(u may give me a link)
thx

Michael Dunn13-Jan-05 12:58

Michael Dunn

13-Jan-05 12:58

These two mean the same thing:

CString* str;
CString *str;

Since whitespace is not important, they have the identical meaning. The first one is more common among C++ programmers, while the second way is more common among old-school C programers.
This:

(CString*) str;

is not a declaration at all. It's an expression statement that casts str to CString* and then throws away the result.

--Mike--
LINKS~! Ericahist | 1ClickPicGrabber | CP SearchBar v2.0.2 | C++ Forum FAQ | You Are Dumb
Magnae clunes mihi placent, nec possum de hac re mentiri.

LighthouseJ13-Jan-05 13:00

13-Jan-05 13:00

1. There is no difference between the first and second declarations, but the third, you are casting str, whatever it is, as a CString and therefore is dissimmilar.

2. Those are data types that are all pointers to established types. LPVOID is a pointer to any type of data. LPCTSTR translates to an LPCWSTR (constant null-terminated string of 16-bit Unicode characters) if UNICODE is defined, else it defaults to constant null-terminated 8-bit Windows ANSI characters, in other words, if UNICODE is define, you'll get a wider string. LPARAM is a message parameter. I paraphrased from a Windows Data Types page in this Visual Studio .NET help file, not a website.

If anyone wants to correct something or add, be my guest.

samson197813-Jan-05 14:52

samson1978

13-Jan-05 14:52

i think the two replies above this one has done question 1 enough justice.
as for LPVOID, LPCTSTR, LPTSTR, LPARAM and so on... they are Microsoft
defined macros of otherwise basic types... think of it this way....

L = LONG = long
P = represents the * (pointer)
LP = pointer of size long
VOID = void
C = const
T = TCHAR
TCHAR = char or wchar_t depending on if the UNICODE macro is defined
STR = string
PARAM = parameter

so LPVOID is just (long) pointer to void/anything
LPCTSTR is just a (long) pointer to a const string of type TCHAR

for more Microsoft defined types lookup "Windows Data Types"

Cheers

Ryan Binns13-Jan-05 17:47

Ryan Binns

13-Jan-05 17:47

Actually, LPVOID and PVOID are the same thing. The L doesn't mean anything any more, and is simply a hangover from the 16-bit DOS/Windows days. Back then:

PVOID was a NEAR pointer that pointed to an address in the same segment and required 16 bits of storage
LPVOID was a FAR pointer that could point to anywhere in the memory address space and required 32 bits of storage

Under Win32, there is no concept of NEAR and FAR pointers since the address space is a flat 32-bit address space and segments are not required.

Ryan

"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"