This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Will therefore GDB utilize C++ or not?
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: gdb at sourceware dot org
- Date: Fri, 30 Mar 2012 18:14:03 +0200
- Subject: Will therefore GDB utilize C++ or not?
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);
}