I wonder if there is a way to have two different names for one function in a class, without copying the same function two times and change names, something like that:
float DoSomething (float a, float b)
{
// code here
}
float DoIt (float a, float b) // Some kind of typedef or alias that makes a #define DoIt DoSomething but only inside class scope
So an user of this class could use any of this names at preference.
Why would you want two different functions to do the exact same thing? That's bad design, and will at least waste people's time that try to hunt through your docs to figure out what the difference is. Be confident that the interface you expose is appropriate.
I think that there are some cases where providing several ways of naming functions can be useful, different users thinks different, is like programming style. Come to my mind one example in vector class, Magnitude, Length and Module means the same, there are the same function, some people likes to call it Module, others Magnitude, and some would like to call it Module in one place, and Length in another for letting more clear what their code do for other people on team.
Having a vector class with both a Magnitude and Length would not be tolerated in a production code base. It certainly does not make it more clear (how COULD it be more clear what .Length() means?), it makes it more difficult to learn, and especially if people mix magnitude and length in the same function, it's more difficult to read as you constantly have to remind yourself that length and magnitude mean the same thing. And if you have to do this with N sets of differently named but identical functions, it would be a nightmare.
But from mathematical side they are the same thing, and have that both names, so is not a bad thing to remember that the two names means the same thing. Is a bad thing to train the mind to remember the less information possible, much more when is useful information i think.
this would be asured to be inline if you put inline keyword ?
[/quote]
No. The inline keyword is all but ignored by compilers, except when it comes to allowing implementations in header files. Any implementation inside a class body is considered "inline" by default.
However, any compiler which wouldn't inline such a function is fairly poor. Unless you are using an old or niche compiler, I think you can safely assume that such a function would be inlined (in fact, the contents of the called function will probably be inlined).
But from mathematical side they are the same thing, and have that both names, so is not a bad thing to remember that the two names means the same thing. Is a bad thing to train the mind to remember the less information possible, much more when is useful information i think.
Having Length() and Magnitude() calls dotted around the place would be very confusing for anyone having to read or use said code. Choose one convention and stick to it. Writing code isn't about catering for every whim users may have and it's certainly not a brain training exercise to help people improve their memory.
The point of coding standards and format specifications and such is that consistency is important. Everyone on a team should be able to look at the same code and understand it the same way. Introducing ambiguity (e.g. by having three functions that do the same thing) is incredibly bad, because now people have to think extra hard about the code just to figure out what's going on. Eliminating ambiguity makes it easier to reason about what a program means.
Catering to different people's preferences is a nice ideal, but ultimately unwise. One person might like Kernighan & Ritchie brace style, and someone else might actually have some taste and format their code like a sane person. Those things are largely irrelevant because pretty-printers can take care of it for you. But one person preferring Magnitude() over Length()? Screw that person, he needs to get the hell over it. Working with shared code - be it on a team, with a library, via middleware, etc. - means you have to accept the conventions that are thrust upon you. It's called being a team player ;-)
