Value initialization using an empty pair of parentheses

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.

>> I've read in a book that "we can value-initialize the elements by following the array size by an empty pair of parentheses:"

Hmm. I've always thought that to be the case also, but GCC doesn't seem to do it properly, and now, well, I'm not so sure. I'll try to see if I can find it in the standard. In any case, keep in mind that assigning a raw pointer to the result of new is quite error prone - it should always be placed in an object with a destructor (or just use something like std::vector and be done with it).

Quote:

---

Originally Posted by zephon

Code:

---

int *pi = new int;        // pi points to an uninitialized int
int *pi = new int();      // pi points to an int value-initialized to 0

---

---

This is correct. The parenthesis instruct the compiler we want to initialize the pointer. This much we understand from user defined objects. If I define my own class and then want to initialize it, I may write something like and call the class default constructor:

myClass* ptr = new myClass();

For built-in types like int, the presence of parenthesis are a simple instruction for the compiler to initialize the pointer. Since we aren't providing any value, it will initialize it to zero. What I find extremely odd is that you are seeing also an initialization to 0 on int *pi = new int. Try the following code and post the results:

Code:

---

#include <iostream>

int main() {

    int a = 13;

    int *pi = new int;
    int *pia = new int();
    int *pib = new int(a);

    std::cout << *pi << "  " << *pia << "    " << *pib;

}

---

It should output a random number, followed by 0, followed by 13.

With MinGW 4.4.1 I see 0 0 13. Could be random luck or could be that the compiler doesn't bother to leave it uninitialized. (In practice I doubt one would ever allocate a single built-in type instance, and 99% of the time you wouldn't use array new either.)

>> What I find extremely odd is that you are seeing also an initialization to 0 on int *pi = new int.

Maybe. But then again, zero is a pretty common value in memory, so that may just be the random value you get. The thing that bothers me is that the default initialization syntax doesn't work when I run it through GCC (the explicit initialization doesn't compile at all, either, though - perhaps I'm just overdue for an update?).

Hmm... the compiler being benign, for a change? :)

Seriously though, may be something somewhat recent. And something one can alter with some switch. I'm pretty sure I saw gcc with uninitialized pointers before and I seriously doubt it will work with -ansi -pedantic.

I also get 0 0 13 with MinGW and with Digital Mars compiler.

For the array initialization I get the following compilation error with Digital Mars Compiler

Code:

---

int *px = new int[10]();
                      ^
main.cpp(9) : Error: function expected

---

So I guess this syntax is not standard. The book in which I've read about this is "C++ Primer" Fourth Edition.

Try to add -ansi -pedantic to the compilation flags.

As for the array. No. It doesn't work. I also have that book somewhere. I honestly don't remember they ever making such a crude mistake. The book is one of the most recommended books to learn C++. What's the page where you see that syntax for the array?

EDIT: I flipped through and saw it. It's on page 134. And it works indeed. It value initializes the array elements to 0. Interesting. I do remember now seeing this before. What you cannot do however, contrary to non-array built in types is something like int *pia = new int[10] (3);. In this case, you'll need to explicitly initialize each member.

Code:

---

#include <iostream>

int main() {

    int *pi = new int[10];
    int *pia = new int[10]();

    std::cout << pi[7] << "  " << pia[7];

}

---

Returns a random number followed by 0 on VC++ 2008.

So, the fact the array is not working under MinGW is more troublesome.

This is what I could found on the standard -- after only a quick perusal -- that, according to my interpretation, seems to indicate gcc is not following it:

Quote:

---

Originally Posted by 5.3.4-15

A new-expression that creates an object of type T initializes that object as follows:
— If the new-initializer is omitted:
— If T is a (possibly cv-qualified) non-POD class type (or array thereof), the object is default-
initialized (8.5). If T is a const-qualified type, the underlying class type shall have a user-declared default constructor.
— Otherwise, the object created has indeterminate value. If T is a const-qualified type, or a (possibly cv-qualified) POD class type (or array thereof) containing (directly or indirectly) a member of const-qualified type, the program is ill-formed;
— If the new-initializer is of the form (), the item is value-initialized (8.5);

---

Quote:

---

Originally Posted by 8.5-5

