Prevent incorrect initialization

[me21]

Prevent incorrect initialization

[bxparks]

I've never been able to come up with a solution that is ergonomic and reliable. It always seems to depend on the programmer to do the right thing, because the C or C++ does not provide any mechanism to bind the length information and pointer together in a robust way.

Yes the ace_time::zonedbc::kZoneAndLinkRegistry array is known at compile-time, but the constructor actually accepts a pointer, not a compile-time array. The constructor relies on the automatic decay of the array into a pointer. It is not guaranteed that we will always know the size of the array at compile time, because the constructor of the ZoneManager may happen in a context (e.g. inside a factory function) where we have only the pointer. We always have to rely on the programmer to pass in the correct length information as a separate parameter.

We could suggest that the programmer do something like:

ace_time::CompleteZoneManager zoneManager(
  sizeof(ace_time::zonedbc::kZoneAndLinkRegistry) / 
    sizeof(ace_time::zonedbc::kZoneAndLinkRegistry[0]),
  ace_time::zonedbc::kZoneAndLinkRegistry,
  zoneProcessorCache);

This only works if the registry is a compile-time array. It does not work if it's passed in as a pointer.

This also depends on the programmer to write the correct sizeof() expression, and that the programmer uses the correct kZoneAndLinkRegistry array inside that sizeof() expression. I've definitely been guilty of copy-and-pasting code like this, and forgetting to replace that array name, or length parameter. But when I write the expression from scratch, I get the sizeof() expression wrong a substantial fraction of the time. Using a #define macro may help, but then the programmer has to remember to either define the correct #define macro, or remember to do a #include of the correct header file that includes this #define macro, which can sometimes be a source of friction.

You could say that we should create a new class (let's call it a SmartZoneRegistry class) that binds the length and array together into a single object. But all we have done is push the problem one step back, because the code fragment that creates a new instance of the SmartZoneRegistry is the same bit of code that creates a ZoneManager class. The other problem with creating a new SmartZoneRegistry class is that it seems to create too much abstraction, for not much benefit. The AceTime library already has too many classes, and I've resisted creating helper classes unless absolutely necessary.