New Delegate class to boost performance of callbacks previously using std::function

[dok-net]

The Delegate class can perform calls at C-function pointer with void* argument pair efficiency, while offering the flexibility to simply use lambdas with captures and std::bind in the same places without changing the API.

…
void readAsync(Delegate<void,void*,int> cb)
{
    …
    cb(recvCount);
    …
}
…

readAsync([this](int received) { this->receivedAsync(received) });

or

static void receivedAsync(void* self, int received)
{
    ((SomeClass*)self)->receivedAsync(received);
}
...
readAsync({ receivedAsync, this });

The ISR handling PR #6047, Schedule.h|cpp adaptation, and WiFi etc. callbacks PR #6782 are updated and waiting to be published.

[dok-net]

@earlephilhower It seems that you are the one taking care of CI. This build is fine except the Mac target has trouble d/l-ing the compiler suite or something at Travis. Is there any user-available way that I could retrigger failed builds without pushing changes to GitHub?

[earlephilhower]

@dok-net, looked like a temporary network interruption. I'm not sure if the submitter can do it, but next time you can hit the Details link, then on the RHS of the list of Travis-CI jobs there should be a small button you can use to re-run a job. If it's not there, then only the maintainers can and you'll have to wait. Don't sweat a single job failure, we can always re-fire just that job while reviewing code.

[earlephilhower]

I assume this has the same issue with C++17 and implicit copy constructors as the version in SoftwareSerial. plerup/espsoftwareserial#140

Also, these add'l 2,362 lines code don't seem to be used for anything in the core with this PR. Maybe a separate library is the way to go? At the very least some sort of documentation/examples since the only use would be end users' code. OTW it's not really visible to the users.

[dok-net]

Once you move on to some of the other pending PRs of mine, you'll find that Delegate and MultiDelegate do get used a lot in core.
Switching to gcc 9.2 and enabling a very fresh deprecation warning, plus turning it into an error, is adding quite a bit pressure on the poor developer having to port their code... I've been able to verify with MSVC in C++17 mode, and GCC-8 until now, and I've added an academic fix for the -Wdeprecated-copy related situation. I'm still needing time to update to a desktop Linux distribution that already includes GCC 9.2. If you get around to running the build process for ESP8266 ahead of me, please let me know the outcome. The latest fixes are in the master branches of the various repositories I manage (https://github.com/plerup/espsoftwareserial).

[dok-net]

@earlephilhower I've got it building on 64bit Linux now. GCC 9.2 is a serious pain w.r.t. to that warning, I had to copy and check ctors and operator=s without end from one template to another to another, just because it's the only compiler that refuses to infer types easily and allow "using" on ctors and assignment ops without balking. Btw, it's not about C++ 17, GCC 9.2 complains the same for the other C++ releases :-(

[earlephilhower]

Thanks for the info. I thought the deprecation was related to a C++ standard, but oh well. The version of Delegate.h in SoftwareSerial looks to be building just fine now, thx!

[dok-net]

I'll take a little more time to run whatever use cases I've collected so far, then I will release and PR that. Cooptask on x86_64 Ubuntu needs some work, too. Do you have any timeline for a working EspSoftwareSerial on gcc9.2? I am not 100 percent confident that I haven't broken anything 🙂, and 5 of my pending PRs depend on Delegate/MultiDelegate nowadays.