Split EEBit into a pointer and reference type

[eric-wieser]

No description provided.

[Chris--A]

This is what I had originally done. I changed it to combine the features as the pointer side of things was only really for iteration. But I have been reconsidering splitting them again so I will have a good look into this.

Mainly it was to avoid another proxy class. However I do agree that the pointer specific stuff does not make sense if people see it only as a reference ( bit++ ).

[eric-wieser]

I don't think there is any harm in having proxy classes, especially if the end user just uses auto anyway. Better to exactly match the semantics of pointers and references

[eric-wieser]

As a side-note, it may be desirable to switch to the following set of types:

• ee_ptr<T> - equivalent to current EEPtr when T is uint8_t
• ee_ptr<ee_bit> - equivalent to current EEBitPtr
• ee_ref<T> - equivalent to current EERef when T is uint8_t
• ee_ref<ee_bit> - equivalent to current EEBit
• ee_ref<const T> - equivalent to current const EERef
• ee_ref<const ee_bit> - equivalent to current const EEBit

Which crucially allows the following to be added, which are not representable right now:

• ee_ptr<const T>
• ee_ptr<const ee_bit>

const ee_ptr<T> continues to mean "This always points in the same place in the eeprom", and const ee_ref<T> and ee_ref<T> are equivalent, in the same way that T& and T& const are equivalent

To the user, there are now only two proxy classes, although clearly you still need to implement all four.

ee_ptr<T> would have the semantics of the current EEPtr, but with operator ++ etc multiplying by sizeof(T). This would eliminate the need for the current get<T> method.

For backwards compatibility, a typedef ee_ptr<uint8_t> EEPtr; typedef ee_ref<uint8_t> EERef should suffice