auto_ptr array

Hello everyone,


I have tried to initialize an auto_ptr array, but failed. My C++ Programming Language book does not contain a sample about how to initialize an auto_ptr array.

(not an auto_ptr pointing to an array, which is not legal)

Any solutions?

Code:

---

#include <memory>

using namespace std;

int main()
{
        auto_ptr<int[]> pi (new int[10]); // compile error
       
        auto_ptr<int> pi (new int[10]); // compile error
       
        return 0;
}

---

thanks in advance,
George

I'm only sort of guessing, but wouldn't it be:

Code:

---

auto_ptr<int> pi[10];

---

--
Mats

Thanks Mats,


But how to initialize it with an int array?

Quote:

---

Originally Posted by matsp

I'm only sort of guessing, but wouldn't it be:

Code:

---

auto_ptr<int> pi[10];

---

--
Mats

---

regards,
George

You can't.
auto_ptr's destructor does:

Code:

---

delete ptr;

---

but to delete an array you would need to do:

Code:

---

delete [] ptr;

---

That's why I wrote my own AutoPtr class which can take a custom "deletor" object. Boost has many other types of auto pointer classes which might do what you need.

Alternatively, you can use a vector inside the auto_ptr for an array.

Hi cpjust,


What is your answer to my question? My question is how to define an auto_ptr array with initialization at the same time.

Seems your answer is we can not make an auto_ptr point to an array -- I already understand it. This is not my question.

Quote:

---

Originally Posted by cpjust

You can't.
auto_ptr's destructor does:

Code:

---

delete ptr;

---

but to delete an array you would need to do:

Code:

---

delete [] ptr;

---

That's why I wrote my own AutoPtr class which can take a custom "deletor" object. Boost has many other types of auto pointer classes which might do what you need.

---

Hi Elysia,


Vector does its own memory management and it is ensured when the vector is out-of scope, all elements' destructor is called. Is there any special benefits we can get if we use auto_ptr to make an additional wrapper, like auto_ptr<vector<int>>?

Quote:

---

Originally Posted by Elysia

Alternatively, you can use a vector inside the auto_ptr for an array.

---

regards,
George

Of course, just as for anything else. If you need a vector (or array) that needs to live beyond the end of the function. That's what smart pointers are for - to encapsulate raw pointers.

Wouldn't

Code:

---

auto_ptr <int> pi[10] = {new int, new int, new int, new int, new int,
        new int, new int, new int, new int, new int};

---

work?
Yes, it's terrible. :p

It would work, but it's not exception-safe. If any of these allocations fail, you leak all others.

What are you trying to do? auto_ptr is not intended to manage arrays. vector is. std::tr1::array is. boost::scoped_array is. boost::shared_array is. Use those options (and others designed to manage arrays).

Quote:

---

It would work, but it's not exception-safe. If any of these allocations fail, you leak all others.

---

It fails to compile on the MinGW port of g++ 3.4.5, the Comeau online compiler and MSVC8. The reason is that auto_ptr's constructor that takes a T* is explicit. A solution would be:

Code:

---

std::auto_ptr<int> pi[10] = {std::auto_ptr<int>(new int),
                            std::auto_ptr<int>(new int),
                            std::auto_ptr<int>(new int),
                            std::auto_ptr<int>(new int),
                            std::auto_ptr<int>(new int),
                            std::auto_ptr<int>(new int),
                            std::auto_ptr<int>(new int),
                            std::auto_ptr<int>(new int),
                            std::auto_ptr<int>(new int),
                            std::auto_ptr<int>(new int)};

---

This modified code should be exception safe, methinks. Nonetheless, I do not see what is the point of an array of auto_ptrs.

Incidentally, this is cross posted in Code Guru: auto_ptr array .

Quote:

---

This modified code should be exception safe, methinks.

---

Nope, still isn't. The compiler is free to execute all allocations before constructing a single auto_ptr.

Quote:

---

Nope, still isn't. The compiler is free to execute all allocations before constructing a single auto_ptr.

---

What is the corresponding section concerning that in the C++ standard?

The definition of sequence points. I'm pretty sure there's no sequence point between the individual initializers of an array.

Although, I probably should look that up.
...
Yeah, no such thing there. So, the individual initializers of an aggregate initializer are not relatively ordered, and as such, the argument computations are not ordered between them.

That's not to say that any sane compiler would actually mix them up.

Thanks Elysia,


Your reply is clear.

Quote:

---

Originally Posted by Elysia

Of course, just as for anything else. If you need a vector (or array) that needs to live beyond the end of the function. That's what smart pointers are for - to encapsulate raw pointers.

