Question

I have the following User.h that holds several attributes (strings). User.cpp has all the definitions.

//User.h
#ifndef USER_H
#define USER_H
#include<iostream>
#include <cstring>

using namespace std;

class User{

  string username;

  public:
         User();
         string getUsername() const;                      
         void setUsername(string);

};
#endif

I’m using a another class, “File” to insert new users/view users from a randomly accessed .dat file

//File.h
#ifndef FILE_H
#define FILE_H
#include "User.h"

class File{
    public:

             void loadUser(); 
             bool addUser(User&); 

};
#endif

File class definitions

//File.cpp
#include<cstring>
#include<iostream>
#include<iomanip>
#include<fstream>

#include "User.h"
#include "File.h"

using namespace std;

User tempUser;
fstream usersFile;

void File::loadUser(){
     usersFile.open("users.dat", ios::in | ios::binary);

     usersFile.seekg(0);  

     // commenting the following lines prevented the issue
     usersFile.read(reinterpret_cast<char *>(&tempUser), sizeof(tempUser)); 

     cout<<tempUser.getUsername().c_str(); 

     usersFile.close();
}

bool File::addUser(User& user){

     usersFile.open("users.dat", ios::out | ios::ate | ios::binary);

     // no issue when writing to file
     usersFile.write( reinterpret_cast<const char *>(&user), sizeof(user));

     usersFile.close();

     cout<<"User added";  
}

I’m getting the above mentioned issue when running. No compilation issue though.

Is there any issue when dealing with objects that has “string attributes” inside, in handling?

Please help

Answer 1

I think the issue is that you are mixing C++ code with a C mindset.
What you should really be doing here is use the extraction operator, opeartor>>(), along with the C++ IO streams. This, as opposed to using the C standard IO along with the read() function. For writing an object, use the insertion operator operator<<() instead of the C write() function.

For working with strings use std::string. This class provides operator<<() and operator>>(). So, you can say std::string s and then io << s and io >> s where io is some C++ IO stream object. This will do The Right Thing(tm). The philosophy here is that the std::string class knows better than you, a user, how to serialize a std::string object. So let it do it, with the << and >> operators.

Going on with the idea, you, as the author of User, know better than anyone else how to serialize a User object. So provide the << and >> operators for users of your class, as a service. “Users of your class” might well be you one week from now, when you have completely forgot how to properly serialize a User object. (Or, you think you remember but in practice you forgot a detail, causing a bug in your code). Example:

// in User.h
#include <string>
#include <iosfwd>  // forward declarations of standard IO streams

namespace mine {
class User {
    User(const std::string& name) : username(name) { }
    friend std::ostream& operator<<(std::ostream&, const User&);
    friend std::istream& operator>>(std::istream&, User&);

private:
    std::string username;
};

std::ostream& operator<<(std::ostream& out, const User& u)
{
    return out << u.username;
}

std::istream& operator>>(std::istream& in, User& u)
{
    return in >> u.username;
}
}  // namespace mine

From here on, to save a user to a file you say

std::ofstream f("filename");
User u("John");
f << u;

That’s it. To read a user:

std::ifstream f2("filename");
f2 >> u;

It’s a good practice to wrap your code in a namespace. IDEs give a good visualization of this issue, by showing how many symbols are visible with the auto-complete feature. You get to see how much of a mess there is in the global scope. By wrapping your code in a namespace you group it under a scope name, saving some more mess in the global name scope. It’s just about being tidy. If you put your code in your own namespace then you can choose any name you want for a function, a class or a variable, so long as you haven’t chosen it before. If you don’t put it in a namespace then you need to share names with others. It’s like a skunk declaring his own territory, only without the bed smell.

On that note I suggest you take off that using namespace std from your header. This brings all the symbols in the std namespace into scope of all files that #include the header. It’s a bad practice. Only say using namespace std in implementation files, if you wish, but not in header files.

Granted, some will say even this is a bad idea. I personally think it’s fine if you’re aware of the fact you might have name clashes in that particular implementation file. But at least you know where that using statement is: it’s in your implementation file, and it only causes clashes in that implementation file. It’s sort of a gun, (a plastic water gun, but a gun nonetheless), only you can only shoot (wet) your own feet and no one else’s. Which in my opinion is perfectly fine.