If I create a vector vec by writing
is the constructor of the vector class called or not?Code:vector<int> vec;
If not, is vec.size() is undefined?
I know I can always write
orCode:vector<int> vec();
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.Code:vector<int> vec() = new vector<int>;
Last edited by TriKri; 11-26-2006 at 05:11 PM.
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.
Last edited by SlyMaelstrom; 11-26-2006 at 06:08 PM.
Sent from my iPad®
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.)
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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.
Sent from my iPad®
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.Originally Posted by CornedBee
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.
One nasty example is an uninitialised reference because references cannot be reinitialised;Code:int main() { int x; // x is uninitialised, not necessarily zero }
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.
You ever try a pink golf ball, Wally? Why, the wind shear on a pink ball alone can take the head clean off a 90 pound midget at 300 yards.
> 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.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
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.
All the buzzt!
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
>> 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.
