Closed gillesdegottex closed 7 months ago
Memory usage change @ be75fe772666c99c157a979e41a27ade78f604d4
Board | flash | % | RAM for global variables | % |
---|---|---|---|---|
arduino:avr:LilyPadUSB |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:atmegang:cpu=atmega168 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:atmegang:cpu=atmega8 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:bt:cpu=atmega168 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:bt:cpu=atmega328 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:chiwawa |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:circuitplay32u4cat |
0 - 0 | 0.0 - 0.0 | 0 - 0 | N/A |
arduino:avr:diecimila:cpu=atmega168 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:diecimila:cpu=atmega328 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:esplora |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:ethernet |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:fio |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:gemma |
0 - 0 | 0.0 - 0.0 | 0 - 0 | N/A |
arduino:avr:leonardo |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:leonardoeth |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:lilypad:cpu=atmega168 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:lilypad:cpu=atmega328 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:mega:cpu=atmega1280 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:mega:cpu=atmega2560 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:megaADK |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:micro |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:mini:cpu=atmega168 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:mini:cpu=atmega328 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:nano:cpu=atmega168 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:nano:cpu=atmega328 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:nano:cpu=atmega328old |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:one |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:pro:cpu=16MHzatmega168 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:pro:cpu=16MHzatmega328 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:pro:cpu=8MHzatmega168 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:pro:cpu=8MHzatmega328 |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:robotControl |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:robotMotor |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:uno |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:unomini |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:unowifi |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:yun |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
arduino:avr:yunmini |
0 - 0 | 0.0 - 0.0 | 0 - 0 | 0.0 - 0.0 |
Oh, my bad, I didn't see this similar PR. I'll close mine then and see if I can bring any 2 cents useful for API#218.
No worries. The goal of my comment was only to make sure the related work in the other repository was given consideration (I don't have enough expertise in C++ to make a judgement in the specific approach that should be taken in this matter).
The intent behind the arduino/ArduinoCore-API
project is to maintain a single copy of all the non architecture-specific core code. Although the arduino/ArduinoCore-API
codebase is used in all the platforms Arduino has created recently, and the "Arduino SAMD Boards (32-bits ARM Cortex-M0+)" platform (which was created years before the establishment of the arduino/ArduinoCore-API
project) has been ported to using it, this platform hasn't yet been ported (https://github.com/arduino/ArduinoCore-avr/pull/329) and it is not clear when or if such a porting will be completed. So this pull request is not really a duplicate of https://github.com/arduino/ArduinoCore-API/pull/218 (though hopefully we should try to align the work in the two repositories).
Thx for the detailed answer!
I'll add the virtual destructor in the meantime on my side, hoping this will get handled in arduino/ArduinoCore-API
as already discussed.
The
Server
class is virtual (begin()
is not defined). Standard thus requires to have the destructor virtual, otherwise undefined behaviour is expected.This PR suggest to fix this issue by adding a simple empty destructor.