Function overloading doesn't work

[DireSpume]

I am using the PCH compiler version 4.140 for a PIC18F67K22.
The following code has two versions of NTimeSet(). Notice in main() that I am calling the second version of NTimeSet(), with the uint32_t argument. However, upon execution, it turns out that the first version (with the NTime* argument) is what is actually being called. Oddly enough, it doesn't crash when the pointer is dereferenced. Anyway, if I reverse the order in which the two functions are defined, it does then call the correct function. CCS claims to support function overloading, but this would seem to demonstrate that function overloading is NOT supported. What am I missing?

[PCM programmer]

Your example fails for me too. But then I played around with it a bit
and it works if you declare the passed variable on a separate line
before you use it. Example of how to make it work:

[RF_Developer]

There are two things that spring to mind. First CCS C is NOT case sensitive by default, unlike many other C compilers. Therefore "NTime* ntime" is the same as "NTime* NTime" and it will confuse the type and the variable, leading to unpredictable errors. Its always wise to differentiate types and variables, some people use "_t" to indicate a type, as in "NTime_t* ntime" and, arguably oddly as unit32 is already a defined type in CCS C in unit32_t. There are many other ways of indicating a type.

The second possible problem is that overloading is NOT a normal part of C, and as far as I can see, was primarily implemented by CCS to facilitate their own library code, particularly the math code, which uses overloading to implement different typed overloads of the functions. As such it MAY, and only may, be that overloading is not fully implemented and tested for all types, only for those which CCS use in their libraries. It is known that some compiler issues have had trouble with some overloading. I do not know which compiler versions were affected.

I suggest only using overloading if you MUST, i.e. there is no other way to implement the functionality, rather than because you can. Its not part of C and will create unportable and difficult to maintain code (because other programmers will not expect C to have overloads and not recognise them as such).

RF Developer

[DireSpume]

Thanks for the helpful responses. You are quite right about the problem of the compiler not being case sensitive -- a truly silly aspect of this compiler that I had to learn the hard way. But fixing that had no effect on the problem. I also tried passing pnew by value instead of by address, but it still called that function instead of the uint32 one. But as PCM programmer pointed out, it calls the correct function if you pass a variable instead of a constant. Regardless, the take-away is that function overloading IS NOT a compiler feature that has been fully implemented, and therefore it should not be used, and IMO is not a feature that CCS should be advertising. Enough said.

[Ttelmah]

It is actually 'quite interesting', since it throws significant light on how CCS treats variables versus constants. It appears that constants, do not have the flag set to say they are not pointers. The overload requires the second value to be a 'non pointer', to select the second routine, defaulting to the first, if it does not find a match. The cast changes the actual size used for the value (if you test with routines that want int16, versus int32).
It is the pointer versus non pointer test, that isn't working on a constant.

Best Wishes

[DireSpume]

Well, actually, Ttelmah, I think it's worse than just not being able to differentiate a constant from a pointer address. Because, remember, I tried passing the second NTime argument (pnew) by value instead of as a pointer, and it still got called. I have no idea what the value of pnew would end up being in that case, with 20000 as the argument, but this is clearly not something the compiler should be doing! But it's easy enough to avoid by not trying to overload functions; I've learned my lesson. It's almost as dumb as a C compiler that isn't case sensitive.

[Ttelmah]

CCS say in the manual, that 'by value' is _limited_ in functionality. I'd avoid it, unless you are using it in it's simplest form.

If you test using two functions that accept an int16, and an int32, rather than a pointer, then use a constant, it works correctly, if you cast the constant as int32, or int16, merrily switching between the functions, but if one of the functions requires a pointer, it instead 'defaults', picking the first function defined, however you cast the constant.
'Pointerness', appears to not have any meaning to a constant, even if you try to cast it in, or away.

As I said, it is an 'insight' into how CCS handles numbers, since with the variable, you can switch merrily using the cast.

It appears that a constant tests as 'true' for being a pointer, whatever you cast, but also tests as 'true' for not being a pointer whatever you cast!.

The compiler is case sensitive, just not by default....

It dates from the origins of CCS, where they were trying to produce a compiler for simple code, and perhaps appeal to people using interpreters on the PIC, such as BASIC, which are normally not case sensitive. They therefore opted to appeal to this market and choose case insensitivity as the default. Just like setting the fuses in the header for your project, just get 'habitual', and set #case.
I've in fact played a trick with a text editor. I dislike the #nolist option that sits at the start of all the processor define files, since it often makes debugging very hard. So I asked a test editor, that can open 'all files' in a directory, to do a search and replace, replacing #nolist, with #case. Makes things much more useable...

Best Wishes

[RF_Developer]

Constants on PICs (at least the PICs CCS C supports) are fundamentally different to variables due to the Harvard architechture of all PICs other than the top end 32s which CCS C doesn't support. CCS C has significant limitations on pointers to constants is all situations, not just in overloading. Its not at all surprising to me that pointerness and constants don't mix well. Its certainly true that a pointer to a variable and a pointer to a constant are quite different beasts as variables and constants are held in a totally different address space, in different memories in fact. CCS C would have to emulate pointer access to a constant by some combination of copying the constant to data space from instruction space and them forming a temporary pointer to it. CCS C may do this with this directive:

[Ranfo]

I know the thread is old, but I just discovered an Overload issue causing a bug in my program. It seems the compiler could not differentiate between integer types and was using the DATE version regardless.

[Ttelmah]

Depends obviously on how the 'dow' being passed is declared.
It works, but only really likes simply declared variables. So not pointers, and not items in a structure.
Also explicitly type all variables. You have two relying on the implicit 'int' declaration, but these will be different on different chips, and even if you use ANSI mode....

[PCM programmer]

It works with vs. 5.078. I ran the test program shown below in MPLAB
vs. 8.92 simulator and got the following output: