C++ API should support static allocation

[turon]

If libmraa is targeted at RTOS embedded platforms, then you may want to statically allocate say a Uart object, but still need a way to stop/release the resource for power management purposes without actually destroying the object:

/// Static allocation -- still need a way to "stop" the peripheral for power
/// (or simply close the fd) that doesn't necessarily free the memory.
Uart theUart(0);

/**
* Uart destructor
*/
~Uart()
{
mraa_uart_stop(m_uart);
}

[alext-mkrs]

I'm not 100% what you're coming at, but the piece of code you've posted is already available in our .hpp wrapper. And there's not much of an object - C++ code is just a wrapper to C one and at the end of the day we're operating on special files in the OS to make UART communication work, so static allocation wouldn't IMHO make a lot of sense, just because there's nothing to allocate.

[arfoll]

So this implementation is aimed at Linux where power management should be done at the kernel level when nothing is been sent to the Uart.

On RTOS where power management is not in the kernel a different mraa implementation is used, but yes a call to 'release' the object without releasing the context may be good, I guess maybe a mraa__release() call? Is that what you where thinking?

[turon]

I'm basically making two comments on the currently defined C++ api:

1. a) There should be at least one "static allocation safe" constructor that does not call mraa_uart_init, as order of operations of static constructors is undefined. Clocks may need to be setup before calling any such init. Such a constructor can safely store the uart # as instance data, but shouldn't call the init.
   b) C++ api should have a means to call .init() besides the constructor. This .init() method could use the information stored from the constructor.

2. C++ api should have a means to call .stop() besides the destructor (which would never be called in a case where theUart is statically constructed).

Does the request make more sense?