Re: Custom (readonly) container and iterators ?
to remove the weirdness, you could just rename RomTable to something like RomTableView and add a constructor taking an handle obtained from some factory method, or just a static opaque handle ( like stdout for iostream ):
Code:
RomTableView<MyType> obj( RomTables::Default ); // or something like that
for (auto it = obj.begin(); it!=obj.end(); ++it)
...
now, in your current implementation the handle constructor would do literally nothing, but this time the semantic would be correct and evident, with the benefit of allowing potential future extensions ...
Re: Custom (readonly) container and iterators ?
Quote:
Originally Posted by
OReubens
emmm no... The class has no data to be copied, so there can't ever be unexpected copy semantics.
Well, I'd say that the fact that the class does not hold the data it exposes itself is an implementation detail. However, the immutability of the data prevents unexpected copy semantics indeed.
Quote:
Originally Posted by
OReubens
I expect the classes you pass to the RomTable template to have/implement a small set of functions. I've provided the obvious classes myself, but users can make their own.
I don't think that mixes well with the singleton design. If users can provide their own type as a template argument to your class, then they must also instantiate the singleton instance. I'm not 100% sure how that would work, but I think it would imply that users could end up with two instances of the same singleton class when they use a RomData<MyType> in two different modules (DLLs).
Quote:
Originally Posted by
OReubens
There is no constructor. Other than an empty one I set as private to prevent multiple instances being made. From your comments in this post I'm not sure doing this is still a good idea now.
I'm not sure I see the benefit in this. It seems to be functionally more or less the same as what I'm already doing but you're adding an extra indirection.
Users would need to type something like
RomTable::View<Type>::Instance()
As opposed to the
RomTable<Type>::instance
with what I have so far.
Wherein lies the real benefit in the approach you are proposing here ?
There's no extra indirection in what I proposed; just a split between the interface of the singleton and the interface of the ROM-data access.
If your class has a trivial constructor (or initialization, more generally) then there's not much benefit, besides the possibility to place some type-agnostic functions in the non-template class. But I don't know if that is relevant for your case.
Re: Custom (readonly) container and iterators ?
Having talked to the other people on the development team and a couple of the biggest/most important users of the library. We now have resorted to making the template class as it is above. A data-less class that "somehow" transparently manages/returns/iterates over data it doesn't hold/own itself.
No singleton instance, since that would indeed mean users not only need to define the class, but are also forced to instantiate the static singleton instance themselves. THe meyers singleton could have been an option, but the vote went towards simpler syntax.
Because the "RomTable" name seems to imply data where it doesn't. And "Rom" doesn't quite fit either. (the memory on the addon card is FLashRom, but it isn't "mapped" into the memory space of the PC, it is accessed through the addon card's hardware interfaces more like reading/writing/streaming data through a modem/serial port. We did decide to change the name to something that makes more sense.
So in the namespace of this templatelib we now have a Proxy<Type> which pretty much names perfectly what it does. The class serves as a proxy or "go between" the addon card and the type provided. Consumers are expected to make their own instances to do anything with this class rather than rely on a singleton created explicitely or through a function.
Looks like this thread can be closed. Actually finishing all the coding on this particular project will take a while...
