Constructor question

This is a discussion on Constructor question within the C++ Programming forums, part of the General Programming Boards category; If I create a vector vec by writing Code: vector<int> vec; is the constructor of the vector class called or ...

  1. #1
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286

    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.
    Last edited by TriKri; 11-26-2006 at 04:11 PM.

  2. #2
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,066
    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 05:08 PM.
    Sent from my iPad®

  3. #3
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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

  4. #4
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,066
    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®

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    6,203
    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.
    }

  6. #6
    Cat
    Cat is offline
    Registered User
    Join Date
    May 2003
    Posts
    1,571
    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.

  7. #7
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,412
    > 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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    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.

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    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!
    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

  9. #9
    Algorithm engineer
    Join Date
    Jun 2006
    Posts
    286
    Thanks. So if I declare an array of objects, are all the objects initialized?

    Code:
    vector<int> myints[1000];

  10. #10
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,473
    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
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  11. #11
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> 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.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21