Move the libcamera_apps class implementation into its own cpp file.

[naushir]

All tests still seem to pass, so that's good!

[naushir]

@davidplowman something for you to ponder over.

[davidplowman]

Yes, sorry, I always use an SSD. They're soooo fast!

[davidplowman]

Gosh, what a lot of tiny changes! I mean, that's always what it was going to take, but I think the separation and improved compile times are worth it.

One thought, have you tried the covariant return type trick? It could ensure that an app always makes the correct set of options (i.e. a user can't get it wrong) and it mostly takes care of the casting for you then.

Here's vaguely what I mean (sorry, long example):

#include <iostream>
#include <memory>

struct AppOptions
{
	AppOptions() : width(640), height (480) {}
	int width, height;
};

struct VideoOptions : public AppOptions
{
	VideoOptions() : AppOptions(), bitrate(10000000) {}
	unsigned int bitrate;
};

struct LibcameraApp
{
	LibcameraApp(AppOptions *opts = nullptr)
	{
		if (!opts)
			opts = new AppOptions;
		options = std::unique_ptr<AppOptions>(opts);
	}
	virtual ~LibcameraApp() {}
	virtual AppOptions const *Options() const { return options.get(); }
	std::unique_ptr<AppOptions> options;
};

struct LibcameraVid : public LibcameraApp
{
	LibcameraVid() : LibcameraApp(new VideoOptions) {}
	virtual VideoOptions const *Options() const override { return (VideoOptions *)options.get(); }
};

int main(int argc, char *argv[])
{
	LibcameraVid v;
	std::cout << v.Options()->bitrate << std::endl;
}

Notice how v.Options() gives you VideoOptions automatically, not AppOptions. I mean, I don't know if it's preferable, but what do you think?

[naushir]

Yes, I could add something like that. Probably as a patch on-top of the existing ones, or perhaps as part of commit b9b5f24 that switches to using unique_ptrs.

[naushir]

On second thoughts, I think there is going to be too much churn with this change, as I then have to convert all the LibcameraApp references passed all around the place into pointers so that we can correctly call the overloaded GetOptions().

@davidplowman, what do you think? Should we just bite the bullet and do it?