5

Lets say that I have multiple functions that accomplish the same goal. An example of this would be creating a 'constructor' for a data type.

String new_String(); String new_String(const char *cstr); String new_String(String s);

Obviously this cant be accomplished in C, but with functions like these (and situations where function overloading is useful) is there a convention or best practice for naming them?

Something like this?

String new_String(); String new_String_c(const char *cstr); String new_String_s(String s);

which to me feels awkward and not easy to read. Or something like this?

String new_String(); String new_String_from_cstr(const char *str); String new_String_copy(String s);

Which reminds me of horribly long java names because this could soon get ridiculous. 

int String_last_index_of_any_characters(String s, char *chars, int length);
Improve this question
3
  • Does this have to be a C project? Rather than try to emulate C++ in C, why not code in C++? Commented Jul 14, 2012 at 22:01
  • 3
    There is a lot of reasons for a project being c rather than c++. Commented Jul 14, 2012 at 22:04
  • Have you ever programmed GTK+? It has those ridiculously long C function names like gtk_icon_view_convert_widget_to_bin_window_coords(). Commented Jul 14, 2012 at 22:18

4 Answers 4

Reset to default
3

You can define a single "constructor" that takes a void * initialization parameter and an enum:

enum StringCtor { SC_DEFAULT, SC_C_STR, SC_COPY }; String new_String(enum StringCtor type, const void *arg); String s1 = new_String(SC_DEFAULT, 0); String s2 = new_String(SC_C_STR, "hello"); String s3 = new_String(SC_COPY, &s2);

You could also choose to use a ... instead of a void *. The idea is the same, but you use the va_* macros to extract the parameter if it supposed to be a string or a copy.

If you just want the API to have the appearance of a single constructor, but still want type safety, you can use the techniques above to create your actual constructor implementation, and use inline functions and preprocessor tricks to give the appearance of a single constructor, with type safety.

String new_StringImpl(enum StringCtor type, const void *arg); static inline String new_StringImplDefault () { return new_StringImpl(SC_DEFAULT, 0); } static inline String new_StringImplCstr (const char *s) { return new_StringImpl(SC_C_STR, s); } static inline String new_StringImplCopy (String *s) { return new_StringImpl(SC_COPY, s); } #define new_String_Paste(TYPE) new_String_ ## TYPE #define new_String_SC_DEFAULT(ARG) new_StringImplDefault() #define new_String_SC_C_STR(ARG) new_StringImplCstr(ARG) #define new_String_SC_COPY(ARG) new_StringImplCopy(ARG) #define new_String(TYPE, ...) new_String_Paste(TYPE)(__VA_ARGS__) String s1 = new_String(SC_DEFAULT); String s2 = new_String(SC_C_STR, "hello"); String s3 = new_String(SC_COPY, &s2);

Notice with the variadic macro, SC_DEFAULT does not need a second parameter any more. At sufficient optimization levels, the code translates to just a call to the single implementation function, with the benefit of compile time type safety checks. So at the cost of some more coding on your part, you can give the user of your library the appearance of a single constructor API with all the type safety of multiple constructor functions.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

Is the new_StringImpl(enum StringCtor type ... required? Is there a reason for not just using the 3 inline functions for the different implementations instead of passing it off to the catch all function?
@Nat: Not, it's not required. You can implement each individual function in full if you wish. I was using the individual functions merely as a type safe pass through.
0

There is no standard convention but in case of many overloads of a more or less similar function, people usually refer to OpenGL function naming convention.

The method provided by @user315052 is typically not preferred because of type safety issues (error prone, hard to change etc) and/or inconvenience when you have more than one argument to pass. But it is sometimes used though for different technical reasons (kernel system calls is a good example).

Improve this answer

1 Comment

While I agree 'just use void*' as in the other answer is usually very bad advice, I'm equally sceptical that "people usually refer to OpenGL function naming convention". What are examples of other (preferably reputable) projects following that convention? How do they handle strings since that's the question here and that link makes no mention of it? Also, I note they advise silly typedefs for fundamental types, which is always very silly, at best a historical relic, and should not be written in any barely modern code. I'm sure their style works for them, but doesn't mean it will for others
0

I don't think that there is a well-established convention on how to handle overloading. Your second approach is fine; use common sense to keep the names reasonably short but still easily understandable.

Some systematic naming convention like your first approach (or as in OpenGL) might be a good idea in some cases, but it makes the code a bit less self-explanatory; anyone reading your code would need to understand your naming convention first.

Improve this answer

Comments

0

Modern C, AKA C11, can do more than you think. It has type generic macros that can accomplish something similar to function overloading in C++ with the new _Generic expressions.

As internal interfaces for your library you still would need the function declarations:

String new_String_from_cstr(const char *str); String new_String_copy(String s);

Now your type generic macro could look like:

#define new_String(X) \ _Generic((X), \ const char*: new_String_from_cstr, \ String: new_String_copy)(X)

C11 is not yet completely implemented, but I think the most recent clang compiler already has what you need here.

For other compilers (gcc and cousins) you may have a look into P99, that emulates features that come close to that. P99 also has tricks to deal with macros that receive different numbers of parameters.

If you use such tools as user interfaces, the naming convention for the functions themselves becomes much less important.

Improve this answer

Comments