Question: I have used initialization lists a great deal in my C++ programs but wasn't aware that you could allocate memory within them.

So you can do something (as a contrived example) like this:

```
class Test
{
private:
    int* i;
    int* j;
    int count;
    int* k;

public:
    Test(void) : i(new int), j(new int[10]), count(10), k(new int[count])
    {
    }

    ~Test(void)
    {
        delete i;
        delete [] j;
        delete [] k;
    }
};

```

Are there any issues in doing memory allocation in this way? Regarding the order of initialization here is it safe to have a parameter initialized by one initialized in the same list? i.e. as I allocate `count` before I use it is it safe to use or is there some special initialization order I could fall foul of?

Answer: 
It's not exception-safe. If the `new` for `j` throws an exception then the destructor for `Test` is not called, and so the memory for `i` is not freed.

The destructor of `i` is called if the initializer for `j` throws, it's just that a raw pointer has no destructor. So you could make it exception-safe by replacing `i` with a suitable smart pointer. In this case, `unique_ptr<int>` for `i` and `unique_ptr<int[]>` for `j` would do.

You can rely on the initializers to be executed in their correct order (the order the members are defined, not necessarily the order in the list). They can safely use data members that have already been initialized, so there's no problem with using `count` in the initializer for `k`.
There's no problem with your initialization -- they are guaranteed by the standard to be done in order, however, do remember that if any of those allocations fails, the former ones won't be freed.

So the only downside is if you want to keep safe against a failed allocation -- then you'd rather want to initialize them to `nil` and in the constructor wrap the allocation up in a `try` block. That is usually not needed though, unless your application is in the real danger of running out of memory, and needs to recover from that.

Of course that holds true assuming that only a lack of memory can throw an exception -- if you allocate objects that can throw other exceptions, you should be more worried about it.