Why generated adaptors/proxies don't have default and move constructor?

[pawelwod]

I'm currently forced to store new objects in std::uint_ptr which in turn are stored in std::vector. If there would be move constructor available then it would enable std::vector<foo_adaptor> instead of std::vector<std::uint_ptr<foo_adaptor>>. Additionally if there would be default constructor available then separating construction from initialization would be possible.

Why generated adaptors don't have default and move constructor?

I know the obvious answear, but is there any obstacle in changing library to hold pointers (maybe shared ones) instead of references?

[sangelovic]

1. What is std::uint_ptr? I know only std::uintptr_t. And that surely isn't a template, so this would be a syntax error: std::uintptr_t<foo_adaptor>

2. Generated adaptors and proxies do have a move constructor and move assignment operator. Look here for an example.

3. Generated adaptors and proxies don't have a default c-tor by design. They need an IObject or IProxy in order to be considered valid and fully constructed instances. But, they are not intended to be used by you as a client directly. Instead, use ProxyInterfaces and AdaptorInterfaces and place the generated classes as their template arguments.

4. We don't have a concept of empty/invalid ProxyInterfaces and AdaptorInterfaces instances. That would start complicating the design.

5. I'd say separating construction and initialization is not what I'd want. We have constructors to actually initialize the instance to be ready for use.

6. to hold pointers (maybe shared ones) instead of references?

What exactly do you mean? Can you provide an example?

7. This is more a discussion thread than an issue. Please use GitHub Discussion feature for that in the future...

[pawelwod]

1. Sorry, typo - I was talking about std::unique_ptr ;)

2. & 2. & 6.- looks like my distro privides version 1.1.0 where there was a reference instead of pointer but anyway...

3. & 4. & 5.

3. ... Instead, use ProxyInterfaces and AdaptorInterfaces and place the generated classes as their template arguments.
4. ... We have constructors to actually initialize the instance to be ready for use.

Yes, yes, I'm aware of that. But this is what I don't understand or not seeing something obvious here. In my mind I should be able to inherit from generated adaptor, overwrite virtual methods which would be my API. This in turn could be totally independent from who ever is calling my API. Something like:

In library

/* the_lib_header.hpp */
#include "generated_lib_interface.hpp"

class feature1 : public feature_interface
{
public:
  void Param(const X a&) overwrite;
  X ParamX() overwrite;

  void doSomethingOnFeature1() overwrite;
};

class the_lib_class : public lib_interface {
public:
  void ParamA(const T1 a&) overwrite;
  T1 ParamA() overwrite;

  void doSomethingOnCore() overwrite;

private:
   feature1 ft1;
   feature2 ft2;
};

/* generated_lib_interface.hpp */

// No need to include sdbus headers here. */
#include <...>

class feature_interface {
public:
  virtual void ParamX(const X a&) = 0;
  virtual X ParamX() = 0;
  void doSomethingOnFeature1() = 0;
};

class lib_interface {
public:
  virtual void ParamA(const T1 a&) = 0
  virtual T1 ParamA() = 0;
  virtual void doSomething() = 0;
};

/* generated_lib_adaptors.hpp */

#include <sdbus-c++/sdbus-c++.h>
#include <string>
#include <tuple>

#include "generated_lib_interface.hpp"

// Put here whatever you need here in SDBUS CPP */
class feature_adaptor : public sdbus::AdaptorInterfaces {
public:
  static constexpr const char* INTERFACE_NAME = "the.lib.feature";
    
  void feature_adaptor(sdbus::IConnection& connection, app_interface &interface) :
  	AdaptorInterfaces(connection, path)
  {
     /* register stuff. */
     getObject().registerMethod("ParamX"). ...;
     ...;
  }
};


class lib_adaptor : public sdbus::AdaptorInterfaces {
public:
  static constexpr const char* INTERFACE_NAME = "the.lib";
  
  void lib_adaptor(sdbus::IConnection& connection, std::string path, lib_interface &interface) :
	  AdaptorInterfaces(connection, path)
  {
     /* register stuff. */
     getObject().registerMethod("ParamA"). ...;
     ...;
  }
};

Then in my main.c

#include "the_lib_header.hpp"
#include "generated_lib_adaptors.hpp"

void main()
{
  the_app_class app {...};
  
  auto conn = sdbu::createConnection();
  conn.enterEventLoop();

  lib_adaptor appAdaptor (conn, APP_PATH, app);
  feature_adaptor feature1Adaptor (conn, APP_F1_PATH, app.f1);
  feature_adaptor feature2Adaptor (conn, APP_F2_PATH, app.f2);
  ...;
}

This is simple example, but in my case I have the project where core functionality is separated into own library and can be linked into application that does not use DBUS at all. So If I don't want tightly couple my internal classes to the sdbus-cpp (like you have in your concatenator example) I need to implement virtual methods in adaptor classes and re-write a lot of stuff what the sdbus-c++-xml2cpp tool is doing for me just to forward the dbus call to the library API call.
If interface-adaptor separation while using sdbus-c++-xml2cpp tool would be possible then a lot of extra code could be avoid.

I could also be totally wrong and there is already other possible way achieve this separation using current version of the library :)

[sangelovic]

@pawelwod

In your example you are mixing several things and it is not valid C++, but I tried to grasp the core of your problem. I don't actually see a problem here, and there is no need for such complication. You can simply delegate the call to the underlying feature interface, like so:

class lib_adaptor : public sdbus::AdaptorInterfaces</*generated interfaces...*/> {
public:
  void lib_adaptor(sdbus::IConnection& connection, std::string path, lib_interface &interface) :
	  AdaptorInterfaces(connection, path), m_interface(interface)
  {
    registerAdaptor();
  }

  void ParamA(const T1& a) override
  {
    m_interface.ParamA(a); // simply delegate the call to the feature interface
  }
};

The adaptor then actually serves as a real adapter, adapting sdbus-c++ calls into your business logic calls.

[pawelwod]

Yes, I'm implementing this pattern already. In my mind this slightly defeat benefits offered by sdbus-c++-xml2cpp. The call to m_interface.ParamA(a) could be generated in adaptor class with possibility to override.

But anyway, if you don't see the issue lets close it.

[sangelovic]

No, sdbus-c++-xml2cpp offers no potential benefits here, and no, m_interface.ParamA(a), by design, cannot be generated in the adaptor class. The adaptor class is just an thin class, with just pure virtual methods with no bodies for them. It's supposed to be you (the client) who overrides them, i.e. gives them concrete body in your concrete class. And that's what exactly my code example is doing -- the body is the call of a feature function. sdbus-c++-xml2cpp doesn't, and shouldn't, care about these details at all.