---

Thanks CornedBee,


Let us know if you have found definite result from standard whether the code in post #11 is exception safe or not? To my point of view, I think it should be safe.

Quote:

---

Originally Posted by CornedBee

The definition of sequence points. I'm pretty sure there's no sequence point between the individual initializers of an array.

Although, I probably should look that up.
...
Yeah, no such thing there. So, the individual initializers of an aggregate initializer are not relatively ordered, and as such, the argument computations are not ordered between them.

That's not to say that any sane compiler would actually mix them up.

---

regards,
George

Quote:

---

Let us know if you have found definite result from standard whether the code in post #11 is exception safe or not? To my point of view, I think it should be safe.

---

He did ("Yeah, no such thing there.") and I agree with him. The code is not guaranteed to be exception safe.

Thanks laserlight,


A little mess. Let me confirm. :-)

1.

For code in post #8, we are definitely sure it is not exception safe?

2.

For code in post #11, we think it is implementation defined whether or not it is exception safe?

Quote:

---

Originally Posted by laserlight

He did ("Yeah, no such thing there.") and I agree with him. The code is not guaranteed to be exception safe.

---

regards,
George

Quote:

---

Originally Posted by George2

For code in post #11, we think it is implementation defined whether or not it is exception safe?

---

And that, by definition, makes it unsafe. If it's not guaranteed to be safe, then it's not safe.

--
Mats

Thanks Mats,


Now I understand both coding practice of code in post #8 and in post #11 are not exception safe.

Quote:

---

Originally Posted by matsp

And that, by definition, makes it unsafe. If it's not guaranteed to be safe, then it's not safe.

--
Mats

---

regards,
George

Quote:

---

Originally Posted by George2

For code in post #8, we are definitely sure it is not exception safe?

---

I believe the verdict was "won't compile".

Quote:

---

For code in post #11, we think it is implementation defined whether or not it is exception safe?

---

No, the implementation is under no obligation to define anything here. It's unspecified, and may change from one compilation to the other, based on some totally unrelated changes that change the way the optimizer reasons about the code.

Thanks CornedBee,


1.

Quote:

---

Originally Posted by CornedBee

I believe the verdict was "won't compile".

---

You are correct. I have tried it.

2.

Quote:

---

Originally Posted by CornedBee

No, the implementation is under no obligation to define anything here. It's unspecified, and may change from one compilation to the other, based on some totally unrelated changes that change the way the optimizer reasons about the code.

---

Interested. In my normal senses, the code in post #11 should not leak. If you know any compiler which will leak memory in code sample in post #11, please let me know. :-)


regards,
George

Quote:

---

Originally Posted by George2

Thanks CornedBee,

Interested. In my normal senses, the code in post #11 should not leak. If you know any compiler which will leak memory in code sample in post #11, please let me know. :-)


regards,
George

---

Well, it won't leak unless you are low on memory, but there's (according to the previous discussion) no guarantee that the compile produces the actual auto_ptr immediately as it's allocating the memory for it, so you may end up with a dangling pointer if you have an exception during the initialization of the array. And as Cornedbee says: It may change at a whim of the compiler, e.g. you change the options, the code generator thinks the function is "too complex", so it uses a different set of rules for the "too complex" function compared to a simple function [because you added an extra if-statement at the end of the code, for example].

--
Mats

Thanks Mats,


Three more comments,

1.

Quote:

---

Originally Posted by matsp

Well, it won't leak unless you are low on memory,

---

Memory leak has nothing to do with whether memory is low or not?

2.

Quote:

---

Originally Posted by matsp

but there's (according to the previous discussion) no guarantee that the compile produces the actual auto_ptr immediately as it's allocating the memory for it, so you may end up with a dangling pointer if you have an exception during the initialization of the array.

---

"Dangling pointer" means, if compiler decides to allocate memory before constructing auto_ptr, and exception in the middle before constructing auto_ptr, no pointer pointed to the allocated memory, so this is what you mean "Dangling pointer"?

3.

Quote:

---

Originally Posted by matsp

And as Cornedbee says: It may change at a whim of the compiler, e.g. you change the options, the code generator thinks the function is "too complex", so it uses a different set of rules for the "too complex" function compared to a simple function [because you added an extra if-statement at the end of the code, for example].

--
Mats

---

I do not understand your "if-statement" sample, can you show the code?


regards,
George

Quote:

---

Originally Posted by George2

Memory leak has nothing to do with whether memory is low or not?

---

Of course it does. Say you manage to allocate 5 of the object, then new fails because there's not enough memory, the rest of the pointers will leak unless assigned to the auto_ptr, which it is not guaranteed to do.

