-1

So i'm doing a little bit of self study with C++ and OO. I'm using some old Uni Labs to teach myself how to do it and Im quite stuck with how to do File I/O with an OO structure. My first question: What is best practice for writing info from a CSV file into objects and then into another text file? The Labs im using intially have an istream and ostream operators in each class as friends then eventually make us create accessors and mutators to return or modify information of an object and remove the friends operators. So do we keep the writing functions in each class? Or do we create a separate writer class for this purpose?

Zayd Bhyat
  • 101
  • 1
  • 2
  • 19
  • 1
    Forget about "OO orientation" whatsoever. Simply learn the canonical use of the iostream library. –  May 02 '16 at 02:28
  • For streaming operations write an input and output operator for each class. `std::istream& operator>>(std::istream& s, Type& data)` and `std::ostream& operator<<(Std::ostream& s, Type const& data)` – Martin York May 02 '16 at 02:38
  • But if all you want to do is a read a CSV file: http://stackoverflow.com/q/415515/14065 – Martin York May 02 '16 at 02:40
  • Oh... But this entire unit is based off OOP. The idea behind the unit is to create a structure that can be translated into different languages if need be. So this OOP structure can be translated into java or python Etc. What advantage would I have using canonical/static structures over OO? – Zayd Bhyat May 02 '16 at 02:40
  • thanks @LokiAstari, that answered my first question. So with these writing operators if I wanted to write data from istream to a class thats inherited could I use: `s >> Results ` where Results is an instance of the Result class? – Zayd Bhyat May 02 '16 at 02:52
  • @ZaydBhyat: Correct. But you read from an `istream` and write to `ostream` – Martin York May 02 '16 at 03:15
  • @LokiAstari Im confused.. You called both the ostream and istream operator S. Ah ok, I misunderstood what you said. – Zayd Bhyat May 02 '16 at 07:33

1 Answers1

0

The issue with putting the serialization logic inside the class and binding it to operator<< is that the overloading rules will call the same function for all usage of some_ostream << your_instance;

But in reality, you might need to write your object in multiple formats. For example, the data could be written as CSV, XML, or binary. Which forces operator<< of every single class to change when the format does.

If you instead make a class for handling a format, you can add new formats more easily. The data structure classes need to responsible for breaking themselves down into a series of constituent parts, but the format-specific class needs to decide how the atomic parts get encoded.

The "Single Responsibility Principle", one of the cornerstones of OOP, also has something to say about this. If stream I/O isn't the single purpose of a particular class, then stream I/O logic doesn't belong in that class at all.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • Ah so you believe the way it was done above isnt efficient? That writing a class just for streaming object data is the way to go? – Zayd Bhyat May 02 '16 at 02:57
  • That's simple to solve. You simply create a serializer class for specific formats. – Martin York May 02 '16 at 03:17
  • @Loki: Right, Zayd was asking why he was told to switch from `operator<<` as friend in his class to a separate serializer class. – Ben Voigt May 02 '16 at 04:02
  • @Zayd: It isn't about efficiency (as long as function call binding is done at compile time, these are all equally efficient -- adding virtual functions could reduce efficiency). It's about maintainability. Does changing the file format require touching every class in your program? Are you mixing file logic in with other functionality? These things make it harder to support changing requirements. – Ben Voigt May 02 '16 at 04:04