Abstract base class with data member, constructor and operator overloaded

Question

I have a abstract base class that hold data, and I need allocate memory to these data, and the other problem is that derivate class has the = operator overloaded and copy constructor, I would like to know how Can I assure that in the derivate class copy the members data from abstract base class will be copied too, follows the code exemple:

class A {
public:
  A(const char* v) {
    value = new char[strlen(v)+1];
    strncpy(value, v, strlen(v));
  }

  A(const A &a) {
    value = new char[strlen(a.value)+1];
    strncpy(value, a.value, strlen(a.value));
  }

  virtual ~A() {
    delete[] value;
  }

  A& operator=(const A& a) {
    value = new char[strlen(a.value)+1];
    strncpy(value, a.value, strlen(a.value));
    return *this;
  }

  const char* get() const {
    return value;
  }

  virtual void do_some() = 0;
private:
  char *value;
};

class B: public A {
public:
  B(const char *v, const char *n) : A(v) {
    name = new char[strlen(n)+1];
    strncpy(name, n, strlen(n));
  }

  B(const B &b) : A(b) {
    name = new char[strlen(b.name)+1];
    strncpy(name, b.name, strlen(b.name));
  }

  ~B() {
    delete[] name;
  }

  B& operator=(const B& b) {
    A::operator=(b);
    name = new char[strlen(b.name)+1];
    strncpy(name, b.name, strlen(b.name));
    return *this;
  }

  const char *get() const {
    return name;
  }

  void do_some() {
    std::cout << name << std::endl;
  }

private:
  char *name;
};

My doubts is, in some C++'s books says that is not a good idea to overload the operator = and declare a copy constructor in abstract base class, so how can I declare a copy constructor and operator= in derivate class and assure that the base class was copied properly?

In my project if I don't use data members at the abstract base class, I have to declare some data members in all derivate class, of course that is more than one, so I designed the abstract class with data member, but I don't know if is the better way to do.

Related: I would be doubting your `strncpy` calls *everywhere*. They're wrong, as they never initialize the terminator. The very nature of how you have structured the length-parameter means `strncpy` *cannot* terminate the string. And ultimately `strncpy` isn't needed here anyway. You *know* you just allocated the proper length to take the target *and* its terminator, so literally a `strcpy`, or even a `memcpy` would suffice. — WhozCraig, Feb 16 '14 at 01:33
Apart from that, you can forego the difficulties of the derived assignment operator by using the [copy-swap idiom](http://stackoverflow.com/questions/3279543/what-is-the-copy-and-swap-idiom), which I would recommend, almost as much as I would just using `std::string` and making the whole issue disappear. — WhozCraig, Feb 16 '14 at 01:38
@WhozCraig you are right about strncpy, it cannot terminate string, I forgot to put strlen(v) + 1. — Alex, Feb 16 '14 at 01:44
In fact I used char only to give an example, of course that in my project I am not using char, but I have to allocate memory to others objects declared at the class. — Alex, Feb 16 '14 at 01:46
No it *can* terminate a string, it simply *won't* if the source string length meets or exceeds the specified length parameter. The little -known fact is `strncpy` *always* fills `N` chars, where `N` is the length parameter, but won't terminate if the source is as long or longer than N *before* termination. If shorter, it tail-fills nulchars. Read more about it [here](http://stackoverflow.com/questions/14065391/strncpy-leading-to-segmentation-fault/14067026#14067026) and [here](http://en.cppreference.com/w/cpp/string/byte/strncpy). — WhozCraig, Feb 16 '14 at 02:39
`operator=` leaks memory, I'd suggest implementing WhozCraig's suggestions. — user1520427, Feb 16 '14 at 03:32

score 1 · Accepted Answer · answered Feb 16 '14 at 01:37

What you're doing is a little awkward, but technically fine (except for leaking memory by not deleting name and value in the assignment operator before new[]-ing it), however only if you have no plans for multiple inheritance. That gets a bit messy, and may be why whatever books you're referring to are warning against it, but you shouldn't be using multiple inheritance (in general, but especially) on classes with data members anyways.

You might want to try a different approach regardless. Consider using a protected helper function (or a few) in the base class to set its variables:

class A
{
public:

// ...

private:
  char *value;

protected:
  void set_value(const char *str)
  {
    delete[] value; // remember, deleting null does nothing
    value = new char[strlen(str)+1];
    strncpy(value, str, strlen(str)); // Also, why do you need strncpy?
    // You'll get no null-terminator, which leads to major problems
    // Consider just strcpy(value, str);
  }
};

This way, you can set that value from any derived class, the functionality is still hidden from public use, and you don't have to write an assignment operator or copy constructor for an abstract class. Which, when you think about it, really doesn't make much sense, does it?

It also saves you from this:

A *a = new B;

B *b = new B;
(*a) = (*b); // ...with an assignment operator on A, this should compile.

But is a good option use the constructor from base class, or is better use none kind of constructor in the base class? — Alex, Feb 16 '14 at 01:48
I wouldn't write a copy constructor or assignment operator in the A class. Instead, in B's copy constructor, you can pass up b.value to A's main constructor. In A's constructor, you could call that protected setter (some reasoning below). In B's assignment operator, you can call the same protected setter. You could also make your data member protected and allocate / set it from every derived class. But it's really easy to forget where you're heap allocating and deallocating, so containing it to one function is nice. — Andy Hill, Feb 16 '14 at 20:52

Abstract base class with data member, constructor and operator overloaded

1 Answers1