[SOLVED] The right way of C++ class init() function

Jerry Mcguire · 08-18-2017, 09:33 AM

Hi all,
Could you teach me the right way of C++ class initialization function, init() ?

Code:

// This class is intended to be reused many times.
class ReusableMessage
{
	size_t len;
	int8_t *buf;
public:
	ReusableMessage( size_t n, int8_t *p )
		: len(n), buf(p)
	{
		init();
	}
	void init()
	{
		if (len && buf) memset( buf, 0, len );
	}
};

// Things look fine ?

class HelloMessage : public ReusableMessage
{
	hello_c_structure_t hello;
public:
	HelloMessage()
		: ReusableMessage( sizeof(hello), (int8_t*)&hello )
	{
		init();
	}
	void init()
	{
		ReusableMessage::init();
		hello.header[0] = 'H'; // e.g. something initialization to the structure.
	}
};

// calling init() in ctor() will call ReusableMessage::init() twice.

So, what is the right thing to do then?

a4z · 08-18-2017, 09:50 AM

you don not use a init function, you implement the init code direct in the costructor
better, you initialize your members direct.
do not use int8_t *buf and len as dynamic arrays,
use std::vector<int8_t>, it will make you more happy

Jerry Mcguire · 08-18-2017, 10:20 AM

Cannot use vector<> in my example. I need the pointer to a C structure.

OK. reset() was what I had intended when I first drafted this post.

Code:

// This class is intended to be reused many times.
class ReusableMessage
{
	size_t len;
	int8_t *buf;
	char state;
public:
	ReusableMessage( size_t n, int8_t *p )
		: len(n), buf(p), state(0)
	{
		reset();
	}
	void reset()
	{
		if (len && buf) memset( buf, 0, len );		
	}
};

// Things look fine ?

class HelloMessage : public ReusableMessage
{
	hello_c_structure_t hello;
	char target;
public:
	HelloMessage()
		: ReusableMessage( sizeof(hello), (int8_t*)&hello )
	{
		reset();
	}
	void reset()
	{
		ReusableMessage::reset();
		hello.header[0] = 'H'; // e.g. something initialization to the structure.
	}
};

Let's say I have the need to re-use the HelloMessage object again and again because I want to keep the state variable between uses. The C structure has to be reset every time which is why the memset() is not called in the ctor().

In this case how should reset()s and the ctor()s should be arranged?

pan64 · 08-18-2017, 12:03 PM

you should insert trace messages into your code to see what's happening, or probably you may try a debugger to test it (ddd).
Trace means something like that:

Code:

printf("trace: %s class %s method %s", classname, methodname, checkpoint)

and you can call this function at the beginning of ctor, at the end, and whenever you want (checkpoint=start/end/whatever)

In general you do not need to call reset in HelloMessage, because it will be automatically invoked from the inherited constructor, but you will see that using those trace.

Jerry Mcguire · 08-21-2017, 08:03 AM

Thank you for hinting. I think I found the right way:

Code:

class Message // name reduced for easy recognition
{
protected:
  size_t len;
  int8_t *buf;
public:
  virtual ~Message() {}
  Message() : len(0), buf(NULL)
  {
    // avoid calling class virtual functions in ctor()
  }
  virtual void reset()
  {
    if( len && buf) memset( buf, 0, len );
  }
};

class HelloMessage : public Message
{
protected:
  hello_c_struct_t hello;
public:
  virtual ~HelloMessage() {}
  HelloMessage()
  {
    // same, do not call reset() here
  }
  virtual void reset()   // <- here
  {
    len = sizeof(hello);
    buf = (int8_t*)&hello;

    Message::reset();

    hello.header[0] = 'H';
  }
};

...

// client code
Message *m = new HelloMessage;
if (m) {
  m->reset();  // call reset from client
  work( m ); // some operation on the object (point to)
  m->reset();  // reset for the next use
  work( m ); // the next use.
  ...
  delete m;
}

One thing I'm not sure about. Must the derived class define the virtual function `virtual void reset()` again or just `void reset()`? See above code marked '<- here'. What is the rule?

pan64 · 08-21-2017, 08:33 AM

you must not implement a virtual function - or at least I think so -, therefore reset of class Message is wrong. But probably I missed something...
Would be nice to see how did you compile it. You ought to use -Wall

ntubski · 08-21-2017, 12:03 PM

Quote:

Originally Posted by pan64

you must not implement a virtual function

No, that's not the case. You may be conflating "virtual" with "pure virtual". Except that apparently even pure virtual functions can have an implementation:

https://en.wikipedia.org/wiki/Virtua...tual_functions

Quote:

Although pure virtual methods typically have no implementation in the class that declares them, pure virtual methods in C++ are permitted to contain an implementation in their declaring class, providing fallback or default behaviour that a derived class can delegate to, if appropriate.

Quote:

Originally Posted by Jerry Mcguire

Must the derived class define the virtual function `virtual void reset()` again or just `void reset()`?

As far as I remember, both ways work. It's just a question of style.

Jerry Mcguire · 08-21-2017, 12:09 PM

@Pan64 I don't get your reply or why. Please give more details.

Jerry Mcguire · 08-21-2017, 12:39 PM

Many web search results say that virtual-ness is propagated to the derived class. Even cplusplus.com has an example on Polymorphism that the derived class does not declare the virtual function with the 'virtual' keyword in the derived classes.

Anyway, my personal choice would be sticking with the 'virtual' keyword so that when writing the next derived class I would immediately know which function is virtual.

Thank you all. It was a good discussion and knowledge mining session.

sundialsvcs · 08-23-2017, 01:30 PM

Methods such as init() and reset() (the names are not significant ...) are sometimes used to avoid timing issues, or simply by convention within a particular programming team. Constructors run in a somewhat-peculiar environment in which, sometimes, "things aren't quite set up yet." So, objects sometimes carry their own initialization and clean-up functions that are intended to be called separately, after the constructor has run and before the destructor. They can also be used to "recycle" an object for re-use, resetting it to its initial state. Programmers are obliged to make explicit calls to them. (The case that you illustrate, where the constructor calls the function, is not one that I commonly see.)

dugan · 08-23-2017, 01:41 PM

Quote:

Originally Posted by sundialsvcs

Methods such as init() and [font=courier]reset()[/i] (the names are not significant ...) are sometimes used to avoid timing issues, or simply by convention within a particular programming team. Constructors run in a somewhat-peculiar environment in which, sometimes, "things aren't quite set up yet." So, objects sometimes carry their own initialization and clean-up functions that are intended to be called separately, after the constructor has run and before the destructor. They can also be used to "recycle" an object for re-use, resetting it to its initial state. Programmers are obliged to make explicit calls to them. (The case that you illustrate, where the constructor calls the function, is not one that I commonly see.)

That's an antipattern.

It results in code that's not exception-safe. If you have code like that, you can't use exception-handling. If you do, you'll get resource leaks.

It's common because a lot of C++ code (Qt, for example) was designed back when exceptions weren't ready for production use.

sundialsvcs · 08-25-2017, 08:07 PM

Quote:

Originally Posted by dugan

That's an antipattern.

It results in code that's not exception-safe. If you have code like that, you can't use exception-handling. If you do, you'll get resource leaks.

It's common because a lot of C++ code (Qt, for example) was designed back when exceptions weren't ready for production use.

You are correct, and thank you for pointing that out.