To zero-initialize an object of type T means:
— if T is a scalar type (3.9), the object is set to the value of 0 (zero) converted to T;
— if T is a non-union class type, each nonstatic data member and each base-class subobject is zero- initialized;
— if T is a union type, the object’s first named data member is zero-initialized;
— if T is an array type, each element is zero-initialized;

---

With -ansi and -pedantic(MinGW) the value of *pi in

Code:

---

int *pi = new int;

---

is 0. Then I've tried the following code

Code:

---

int main()
{
    const int arr_size=2;
    int *px = new int[arr_size];
    for (size_t i  = 0; i < arr_size; ++i)
        std::cout << *(px + i) << std::endl;
    delete []px;
    return 0;
}

---

What I noticed is that for array sizes of one and two I always get 0 values in the array and for values bigger than two I get random values. Maybe the memory contains 0's at the adresses that the compiler choses for these smaller arrays.

So this dynamic array initialisation is from standard. Then it means MinGW and Digital Mars are not quite standard conformant. Can somebody try this in GCC?

Yes. It has to be a simple coincidence. But if:

Quote:

---

for array sizes of one and two I always get 0 values in the array and for values bigger than two I get random values

---

Then you can always try this:

Code:

---

int main()
{

    int *ptr = new int[120];

    const int arr_size=2;
    int *px = new int[arr_size];
    for (size_t i  = 0; i < arr_size; ++i)
        std::cout << *(px + i) << std::endl;
    delete []px;
    delete[] ptr;

    return 0;
}

---

Let's use up some of the heap prior to your array.

Quote:

---

Originally Posted by Mario F.

So, the fact the array is not working under MinGW is more troublesome.

This is what I could found on the standard -- after only a quick perusal -- that, according to my interpretation, seems to indicate gcc is not following it:

Quote:

---

— if T is an array type, each element is zero-initialized;

---

---

Does that just mean an array on the stack, or also a pointer to an array on the heap?

Quote:

---

Originally Posted by Mario F.

Code:

---

int main()
{

    int *ptr = new int[120];

    const int arr_size=2;
    int *px = new int[arr_size];
    for (size_t i  = 0; i < arr_size; ++i)
        std::cout << *(px + i) << std::endl;
    delete []px;
    delete[] ptr;

    return 0;
}

---

---

I've tried it and it made no difference if the first array was bigger than 2. If the first array was of size 1 or 2, then the second one would get random values. So I guess my assumption was correct.

Next I've tried this code:

Code:

---

int main()
{

    const unsigned arr_size = 5;
    int *ptr[arr_size];

    for (size_t i=0; i < arr_size; ++i)
        ptr[i] = new int ();

    for (size_t i  = 0; i < arr_size; ++i)
        std::cout << *ptr[i] << std::endl;

    for (size_t i  = 0; i < arr_size; ++i)
        delete ptr[i];

    return 0;
}

---

Now here if I use new int() all ints will be 0 initialized while if the brackets were missing, the values will be random (only the first one will be 0, but the reason is similar to the case described above). So default value initialization is correct for single built-in types in MinGW. Only the array initialisation is not correct.

Quote:

---

Originally Posted by cpjust

Does that just mean an array on the stack, or also a pointer to an array on the heap?

---

Well, also an array on the heap, I'd think.
The provision is established in 5.3.4-15 ("If the new-initializer is of the form (), the item is value-initialized (8.5)") and provides no exception for T being an array.

Zero initializing when it's not required to isn't failing to follow the standard anyway.

I'm not arguing that. But if indeed gcc fails to support the syntax...

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. :p Fixed.

EDIT#3: Fixed throw specification bug.

EDIT#4: Removed exception specification altogether.

EDIT#5: Reinstated exception specification, added nothrow variants.

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.

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. :)

Quote:

---

Originally Posted by adeyblue

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.

Why use exception specifications ever? They do nothing useful and spread like a virus in code that uses them.

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.

Exception specifications are largely ignored or unimplemented from what I'm told. Visual C++ doesn't support anything of the type throw(T) even.

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.

Quote:

---

Originally Posted by zephon

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.

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 Elysia

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. ;)

Quote:

---

