Sign in to follow this  
KanonBaum

Visual Studio 2008: 'W' is for WTF?

Recommended Posts

[img]http://a7.sphotos.ak.fbcdn.net/hphotos-ak-ash4/317617_10150426447891224_189155721223_10555263_1371273371_n.jpg[/img]

It is saying there is not such member 'GetObjectW' for ObjectGroup when CLEARLY the only method being called is 'GetObject'

What.

Share this post


Link to post
Share on other sites
Does that file directly or indirectly include windows.h or any of the other Windows headers? If so then you're now experiencing the joy of preprocessor rewrites of your code.

Share this post


Link to post
Share on other sites
You're definitely including a Windows header somewhere in this source file. Otherwise, you wouldn't get an error message since the Tmx::Object::GetObject would also be changed to Tmx::Object::GetObjectW. Therefore the Tmx::Object header is not including a Windows header and map.cpp (or one of its dependencies) is. See if [url=http://msdn.microsoft.com/en-us/library/hdkef6tk%28v=VS.100%29.aspx]/showIncludes[/url] shows anything suspicious.

Also, here's a quickfix:
[code]
#undef GetObject // OMG TEH WIN32 D:<
[/code]

Share this post


Link to post
Share on other sites
Did some research. Turns out the library I was using includes windows and it DOES in fact have a method named GetObject.

Using the quickfix before usage made it work. Thanks a bunch.

But WHY does Win32 DO that?? That's so messed up!

Share this post


Link to post
Share on other sites
[quote name='KanonBaum' timestamp='1318826389' post='4873313']
Did some research. Turns out the library I was using includes windows and it DOES in fact have a method named GetObject.

Using the quickfix before usage made it work. Thanks a bunch.

But WHY does Win32 DO that?? That's so messed up!
[/quote]

If you enable unicode support in your build windows.h automatically replaces a certain set of functions with their unicode equivalents and since its done using preprocessor macros they are effectivly just dumb text replacements (Which is one of the reasons why C++ macros are such an awful idea)

This problem exists for pretty much all functions in the Windows API.

Share this post


Link to post
Share on other sites
[quote name='shurcool' timestamp='1318827715' post='4873321']
They didn't consider the consequences of their decision hard enough at the time.
[/quote]
[i]at the time[/i], the dominant language was C, not C++, so function overloading wasn't an option. They could have just made everyone call the W version directly, but then people would have whined about how dumb all the API names were (like you sometimes see for the unicode C-runtime functions, e.g. wcslen). Plus Microsoft was already fighting an uphill battle to get people to accept that Unicode was a good thing rather than a waste of memory (ASCII should be good enough for anybody!) And even the people who were willing to accept Unicode didn't want to have to go through their entire program changing function names - porting to NT (from Win16) was enough work already. Plus if they did that then it wouldn't compile for 16-bit anymore and that was where the real market was.

The macros were a perfectly reasonable compromise [i]at the time[/i]. It is unfortunate that they don't provide a way to use overloading instead of macros for C++ nowadays, but I imagine there's little real benefit and it would very likely increase compile times in addition to making the headers simply bigger.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this