My compiler is rewriting my code!

Started by
13 comments, last by pan narrans 20 years, 3 months ago
OK, this error has got me beat. In my code I have this:
cTextureResource *Texture = TexturePool.FindResource("Texture1");  
And I get the error:
C2039: 'FindResourceA' : is not a member of 'cResourcePool'
        with
        [
            T=cTextureResource
        ]  
I'm using Visual C++ .NET and I don't understand why the compiler is seeing it as FindResourceA when I have written FindResource. If I go through my code and change FindResource to FindResourceA, it works! So why is my compiler deciding to rewrite my code? I presume there is some kind of clash with the Windows FindResource function, but shouldn't the compiler realise that I am calling the member of cResourcePool? I could obviously fix this by changing the name, but I'd like to understand what is going on too. pan narrans | My Website | Study + Hard Work + Loud Profanity = Good Code [edited by - pan narrans on January 14, 2004 2:43:37 PM]
Minister of Propaganda : leighstringer.com : Nobody likes the man who brings bad news - Sophocles (496 BC - 406 BC), Antigone
Advertisement
Because there is a #define that does that in windows.h

Most of the functions in windows.h are actually defines, to eithery the A or W version (ANSI or Wide character versions), in order for the UNICODE define to make your app compile as unicode.
--------------------------------"I'm a half time coder, full time Britney Spears addict" Targhan
Probably what''s happening is that you''re including windows.h or some other include file from the Platform SDK. In these headers many windows functions are written so that SomeFunc is #define''d to be SomeFuncA or SomeFuncW depending if it''s a Unicode build or not. FindResource is aparantly one of these functions.

Try to #undef FindResource somewhere before the line of code that''s giving you errors.
So that puts the FindResource name kind of off limits then, eh

pan narrans | My Website | Study + Hard Work + Loud Profanity = Good Code
Minister of Propaganda : leighstringer.com : Nobody likes the man who brings bad news - Sophocles (496 BC - 406 BC), Antigone
This is one of the situations where "macros are evil" rears
its ugly head.

The function macros in "windows.h" hijack the names and
make it impossible to use the names in my own classes,
without doing some sort of #undef trickery and other
fun stuff. In the end, I just chose to use another name.
Such inconvenience!

Yep, FindResource is one of those damned macros that change
to FindResourceA or FindResourceW.

I lost count of the number of times I''ve been bitten by it.



Kami no Itte ga ore ni zettai naru!
神はサイコロを振らない!
Amen, brother!

pan narrans | My Website | Study + Hard Work + Loud Profanity = Good Code
Minister of Propaganda : leighstringer.com : Nobody likes the man who brings bad news - Sophocles (496 BC - 406 BC), Antigone
quote:Original post by pan narrans
So that puts the FindResource name kind of off limits then, eh


Or just

#ifdef FindResource
# undef FindResource
#endif

"Without deviation, progress itself is impossible." -- Frank Zappa
"There is only one everything"
the moment i started to work with windows was the moment i dropped

CapitalLetterFunctions()

and moved to

smallLetterFunctions() instead..

because createWindow works, but CreateWindow doesn''t.

you found another example.



If that''s not the help you''re after then you''re going to have to explain the problem better than what you have. - joanusdmentia

davepermen.net
If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia

My Page davepermen.net | My Music on Bandcamp and on Soundcloud

If everyone used namespaces how they were intended the world would be a better place Then again, Microsoft is certainly not the model by which to code...
Well the Win32 API was written in C, before C++ became standard. Namespaces were not an option.

This topic is closed to new replies.

Advertisement