Originally Posted by cpjust

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!"

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.

Ok, well, considering what everyone has pointed out here, I've decided to remove the exception specifications from the implementation. Done.

Yup. And you just made it non-standard.

Oh - so the standard mandates that operator 'new' has an exception specification? Ok, well I'll just undo that then. :p

EDIT:

I see, post #22.

Hmm, come to think of it, I guess I need to implement a nothrow version as well, right?

Yup. And don't forget that exception specifications are part of the function interface. So, removing them actually doesn't redefine the standard global functions. It creates a new unrelated function.

Ok, thanks. And what about delete? Do you know if it requires an exception specification?

EDIT: Ah, found it. Yes, it does.

Ok, so I've reverted back to using exception specifications, and also added the nothrow variants. Hopefully, everything is kosher now. :p

Quote:

---

Originally Posted by Mario F.

I also yet to see a convincing argument for the removal of exception specifications. Other than the usual because it's evil. Riight.

---

Read chapter 75 "Avoid exception specifications" of "C++ Coding Standards" by Herb Sutter & Andrei Alexandrescu. That should give you all the reasons you need.
Unfortunately the web version of the book seems to be down, so I don't have a link.

Quote:

---

Originally Posted by cpjust

Read chapter 75 "Avoid exception specifications" of "C++ Coding Standards" by Herb Sutter & Andrei Alexandrescu. That should give you all the reasons you need.
Unfortunately the web version of the book seems to be down, so I don't have a link.

---

Sounds interesting. Is that a pretty good read, besides what you mentioned?

Quote:

---

Originally Posted by cpjust

Read chapter 75 "Avoid exception specifications" of "C++ Coding Standards" by Herb Sutter & Andrei Alexandrescu. That should give you all the reasons you need.
Unfortunately the web version of the book seems to be down, so I don't have a link.

---

I'm aware of those issue. I linked to this before. Check some posts back. But I need to ask...

Do you agree it is plausible for a mission critical application/unit/algorithm to rely in std::unexpected() as an exit mechanism and control this through exception specifications?

Quote:

---

Sounds interesting. Is that a pretty good read, besides what you mentioned?

---

One of the most important books in best code practices, Sebastiani. It's a must-have in my opinion.

Quote:

---

Originally Posted by Mario F.

Do you agree it is plausible for a mission critical application/unit/algorithm to rely in std::unexpected() as an exit mechanism and control this through exception specifications?

---

No, not with VC++ at least:

Quote:

---

Originally Posted by MSDN

The C++ Standard requires that unexpected is called when a function throws an exception that is not on its throw list. The current implementation does not support this.

---

set_unexpected (<exception>)

Quote:

---

Originally Posted by Mario F.

I'm aware of those issue. I linked to this before. Check some posts back. But I need to ask...

Do you agree it is plausible for a mission critical application/unit/algorithm to rely in std::unexpected() as an exit mechanism and control this through exception specifications?

---

I think that in a mission critical application, exception specifications lead to undesired coupling between code units. A unit of code must be aware of all possible contexts in which it could be called and guarantee that no exception would be thrown that could propagate through a function with an exception specification that bars that exception. To me this seems to defeat the purpose of code modularity while providing no real design benefit.

The purpose of the exception specification, ostensibly, is to prevent propagation of exceptions that can't be correctly handled. But what actually occurs when this happens is a program abort -- so no problem has actually been solved.

Quote:

---

Originally Posted by brewbuck

The purpose of the exception specification, ostensibly, is to prevent propagation of exceptions that can't be correctly handled. But what actually occurs when this happens is a program abort -- so no problem has actually been solved.

---

Should probably had had an addendum to my post. To better clarify the question.

It's perfectly plausible to want a program abort in some mission critical scenarios where an unhandled exception is met. One example that occurs to me is that of PTA databases. I'd be hard pressed to believe that it isn't acceptable to design a system that, having designed its own exception hierarchy, doesn't want to take advantage of exception specifications to immediately abort execution on unhandled exceptions in certain scenarios. A condition that may guarantee the safety or consistency of data in real-time. Or simply to use exception specifications to expose exception or error handling rules in some middle-tier library.

