Thread: another question on using The colon :

  1. #1
    Registered User
    Join Date
    Dec 2001
    Posts
    104

    another question on using The colon :

    In the following snippet of code, what is the significance of the colon ( : ) after Tree::Tree() and after Tree::Tree(Node const &node)? Is it supposed to mean that Tree::Tree() inherits from left(0), or the two subtrees and the node?
    Code:
    #include "tree.h"
    //default constructor: initializes to 0
    Tree::Tree()
    :  // what does this colon signify?
      left(0),
      right(0),
      node(0)
    {
    }
    
    // Node constructor: adda Node object
    Tree::Tree(Node const &node)
    :  //what does this colon mean?
      left(0),
      right(0),
      node(node.clone())
    {
    }

  2. #2
    Registered User
    Join Date
    May 2003
    Posts
    1,619
    That colon means that what follows is an initializer list. In constructor definitions, between the name and the body can sit an initializer list. This code:

    Code:
    Tree::Tree()
    :  // what does this colon signify?
      left(0),
      right(0),
      node(0)
    {
    }
    Sets left, right, and node to 0. It's mostly the same as:

    Code:
    Tree::Tree()
    {  
      left = 0;
      right = 0;
      node = 0;
    }
    but the first method is preferred. There are differences:

    * Initializer lists can offer improved performance.
    * Initializer lists are the ONLY place you can correctly call a base constructor.
    * Initialization happens in the order the variables are defined, NOT the order of the list itself. E.g. in this code:

    Code:
    class X{
    public:
      X() : y(0), x(7), z(22){}
    private:
      int x, y, z;
    };
    The variables are instantiated beginning with *x*, then y, then z, because that is the order they are declared in the class. The order they are declared in the initializer list is irrelevant (although, for readability, I always make both orders the same).
    Last edited by Cat; 08-08-2003 at 07:49 PM.

  3. #3
    Pursuing knowledge confuted's Avatar
    Join Date
    Jun 2002
    Posts
    1,916
    Cat:

    Why is the first method prefered?
    Away.

  4. #4
    Registered User
    Join Date
    May 2003
    Posts
    1,619
    It can be more efficient, and in some cases, there is no alternative. Calling base constructors or constructing members without using the default constructor are two examples.

    Further, having an empty-bodied constructor can help optimizing compilers.

    Here's an efficiency example. Imagine class X has an object of class Point called P.

    X::X():p(10,10){}
    // This constructs the object p once with 10,10 as params.


    X::X(){p = Point(10,10);}
    // p is first default constructed, then a new temporary point object is constructed and assigned to p.
    // This won't even compile unless Point has a default constructor.

    Another example, calling a base constructor:

    Derived::Derived() : Base(43, "hello") {}
    // It correctly calls the base constructor for the object

    Derived::Derived() { Base(43, "hello"); }
    // This doesn't do even close to the same thing. The default Base constructor is called.
    // The call in the body actually creates and immediately destroys a temporary object of type Base. It has no effect on the Derived object.
    Last edited by Cat; 08-08-2003 at 08:05 PM.

  5. #5
    Veni Vidi Vice
    Join Date
    Aug 2001
    Posts
    343
    Additional to what Cat said.

    Cat:
    Why is the first method prefered?
    This calls the constructor for the object. The second method calls the constructor and the copy assignment operator. This is a perfomence bottleneck if the classes are BIG.
    01000111011011110110111101100100 011101000110100001101001011011100110011101110011 01100100011011110110111001110100 01100011011011110110110101100101 01100101011000010111100101110011 0110100101101110 01101100011010010110011001100101
    Good things donīt come easy in life!!!

  6. #6
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Another necessary place for the initializer list are member constants.
    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

  7. #7
    mustang benny bennyandthejets's Avatar
    Join Date
    Jul 2002
    Posts
    1,401
    I don't understand. How can initializing member data using initializer lists or in the body make a difference? Isn't it all the same in assembly language anyway? I mean, all that happens is that a memory location is filled with a value.
    [email protected]
    Microsoft Visual Studio .NET 2003 Enterprise Architect
    Windows XP Pro

    Code Tags
    Programming FAQ
    Tutorials

  8. #8
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    >How can initializing member data using initializer lists or in the body make a difference?
    Try initializing a const data member in the body of the constructor. Then try using an initializer list. See the difference?
    My best code is written with the delete key.

  9. #9
    Registered User
    Join Date
    May 2003
    Posts
    1,619
    Originally posted by bennyandthejets
    I don't understand. How can initializing member data using initializer lists or in the body make a difference? Isn't it all the same in assembly language anyway? I mean, all that happens is that a memory location is filled with a value.
    Here's one example:

    Code:
    X::X():p(10,10){} 
    
    X::X(){p = Point(10,10);}
    The first calls the constructor of Point once. The second calls it twice and calls the assignment operator once.

    Further, even with primitive types, it's NOT always the same. Compilers are allowed to do all kinds of magic behind the scenes, and when you put stuff in the list, they're allowed by the language to do different and more aggressive optimizations.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Alice....
    By Lurker in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 06-20-2005, 02:51 PM
  2. Debugging question
    By o_0 in forum C Programming
    Replies: 9
    Last Post: 10-10-2004, 05:51 PM
  3. Question about pointers #2
    By maxhavoc in forum C++ Programming
    Replies: 28
    Last Post: 06-21-2004, 12:52 PM
  4. Question...
    By TechWins in forum A Brief History of Cprogramming.com
    Replies: 16
    Last Post: 07-28-2003, 09:47 PM
  5. Question, question!
    By oskilian in forum A Brief History of Cprogramming.com
    Replies: 5
    Last Post: 12-24-2001, 01:47 AM