Thread: File Manipulator Library, just some suggestions

hello.

I've been working a little on a thing I call File Manipulator Library, and uploaded it to a SVN, just 'cause I like SVN for programming stuff

But I'm a little short on ideas for what I need to implement into it, and I'm also deadly tired, maybe that makes me not think enough
Anyways, if you have time to spend, feel free to download the SVN and give me suggestions The SVN is also open as long as you're registered at assembla.com, just give your username and password, and you can commit to the project

SVN space: Changesets | File Manipulator Library | Assembla Code Browser (This is a browser link)

Thanks in advance!

What is the purpose of this library? It looks like a simple wrapper over the standard C++ file I/O stream classes.

A few things to watch out for:

• Pass by reference. CFileReader's constructor does not take the filename by const reference, but it should.
• Const-correctness. CFileWriter's constructor takes the filename by non-const reference, but that does not make sense. Likewise, the overloads of operator<< should have const char* and const std::string& parameters. The various getter member functions should be declared const.
• GetStream() should return a reference, not a pointer. Actually, is there even a point in returning a pointer or reference to the internals of the object? If you do see a point, then maybe you should consider const overloading: a non-const version of GetStream() that returns a non-const reference, and a const version that returns a const reference.
• CFileReader and CFileWriter have non-copyable members. It would be clearer if you just declared their copy constructors and copy assignment operators as private.
• Why does CFileWriter have a member pointer to a std::string? It looks out of place.
• The order of construction of member variables is according to their order of declaration in the class definition. Therefore, CFileWriter's m_outFile is constructed followed by m_filename, despite the reversed order in the initialisation list. This is problematic since m_outFile depends on m_filename for initialisation. CFileReader has a similiar problem.
• CFileReader and CFileWriter both have constructors with a single parameter. Consider declaring these constructors as explicit. Also, note that these classes do not have default constructors, which may make sense as a conscious design decision, but you should be aware of this fact.

damn, I guess I forgot to say that the purpose of it was for me to learn xP I lack IO knowledge... Anyways, it's like not done at all, what it will do is make it a little simpler for you to make your programs write and read files ( Meant for my C++ module system for Mount&Blade ) and it also allows for 'symbolic commands', what this means is that you can make it know that if it finds '$N$' in the text, it executes a function... But this is all work in progress and untested!

Just so peeps know, I keep on updating the SVN

laserlight, i've fixed some of your complaints for the SVN now, but some stuff I don't understand..
Also, the reason I have m_filename there is just 'cause I thought that the classes should know their file's name... Haven't really needed it yet tho