Constructor question

If I create a vector vec by writing

Code:

---

vector<int> vec;

---

is the constructor of the vector class called or not?
If not, is vec.size() is undefined?

I know I can always write

Code:

---

vector<int> vec();

---

or

Code:

---

vector<int> vec() = new vector<int>;

---

etc, but I think I have a lot of old programs where I haven't, and I would like to know if I have to modify them.

Yes the constructor is called, you don't need the empty parenthesis; I'm pretty sure size would be initialized to 0; Your last line of code is incorrect, because you're not assigning the new memory to a pointer.

Both of the lines you "know" you can write are incorrect. The first doesn't create a vector object; it declares a function returning a vector and taking no arguments. The second is just plain invalid.

Constructors are always called for objects. That's a guarantee of the C++ object model. There is no way of getting an uninitialized object, except of course in constructors and functions called from there. (Casting pointers does not count as getting uninitialized objects.)

Eh heh... that's a good point about the function declaration, that didn't even hit me. My god I haven't programmed in a long time. I suppose you will in the end have to fix all "objects" declared like that.

Quote:

---

Originally Posted by CornedBee

Constructors are always called for objects. That's a guarantee of the C++ object model. There is no way of getting an uninitialized object, except of course in constructors and functions called from there. (Casting pointers does not count as getting uninitialized objects.)

---

Depends on your notion of an uninitialised object. You're referring to the notion of an object as "an instance of a C++ class type" (and your comments are correct in that context). But both the notions of "object" and "uninitialised" can have more general meanings.

There is a frequently used (unfortunately) technique of lazy initialisation --- the constructor doesn't do much, and an initialisation function is manually called later. This sort of thing is a prime opportunity to forget to call the initialisation function and cause chaos when some action occurs based on an assumption that it has. In practice, IMHO, it is simply better to delay creating the object until it is needed, and have a constructor or default initialisation which does all the required initialisation.

Instances of basic types can be viewed as objects, depending on your philosophy in life. And basic types are not necessarily initialised.

Code:

---

int main()
{
    int x;  //  x is uninitialised, not necessarily zero
}

---

One nasty example is an uninitialised reference because references cannot be reinitialised;

Code:

---

int main()
{
    int &x;  // uninitialised reference

    //  most assignments to x will now yield undefined behaviour.

    int j = 5;
    x = j;          //  undefined behaviour as x is uninitialised.
                      //    this assignment does not make x an alias of (or reference to) j.
}

---

A reference that isn't initialized (like an uninitialized constant pointer) should generate a compile-time error, if your compiler is compliant.

> Depends on your notion of an uninitialised object.

There is really only one notion. The standard makes sure of that. Objects of user-defined types can't be defined uninitialized.

> There is a frequently used (unfortunately) technique of lazy initialisation --- the constructor doesn't do much, and an initialisation function is manually called later.

Frequent because it makes sense sometimes, and the alternatives simply put too much weight (either in code or amount of work). I see little of shocking in an object with a load() function as part of its semantics. The user of that object read the documentation and understood the use. What's the problem?

The alternative could mean a constructor with a huge list of parameters or some other object construction technique that would only put more weight into the who object hierarchy.

By uninitialized I mean "constructor was not called", obviously.

Even two-phase initialization should never leave an object uninitialized. If it does, it's an extremely poor implementation of the pattern. The constructor should always at least put the object into the null-state, i.e. the "my second initialization phase hasn't been done, but at least I know it" state. Thus, it's not uninitialized.

Thanks. So if I declare an array of objects, are all the objects initialized?

Code:

---

vector<int> myints[1000];

---

yes - for each object in the array default constructor is called.
you can actually test it - build your own object, add print-out in the CTOR, create the array of objects and see the output

>> vector<int> myints[1000];
I assume you wanted to have an array of 1000 vector<int> objects all initialized to empty with the default vector<int> constructor. If so, then that code is correct, but based on the previous confusion I just want to make sure you don't want vector<int> myints(1000); which uses a non-default vector<int> constructor to create 1000 zero-initialized int values.