Will therefore GDB utilize C++ or not?
Russell Shaw
rjshaw@netspace.net.au
Sat Jun 2 07:01:00 GMT 2012
On 27/05/12 01:50, Jan Kratochvil wrote:
> On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote:
...
> 453728 vs. 265000 bytes is +71% increase.
> It still seems perfectly worth to me for all the discussed C++ benefits for GDB.
...
A few of the things i didn't like about C++ have been fixed in the C++11
standard. In particular, under: Rvalue references and move constructors
<http://en.wikipedia.org/wiki/C%2B%2B11#Rvalue_references_and_move_constructors>
A lot of C++ code was copying objects by value, which means the copy constructor
had to deep-copy and malloc to make temporaries, only to throw them away later.
That is *slow* and fragments the heap, especially on smaller systems.
With C11, new "move constructors" have been added for copying malloc'd memory to
avoid that problem.
Parsing C++ has also been improved. <http://en.wikipedia.org/wiki/Most_vexing_parse>
A lot of other improvements too.
I just read the C11 standard (close to final version), and am re-considering the
use of C++ for smaller microcontrollers.
If gdb is done in C++, run-time performance and bloat should be kept in check by
avoiding gratuitous use of generalized template libraries. C-like libraries for
things like bit-sets and symbol tables should work equally as efficient in C++
if translated with some superficial C++ syntax.
Hitting my F9 "compile" button would result in an annoying half-second delay
when compiling simple programs using the STL (years ago when i did C++). Self
written utility libraries such as those already done in C in gdb could avoid that.
More information about the Gdb
mailing list