This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

OOP rules for global objects

Hi,

What I do in my current project:

1- I've developed a library by using C++ (compiler: arm-none-eabi-g++ -std=c++17) and generated a static library (arm-none-eabi-ar) with some c-api wrapper functions. In the static library there are some global instances of some classes, and exposed c functions provide access to their functionality

2- I've developed the app (compiler: arm-none-eabi-gcc) to be run on an ARM chip and linked with the static library. In the main function, a call is made to an init function which is in the static library

My observation is that, if I am not wrong, OOP inheritance rules don't work on those global objects. If I take a global object into a member function as a local variable, then I can access it via a pointer of its base class. A sample code is below:

Some test classes:

class CtBase
{
public:
    virtual void foo(void) = 0;
    int i = 0;
};

class CtDer : public CtBase
{
public:
    void foo(void) override;
};

void CtDer::foo(void)
{
    ++this->i;
}

 

Use them in a class member function implementation, where its instance (PlatformDevice) is a global object in the static library:

Version 1 - Doesn't work

CtDer der;

namespace mevoo::loni6
{

    void PlatformDevice::init(UdpComm *udp, BufferBase *b)
    {
        CtBase *ctptr = &der;

        ctptr->foo(); // doesn't work
// some more code

Version 2 - works:

namespace mevoo::loni6
{

    void PlatformDevice::init(UdpComm *udp, BufferBase *b)
    {
        CtDer der; // now a local var
        CtBase *ctptr = &der;

        ctptr->foo(); // works

// some more code

Any comment would be highly appreciated. 

Best regards,

Ozan

Parents
  • Sorry, both :) I have to use a 3rd-party lib (with C). This lib manages the whole boot sequence, rtos, and hal. I had developed another library which provides an app layer (with C++). The 3rd-party lib provides an API where I can integrate my app. I didn't mention about the whole story to set a better focus on the problem. 

Reply
  • Sorry, both :) I have to use a 3rd-party lib (with C). This lib manages the whole boot sequence, rtos, and hal. I had developed another library which provides an app layer (with C++). The 3rd-party lib provides an API where I can integrate my app. I didn't mention about the whole story to set a better focus on the problem. 

Children
  • That's using the terms "lib" and "app" rather contrary to their actual roles.  What you actually have there is a C framework which you're trying to fill out with code from a C++ lib (and a C shimmy around that).  And that's a known road to hell.

    C++ code generally needs the C++ version of the compiler's run-time environment and run-time library to work properly, even if you don't use all of C++'s features.  To get that, the linker has to be in C++ mode, and often the main() function has to be compiled C++, too.

  • Thank you, Broeker, for your explanation. I figured out a nice architectural workaround to this problem, where both C and C++ 'libraries and frameworks' can live together without going to hell. It was a good experience for me and I will write an article about it and share here, so you can comment ;)