Tamas Rudnai schreef op 03-Mar-14 9:01 PM:
> Are you using C++ only for compile time strong type checking and for
> templates only? Or it is too much of simplification of the complex librar=
y
> you have built?
- I use templates (and template specialization, and SFINAE) for=20
compile-time configuration (which might seem small peanuts, but this=20
covers almost everything).
- I use ADTs, for instance for representing (absolute) time and duration
- I do NOT use run-time type information, exceptions, dynamic=20
deallocation, run-time initialized globals, STL, and most of the other=20
standard libraries
- I use virtual functions only when no other via options exits.
- I use the << syntax for formatted character output, but with my own=20
implementation of std:cout (the standard ostream takes WAY too much ROM=20
and RAM, and drags in the execption handling)

A simple example: reading a temperature sensor (in this case in a=20
DHT11). The simplified interface is

  template<
       class _pin,
       class timing
 >
struct dht11 {
       template< class details >
       static bool get(
          units::quantity< temperature_dimension, details > & x
       );
}

The interface must be instantiated with a timing service (essentially a=20
wait() call) and a pin. It provides a bool get(...) method that can be=20
called with any instatiation of a quantity, provided that it has the=20
dimension temperature. A call could be

       units::temperature_in_celcius< int > t;
       if( dht11::get( t )){
          td::cout << "temperature =3D " << h.raw() << " " << h.symbol <<=20
"\n";
       }

This would write

    temperature =3D 20 C

But with

    units::temperature_in_kelvin< long long > t;

(using 'long long' just to show that a different representation can be=20
choosen) it would print

    temperature =3D 293 K

The point here is that the library does not have to fix
- how timing is done
- who the pin is accessed
- in which representation (datatype) the answer is returned

Note that this does not mean that the run time code has to have all this=20
flexibility, it is the compiler that fills in the appropriate details.=20
When the pin is a microcontroller pin that can be accessed with two asm=20
instructions, that is what will be in the run-time code. But if it is a=20
pin on some I2C extender chip that will be used just as easily (but in=20
this case it might screw up the timing.) If timing is to be one using a=20
hardware timer, fine. But it can also be busy waiting. It is up to the=20
user of the library to decide, the library is flexible.

I am not totally sure this is a good idea, but as I have written this=20
interfaec right now you can use the 'same' get method to read either the=20
tempeature or the humidity. What you get depends on the dimension of the=20
variable that you pass to the get() call.

Wouter




--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.