• Advertisement

Archived

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

My compiler is rewriting my code!

This topic is 5150 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'
        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]

Share this post


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

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

Share this post


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

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
And on top of that, macro''s can not be put into namespaces.

I''ve spent quite some hours messing with a similar problem, they should lock up the people who place #defines for words like that in headers. I mean, if it was win32_FindResource, allright, but they really could expect someone else to use the name FindResource somewhere.

Share this post


Link to post
Share on other sites
Well macros are really outdated now with inline functions. I know that the Windows API was back in the good old "C" days, but it never hurts to dream of a sunny tomorrow

Share this post


Link to post
Share on other sites
quote:
Original post by AndyTX
Well macros are really outdated now with inline functions. I know that the Windows API was back in the good old "C" days, but it never hurts to dream of a sunny tomorrow


You have no clue what the defines in windows.h are used for, do you?

If you #define UNICODE, all the Win32 functions will map via macros to SomeFunctionW, otherwise they will map to SomeFunctionA. It''s a fairly clean way to do it...most of the time. This is conditional define magic, not inlining.

Share this post


Link to post
Share on other sites
I understand that completely - hence my original comment. The second response was to do with MACROS, as stated.

The "unicode" type of thing, while being "typical" to do it that way, can be as easily (and more robustly) done with namespaces and templates etc. in C++, but as was previously discussed, the Windows API was not written with these things in mind (for good or for bad).

Share this post


Link to post
Share on other sites
quote:
Original post by targhan
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.


Dear God.

Share this post


Link to post
Share on other sites

  • Advertisement