# should I wrap ifstream and ofstream?

This topic is 4835 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Basically I've been frustrated with writing functions that accept references to fstreams. As an example of why its annoying: Suppose I have to pass an ifstream to a function that will read some data from the stream into a class, the function can check if the stream is open but doesn't know whether to expect binary or ascii data so assumptions must be made. Previously I have got around this by doing my best to ensure either binary or ascii throughout (so no confusion), or to put a flag at the start of every file indicating ascii or binary (so a check can be made). But nothings fool-proof from other people doing silly things :) Anyway I was thinking if it was a good idea to unify all kinds of streams through creating an abstract stream class and having differing types of stream implement virtual members for input/output/eof, etc. Perhaps like this:
//pure virtual base class for all streams
class stream

//I/O stream for ascii files
class ascii_fstream : public stream

//I/O stream for binary files
class binary_fstream : public stream

//-> I could also create other stream types such as...
//a memory stream for some purpose I havn't thought of yet :)

//ascii
class ascii_mem_stream : public stream
//binary
class binary_mem_stream : public stream


well you get the idea :) The advantages here are that I can safely use a reference to a stream object without knowing (or caring) if its for input, output, ascii or binary. I can also extend the system to a memory stream (as demonstrated) possibly for reading data that had to be decompressed and put into a buffer. Also if I design it right, I can eliminate issues regarding endianess for binary files (which is a pain for me normally). But what is the usual solution to these problems (surely they're commmon problems when passing any fstreams around), I wondered if something already existed in the standard that I wasn't aware of. Thanks for any help or critique.

##### Share on other sites
I think there are some things that are worth wrapping and others that are. I dont think this is worth wrapping, because your simply bridging and not performing much more functionality as well as what stream already does. There is little point in just repeating the creation code and changine a few parameters.

Then again you could argue that it isnt a complicated wrap, so it wont tka much time to write or dent performance.

But for me its a dont bother, but llike i said i dont use all types of file access all the time.

ace

##### Share on other sites
I wrapped it up so I could just make one function call to write to the log file in my engine, without having to worry about getting the file stream. It also means that the user of the file system doesn't have to worry about handling errors that could crop up, and I can store some useful info along with the stream if I need it.

1. 1
Rutin
36
2. 2
3. 3
4. 4
5. 5

• 12
• 14
• 9
• 9
• 14
• ### Forum Statistics

• Total Topics
633343
• Total Posts
3011434
• ### Who's Online (See full list)

There are no registered users currently online

×