Temporaries problem (C++)

[GameZelda]

I have some code that is like this:

(input is a stream &)

[...]
stream *uncompStream;

if (compressed == false)
{
    uncompStream = &input;
}
else
{
    uncompStream = new uncompress_stream(&input);
}
[...]

Is there any way to write this code without dynamically allocating the uncompress_stream class?
I can't find any way to allocate the uncompress_stream in the stack without it being destroyed in the "}".

The only "automatic" solution that I've found is to use a smart pointer (assigned to NULL initially), and use it if it I need an uncompress_stream. However, that looks a bit bad.

[laserlight]

It does sound like dynamic memory allocation is the correct approach here, particularly with a smart pointer.

[NMTop40]

You can use boost/tr1 here but you need a custom deleter to do nothing with the one passed in as a parameter.

You can also possibly use auto_ptr which is left empty if not used.

Example with shared_ptr:

template < typename T > struct no_op_deleter
{
   void operator() ( T * ) {} // do not delete the pointer
};
   
shared_ptr< stream > uncompStream;
if( !compressed )
{
   uncompStream.reset( &input, no_op_deleter< stream >() );
}
else
{
  uncompStream.reset( new uncompress_stream( &input ) );
}

Example using auto_ptr

stream * uncompStream;
std::auto_ptr< stream > autoStream;
if ( !compressed )
{
    uncompStream = &input;
}
else
{
   autoStream.reset( new uncompress_stream( &input );
    uncompStream = autoStream.get()
}
// rest of function

[GameZelda]

Thanks!

[Lindley]

You'd be doing the same thing under the hood more or less, but this seems like a case where the Factory pattern could aid in maintaining the abstraction.

[JVene]

It's an ugly problem, IMO.

The parameter input is clean enough - a reference, no problems there.

The problem comes in with the dynamically allocated de-compressor. In one context you have something to delete, but not in the other. That's the ugly part.

I'd personally prefer to choose one of a few other methods, and that's primarily out of habit to avoid situations like this, which if handed off to other developers becomes something they have to 'know'.

I'd call one of two functions, differentiated between one and the other paradigm, making this an inline.

Alternatively, I'd change the function so the parameter is a shared_ptr of the input stream, but that assumes I could make the de-compressor accept a smart pointer (which it just might if I made it). The shared_ptr also helps support threaded work, so I could toss this stream to other threads at will without further containment questions.

My point is that I suggest you establish habits that avoid this kind of "dual mode containment" question (probably the reason you sought inquiry in the first place, it's on your mind - and that's excellent).