inherited classes and const members

mzimmers

Hi all -

I'm sure this isn't really a guru-level question, but after years of C++ programming, I've finally come across a use for inheritance, and I'm having trouble.

I want to create a base class that contains some constant members, and from this class derive a subclass that would have different values for those members. Something like this:

class Button
{
protected:
    const TickType_t READ_INTERVAL;
};

class ButtonRTFM: public Button {}
Button::Button(Tasks *tasks) 
    :    READ_INTERVAL (100)
{}

ButtonRTFM::ButtonRTFM(Tasks *tasks) 
    : )  READ_INTERVAL (500) 
{}

But this gives me an error about READ_INTERVAL being non-static (in the derived class). So obviously I don't understand how this is supposed to be done; can someone give me some guidance?

Thanks...

Kent-Dorfman

ButtonRTFM::ButtonRTFM(Tasks *tasks)
: ) READ_INTERVAL (500)
{}

what's with this syntax? It doesn't look right. ")" after the colon?

and if ButtonRTFM::ButtonTRFM is the constructor of hte subclass then you should call the parent constructor too.

// ------------------------------------------------------------------
ButtonRTFM::ButtonTRFM(Tasks *tasks): Button(tasks), READ_INTERVAL (500)  {
}

I'd also suggest NOT making READ_INTERVAL const because you are setting it in both the base constructor, and the subclass constructor as an overriden value.

mzimmers

Yeah, you're right...sloppy cut-and-paste on my part.

class Button
{
protected:
    const TickType_t READ_INTERVAL;
};

class ButtonRTFM: public Button {}
Button::Button(Tasks *tasks) 
    :    READ_INTERVAL (100)
{}

ButtonRTFM::ButtonRTFM(Tasks *tasks) 
    :  READ_INTERVAL (500) 
{}

Sorry about that...

Kent-Dorfman

and oh, you cannot initialize a const variable in the base class from within the subclass. you have to create a base class constructor that sets it , and chain that constructor in the subclass initialization as I showed above.

kshegunov

Also some floating types and missing declaration. Anyways, READ_INTERVAL isn't part of ButtonRTFM, so you can't use it in the initializer list. If you want to do that, you need to delegate it through the parent's constructor. E.g.

class Button
{
public:
    Button();

protected:
    Button(TickType_t);

    const TickType_t READ_INTERVAL;
};

Button::Button()
    : Button(100)
{
}

Button::Button(TickType_t interval)
    : READ_INTERVAL(interval)
{
}

class ButtonRTFM : public Button
{
public:
    ButtonRTFM();
};

ButtonRTFM::ButtonRTFM()
    : Button(500)
{
}

Kent-Dorfman

StackOverflow thread about this very issue:

JonB

@mzimmers said in inherited classes and const members:

but after years of C++ programming, I've finally come across a use for inheritance

Blimey, my friend, this is really the first time you've you've found a use for inheritance?!! :)

J.Hilk

@JonB you know, we all start somewhere.

Before I knew better, I had duplicates of my classes in projects, with slightly different names, to have more than 1 object at a time....

0_1550660045864_f62ceeac-7377-4f97-97e7-0c5642ff37d2-image.png

thankfully that phase didn't last long.

mzimmers

@JonB said in inherited classes and const members:

Blimey, my friend, this is really the first time you've you've found a use for inheritance?!! :)

Perhaps it would have been more accurate to say that it's the first time I found a use for it before I started coding. There have been a few instances where I did a retrospective look at some work and thought "oh yeah..."

mzimmers

@kshegunov thanks for the example. I'm starting to think it was a bad idea to re-use names of consts - makes for more complex code, and could be very confusing to keep straight.

I guess I still don't entirely understand inheritance. Why is this wrong?

class Base
{
protected:
    int i;
};

class Derived : public Base
{
public:
    Derived();
};

Derived::Derived() : i (1)
{}

kshegunov

@mzimmers said in inherited classes and const members:

Why is this wrong?

Consistency in the language and/or typing. You can only use the current class' members in the initializer list to prevent you from blowing off your toe (as opposed to shooting yourself in the foot).

In C++ even if you don't do it explicitly the base class' default constructor is going to be called for you (this is the first thing in the initializer list). Now imagine what is supposed to happen if the base class' constructor is initializing the same variable and then you overwrite it in the derived class' initializer. Is it correct, or simply an error?

Even worse, suppose the base class (being badly written) expects the derived class to init the base's own privates, because why not, it's allowed ... then you're in for a treat. In principle the base class is responsible for its resources (RAII), not the derived ones. If it were the other way around, it'd be like asking a car type to make sure there's internal consistency in the machine type it derives from, why should the "car" care? It's a "machine" already, right? So everything related to the machine type should already be available out of the box for its subtypes.

mzimmers