Quote:

---

3. I do not understand your "if-statement" sample, can you show the code?

---

Mats was making a general statement. Meaning that the behavior could be different just because you added or removed a line of code.

Quote:

---

Originally Posted by George2

Thanks Mats,


Three more comments,

1.



Memory leak has nothing to do with whether memory is low or not?

---

Well, not technically, but the only reason it would leak is if your function exits before the auto_ptr's constructor has been called - and this will only happen if new throws, which normally only happens if you're running out of memory (or something has gone wrong with the heap).

Quote:

---

2.



"Dangling pointer" means, if compiler decides to allocate memory before constructing auto_ptr, and exception in the middle before constructing auto_ptr, no pointer pointed to the allocated memory, so this is what you mean "Dangling pointer"?

---

Yes.

Quote:

---

3.



I do not understand your "if-statement" sample, can you show the code?


regards,
George

---

Well, the example I was making is if the compiler counts the number of basic-blocks (e.g. if/else branches etc) and then decides which of several code-generation functions to use. So adding an extra if-statement for example, will perhaps push it into "code-generation function 2" instead of "code-generation function 1".

--
Mats

Thanks Elysia,


Two more comments,

1.

Quote:

---

Originally Posted by Elysia

Of course it does. Say you manage to allocate 5 of the object, then new fails because there's not enough memory, the rest of the pointers will leak unless assigned to the auto_ptr, which it is not guaranteed to do.

---

In my senses, I think when we say exception safety, it means code should not leak memory in any situation based on ensurance of defined behavior of underlying SDK, e.g. we assume delete never throws. It has nothing to do with environment.

2.

Any comments to my item 2 in post #23?


regards,
George

Quote:

---

Originally Posted by George2

In my senses, I think when we say exception safety, it means code should not leak memory in any situation based on ensurance of defined behavior of underlying SDK, e.g. we assume delete never throws. It has nothing to do with environment.

---

I think that sums it up. Exception safety should mean that under no ciruimstance should memory leak or a class be left in a zombie state. Which means avoiding all undefined behaviors,

Quote:

---

2. Any comments to my item 2 in post #23?

---

Mats already told you.

Thanks Mats,

Quote:

---

Originally Posted by matsp

Well, the example I was making is if the compiler counts the number of basic-blocks (e.g. if/else branches etc) and then decides which of several code-generation functions to use. So adding an extra if-statement for example, will perhaps push it into "code-generation function 2" instead of "code-generation function 1".

--
Mats

---

You mean compiler has some different internal functions, which for examples handles if-block and non-if block separately?


regards,
George

Thanks Elysia,


Your reply is clear. Looks like we are posting at the same time. :-)

Quote:

---

Originally Posted by Elysia

I think that sums it up. Exception safety should mean that under no ciruimstance should memory leak or a class be left in a zombie state. Which means avoiding all undefined behaviors,


Mats already told you.

---

regards,
George

Quote:

---

Originally Posted by George2

You mean compiler has some different internal functions, which for examples handles if-block and non-if block separately?

---

Maybe. How a compiler works is a mystery to most programmers. You don't know what it does. It's a black box. You put in source on one end and get out object code on the other. Much can happen in-between.

Thanks CornedBee,


Question answered.

Quote:

---

Originally Posted by CornedBee

Maybe. How a compiler works is a mystery to most programmers. You don't know what it does. It's a black box. You put in source on one end and get out object code on the other. Much can happen in-between.

---

regards,
George

Quote:

---

Originally Posted by CornedBee

Maybe. How a compiler works is a mystery to most programmers. You don't know what it does. It's a black box. You put in source on one end and get out object code on the other. Much can happen in-between.

---

And just like the question of "Meaning of life, universe and everything" according to the great Douglas Adams "Once you've got it figured out, it gets replaced with an even more complex version" - once you think you know what the compiler does for all things, the next version of the compiler comes out, and things are different.

We're just getting a new compiler in at work, and the initial tests show that it generates code that is about 2% longer than the previous compiler version - you'd expect the new compiler to generate SMALLER code.

--
Mats

You know so much, thanks Mats!

Quote:

---

Originally Posted by matsp

And just like the question of "Meaning of life, universe and everything" according to the great Douglas Adams "Once you've got it figured out, it gets replaced with an even more complex version" - once you think you know what the compiler does for all things, the next version of the compiler comes out, and things are different.

We're just getting a new compiler in at work, and the initial tests show that it generates code that is about 2% longer than the previous compiler version - you'd expect the new compiler to generate SMALLER code.

--
Mats

---

regards,
George