Hi Rob,
True, I didn't make any fundamental changes to what you had. I just reorganized it a bit.
To answer your questions:
robtillaart:
- Did you measure the effect of the code changes on the footprint (per object) ?
- No, I haven't measured the footprint. I imagine per object it should increase only by the sizeof(pin) (plus maybe some padding). The program text size may have increased some as well, but again I haven't measured.
robtillaart:
- Are you familiar with - Arduino Playground - DHTLib - which supports the DHT22 too (and DHT21 under test) ?
This is my preferred lib for DHT sensors, and I still want to rewrite it in OO with a base class and 3 derived classes.
- No, I wasn't familiar with it -- thanks for the pointer. I took a stab at refactoring that version to the OO version that you mentioned, combined with the changes I introduced in the old version. You can find the new version at: arduino/projects/Dht_Library at master · adalton/arduino · GitHub. This version more exemplifies why I liked having the pin be part of the object (see the readSensor() function in the driver).
robtillaart:
- can you add a link to the playground in your code?
- Yes, absolutely! I actually intended to do that up front, but I made these changes late at night and it slipped my mind. I've already pushed the update.
robtillaart:
Final note, I see you used the goto statement to handle error conditions. Although you did it in a structured way to handle error conditions it is discouraged as goto's can disrupt code/stack/heap.
I'm not sure that I follow. Is there some flaw in the compiler that causes it not to properly handle gotos? From a structured programming perspective, neither goto nor having multiple returns is great, but I prefer this over multiple returns.
Thanks again!
Andy