member methods overloading - have I gone stupid?

Hi ANYONE!
I'm using MS Visual Studio (I can only attribute this to the compiler), and have an overloaded method:

void FuncName(unsigned short id_num, Type_t &ret_val);
void FuncName(const char *id_name, Type_t &ret_val);

Where the "ret_val" may be found by it's numerical id (first func) or it's logical name (second).
When using the second method

FuncName("value_logical_name",ret_val);

I get a compiler error, that parameter one can not be converted from const char[] to unsigned short.
The only problem is that it is not constant!!! In some projects it will work, and in some it wont.

Does anybody have any idea why? Is it something with the project settings? WHAT?!
Thanks

Quote:

---

The only problem is that it is not constant!!!

---

No. The char * literal "value_logical_name" is a constant.

I have no problems compiling this code with VC++ 6.0

Code:

---

void FuncName(unsigned short id_num, int &ret_val);
void FuncName(const char *id_name, int &ret_val);

int main()
{
    int ret_val = 0;
    FuncName("value_logical_name",ret_val);
}

---

Maybe you should post the module that you say could not be compiled.

Regards,

Paul McKenzie

Hi Paul,
I've tried the old "Geronimo" play: I've switched the definitions of the methods around, and now everything works...
I've had several pairs of the methods, for different types of returned values. Some worked, some didn't, and different methods compiled or failed to compile on different instances.

(These are members of a class defined in DLL. The class is defined as __declspec(dllexport) and the project produces a .lib to link with)

bool GetSlong (unsigned short id, signed long& val);
bool GetSlong(const char* id, signed long& val);

bool GetUlong (unsigned short id, unsigned long& val);
bool GetUlong(const char* id, unsigned long& val);

bool GetUchar (unsigned short id, unsigned char& val);
bool GetUchar(const char* id, unsigned char& val);
etc....

All values are primitive types.

Either GetSlong will work, but the second GetUlong will not. On a different project, GetUlong(const char*....) will work fine.

Have you ever seen or heard of anything like this? I've been programming for over ten years, and have NEVER seen anything like it.

My only guess would be that the auto-casting the compiler does is confused. My program settings align everything to four bytes. Is it possible that pointers are converted to anything 4 bytes wide? (Very un-c++ like).
Anyway, thanks for the help, I'll keep hunting....
(please let me know if you think of anything else...)

Quote:

---

Originally posted by sperlis
Hi Paul,
(These are members of a class defined in DLL. The class is defined as __declspec(dllexport) and the project produces a .lib to link with)

---

I highly suggest you post the class (plus any class you may have derived from), plus a small sample program that you say couldn't be compiled. There was no indication in your original post that these functions are members of a class. Just that fact alone increases the number of reasons a function is not called.

I don't know anything about exporting classes with DLL's, so I have no idea if this is important information. The first thing to establish is if you can duplicate this behavior with a simple program (forget about DLL's and declspec's). If you can't duplicate it, it isn't a compiler issue, it is a linker issue.

Regards,

Paul McKenzie

Sorry about that..I thought that using the name "member method" would be clear enough...I'll be more specific next time...

Anyway, I'll try what you've suggested, although it is deffinately the compiler that fails (Compiler Error C2664 in MS Visual Studio C++ v6).

I'll try making a simplified project to see if I can recreate it, and post it again if I'm successul. If not, I have a new tree to bark up at (the DLL tree, that is).

Thanks again for your help.

This question is directed to paul - but of course anyone can provide an answer to my question :

The question is :
Instead of function overloading, don't you think that the correct way is now through the use of templates?

and if not the next question would be :
when would you use templates instead of function overloading and vice versa?

Its just to satisfy my curiosity more than anything.

Best regards

John

Quote:

---

Originally posted by caffineplease
The question is :
Instead of function overloading, don't you think that the correct way is now through the use of templates?

and if not the next question would be :
when would you use templates instead of function overloading and vice versa?

---

Well, in this particular example, I would think that overloading is sufficient. Both overloading and templates can allow function signature differences under calls to the same function name, but there are important differences between the two. First of all, template methods do not call with conversions and so act like duals to explicit ctors (which act as constraints on the object). Also, the type matching is open for templated methods, and although in this particular example you could use forward declaration with complete specialization to get the translationtime errors for use as protection against wrong client calls, but with more complicated signatures, the lack of partial specialization here will likely force use of overloading if you want errors to be reported at translationtime.

Also, you can't have virtual template functions. When
polymorphism is desired, template functions simply won't do.

--Paul

2 things:
To caffineplease: Template would have done well for avoiding the multiple pairs of methods, but could not have helped in completely avoiding the fact that I need two members, wherein lie my original compiler problem. (BTW: This is a record-set type class, where the data type is not known. The Specific method-call generates the required type. It is up to the user to know what is expected, so that templates would be completely unhelpfull in this specific case).

To anyone else whom this thread is interesting:
I have discovered that in the original C compilers, function names overloading was possible as long as the parameters SIZE was different (that is: the total stack size the function call itself would require). It might be that the C++ compiler does the same thing, under certain circumstances.
Anyway, this is where my investigation is heading next....

Quote:

---

Originally posted by sperlis
To anyone else whom this thread is interesting:
I have discovered that in the original C compilers, function names overloading was possible as long as the parameters SIZE was different (that is: the total stack size the function call itself would require).

---

Function overloading in C? I don't think that that is standard C, but some extension.

Of course, you're right!

Must be all that compiling 10 yr old C programs with VC++.

Maybe I HAVE gone stupid?