Thread: constructor for POD types?

  1. #1
    Registered User
    Join Date
    May 2006
    Posts
    1,579

    constructor for POD types?

    Hello everyone,


    When implementing a general template class, sometimes we call T() -- suppose T is type argument of a template class.

    My questions,

    1. what will happen if T is POD type? Do nothing?

    2. Is it good code? Or working but not good code?

    Here is my test code, works in MSVC 2008.

    Code:
    template <class T> class Foo {
    public:
    	void static test()
    	{
    		T(); // call constructor for any type, including POD?
    	}
    };
    
    int main()
    {
    	Foo<int> g;
    
    	g.test();
    
    	return 0;
    }

    thanks in advance,
    George

  2. #2
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    It is zero-initialized. In the case of int, that means initialized to 0. See this post for more information:

    http://www.codeguru.com/forum/showth...87&postcount=9

    The code is "good".

  3. #3
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Isn't that just creating a temporary T?
    Maybe something more useful would be:
    Code:
    template <class T> class Foo {
    public:
        static void Test()
        {
            T t;
            ...
        }
    };
    This will also call the default T constructor, and now you can use the T you created.

  4. #4
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Daved,


    Clear reply and good reference! Cool!!

    Quote Originally Posted by Daved View Post
    It is zero-initialized. In the case of int, that means initialized to 0. See this post for more information:

    http://www.codeguru.com/forum/showth...87&postcount=9

    The code is "good".

    Thanks cpjust,


    How to test default T constructor is called for POD types?

    Quote Originally Posted by cpjust View Post
    Isn't that just creating a temporary T?
    Maybe something more useful would be:
    Code:
    template <class T> class Foo {
    public:
        static void Test()
        {
            T t;
            ...
        }
    };
    This will also call the default T constructor, and now you can use the T you created.

    regards,
    George

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    You can't, because the default constructor of PODs does nothing.
    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

  6. #6
    The larch
    Join Date
    May 2006
    Posts
    3,573
    It seems to me (with MingW) that T t; leaves t uninitialized whereas T t = T(); does zero-initialization. It seems that this was also mentioned in the linked thread.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  7. #7
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    I think from Spec, in the case of constructor for POD type, the behavior should be zero initialized, right?

    Quote Originally Posted by CornedBee View Post
    You can't, because the default constructor of PODs does nothing.

    Thanks anon,


    1.

    I think the correct behavior should be zero-initialized for T t?

    2.

    For T t = T(); I think it will invoke the copy constructor of t? I am not sure. Do you have any ideas, CornedBee?

    Quote Originally Posted by anon View Post
    It seems to me (with MingW) that T t; leaves t uninitialized whereas T t = T(); does zero-initialization. It seems that this was also mentioned in the linked thread.

    regards,
    George

  8. #8
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    I think from Spec, in the case of constructor for POD type, the behavior should be zero initialized, right?
    Which part of "does nothing" was too hard to understand? A default-initialized POD has an unspecified value. Reading it invokes undefined behaviour.

    The subtlety here comes not from what the default constructor does, but from when a POD is default-constructed, and when it is value-initialized. Value-initialization of PODs leads to zero-initialization.

    T t;
    Default-constructs t. If it's a POD, the value is unspecified.

    T t = T();
    Default-constructs a T, and copies it to t. If T is a POD, this default-construction leads to value-initialization.
    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
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    The question is probably how can you tell if a POD type has been zero-initialized.

    The answer is you can't really for sure. You can check to see if it is zero, but an uninitialized value can often be zero as well.

  10. #10
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks Daved,


    Yes, we can not distinguish with uninitialized and zero initialized, if uninitialized is 0. :-)

    What I want to discuss is more about how Spec regulates it, from Spec,

    http://www.codeguru.com/forum/showth...87&postcount=9

    Seems it is regualated in Spec it should be zero initialized for POD, right?

    Quote Originally Posted by Daved View Post
    The question is probably how can you tell if a POD type has been zero-initialized.

    The answer is you can't really for sure. You can check to see if it is zero, but an uninitialized value can often be zero as well.

    Thanks CornedBee,


    You mean both statements will make variable t undefined values?

    Quote Originally Posted by CornedBee View Post
    Which part of "does nothing" was too hard to understand? A default-initialized POD has an unspecified value. Reading it invokes undefined behaviour.

    The subtlety here comes not from what the default constructor does, but from when a POD is default-constructed, and when it is value-initialized. Value-initialization of PODs leads to zero-initialization.

    T t;
    Default-constructs t. If it's a POD, the value is unspecified.

    T t = T();
    Default-constructs a T, and copies it to t. If T is a POD, this default-construction leads to value-initialization.

    regards,
    George

  11. #11
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    No, the first will make it unspecified, the second will make it zero.
    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

  12. #12
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    1.

    I think in both cases as you mentioned, default constructor is invoked, right?

    2.

    http://www.codeguru.com/forum/showth...87&postcount=9

    If you referes to the Spec, I think this statement mentions it should be zero initialized, agree?

    --------------------
    — otherwise, the object is zero-initialized
    --------------------

    Quote Originally Posted by CornedBee View Post
    No, the first will make it unspecified, the second will make it zero.

    regards,
    George

  13. #13
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    8.5 is the relevant standard section. I was inaccurate in my wording above. The accurate but simplified version is this:

    default-initialization: For non-PODs, call the default constructor (if any). For PODs, zero-initialize.

    zero-initialize: For simple variables, set to 0. For aggregates, recursively zero-initialize all members. For non-PODs, set the underlying storage to all 0s.

    T(): Default-initialize.

    T t;: For non-primitives, default-initialize. For primitives, don't initialize at all.

    Note: T t(); declares a function.

    In addition, all static duration variables (globals, class statics, function statics) are zero-initialized before anything else is done.

    Does that clear everything up?
    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

  14. #14
    Registered User
    Join Date
    May 2006
    Posts
    1,579
    Thanks CornedBee,


    I quote your below two statements here.

    1. "For PODs, zero-initialize."

    2. "T t;: For non-primitives, default-initialize. For primitives, don't initialize at all."

    Are they conflicting with each other for POD type? (I assume when you talks about primitive, you mean POD types.)

    For normal understanding, T t should invoke constructor (default constructor), you mean for POD type, default constructor is not invoked so the value is un-initialized?

    If yes, does any Spec covers T t does not make zero-initialization for POD type?

    Quote Originally Posted by CornedBee View Post
    8.5 is the relevant standard section. I was inaccurate in my wording above. The accurate but simplified version is this:

    default-initialization: For non-PODs, call the default constructor (if any). For PODs, zero-initialize.

    zero-initialize: For simple variables, set to 0. For aggregates, recursively zero-initialize all members. For non-PODs, set the underlying storage to all 0s.

    T(): Default-initialize.

    T t;: For non-primitives, default-initialize. For primitives, don't initialize at all.

    Note: T t(); declares a function.

    In addition, all static duration variables (globals, class statics, function statics) are zero-initialized before anything else is done.

    Does that clear everything up?

    regards,
    George

  15. #15
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    1) This covers the behaviour for default-initialization.
    2) This covers the behaviour of the statement "T t;". Note that it does not cause default-initialization for primitives, and thus doesn't conflict with #1.
    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

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. invalid types 'int[int]' for array subscript
    By kolistivra in forum C++ Programming
    Replies: 6
    Last Post: 12-11-2010, 12:57 PM
  2. Generalising methods to handle multiple weapon types
    By Swarvy in forum Game Programming
    Replies: 2
    Last Post: 05-22-2009, 02:52 AM
  3. Replies: 6
    Last Post: 08-23-2008, 01:16 PM
  4. The Interactive Animation - my first released C program
    By ulillillia in forum A Brief History of Cprogramming.com
    Replies: 48
    Last Post: 05-10-2007, 02:25 AM
  5. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 06:39 AM