Jump to content
  • Advertisement
blackapple

C++ Overloading Question

This topic is 385 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

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;
//Instead of:
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.

I want to hear exact answer about it. Thx.

Share this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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. ;)

In all other cases, overloading shouldn't be a big deal.

Edited by matt77hias

Share this post


Link to post
Share on other sites

This C++ coding style guideline is NOT about readability.  Not if you mean making people THINK they like reading the code.  This is about true readability, accuracy, debug-ability.  The overload based version reads easier ... you don't think about the function as 2 functions, and you don't have to think about the type.  However, these methods are actually 2 different lookups, semantically, so they should have 2 different names - If I converted the int 5 to the string "5" and called the method, it would NOT return the animation with the index 5, but instead of return a null pointer because there is no animation with the NAME "5".  As C++ has evolved with all sorts of anonymous and auto typing, this kind of thing would be almost 100% invisible to a reader and even tough for a debugger.

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 this post


Link to post
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 this post


Link to post
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?

 

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!