True, I didn't make any fundamental changes to what you had. I just reorganized it a bit.
To answer your questions:
- 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.
- Are you familiar with - http://playground.arduino.cc/Main/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: https://github.com/adalton/arduino/tree/master/projects/Dht_Library
. This version more exemplifies why I liked having the pin be part of the object (see the readSensor() function in the driver).
- 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.
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.