I refer you to this image:
And its accompanying article:
Though that only half answers the question because it’s not obvious what all of those markings mean and that doesn’t tell you how to make use of those features.
I believe EXT 0 through EXT 17 ought to be able to be used as both digital inputs and digital outputs, so that’s probably a good place to start, particularly if your goal at the moment is just to light up an LED.
You may also want to read the tutorial I wrote eons ago that shows how to set up an LED on a breadboard and provides some code demonstrating how to use DigitalIn which you could use as a baseline to compare your own library variant with.
int value = pin; might be a tad cryptic, but I don’t see how pin.read() is any more cryptic than read(pin) or how pin.is_connected() is any more cryptic than is_connected(pin).
As for ‘bloated’, it’s not likely to be that more expensive than maintaining a pin variable and having a set of functions for interacting with pins.
There’s no virtuality or weird indirection going on here, the DigitalIn/DigitalOut classes are just zero-cost wrappers around a C-like API.
Assuming ARM doesn’t do something weird with thiscalls, the end result should be as if the C-like API had been used directly.
I.e. the compiler will end up translating this:
DigitalIn pin(LED1);
if(pin.is_connected())
{
std::printf("Value: %d", pin.read());
}
To the equivalent of:
gpio_t gpio = gpio_t();
gpio_init_in(&gpio, LED1);
if(gpio_is_connected(&gpio))
{
std::printf("Value: %d", gpio_read(&gpio));
}
If those functions are small enough they’ll be inlined.
If they aren’t small enough to be inlined by the compiler, you probably don’t want them to be inlined anyway.
(Though in fairness I haven’t seen how those gpio functions are implemented so I can’t vouch that they’re as simple as they could be.)