Value initialization using an empty pair of parentheses

This is a discussion on Value initialization using an empty pair of parentheses within the C++ Programming forums, part of the General Programming Boards category; I'm not arguing that. But if indeed gcc fails to support the syntax......

  1. #16
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    I'm not arguing that. But if indeed gcc fails to support the syntax...
    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.

  2. #17
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    OK, well, I've attached a workaround that can be used with broken compilers in the meantime. Here's a sample test program:

    Code:
    #include <iostream>
    #include <iterator>
    #include <algorithm>
    #include "broken_new_default_initialization_workaround"
    
    using namespace std;
    
    int main( void )
    {
        size_t
            length = 32;
        double*
            data = new double[ length ]( );    
        copy( data, data + length, ostream_iterator< double >( cout, "\n" ) );
        delete [ ] data;    
    }
    EDIT: Had to add .txt extension to upload

    EDIT#2: Whoops, had set 'BROKEN_NEW_DEFAULT_INITIALIZATION_WORKAROUND_ALIG NMENT' to an arbitrary value for debugging purposes and forgot to reset to 0. Fixed.

    EDIT#3: Fixed throw specification bug.

    EDIT#4: Removed exception specification altogether.

    EDIT#5: Reinstated exception specification, added nothrow variants.
    Attached Files Attached Files
    Last edited by Sebastiani; 09-06-2009 at 05:46 PM.

  3. #18
    'Allo, 'Allo, Allo
    Join Date
    Apr 2008
    Posts
    612
    Code:
    void* allocate( size_t size ) throw( )
    {
        ...
        if( data == 0 )
            throw std::bad_alloc( );
    Oops, slight brain fart there, but kudos as well. std::unexpected never seems to get any coverage, even if it is indirectly here. The last mention on these boards seems to have been 2007 so either exception specifications are less popular than Simon Cowell's Teletubby back catalogue or teaching material does an excellent job of explaining them.

  4. #19
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    Yeah. Should be a null pointer instead. Or the admission of bad_alloc in the exception specification. Both cases will be Standard-friendly.

    But well done, Sebastiani.
    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.

  5. #20
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by adeyblue View Post
    Code:
    void* allocate( size_t size ) throw( )
    {
        ...
        if( data == 0 )
            throw std::bad_alloc( );
    Oops, slight brain fart there, but kudos as well. std::unexpected never seems to get any coverage, even if it is indirectly here. The last mention on these boards seems to have been 2007 so either exception specifications are less popular than Simon Cowell's Teletubby back catalogue or teaching material does an excellent job of explaining them.
    To be honest, I've only used exception specifications on a few rare occasions, and so I was genuinely confused about their proper usage. Thanks for pointing that out! Also fixed.

  6. #21
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Why use exception specifications ever? They do nothing useful and spread like a virus in code that uses them.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  7. #22
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    erm... because you can?

    Quote Originally Posted by ISO-IEC 14882-2003(E), 3.7.3-2, pag. 47
    The library provides default definitions for the global allocation and deallocation functions. Some global allocation and deallocation functions are replaceable (18.4.1).
    Quote Originally Posted by ISO-IEC 14882-2003(E), 18.4.1.2, pag. 345
    Array forms
    Code:
    void* operator new[](std::size_t size) throw(std::bad_alloc);
    1 Effects: The allocation function (3.7.3.1) called by the array form of a new-expression (5.3.4) to allocate size bytes of storage suitably aligned to represent any array object of that size or smaller.
    2 Replaceable: a C++ program can define a function with this function signature that displaces the default version defined by the C++ Standard library.
    3 Required behavior: Same as for operator new(std::size_t). This requirement is binding on a replacement version of this function.
    4 Default behavior: Returns operator new(size).

    Code:
    void* operator new[](std::size_t size, const std::nothrow_t&) throw();
    5 Effects: Same as above, except that it is called by a placement version of a new-expression when a C++ program prefers a null pointer result as an error indication, instead of a bad_alloc exception.
    6 Replaceable: a C++ program can define a function with this function signature that displaces the default version defined by the C++ Standard library.
    7 Required behavior: Same as for operator new(std::size_t,const std::nothrow_t&). This nothrow version of operator new[] returns a pointer obtained as if acquired from the ordinary version.
    8 Default behavior: Returns operator new(size,nothrow).
    I could ask what's so wrong about exception specifications anyway. But I'd rather not.
    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. #23
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,033
    Exception specifications are largely ignored or unimplemented from what I'm told. Visual C++ doesn't support anything of the type throw(T) even.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #24
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    To my knowledge throw() behaves differently in VC++. It will not call std::unexpected(), but calls terminate(). throw(T) works just fine, although it does the same thing in case another exception is thrown.

    In any case, following the standard, you can't avoid an exception specification for the redefinition of the alloc functions.

    Meanwhile a debate on exception specifications can be found here: GotW #82: Debate #1 - Exception Safety and Specifications: Are They Worth It?, The point 4 is, to me , pretty obvious in it's usage of words like "generally" and "not always". You can't at least avoid exception specifications were they are required.
    Last edited by Mario F.; 09-06-2009 at 02:30 PM.
    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.

  10. #25
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by zephon View Post
    I've read in a book that "we can value-initialize the elements by following the array size by an empty pair of parentheses:"
    Code:
     int *pia = new int[10] ()
    Also the same book states that the following statements will generate different results:
    Code:
    int *pi = new int;         // pi points to an uninitialized int
    int *pi = new int();       // pi points to an int value-initialized to 0
    I've tested those with MinGW and I found no difference in using the pair of parentheses or not. In the case of the array, the elements will not be initialized and in the second case, pi will point to a 0 initialized int in both cases.
    Its undefined behavior. It's implimentation dependent, meaning compilers are free to handle it any way they want. Microsoft compilers generally initialize all variables to 0. Other compilers may or may not. Either way is acceptable to the standard.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  11. #26
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,033
    If they are required, then they are required, true, but for everywhere else, I'd avoid them like the plague, since that's what they are. Compile-time errors for throws might have been better.
    Also, Visual C++ does ignore them (except throw()), as pointed out here.
    Furthermore, according to MSDN, the compiler will generate code that ignores exceptions if you use throw(), which may lead to undefined behavior if exceptions are thrown (Source). It will not call std::unexpected or std::terminate. Or at least don't rely on it.
    throw(T) is handled the same as throw(...), meaning it can throw anything.

    The page is specified to VS2005, but I believe it will carry over to 2008, as well since not much changed between them.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  12. #27
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by Elysia View Post
    Also, Visual C++ does ignore them (except throw()), as pointed out here.
    Furthermore, according to MSDN, the compiler will generate code that ignores exceptions if you use throw(), which may lead to undefined behavior if exceptions are thrown (Source). It will not call std::unexpected or std::terminate. Or at least don't rely on it.
    I didn't know that. Way to go MS! Next we just need to get them removed from the standard completel.
    "I am probably the laziest programmer on the planet, a fact with which anyone who has ever seen my code will agree." - esbo, 11/15/2008

    "the internet is a scary place to be thats why i dont use it much." - billet, 03/17/2010

  13. #28
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Quote Originally Posted by cpjust View Post
    I didn't know that. Way to go MS! Next we just need to get them removed from the standard completel.
    It seems that MS quite often interprets standards (including their own) as mere 'suggestions'. Try parsing a PE file correctly, for example - not only will you find undocumented layouts but ones that clearly *contradict* the specs.

    MS: "Standards? We don't need no stinking standards!"

  14. #29
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,581
    Weird. I didn't know about this either. Had to test just to be sure.
    But I'm not so sure the loss of std::undefined() is a desirable thing. Definitely this affects portability and no matter what one may think or not of the feature, it is a non-standard implementation.

    I also yet to see a convincing argument for the removal of exception specifications. Other than the usual because it's evil. Riight.
    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.

  15. #30
    Guest Sebastiani's Avatar
    Join Date
    Aug 2001
    Location
    Waterloo, Texas
    Posts
    5,708
    Ok, well, considering what everyone has pointed out here, I've decided to remove the exception specifications from the implementation. Done.

Page 2 of 3 FirstFirst 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Regarding const array initialization
    By codegeru in forum C++ Programming
    Replies: 7
    Last Post: 07-19-2009, 11:55 AM
  2. Help with binary file c++
    By lucky_mutani in forum C++ Programming
    Replies: 4
    Last Post: 06-05-2009, 10:24 AM
  3. Polynomials and ADT's
    By Emeighty in forum C++ Programming
    Replies: 20
    Last Post: 08-19-2008, 09:32 AM
  4. Writing my own stl container
    By curos in forum C++ Programming
    Replies: 10
    Last Post: 12-18-2005, 04:33 AM
  5. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 07:39 AM

Tags for this Thread


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