Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
1  
One should only expend effort providing for multiple ways of expressing something if each explicitly-provided way will in some cases be clearly and unambiguously superior to any of the others. That doesn't mean one should generally expend effort ensuring that something can only be written in one canonical form, but it doesn't make sense to put forth effort allowing something to be specified in some way that isn't the best. –  supercat Jan 16 '13 at 21:16
    
Kind of a duplicate of my question here (I now agree that it's a bad idea). –  leftaroundabout Jan 16 '13 at 23:02
add comment

2 Answers

up vote 78 down vote accepted

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 will use tools like IntelliSense that 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.

share|improve this answer
13  
lots of up-votes. I will stop immediately. thank you. –  Trevor Hickey Jan 16 '13 at 18:09
7  
In addition, you can't name constructors differently to explain your purpose, readers have to infer it from the parameters. Overloading the constructor this way makes it much harder to understand. –  Zachary Yates Jan 16 '13 at 18:15
2  
"Having multiple function names that do the same thing..." - for a 'good' time, look at Ruby's classes String Hash Array File. –  MichaelT Jan 16 '13 at 18:42
    
+1. You are dealing with developers/programmers. Microsoft idea of "user is monkey", does not work here. –  Manoj R Jan 17 '13 at 7:00
1  
@ZacharyYates Lack of "constructor names" can be worked around by exposing a static construction methods instead. This is a standard practice in Java, although not so much in C++. –  Xion Jan 21 '13 at 6:17
show 4 more comments

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.