An unhandled exception is by definition a problem that usually can't be solved. The standard makes this definition evident by calling std::unexpected() which by default calls std::terminate(). This is a language feature. And one that I can find useful on certain scenarios. More importantly because it didn't forget to give me the means to alter this behavior.

...

The alternative is not to use it. And we are given that option too. So, where exactly is the need to remove it from the standard? (note I refuse to use the obvious argument of backwards compatibility. We can ignore that for the sake of argumentation. I'm hoping for a more involving discussion).

This is what a exception specification does:

Code:

---

//for something like void func() throw (X, Y);

void func() {

    try {
        //something
    }
    catch (X) { throw; }
    catch (Y) { throw; }
    catch (...)  { std::unexpected(); }
}

---

There's an advantage in having moved to the function interface information that may be relevant to its user, instead of having it hidden away in the function definition. The disadvantages on the other hand are well known and documented (and on this thread too). So to deny there is never going to exist a scenario where exception specifications may be a useful and elegant solution is pretty much the C++ Never Argument, that we know very well is only true in one situation: Never say never.

This is particularly important to me, because I've found useful scenarios for exception handling that go beyond the conventional and too often alluded approach. It's, for instance, quite acceptable to me to want to use the exception infrastruture and semantics for error handling, instead of (or in addition to) exception handling. As long as there's a clear separation between the too, as long as I'm aware of he implications, as long as any performance hits are well within acceptable ranges, and as well as I guarantee a clear interface, just why not? It's just another idiom. I don't expect to do it often, I don't even expect to do it at all. But the option is there and it is very visible. I'd be a fool not to take it if the opportunity arises, simply because I'm told I shouldn't do it.

In contrast, by removing it from the implementation as VC++ has done (although I suspect I can recover it through the eh.h header), I'm removed of a language feature. For better and for worst. Doesn't strike me wise at all.

EDIT: hmm, this probably should be split...

Well what I actually meant was exception specifications should be removed from all standard functions, so that it's:

Code:

---

void* operator new( std::size_t _Count );

---

instead of:

Code:

---

void* operator new( std::size_t _Count ) throw( bad_alloc );

---

If people want to add them to their own code, they can go right ahead (although I still see no reason why they'd want to).

If exception specifications worked like they do in Java, then they'd be worth using.

Quote:

---

Originally Posted by cpjust

Well what I actually meant was exception specifications should be removed from all standard functions

---

Possibly. Although this time is for me to wonder what you could possible want to throw other than bad_alloc in a function of this nature :)

I's exactly one example where the usage of an exception specification carries with it 2 obvious advantages, and no disadvantage:

- It exposes its exception handling semantics to the user.
- It enforces those semantics.

The alternative, no exception specification, can certainly be achieved without prejudice to the throw(std::bad_alloc). It's my guess you want to do that because you expect to throw something else other than bad_alloc. So, it's acceptable to conclude you want to do something else other than just allocate room. Probably some bookkeeping? Well, you have this mechanism at your disposal by encapsulating the allocator function in your own class.

Quote:

---

If exception specifications worked like they do in Java, then they'd be worth using.

---

Hmm... I suppose you mean the static checking.
This is what Sutter has to say, this time about Java exceptions:

Quoting it here too:

Quote:

---

Essentially, exception specifications are a wonderful idea in basic principle, but no one really knows how to design them.
There are two major approaches, and both have serious problems. Java chose static enforcement (at compile time, as suggested above), and C++ chose dynamic enforcement. Interestingly, I see Java people ask "why not enforce these dynamically?" about as often as I see C++ people ask "why not enforce these statically?"
Briefly:
When you go down the Java path, people love exception specifications until they find themselves all too often encouraged, or even forced, to add throws Exception, which immediately renders the exception specification entirely meaningless. (Example: Imagine writing a Java generic that manipulates an arbitrary type T…)
When you go down the C++ path, people love exception specifications until they discover that violating one means invoking terminate, which is almost never what you want.

---

Even more interesting is this article were checked and unchecked exceptions are discussed in great detail. Here too there's a clear case against static checking.

EDIT: Quite curious. Because I copy-pasted a quote from Sutter's blog, a script on his page added this thread to his blog comments list, without my intention and without informing me.