Jump to content
  • Advertisement
Sign in to follow this  
dmatter

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!