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

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

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.

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.

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]

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.