suersaiyangod:
Here's an example: I'm reading the Strings stored in the EEPROM, each String can vary in size and obviously I won't know the size of each String. So if I have to read each String from each address I can't specify the length of the character array I'm using to store each character of the String since I will have to read more than one String from the EEPROM and each one will vary in size. If I use Strings instead of character strings then I don't need to specify the size. I want to this advantage. I hope you understand my example. Thanks
Short of re-writing the memory allocation functions provided by the low-level startup code (malloc, free, sbrk, etc.), there is nothing you can do to change the way objects, like String, use memory in any beneficial manner. So, any class you write, will suffer the exact same problems as String. Your base assumption is that there is something the authors of the String class could/should have done to avoid memory fragmentation. There is not. The problems with the String class are, first and foremost, a result of the very limited amount of RAM available on many Arduinos, and the fundamental way memory allocation is done, which is completely outside the String class. It's kinda like deciding the guys that designed your car didn't do a very good job, because it does not accelerate as fast as a Bugatti Veyron. So you're going to re-design your 1.6L 4-cylinder engine to "overcome" this limitation. Basic physics says it just ain't gonna happen.
Now, if you want your EEPROM class to provide the same functionality as String, that is quite do-able, and does not require you to even know how the low-level memory allocation works. That is the beauty of C++ inheritance.
Regards,
Ray L.