declaring data in classes - what's better?

A

alternativa

Hi,
what would you say - which way of building a class is better? Why?

/**** 1 ****/
class Person {
public:
Person(char *n, char *sn, int d);
~Person();
protected:
char *name;
char *second_name;
int date_of_birth;
};

/**** 2 ****/
class Person {
char name;
char second_name;
int date_of_birth;
public:
Person(char n, char sn, int d);
~Person();
};
 
W

W Marsh

Hi,
what would you say - which way of building a class is better? Why?

/**** 1 ****/
class Person {
public:
Person(char *n, char *sn, int d);
~Person();
protected:
char *name;
char *second_name;
int date_of_birth;
};

/**** 2 ****/
class Person {
char name;
char second_name;
int date_of_birth;
public:
Person(char n, char sn, int d);
~Person();
};

Depends on how many people you know with first and second names that
are only one letter long.

Look up std::string.
 
A

alternativa

Sorry, I forgot to change the second one.. Of course it should look
like this:

/**** 2 ****/
class Person {
string name;
string second_name;
int date_of_birth;
public:
Person(char n, char sn, int d);
~Person();
 
A

alternativa

Sorry, I forgot to change the second one.. Of course it should look
like this:

/**** 2 ****/
class Person {
string name;
string second_name;
int date_of_birth;
public:
Person(string n, string sn, int d);
~Person();
 
P

Phlip

alternativa said:
class Person {
public:
Person(char *n, char *sn, int d);
~Person();
protected:
char *name;
char *second_name;
int date_of_birth;
};

When you read the first one, you read the public things first. If the class
is useful, you shouldn't even need to read the private part.

And don't use protected until you run out of alternatives. It's not a
language feature so much as a workaround, like mutable or explicit.
 
D

davidrubin

alternativa said:
Hi,
what would you say - which way of building a class is better? Why?

/**** 1 ****/
class Person {
public:
Person(char *n, char *sn, int d);
~Person();
protected:
char *name;
char *second_name;
int date_of_birth;
};

/**** 2 ****/
class Person {
char name;
char second_name;
int date_of_birth;
public:
Person(char n, char sn, int d);
~Person();
};

The second (with corrections) is better because the first implies the
possibility of some very broken form of structural inheritence, which
itself is bogus in almost all cases.
 
C

Cy Edmunds

alternativa said:
Hi,
what would you say - which way of building a class is better? Why?

/**** 1 ****/
class Person {
public:
Person(char *n, char *sn, int d);
~Person();
protected:
char *name;
char *second_name;
int date_of_birth;
};

/**** 2 ****/
class Person {
char name;
char second_name;
int date_of_birth;
public:
Person(char n, char sn, int d);
~Person();
};

class Person
{
private:
std::string m_name;
std::string m_second_name;
int m_date_of_birth;
public:
Person(std::string const &i_name, std::string const &i_second_name, int
i_date_of_birth) :
m_name(i_name), m_second_name(i_second_name),
m_date_of_birth(i_date_of_birth) {}
std::string const &name() const {return m_name;}
std::string const &second_name() const {return m_second_name;}
int date_of_birth() const {return date_of_birth;}
// no destructor
};

std::string should be preferred over char * in modern C++ programming,
mostly because it just makes things so much easier and less error prone.

It is usually better to initialize a std::string with another std::string.
If you have a char * it still works fine:
Person p("Elmer", "Fudd", 19898973);
and if you already have std::strings you can just write
Person q(astring, bstring, date);
rather than the awkward
Person q(astring.c_str(), bstring.c_str(), date);

If you need a destructor (which you don't when using std::string) you
probably also need a copy constructor and assignment operator. Google for
"C++ rule of 3".

Some programmers reflexively write get/set pairs for each data item. I think
that's a bad habit. You can use the constructor itself to change the data
values:
p = Person("Daffy", "Duck", 890);
This usage emphasizes the idea that a Person is an object rather than just
three related values.

Cy
 
I

Ian Collins

Cy said:
class Person
{
private:
std::string m_name;
std::string m_second_name;
int m_date_of_birth;
public:
Person(std::string const &i_name, std::string const &i_second_name, int
i_date_of_birth) :
m_name(i_name), m_second_name(i_second_name),
m_date_of_birth(i_date_of_birth) {}
std::string const &name() const {return m_name;}
std::string const &second_name() const {return m_second_name;}
int date_of_birth() const {return date_of_birth;}
// no destructor
};
If you are going to provide accessors to all members, why not just use a
struct and make the members const?
 
C

Cy Edmunds

Ian Collins said:
If you are going to provide accessors to all members, why not just use a
struct and make the members const?

Don't think of the member functions as accessors to members. Think of them
as inspectors of the object state. I might change the implementation to read
a database instead of storing locally. As long as I don't change the
interface you shouldn't have to worry about it.

Cy
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top