@kshegunov good explanation, and it makes sense (though it's a little odd that you can't initialize a member, but you can assign to it, but...no matter).

So, what is considered best practices for a situation like this, where you want modified (yet constant) parameters in a subclass?

J.Hilk

@mzimmers
see @kshegunov post, 8 post prior
@kshegunov said in inherited classes and const members:

class Button
{
public:
    Button();

protected:
    Button(TickType_t);

    const TickType_t READ_INTERVAL;
};

Button::Button()
    : Button(100)
{
}

Button::Button(TickType_t interval)
    : READ_INTERVAL(interval)
{
}

class ButtonRTFM : public Button
{
public:
    ButtonRTFM();
};

ButtonRTFM::ButtonRTFM()
    : Button(500)
{
}

mzimmers

@J.Hilk I recognize kshegunov's suggestion as the correct answer, assuming I was going to stubbornly insist on trying to implement this as I originally described. What I meant to ask was, should I be taking a different approach to this problem? Perhaps multiple true const definitions outside the class, and the subclasses have their own members instead of re-using the base class'? Just thinking out loud here.

kshegunov

@mzimmers said in inherited classes and const members:

What I meant to ask was, should I be taking a different approach to this problem?

Perhaps, but let me rephrase your question as it sounds to me (warning metaphor following):

I want to drive a nail, how heavy a hammer do I need?

The obvious answer would be: "Well, depends on the nail". That is to say, what's your context?
From what we've discussed so far we have a dummy class with a constant - nothing more than a means to an end. So what's your end goal? Where, how are you going to use it and why you need that constant?

mzimmers

@kshegunov fair enough. I'm working on an embedded application. The host device originally called for a push button (a real button, not a QPushButton). Now it is being modified to have 2 buttons. For each button, I need to poll a GPIO, perform debouncing, and report when a valid press has occurred.

Except for a few arguments for the debouncing algorithm, the software for the buttons will be identical. So, I thought that for each button type, I'd just pass in some values at construction and leave it at that. Those values don't have to be constants, but that was my original thinking before I realized that it wasn't entirely straightforward.

Kent-Dorfman

Have you no one there on site to preach about how evil it is to use c++ for embedded applications? non-deterministic memory management with a high probability of long term memory fragmentation, the overhead of exceptions and/or the c++ runtime?

the term "embedded" has become so ambiguous in recent years. LOL

To me, embedded usually mean hard RTOS, with extremely tight deterministic requirements for things like memory managment and interupt handling...not exactly the typical Qt use case.

and yeah, for non-critical embedded systems I like coding in c++ too, if they'll let me. :^)

PS - yell and scream until they implement the debounce in hardware. It's just a couple freaking caps and it will work flawlessly.

Kent-Dorfman

@mzimmers said in inherited classes and const members:

@kshegunov thanks for the example. I'm starting to think it was a bad idea to re-use names of consts - makes for more complex code, and could be very confusing to keep straight.

I guess I still don't entirely understand inheritance. Why is this wrong?
class Base
{
protected:
    int i;
};

class Derived : public Base
{
public:
    Derived();
};

Derived::Derived() : i (1)
{}

see this -> StackOverflow

mzimmers

@Kent-Dorfman you did know that Reagan's out of office, right? You sound like you're almost as much of a dinosaur as I am.

In seriousness, I don't disagree with your definition of embedded systems, though it is a bit limiting in the age of IoT. I think Qt is a fine platform for many embedded applications, provided that the product designer doesn't get too stingy with the hardware resources.

In my case, this app is headless, so I'm not using the Qt libraries...just Creator as an editor and code browser. Better than anything else I've found so far.

kshegunov

The host device originally called for a push button (a real button, not a QPushButton). Now it is being modified to have 2 buttons. For each button, I need to poll a GPIO, perform debouncing, and report when a valid press has occurred.

You could use a private anonymous enum for that, e.g.:

class Something
{
private:
    enum { Whatever = 300 };
};

I don't see any real gain in having it as a member though, probably a static for each class (basically a scoped global constant) would be more practical, e.g.:

class Something
{
private:
    static const int whatever;
};

and don't forget to define it in the source (or use direct initialization if your compiler supports it):

static const int Something::whatever = 200;

@Kent-Dorfman said in inherited classes and const members:

non-deterministic memory management

What's non-deterministic about it?

with a high probability of long term memory fragmentation

I don't see how memory fragmentation has anything to do with c++. Heap allocations are calls into the kernel, they're not managed directly.

the overhead of exceptions

Exceptions can be disabled, and setjmp and longjmp existed for pretty much as long as computers have.

and/or the c++ runtime?

What would be that exactly? Constructors, destructors, operators? All of this existed before and continue to do so in C, they're just free functions. Hell even virtual methods I have seen emulated in C through function pointers ...