Thread: intialize array allocated by new

How about the following? I'm particularly interested in the const references.

Code:

#include <iterator>
#include <iostream>

using namespace std;

namespace detail
{
template <class, class, unsigned>
class block_n;

template <class Block, class T, unsigned N>
T* allocate(const block_n<Block, T, N>& block);

template <class Block, class T, unsigned N>
class block_n
{
    const Block& left;
    const T& value;
public:
    block_n(const Block& left, const T& value): left(left), value(value) {}
    block_n<block_n<Block, T, N>, T, N + 1u> operator, (const T& t) const
    {
        return block_n<block_n<Block, T, N>, T, N + 1u>(*this, t);
    }
    T* assign(T* p) const
    {
        p = left.assign(p);
        *p = value;
        return ++p;
    }
    operator T* () const
    {
        return allocate(*this);
    }
};

template <class T>
class block_n<void, T, 1u>
{
    const T& value;
public:
    block_n(const T& t): value(t) {}
    block_n<block_n<void, T, 1u>, T, 2u> operator, (const T& t) const
    {
        return block_n<block_n<void, T, 1u>, T, 2u>(*this, t);
    }
    T* assign(T* p) const { *p = value; return ++p; }
    operator T* () const
    {
        return allocate(*this);
    }
};

template <class Block, class T, unsigned N>
T* allocate(const block_n<Block, T, N>& block)
{
    T* p = new T[N];
    try {
        block.assign(p);
    } catch (...) {
        delete [] p;
        throw;
    }
    return p;
}
} //namespace detail

template <class T>
class block
{
public:
    detail::block_n<void, T, 1u> operator, (const T& t)
    {
        return detail::block_n<void, T, 1u>(t);
    }
};

int main( void )
{
    int*  array = ( block< int >( ), 1, 2, 3 );
    copy( array, array + 3, ostream_iterator< int, char >( cout, "\n" ) );
    return 0;
}

P.S For all practical purposes this syntax is meaningless. The size of the array is deduced from the number of arguments only. Other code has no means of finding out the size of the dynamically allocated array. (Compare with how you can find out the size of the stack array even if you let the array's size be deduced from the initalization arguments.)

Best thing to do is to hope that the hard-coded 3 in the copy call is correct and no-one removes any arguments from the initialization...

>> Sebastiani points out the exception safety missing from that example, but here's another way you could add it:

In this particular case it was actually already exception safe (without the try block), but anyway, in general I think your approach can be quite useful in many different contexts. In fact, after you posted that I realized that something like that might even be useful for implementing "function within a function" semantics.

>> With an almost negligible change in the interface you can bypass additional copies mandated by the assignment and possibly avoid allocation.

I wouldn't design the whole thing around avoiding copies, necessarily, but it would probably be a good idea to provide an extended interface to allow it.

>> How about the following? I'm particularly interested in the const references.

That's pretty cool, actually. I didn't even consider a compile-time solution. The only drawback to something like this, though, would be really large array initializations. The effect on compilation time can be noticeable:

Code:

int main( void )
{
	char*
		text = 
	( 
		block< char >( ), 
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',		
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		'T', 'e', 's', 't', 'i', 'n', 'g', '\n',
		0	
	);
	cout << text;
	delete [ ] text;
	return 0;
}

Anyway, it is rather ingenious, and so I've added it to my library of "interesting uses of templates".

>> For this silly thing, it isn't that major, but take a moment to consider the implications.

Well, obviously, in the case of a full-featured object one would be concerned with the state of such things as 'size', 'capacity', etc, but this was just a demonstrative example that assumes the user won't be cacheing the object for some later use. In that case, a handful of temporary variables to hold the results and a RAII approach to memory management (such as suggested by iMalc) would suffice.