I would prefer to have a more descriptive name for this function. init sounds a bit confusing since the whole purpose of the base constructor is to initialize the object. How about record_usage(), or something along the line?

So I was using the two-phase initialization pattern described here: https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctor-idiom. Although, currently the init() method only does API usage logging. It can be repurposed to do additional initialization as well later. Otherwise we would end up with multiple methods like record_usage(), record_foo(), record_bar()` etc. that all need to be called by the subclasses

Although I agree that the name record_usage() (deliberately) reduces the scope of the function, I would consider it a design smell if we needed to have further logic in our constructor that depends on virtual calls. Even in this particular case the cleaner, but BC-breaking, solution would be to take the backend name as a constructor parameter.

Having said that I don't have a strong objection about the name init(). One thing that we should mind though is if we want to preserve BC-compatibility, and consider init() as a place where we can potentially add further initialization logic, we have to make sure that all ProcessGroup implementations out there are updated to call it. Otherwise it will silently break implementations that don't call init().

Although I agree that the name record_usage() (deliberately) reduces the scope of the function, I would consider it a design smell if we needed to have further logic in our constructor that depends on virtual calls. Even in this particular case the cleaner, but BC-breaking, solution would be to take the backend name as a constructor parameter.

I agree with this and if we were building this from scratch we wouldn't implement it this way. But the tricky thing is to do this in a backward compatible way. The solution in this PR is already a workaround and is probably the best way I know off to achieve this logging. The reason I chose init() was because I worry about the fact of having to do something like this a couple of more times.

Having said that I don't have a strong objection about the name init(). One thing that we should mind though is if we want to preserve BC-compatibility, and consider init() as a place where we can potentially add further initialization logic, we have to make sure that all ProcessGroup implementations out there are updated to call it. Otherwise it will silently break implementations that don't call init().

I did update a bunch of ProcessGroups in our repo already. Once this lands, I can probably create a PR for other repos. But there probably will be many ProcessGroups out there that we don't know about and hence I left a comment in our docs as a best effort mechanism.