Sign in to follow this  
ChaosPhoenix

VC++ not liking multiple function names with same number/types of variables.

Recommended Posts

Trying to do a robust GUI system and so I tend to use a lot of polymorphism to offer up a variety of options. No big deal right? Well, VC .NET 2003 doesn't seem to like it when I have 2 functions with the same number of parameters that happen to also be the same type but have different variable names. Example:
int CreateButton(char* cDefaultTexture, char* cHighlightTexture, D3DXVECTOR2* tPosition, bool bVisible);

int CreateButton(char* cDefaultTexture, char* cClickedTexture, D3DXVECTOR2* tPosition, bool bVisible);

I know I've seen various functions use polymorphism like this (same data types, different variable names). Is this really a violation of C++ and I've lost my mind, or is this just VC++ hating me?

Share this post


Link to post
Share on other sites
I think it's your function name (CreateButton). You might want to try changing it to something like GUICreateButton or CreateGUIButton. The reason I believe it's the function name is because windows uses the CreateButton function when creating buttons for the Win32 and/or MFC API. You can try doing that because it might be easiest. Hope this helps. Actually TheTroll is right. Your functions are not different so there is no need for them both. The only thing that is different is the variable name for your second parameter.

Share this post


Link to post
Share on other sites
Quote:
Original post by TheTroll
You can't do that. You need to have either different number of variables or different types. The compiler doesn't care about the names, they are irelivent.

theTroll



I figured as much.

Thanks.

Share this post


Link to post
Share on other sites
What's the purpose for the second function?

Here is an example of what I believe you wish to do.

char *ParseData(char *cData, int start, int end);
void ParseData(char *cData, int start, int end,char **retr);

Both are included in a class.

Share this post


Link to post
Share on other sites
This is not specific to Visual C++'s compiler, either. This is a language-level thing (when you think about it, it should be pretty obvious why this doesn't work).

A cursory search of the MSDN reveals no "CreateButton" function. However, even if one existed, its not really pertinant to the problem. A functions name and the types of its parameters are considered in overload resolution in C++, so unless his CreateButton function matched this mythical Win32 CreateButton function exactly in terms of parameter types, the compiler would be able to disambiguate the overload (at least between the "Win32" CreateButton and one of the OP's CreateButton functions).

Quote:

char *ParseData(char *cData, int start, int end);
void ParseData(char *cData, int start, int end,char **retr);


I understand what your trying to get at (overload selection is based on function name and parameter types, but not return type), but this example is not particularly clear because you've completely changed the function name and types and provided very little context or information about what exactly is going on.

To the OP: If you have two button creation functions that perform very different actions (it appears that you have one to create a button with a hilight texture, and one to create a button with a "clicked" texture -- why you need two separate functions for this isn't clear to me, but I digress) but require the same parameter types, you cannot rely on overloads to accomplish this -- you've got to name your functions two different things.

[Edited by - jpetrie on May 16, 2006 9:19:08 PM]

Share this post


Link to post
Share on other sites
Though it's not the problem in this specific case, darrenc182 has a valid point. If you happen to include windows.h, your code gets polluted with all sorts of macros like with pleasant names like 'CreateObject'. CreateObject is a winapi function. Instead of changing it's signature when they made a change, they created CreateObjectEx and made CreateObject a macro instead. This macro will silently change your code. Even worse, it will be changed in a compilation unit that includes windows.h - and not in one that doesn't! And it's dependant on the order of your includes!

Share this post


Link to post
Share on other sites
True, but since they are macros they'll change your code as well. It shouldn't cause errors of any sort (never has in my experience except with the min/max macros, which can be suppressed easily), although it will change the names of some functions slightly which may confuse you when reading compile or error messages.

The Win32 API had to maintain backwards compatibility with C code, thus the new functions and macros to wrap them (C does not support function overloading). It is true that a translation unit that doesn't see the Windows header won't see the macros and thus you might get some errors. Most of the time windows.h gets included before your header or jammed into a precompiled header someplace where it gets included by everything, so these issues don't actually surface as often as they could.

Share this post


Link to post
Share on other sites
It's much worse than that. Changing the name of the function just scratches the surface (besides that it can change it in some compilation units and not others); the macros also silently add default parameters, and heaven forbid you're using templates with more than one parameter! It's a mess, it's sloppy coding, and it's just plain UNFRIENDLY.

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