passing around iostreams

[Sören]

Hi,

I'd like advise on passing ownership of an iostream.

The idea is that my factory class/function should open a file,
read enough to detect file type (eg which soundfile format),
then create a Reader object of the appropriate type for the file.

Of course I can call close(), then pass the filename to
the reader constructor and reopen the file there.
But I'd prefer to let the Reader class have an istream (no "f")
- then, if the file is small, the factory could perhaps read it
into a string and pass a stringstream instead of the file handle
(just an example, didn't look at this yet).

So is it safe to let the factory create an ifstream by new,
pass the pointer to reader and dereference it so the Reader
can use an istream& (reference)?
Or would it be better to pass just the streambuf?
- or should I go for reopening (which pretty much rules out
having an istream& in the Reader

Thanks,

Sören

[Cy Edmunds]

"Sören" <sq********@kryphal.nu> wrote in message
news:bf**********@oden.abc.se...

Hi,

I'd like advise on passing ownership of an iostream.

The idea is that my factory class/function should open a file,
read enough to detect file type (eg which soundfile format),
then create a Reader object of the appropriate type for the file.

Of course I can call close(), then pass the filename to
the reader constructor and reopen the file there.
But I'd prefer to let the Reader class have an istream (no "f")
- then, if the file is small, the factory could perhaps read it
into a string and pass a stringstream instead of the file handle
(just an example, didn't look at this yet).

So is it safe to let the factory create an ifstream by new,
pass the pointer to reader and dereference it so the Reader
can use an istream& (reference)?
Or would it be better to pass just the streambuf?
- or should I go for reopening (which pretty much rules out
having an istream& in the Reader

Thanks,

Sören

A stream is a resource your class would have to manage. If you create one
with new you will have memory to manage also. I can't see why you would want
to do that. The filename can just be a std::string. No muss no fuss.

Is your concern about reopening based on performance?

--
Cy
http://home.rochester.rr.com/cyhome/

[Buster Copley]

Sören wrote:

Hi,

I'd like advise on passing ownership of an iostream.

The idea is that my factory class/function should open a file,
read enough to detect file type (eg which soundfile format),
then create a Reader object of the appropriate type for the file.
I don't get it. Does the factory then return the Reader object?
In that case, the Reader would have to take over ownership of the
istream. You can express this by passing a pointer-to-istream,
allocated by new, to the Reader. You would delete the istream in the
Reader, perhaps in the destructor. The factory can forget about it.

But you still have to copy the Reader at least once in order to return
it by value, and you need to make sure the 'right' copy owns the
stream. I think you would need an auto_ptr <istream> as a member
of Reader, initialized in the constructor (maybe even by the copy
constructor from an auto_ptr in the factory, just to show off).

Alternatively, and more likely, does the factory return the object
created by the Reader? Then unless I'm missing something, you can use
automatic variables. If the ifstream's scope encloses that of the
Reader, you can simply pass by reference-to-istream, and leave ownership
of the ifstream with the factory.
Of course I can call close(), then pass the filename to
the reader constructor and reopen the file there.
But I'd prefer to let the Reader class have an istream (no "f")
- then, if the file is small, the factory could perhaps read it
into a string and pass a stringstream instead of the file handle
(just an example, didn't look at this yet).

So is it safe to let the factory create an ifstream by new,
pass the pointer to reader and dereference it so the Reader
can use an istream& (reference)?
Or would it be better to pass just the streambuf?
- or should I go for reopening (which pretty much rules out
having an istream& in the Reader

Thanks,

Sören

Regards,
Buster

[Sören]

Thanks for your comments!

Cy Edmunds wrote:

A stream is a resource your class would have to manage. If you create one
with new you will have memory to manage also. I can't see why you would want
to do that. The filename can just be a std::string. No muss no fuss.

Is your concern about reopening based on performance?

No, generality. I'll rephrase below.
My Reader (or Decoder) class should (i think) have an istream member for the bytes,
not an ifstream.
Its task is to decode these bytes into meaningful data and deliver on request.
The *typical* case is that the bytes come from a file, but they might also
be stored in an array - if the file was so small it could be loaded into memory.

General question: How to handle this?
(- I have now a sketch of solution as follows)

More specific question: Is the following a good idea?

As mentioned in my first post, my factory method opens a file, decodes file type,
then creates a Reader and returns a pointer-to-Reader (well, a smart ptr).
Optionally it may load the entire file, but usually it would pass file ownership.

Now, to pass ifstream (file) ownership from factory to product I think I could pass
the factory ifstream streambuf into the Reader (product) class constructor,
and construct the Reader's istream member around that.
I understand that the Reader-istream then does take ownership,
and will close and destroy the file when Reader is destroyed?
(or free memory if the streambuf is a stringstreambuf, etc)

But the istream in the factory will of course also be destroyed when it goes out
of scope. To prevent that I guess I could switch the streambuf of the factory-istream.
But is this a good idea?
Thanks for your patience.

Sören