Will therefore GDB utilize C++ or not?

[Jan Kratochvil <jan.kratochvil@redhat.com>]

Hi,

there is now new patch:
	Re: [PATCH] Allow 64-bit enum values
	http://sourceware.org/ml/gdb-patches/2012-03/msg00932.html
which is a pre-requisite for GDB inferior type fields safety similar to what
I already checked in as:
	[commit] [patch 2/2] typedef-checking for CU relative vs. absolute offsets
	http://sourceware.org/ml/gdb-patches/2012-03/msg00721.html

But compared to the [commit] patch of only 282 '+' lines limited to dwarf*
files only above the type fields safety patch will be huge and thorough the
whole GDB codebase (TYPE_LENGTH: 1103 lines, FIELD_BITPOS: 22 lines, sure the
patch will be larger)..


->
This whole effort is wrong if GDB was in C++ which allows to use:
	http://en.wikipedia.org/wiki/Object_type_%28object-oriented_programming%29#Boxing

so that one can directly use type->length as long as it is safe, an example of
C++ solution is given below.

It no longer needs to patch every use of TYPE_LENGTH into some TYPE_LENGTH_VAL
or to append '.cu_off' to every use of the "integer" like I did in the
[commit] patch above.


There are sure many other cases I still wait to solve using C++.  There was
some plan to have GDB exceptions and cleanups converted to C++ exceptions and
RAII
	http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
automatic allocation/deallocation which would automatically solve many other
bugs being fixed by hand here and there.  I have filed also
	crashes from stale frame_info *
	http://sourceware.org/bugzilla/show_bug.cgi?id=13866
which would be easily sanity-protected by mandatory referencing frame_info *
by C++ smart-pointer and during reinit_frame_cache just assert there are no
live instances of frame_info references out there etc. etc.


For switching GDB compilation to C++ there is needed to resolve some name
clashes first
	http://sourceware.org/gdb/wiki/ArcherBranchManagement
	Enabling gdb to compile with the -Wc++-compat flag to gcc.
	archer-ratmice-compile-Wc++-compat
but there is enough workforce to do this mechanical type of work as long as
there is an agreement to switch to C++.

To C++ or not to C++?  Unfortunately the discussion was here already before
and I am aware several contributors are not welcome with it, I think it does
not need to affect readability of C code much, there is not enough workforce
to rewrite all the GDB code into C++ style anyway.  Still C++ would help
a lot, some kinds of bugs are not solvable without it.

I am open to suggestions of static analysis tools to use instead but at least
according to the experience of Tom Tromey it is not so easy / safe / foolproof
to use, IIUC his words.


Thanks,
Jan


#include <stdint.h>
class Length
{
  int64_t _x;
public:
  Length(int64_t x) { _x = x; }
  operator int64_t() { return _x; }
private:
  operator int() { return _x; }
};
void ok (int64_t l) {}
void bad (int l) {}
void bad2 (long long l) {}
int
main()
{
  Length l(10);
// great, no errors
  ok (l);
// error: ‘Length::operator int()’ is private
// error: within this context
// note: candidates are:
// note: Length::operator int()
// note: Length::operator int64_t()
// error:   initializing argument 1 of ‘void bad2(long long int)’
  bad (l);
// error: conversion from ‘Length’ to ‘long long int’ is ambiguous
  bad2 (l);
}