Function vs object approach

[ningaman151]

I prefer this minor difference...

class DisplayHelperMonochrome
{
  public:
    void setColor(unsigned color) 
    {
      // Ignored because the display is monochrome.
      // Suppress the warning.
      (void)(color);
    }
};

class DisplayHelperColor
{
  public:
    void setColor(unsigned color) 
    {
      // Do something useful here.
      // Suppress the warning until color is actually used.
      (void)(color);
    }
};

#if DISPLAY_SUPPORTS_COLOR
typedef DisplayHelperColor DisplayHelper;
#else
typedef DisplayHelperMonochrome DisplayHelper;
#endif

class NexButton
{
  public:
    NexButton(DisplayHelper& helper)
      : helper(helper)
    {
        // other constructor stuff
    }
  private:
    // Use helper to adjust the display.  It's responsible for doing the display specific things.
    DisplayHelper& helper;
};

void setup(void)
{
}

void loop(void)
{
}

Having access to both classes makes unit testing easier.

Thank you for the examples. However I don't understand what is the helper and its role.

[gcjr]

perhaps this is why Bjarne Stroustrup says it takes 10 years to become proficient in c++

he also said not to use features unnecessarily

[ningaman151]

gcjr:
perhaps this is why Bjarne Stroustrup says it takes 10 years to become proficient in c++

Did he really say that haha? Can you link me the source please?

[gcjr]

yes
i saw it maybe 10 years ago. i haven't been able to find it again. i think he may also have been asked what computer he uses.

[Coding_Badly]

ningaman151:
However I don't understand what is the helper and its role.

That's where you put code specific to the two kinds of displays you want to support. Things like setColor. setText also belongs there if setting text varies by display.

Essentially the example is creating two namespaces with a common interface.

Which brings up another point. You were on a path towards [coarse granularity](coarse - Google Search granularity+object+oriented+programming). That path usually ends in sadness.

[Johan_Ha]

"perhaps this is why Bjarne Stroustrup says it takes 10 years to become proficient in c++"

Someone make a t-shirt with the text "C++, the quantum physics of programming languages".
Have you read this:
https://www-users.cs.york.ac.uk/susan/joke/cpp.htm

[ningaman151]

[quote author=Coding Badly date=1615147566 link=msg=4919315]
In which case your code should never include virtual methods.[/quote]
What's wrong with virtual inheritance?

[J-M-L]

gcjr:
perhaps this is why Bjarne Stroustrup says it takes 10 years to become proficient in c++

(source)

Q: In your experience, how long does it take for a novice programmer to become a reasonably proficient [C/C++/Java] developer, capable of writing nontrivial production code? How long for a programmer with experience in one or more other languages? How can this time be shortened?
Ritchie: I don't know the answer to this question either--my stock joke on similar ones is, "Well, I never had to learn C...."

Stroustrup: That depends critically on the background of the novice, on the complexity of the task first attempted with C++, and on the teaching/learning approach.

For a novice programmer, a year and a half seems appropriate; for a programmer who is a novice to C++ and the techniques it supports half a year seems more likely. Clearly, I'm talking of the time needed to really use the facilities of the language in a significant application. Learning to write "Hello world" and its cousins can obviously be done in a few minutes.

I consider good libraries essential to provide a smooth learning curve and to properly sequence the learning of C++ concepts. For example, having the C++ standard library available makes it possible to learn the basic type, scope, and control structure concepts without having to deal with arrays, pointers, and memory management at the same time. Such fundamental, yet low-level concepts are best learned a bit later.

There is of course a danger in relying on libraries in teaching. They can provide an appearance of competence while hiding utter ignorance. One aim of teaching programming must be to make what is going on comprehensible rather than magical. To many programmers, the behavior of their system and even of their fundamental libraries is pure magic. This is dangerous. In this context, it is a strength C++ (and of C) that the standard libraries usually are implemented in the language itself using only the facilities available to every programmer.

[Coding_Badly]

ningaman151:
What's wrong with virtual inheritance?

I made no claim about inheritance.

[ningaman151]

I made no claim about inheritance.

Ah I thought you were referring to virtual inheritance. What is the relevance of virtual methods, and why should I not use them?

[Coding_Badly]

They are memory expensive. The VMT of each class is included in SRAM. It makes no difference if instances are constructed or not.

They are somewhat CPU expensive. Calling a virtual method involves a pointer indirection, a pointer indirection, and a indirect call.

They can be dangerous. Try calling a virtual abstract method on an embedded processor.

For what you're doing, they're pointless.

[ningaman151]

They are memory expensive. The VMT of each class is included in SRAM. It makes no difference if instances are constructed or not.

They are somewhat CPU expensive. Calling a virtual method involves a pointer indirection, a pointer indirection, and a indirect call.

They can be dangerous. Try calling a virtual abstract method on an embedded processor.

For what you're doing, they're pointless.

I'm using abstract classes in another project. Are they really that bad? It makes the code more modular.
Are you talking about virtual methods in general or pure virtual?

[Coding_Badly]

ningaman151:
Are you talking about virtual methods in general or pure virtual?

From the compiler's perspective there is no difference. Anything virtual is virtual.

ningaman151:
Are they really that bad?

One pointer per method per class. Interior classes count.

Instances gain one hidden pointer for simple inheritance.

It makes the code more modular.

That sounds suspiciously unrelated to polymorphic.