C++ on Embedded Systems

Re:C++ on Embedded Systems by minipci1321 on Tuesday February 21, 2017 @02:27AM (#13693957)

This makes instances of all derived classes be at least as long as a pointer -- many of them will be adding a data member so be longer yet, which will disqualify them for passing over in a general-purpose register (details per each ABI). This can have dramatic adverse effect on the overall performance of the code which, depending on the domain, can be very negative.

EDIT: actually, adding a virtual, or a destructor, alone (without size considerations) makes the type non-POD which prevents it from being returned in a register.

[ Parent | on HN ]

Re:C++ on Embedded Systems by pandaman on Tuesday February 21, 2017 @02:57AM (#13694077)

To be honest, a derived class already cannot be a POD. But stuffing the vtable pointer into any derived class is indeed wasteful for embedded programming and opens another way to exploit your system (if you care about security) by leaving code pointers at the fixed addresses in r/w memory.

[ Parent | on HN ]

Re:C++ on Embedded Systems by gpderetta on Tuesday February 21, 2017 @05:06AM (#13694546)

it can still be standard layout (the 'new' POD for all intents and purposes) if either the base or the derived class is empty.

/pedantic

[ Parent | on HN ]

Re:C++ on Embedded Systems by mrkline on Tuesday February 21, 2017 @02:43AM (#13694012)

Great points. In our cases, these objects were few in number and were accessed infrequently through a pointer, so I don't think there's much to be concerned about. Avoiding unnecessary vtables is definitely something to keep in mind, though.

[ Parent | on HN ]