Jump to content
  • Advertisement


This topic is now archived and is closed to further replies.

pan narrans

My compiler is rewriting my code!

This topic is 5393 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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'
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]

Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
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.

Share this post

Link to post
Share on other sites
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!

Share this post

Link to post
Share on other sites
Original post by pan narrans
So that puts the FindResource name kind of off limits then, eh

Or just

#ifdef FindResource
# undef FindResource

"Without deviation, progress itself is impossible." -- Frank Zappa

Share this post

Link to post
Share on other sites
the moment i started to work with windows was the moment i dropped


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


Share this post

Link to post
Share on other sites
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...

Share this post

Link to post
Share on other sites

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!