1

To me, the word "default" means what happens if I do nothing. So I feel that the "default constructor" should refer only to the one that the compiler provides if I do not write any. That makes it clear that "no argument constructor" means one that I have written, just like any method could have no arguments.

I don't see that this is an agreed-on convention though, because many people use "default constructor" to mean the same thing as "one with no arguments". But that is not the case for other types of methods. All my Accessors are not referred to as "default accessors", and calculation methods that take no arguments are not referred to as "default calculations". So why is this confused for Constructors? Can we clear it up?

Improve this question
2
  • 2
    Is your question specifically about C++ (where the default constructor is an important and well-defined concept), or about OOP in general (which has very diverse concepts, up to the point that there might not even be classes and therefore no constructors)?
    – amon
    Feb 17, 2016 at 21:13
  • 1
    @amon I am teaching C#, and was striving to distinguish the one the students could create from the "implicitily defined" one supplied by the compiler (thank you Jerry Coffin for that term). As ixrec stated, from the view of the user of a class, they have no idea how the no-arg constructor came to be, they only care that it is the one that is called "if they do nothing" (pass no arguments). So no argument there, it is all cleared up. We now return you to your usual programming.
    – user186205
    Feb 17, 2016 at 21:39

2 Answers 2

Reset to default
6

There's no need for confusion. A default constructor is one (and only one) that can be invoked without any arguments. It's what's invoked by default if you create an object of that class without specifying any other value. If you want the official wording (§[class.ctor]/4):

A default constructor for a class X is a constructor of class X that either has no parameters or else each parameter that is not a function parameter pack has a default argument.

The only confusion here is your using "default ctor" to mean "implicitly defined ctor". The two are separate concepts.

I suppose if somebody had wanted to badly enough, they could have used "default" to mean an implicitly defined ctor, and defined some other term to mean a ctor that doesn't require any arguments--but at least in my opinion, they'd have had to do that a long time ago. It's at least a few decades too late to try to change the terms now.

Improve this answer
2
  • 5
    I'd add that the OP's suggestion that "default ctor" -> "the one the compiler makes by default" is like thinking about the class from the creator's point of view, while "default ctor" -> "the one that gets called by default" is thinking about it from the user's point of view. For any class with more than one user, the latter usage "wins".
    – Ixrec
    Feb 17, 2016 at 21:15
  • @Ixrec "the User is always right." Thank you for pointing out this other view that I had not taken in to account. I see why the term was chosen as it was.
    – user186205
    Feb 17, 2016 at 21:41
2

I think you are conflating several concepts here, and there can be some overlap. Since you did not tag this with a language, I will defer to the general definitions of the words as they mean to me as a software professional of over 15 years:

  • No-argument constructor is a constructor that accepts exactly zero arguments.

  • Default constructor is a constructor that can be invoked without any explicit arguments. This may be a no-arg constructor, or it may have default parameters.

  • Compiler-generated constructor is one that the compiler creates for you in the absence of an explicitly-defined constructor. This will typically be a no-arg constructor. Note: C++ may also generate other constructors, although the rules are not so simple anymore as of C++11.

To me, the word "default" means what happens if I do nothing.

I agree, in the sense of "do nothing" meaning "I do not provide any arguments, regardless of whether the compiler provides them for me as default parameters."

So I feel that the "default constructor" should refer only to the one that the compiler provides if I do not write any.

Why can the programmer not provide a default constructor? Often they would be equivalent in terms of interface, at least: the only reason for providing a default constructor is to initialize state that would not be done in a do-nothing implementation, or to call another constructor (i.e. this(...)).

I don't see that this is an agreed-on convention though, because many people use "default constructor" to mean the same thing as "one with no arguments"

I see this sometimes as well, but I think the semantic difference is "can be constructed without providing any arguments" which is consistent with the definition I provided.

But that is not the case for other types of methods.

There is a subtle distinction here. In every language I am familiar with, all constructors are not functions. While the term "overload" may apply to both, overloaded functions are technically separate entities with different method signatures but the same name. Constructors are special in that while they may also be overloaded, they represent the same thing and share the same responsibility (object initialization).

Furthermore, constructors are generally not part of a class's interface: it is not possible to call a constructor except when creating the object. Constructors and methods/functions are different animals and must be treated differently when discussing a class's interface. There is simply no comparison between the two entities except that constructor invocations look similar to method invocations (the difference being one does not invoke a constructor using an object reference).

Improve this answer
5
  • In C# the compiler provides a constructor which invokes the base constructor, if you do not write any constructors for a class. If you write any constructors, the compiler does not provide one, leaving the task to the programmer if they want a no-argument one. I was trying to make sure that my students were clear about what was going on when they write code. I thought that distinguishing the situations with different terms was a good idea. But I see why other people might not care. With hundreds of OO languages, it is unfortunate that words can take on entirely different meanings.
    – user186205
    Feb 17, 2016 at 23:43
  • @JerryCoffin Good point, I updated my answer to make note of that. C++ is a bit different in this regard, and still quite a popular language so it is worth calling that out.
    – user22815
    Feb 18, 2016 at 0:34
  • 1
    @nocomprende note that when I discuss the differences, I am focusing on the interface and not the implementation. The fact that a constructor may implicitly call a superclass constructor is irrelevant to which constructor is generated or used. In other words, this answer doesn't care about what goes in between { and } regardless of whether the compiler or the programmer puts it there.
    – user22815
    Feb 18, 2016 at 0:35
  • 1
    I was teaching my students about constructor chaining and how all constructors implicitly call their base class constructor, all the way up to the .Net "Object" class, which includes some built-in functionality. We have not gotten around to discussing Interfaces (as I understand the term - a contract of how to use a class) yet. I guess the world is round after all.
    – user186205
    Feb 18, 2016 at 0:46
  • 1
    @nocomprende yep, you can sugar-coat the definitions all you want. In the end, they are pretty much all circular-referenced no matter how you describe them. I blame the OO term "contract" for all of this.
    – user22815
    Feb 18, 2016 at 6:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.