Re: Will therefore GDB utilize C++ or not?

[Russell Shaw <rjshaw at netspace dot net dot au>]

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.