This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Will therefore GDB utilize C++ or not?


there is now new patch:
	Re: [PATCH] Allow 64-bit enum values
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

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:

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
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 *
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
	Enabling gdb to compile with the -Wc++-compat flag to gcc.
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.


#include <stdint.h>
class Length
  int64_t _x;
  Length(int64_t x) { _x = x; }
  operator int64_t() { return _x; }
  operator int() { return _x; }
void ok (int64_t l) {}
void bad (int l) {}
void bad2 (long long l) {}
  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);

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]