InternalControlFunction and PartneredControlFunction not working

[thiagozf1]

Good morning @ad3154 and @GwnDaan. Today I was trying to compile the seeder example and the program wasn't able to create the objects of InternalControlFunction and PartneredControlFunction classes (and yes, I used the create method). Until I made the constructors public, they won't work and I don't know why. It may be something silly, but sadly I was not successfull solving the problem. The error was the following: [{ "resource": "/d:/esp/.espressif_v4.3.4/tools/xtensa-esp32-elf/esp-2021r2-patch3-8.4.0/xtensa-esp32-elf/xtensa-esp32-elf/include/c++/8.4.0/ext/new_allocator.h", "owner": "cpp", "severity": 8, "message": "'isobus::PartneredControlFunction::PartneredControlFunction(uint8_t, std::vector<isobus::NAMEFilter>)' is private within this context", "startLineNumber": 136, "startColumn": 4, "endLineNumber": 136, "endColumn": 4 }]

The only way I've found to compile it, was by moving the constructors to the public section.

[ad3154]

Hmmmm... strange. This is not the first time their compiler has done something that seemed a little odd.

Here's another option we might consider @GwnDaan

We could make the constructors public but add a CANLibBadge<PartneredControlFunction> or CANLibBadge<InternalControlFunction> to the constructor's parameters so that they can still not be called outside the class itself.

So then we'd have:

PartneredControlFunction(std::uint8_t CANPort, const std::vector<NAMEFilter> NAMEFilters, CANLibBadge<PartneredControlFunction>);

...

std::shared_ptr<PartneredControlFunction> PartneredControlFunction::create(std::uint8_t CANPort, const std::vector<NAMEFilter> NAMEFilters)
	{
		// Unfortunately, we can't use `std::make_shared` here because the constructor is meant to be protected
		auto controlFunction = std::shared_ptr<PartneredControlFunction>(new PartneredControlFunction(CANPort, NAMEFilters, {}));
		CANNetworkManager::CANNetwork.on_control_function_created(controlFunction, {});
		return controlFunction;
	}

[GwnDaan]

Sounds good to me! Too bad that there are so many ways of getting platform dependent issues, we might want to look into expanding our test suite environments? So that we can catch such issues beforehand

[ad3154]

Yeah, I think we should definitely expand our CI builds to try and build on each platform we support if possible. It seems like some actions might already exist out there for some of these like ESP32 - so we'll have to check those out

[ad3154]

@thiagozf1 I pushed a new commit (c0e392e) to #292 can you try it and see if your compilation issue is resolved? If it is, I'll cherry pick it onto another branch and open another PR.

[thiagozf1]

Worked!!!