counfused.. about rule of 3...

[SpreadTooThin]

I am developing a class. It's a pretty simple one.
The class has one data member which is a std::string.
The purpose of the class it simple to make sure that the string that
is used as a constructor has an even length.
The class is called a uid.
I'm a little confused.. should this just inherit from std::string ie
class uid:public std::string ?
I'm not sure I'm handling the copy constructors properly.

class uid
{
private:
std::string id;
public:
uid(std::string _id)
{
id = _id;
if (id.size() & 1) // is the length odd?
id.append(" "); // yes. Now the length should be even
}
uid& operator=(std::string& _id)
{
id = _id;
if (id.size() & 1) // is the length odd?
id.append(" ");
}
uid& operator=(uid& _id)
{
id = _id;
}
~uid(void)
{
// Nothing to do really.
}
};

[Victor Bazarov]

SpreadTooThin wrote:

I am developing a class. It's a pretty simple one.
The class has one data member which is a std::string.
The purpose of the class it simple to make sure that the string that
is used as a constructor has an even length.
The class is called a uid.
I'm a little confused.. should this just inherit from std::string ie
class uid:public std::string ?

No.

I'm not sure I'm handling the copy constructors properly.

class uid
{
private:
std::string id;
public:
uid(std::string _id)

Do

uid(std::string const & _id) : id(_id) // conversion c-tor

{
id = _id;

Prefer initialisation to assignment. Drop the line above in favor of
using the initialiser list (the stuff after the ':').

if (id.size() & 1) // is the length odd?
id.append(" "); // yes. Now the length should be even
}
uid& operator=(std::string& _id)

uid& operator =(std::string const& _id) // conversion assignment

{
id = _id;
if (id.size() & 1) // is the length odd?
id.append(" ");

return *this;

}
uid& operator=(uid& _id)

uid& operator =(uid const& rhs) // copy assignment

{
id = _id;

Nope. It should be

id = rhs.id;
return *this;

}
~uid(void)

Drop the 'void' (if you decide to keep the d-tor). This is C++, not C.

{
// Nothing to do really.
}

If nothing to do, drop the whole destructor altogether.

};

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[acehreli]

On Jun 19, 12:51 pm, SpreadTooThin <[e-mail]:

I am developing a class. It's a pretty simple one.
The class has one data member which is a std::string.

If a class consists only of members that know how to take care of
their resources (e.g. std::string), you usually don't need to do
anything yourself.

The purpose of the class it simple to make sure that the string that
is used as a constructor has an even length.
The class is called a uid.
I'm a little confused.. should this just inherit from std::string ie
class uid:public std::string ?

No.

I'm not sure I'm handling the copy constructors properly.

You don't need to provide a copy constructor or a destructor in this
case.

class uid
{
private:
std::string id;
public:
uid(std::string _id)
{
id = _id;
if (id.size() & 1) // is the length odd?
id.append(" "); // yes. Now the length should be even
}
uid& operator=(std::string& _id)

Do you really have to assign a std::string? I don't think so, because
you can always assign from a uid, which is guaranteed to have 'id' of
even length.

{
id = _id;
if (id.size() & 1) // is the length odd?
id.append(" ");
}
uid& operator=(uid& _id)

You don't need to provide that assignment operator, because the
compiler generated one does the same thing:

{
id = _id;
}

Actually, the compiler generated one would do better by assigning even
the bases, if you had any.

On the other hand, the compiler generated one would not be exception
safe, if you had more than one object in this class. Because the C++
standard doesn't define the generated operator= be exception safe. It
is possible that the object is left in a half-assigned state if one of
the member assignments throws. But you don't have a second member
here.

~uid(void)
{
// Nothing to do really.
}

};

Start with the following simple class. I bet that works the way you
need:

#include <string>

class uid
{
std::string id;

public:

explicit uid(const std::string & _id)
:
id(_id)
{
if (id.size() & 1) // is the length odd?
id.append(" "); // yes. Now the length should be even
}
};

int main()
{
uid u("abc");
u = uid("xyz");

// Remove 'explicit' above to be able to compile the following as well
// std::string s("123");
// u = s;
}

Ali

[James Kanze]

On Jun 19, 9:51 pm, SpreadTooThin <[e-mail]:

I am developing a class. It's a pretty simple one.
The class has one data member which is a std::string. The
purpose of the class it simple to make sure that the string
that is used as a constructor has an even length.
The class is called a uid.
I'm a little confused.. should this just inherit from
std::string ie class uid:public std::string ?

Probably not. You don't want to support all of the interface of
std::string: appending a single character to your uid would
break the invariant, for example.

I'm not sure I'm handling the copy constructors properly.

There's nothing you have to do. If the only data member of your
class is an std::string, the compiler will handle the copy
constructor, assignment and the destructor correctly. You don't
need any of the three.

class uid
{
private:
std::string id;
public:
uid(std::string _id)
{
id = _id;
if (id.size() & 1) // is the length odd?
id.append(" "); // yes. Now the length should be even
}
uid& operator=(std::string& _id)
{
id = _id;
if (id.size() & 1) // is the length odd?
id.append(" ");
}

Note that this is NOT a copy assignment operator, so the
compiler will still provide the copy assignment operator you
need. (And of course, you forgot the return at the end.)

uid& operator=(uid& _id)
{
id = _id;
}

Which is exactly what the compiler provided copy assignment will
do. Almost: in the compiler provided version, the parameter
will be a cosnt reference (which it should be), and the compiler
won't forget the return.

~uid(void)
{
// Nothing to do really.

So why bother providing it?

}
};

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]