A Lot of issues with your library

[codebeat-nl]

Hi, nice idea of a library with some design flaws. The major problems are the pointer (address) and using char type when it needs to be an unsigned char like a byte really is. Get mixed results with this library but overall pretty unreliable for now.

The pointer address you are using is too large to use as EEPROM storage address because most build-in EEPROM's are pretty small, like 1024 bytes (1Kb) or lower. Also there can be huge gaps between locations of variables that makes it very inefficient. Made a debug function and most of the time it is above the limit of the EEPROM size and overflows and overwriting other data. Another problem is that the pointer can change when you upload a new compiled sketch with modifications, so the address changes and produces 'wrong' indexes. In fact all stored values are lost.

The char issue, for example in these functions you are using a char* pointer and not a unsigned char pointer or better an uint8_t* pointer. The EEPROM function/routine expect a byte value, not a char value. So strange things may happen when a larger value than 127 or less than zero is passed thru the update function or a byte retrieved that is larger than 127.

inline void EEReadBlockElement(  char *out, uint8_t *addr, const unsigned int len ){
            for( unsigned int i = 0 ; i < len ; ++i ) *out-- = EEPROM[int(addr++)];
        }

        inline void EEWriteBlockElement(  const char *in, uint8_t *addr, const unsigned int len ){
            for( unsigned int i = 0 ; i < len ; i++ ){
                const char b = *in;
                EEPROM[int(addr++)].update(b);
                --in;
            }
}

Did you test this library anyway, or did you test this library only with low values and with a few declarations? You have to test your library better before posting great achievements, I don't think you are able to fix this pointer/address problem because of the way it is designed. There is no unique and stable identifier.

Also have some doubts about the EEMEM usage, see this example you provide at the project page:

//Use the xxx_e types rather than the standard types like uint8_t
struct Foo{
  uint8_e a;
  int16_e b;
  float_e c;
};

Foo foo EEMEM; //EEMEM tells the compiler that the object resides in the EEPROM 

By using uint8_e etc instead of uint8_t you already notice the compiler to use the class you designed and it's value will be stored or retrieved from EEPROM. Again, did you test this library anyway, it doesn't make any sense and doesn't work either.