Public Group

## Recommended Posts

Hi guys. I recently studied C / C++ Coding Standards book.

//Function overloading must be avoided in most cases
//Use:
const Anim* GetAnimByIndex(const int index) const;
const Anim* GetAnimByName(const char* name) const;
const Anim* GetAnim(const int index) const;
const Anim* GetAnim(const char* name) const;

I found this, and I'm really curious why function overloading must be avoided in most cases.

##### Share on other sites
1 hour ago, Zao said:

In this particular case, the call site may be a bit unexpected if you use NULL or 0 as a null pointer constant, as the integer overload will be chosen.

If you want to avoid this, you need to use "nullptr" instead of avoiding overloads. This, however, depends on the language standard you use which for most books is unfortunately still below C++11/14.

##### Share on other sites

The only time overloading becomes very tricky and problematic is in the case of universal reference templates.

template< typename T >

void Func(T &&arg);

This becomes even more tricky with variadic template arguments.

template< typename... T >

void Func(T&&... args);

Which becomes even more tricky with constructors.

Edited by matt77hias

##### Share on other sites

If you pass primitive types by value to a function const is not needed on that parameter. The code outside wont see any changes you make to the parameter anyway.

##### Share on other sites

There is nothing wrong with overloads like in the math library:

float sqrt(float)

double sqrt(double)

because they are semantically identical.  Never mix (basic) TYPE selection with semantic selection.

There are reasons to violate every "rule".  But in general only violate rules like this in methods are only FOR violating this rule.  in other words a method with overloads that change the behavior based on the type of the input, should ONLY be a facade for selecting different behaviors based on type

##### Share on other sites
On 8/27/2017 at 5:49 AM, Hodgman said:

Personally I believe you should not write code where using the slow path and using the fast path will look the same. It should be obvious when reading the calling code whether they're doing something dumb (repeatedly doing unnecessary string comparisons) or not.

While I agree with the idea of "you should not write code where using the slow path and using the fast path will look the same", I'm not sure it applies that much here.  The two functions still take two different arguments, one an index and one a string.  So looking at the code it should be clear that you're calling the one that takes the string, and hence would be expected to be slower.  Adding "ByName" to the end of the function only mostly succeeds in making the function name longer and more redundant, since the input type already tells you the same information.

Edited by 0r0d

##### Share on other sites
1 hour ago, 0r0d said:

Adding "ByName" to the end of the function only mostly succeeds in making the function name longer and more redundant, since the input type already tells you the same information.

I guess it depends what your naming convention for variables is. If you're using some horrible systems hungarian where you attach the data type to the variable name, then sure, you'd have something redundant like:

GetAnimByName( pszMyAnimation1 ); // slow string-based logic
GetAnimByIndex( uidxMyAnimation2 ); // fast index-based logic

But if your variable is just called "myAnimationN", then the call-site could look like:

GetAnim( myAnimation );//is this the fast path or the slow path?

1. 1
2. 2
Rutin
25
3. 3
4. 4
JoeJ
18
5. 5
gaxio
11

• 14
• 22
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631765
• Total Posts
3002213
×