macOS C functions cannot be overloaded?

[zippyfly]

I am writing C in Xcode. That is, it's all ANSI C, without Objective-C stuff, although I am editing the .m file.

I noticed I can't overload the C functions (with different parameter types).

I understand that C does not define function overloading, but is there a workaround (out of curiosity) that does not require defining a class and then writing a method?

This is just for curiosity; I am thinking that such a feature could be useful for certain types of porting exercises (porting C code from elsewhere to run on OSX/iOS).

Thanks.

 

[mfram]

Neither C nor Objective-C directly support function overloading with different argument types. C++ only supports some situations where there is no ambiguity between the different function signatures with the same name.

The best alternative you could get in C is by using variable arguments and processing the arguments yourself. This could get you the same effect if you worked hard enough at it, I guess. Google for "C function variable arguments".

 

[chown33]

I am writing C in Xcode. That is, it's all ANSI C, without Objective-C stuff, although I am editing the .m file.

I noticed I can't overload the C functions (with different parameter types).

I understand that C does not define function overloading, but is there a workaround (out of curiosity) that does not require defining a class and then writing a method?

No. Each function must have a unique name across the entire program, including any libraries used. The only exception is functions that are declared static. They are unique within their compilation unit (source file).

This is just for curiosity; I am thinking that such a feature could be useful for certain types of porting exercises (porting C code from elsewhere to run on OSX/iOS).

C code must adhere to the rules of C. So I don't see how overloading functions will help porting. No C code contains overloaded functions.

Give a specific example of the kind of problem overloading is intended to solve.

The C preprocessor's #defines were historically used for altering the names of functions. For example, you can #define a read() macro whose args mirror the I/O function of the same name, and when you compile your program, any source that includes the macro and calls read() will actually call your function instead. This can go the other direction, too: #define a macro that expands to your function or to read().

 

[zippyfly]

Give a specific example of the kind of problem overloading is intended to solve.

This is just theoretical, but I can imagine a situation where it would be convenient to have an overloaded function that you can call using different variable types, such as int, float, string, etc. and depending on the overloaded functions, they would all convert/cast the parameter accordingly to the type (say, float) that is used in the algorithm.

I guess the argument against this is that it leads to sloppiness since you should pass the exact argument for the function call instead of rely on the function to do the conversion, but I am just thinking that perhaps during rapid prototyping an overloaded function could be quite convenient.

 

[zippyfly]

The best alternative you could get in C is by using variable arguments and processing the arguments yourself. This could get you the same effect if you worked hard enough at it, I guess. Google for "C function variable arguments".

Thanks. I searched and read the info about va_list, etc. It's interesting but not really in line with the overloading. But probably useful for certain applications (however I can imagine passing an object array in Objective-C would be easier to implement and to understand).

 

[chown33]

This is just theoretical, but I can imagine a situation where it would be convenient to have an overloaded function that you can call using different variable types, such as int, float, string, etc. and depending on the overloaded functions, they would all convert/cast the parameter accordingly to the type (say, float) that is used in the algorithm.

I guess the argument against this is that it leads to sloppiness since you should pass the exact argument for the function call instead of rely on the function to do the conversion, but I am just thinking that perhaps during rapid prototyping an overloaded function could be quite convenient.

I don't think it helps at all in rapid prototyping. Either because you wouldn't be using plain ordinary C for rapid prototyping, or because you'd be able to name functions uniquely. I've written a lot of code, prototyping and otherwise, and never once did I think "Wow, what would really speed this up is overloaded C functions".

 

[Sander]

This is just theoretical, but I can imagine a situation where it would be convenient to have an overloaded function that you can call using different variable types, such as int, float, string, etc. and depending on the overloaded functions, they would all convert/cast the parameter accordingly to the type (say, float) that is used in the algorithm.

If you run into limitations of the language, perhaps it's time to switch to a different one. You could do the vararg trick and make a big switch-case which dispatches to the "real" implementations, but it'd be easier to switch to C++.

 

[foidulus]

You could also use function pointers(call the functions different names but depending on your argument list choose a different pointer)

but I really wouldn't recommend it unless you REALLY know what you are doing, those things can get ugly pretty fast(not to mention it makes your code much harder to maintain)

 

[zippyfly]

I've written a lot of code, prototyping and otherwise, and never once did I think "Wow, what would really speed this up is overloaded C functions".

Haha ok. I'll take your word for it!