Here is a C++ class that gets constructed with three values.
class Foo{
//Constructor
Foo(std::string, int, char);
private:
std::string foo;
char bar;
int baz;
};
All of the parameter types are different.
I could overload the constructor so that order doesn’t matter.
class Foo{
//Constructors
Foo(std::string, char, int);
Foo(std::string, int, char);
Foo(char, int, std::string);
Foo(char, std::string, int);
Foo(int, std::string, char);
Foo(int, char, std::string);
private:
std::string foo;
char bar;
int baz;
};
But is that a good idea?
I started doing it because I knew what things a class/function needed;
I didn’t always remember what order it took them in.
I’ve been assuming that the compiler optimizes this as if I called the same constructor.
//compiler will implement this with the same code?
//maybe not.. I could call a function to get a parameter,
//and that function could change the state of the program, before calling
//a function to get another parameter and the compiler would have to
//implement both
Foo foo1("hello",1,'a');
Foo foo2('z',0,"world");
What are your opinions on overloading a function so that the order doesn’t matter?
Also, If I’m writing some utility functions,
Is it a good idea to provide different function names that do the same thing?
eg.
void Do_Foo();
void DoFoo();
void do_foo();
//etc..
I don’t often see these two but similar conventions.
Should I break or embrace the habit?
2
I could overload the constructor so that order [of the parameters] doesn’t matter… But is that a good idea?
No.
Having different constructor overloads will have the opposite effect of what you are intending. The programmer coming after you expects different overloads to have different behavior, and will ask: “What sort of different behavior is being expressed by each of these overloads?
Most programmers expect the discipline of having method parameters in a predefined order, and tools like IntelliSense will tell them the expected order of the parameters as they enter them.
Having multiple function names that do the same thing is the same problem; programmers expect the variants to have different behavior. One function or method per behavior, please, and just adopt a consistent naming pattern.
9
Sometimes supporting commutation among arguments is necessary. For instance:
double operator *(int, double);
double operator *(double, int);
We do not want multiplication of an int and double to compute something different if the operands are reversed. Nor do we want to force programmers to remember that when multiplying ints and doubles, the double goes on the left!
It doesn’t matter that this is an operator because the same goes for:
footype plus(const footype &, const bartype &);
footype plus(const bartype &, const footype &);
It really depends on the kinds of function. Whereas most programmers probably want support for commutativity in arithmetic libraries, they don’t necessarily want, say, an I/O library functions to support all possible argument orders.
The concern probably hinges around the expected nesting in which the function calls are going to be involved. The flexibility in the arithmetic operators allows us to change the overall structure of the syntax tree to clarify the overall expression: group together similar terms and such.