From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb@sourceware.org
Subject: Re: Will therefore GDB utilize C++ or not?
Date: Mon, 16 Apr 2012 06:55:00 -0000 [thread overview]
Message-ID: <20120416065456.GA30097@host2.jankratochvil.net> (raw)
In-Reply-To: <4F833D29.4050102@redhat.com>
On Mon, 09 Apr 2012 21:48:57 +0200, Pedro Alves wrote:
> Symbol/types even are long lived objects, it's not common at all to need to
> worry about leaks (RAII/exceptions) here.
They are and they should not be, this is what archer-jankratochvil-vla with
dynamic types is there for and which are not well maintainable without C++.
There was Tom's reference counting implementation which I found fragile
+ complicated so I wrote a custom garbage collector
[patch 0/8] Types Garbage Collector (for VLA+Python)
http://sourceware.org/ml/gdb-patches/2009-05/msg00543.html
but it was sure also a wheel reinvention, with RAII it would be all easier
(sure not automagical but some parts of reference counting done
automatically).
> On 04/09/2012 08:05 PM, Jan Kratochvil wrote:
> > Not just that one, std::string vs. cleanups vs. exceptions are even more
> > wanted (by me); just static typing (probably) cannot be done without C++,
> > the other parts are still being fixed up without C++.
>
> Sure, there will always be bugs. C++ doesn't magically make all bugs go away.
> Even RAII is not _that_ different from cleanups.
It is very different, for the very common std::string one does not even have
to start thinking about any cleanups.
If GDB should stay with C then OK (although FYI I am not so in favor of it).
But then it should be real C - therefore without GDB cleanups, without GDB
TRY_CATCH etc. etc., proper C code returning error codes from each function
and each caller checking it and doing all the local cleanups by hand.
I do not know any larger project in C with proper error checking, there are:
* Linux kernel lacks proper error reporting, common unclear EPERM from ptrace
for 100+ different reasons is a great illustration. At most it uses printk,
not too good and even reusable for GDB.
* GCC uses an extra garbage collector with terrible markers in C code, that
is also not a good example to follow. I do not remember / know how they
resolve error reporting / exceptions in GCC.
* There sure are more larger projects in plain C, but which ones?
Daniel's idea of having two - light (C, separate code) + heavy (C++, GDB
sharing code) - gdbservers I had on my mind myself before his post.
Thanks,
Jan
next prev parent reply other threads:[~2012-04-16 6:55 UTC|newest]
Thread overview: 115+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-30 16:14 Jan Kratochvil
2012-04-04 20:48 ` Tom Tromey
2012-04-04 21:55 ` Mark Kettenis
2012-04-05 3:31 ` Sergio Durigan Junior
2012-04-05 11:46 ` Phil Muldoon
2012-04-06 0:35 ` Will therefore GDB utilize C++? Not John Gilmore
2012-04-06 1:35 ` Russell Shaw
2012-04-06 13:16 ` Joel Brobecker
2012-04-06 14:43 ` Russell Shaw
2012-04-06 15:34 ` Michael Eager
2012-04-06 23:32 ` John Gilmore
2012-04-07 1:04 ` Robert Dewar
2012-04-07 1:52 ` Thomas Dineen
2012-04-07 16:54 ` Michael Eager
2012-04-09 23:59 ` Stan Shebs
2012-04-05 0:22 ` Will therefore GDB utilize C++ or not? asmwarrior
2012-04-09 18:41 ` Pedro Alves
2012-04-09 19:05 ` Jan Kratochvil
2012-04-09 19:49 ` Pedro Alves
2012-04-09 20:15 ` Paul Smith
2012-04-12 20:06 ` Daniel Jacobowitz
2012-04-12 21:28 ` Paul_Koning
2012-04-13 0:04 ` Doug Evans
2012-04-18 14:10 ` Pedro Alves
2012-04-18 20:27 ` Tom Tromey
2012-04-18 14:08 ` Pedro Alves
2012-04-21 17:24 ` Daniel Jacobowitz
2012-04-16 6:55 ` Jan Kratochvil [this message]
2012-04-18 14:11 ` Pedro Alves
2012-04-18 15:16 ` Jan Kratochvil
2012-04-18 15:28 ` Pedro Alves
2012-04-18 15:54 ` Jan Kratochvil
2012-04-18 16:01 ` Pedro Alves
2012-04-18 16:07 ` Joel Brobecker
2012-04-18 16:13 ` Jan Kratochvil
2012-04-18 16:23 ` Joel Brobecker
2012-04-18 16:31 ` Joel Sherrill
2012-04-18 16:50 ` Pedro Alves
2012-04-18 16:57 ` Joel Brobecker
2012-04-18 17:28 ` Joel Sherrill
2012-04-18 17:40 ` Paul_Koning
2012-04-18 20:37 ` Frank Ch. Eigler
2012-04-18 20:38 ` Paul_Koning
2012-04-18 20:36 ` Tom Tromey
2012-04-18 17:48 ` John Gilmore
2012-04-18 19:07 ` Tom Tromey
2012-04-18 23:10 ` John Gilmore
2012-05-18 18:36 ` Tom Tromey
2012-05-18 18:47 ` Paul_Koning
2012-05-18 19:36 ` Tom Tromey
2012-05-18 19:44 ` Paul_Koning
2012-05-18 20:07 ` Tom Tromey
2012-05-18 20:41 ` Aurelian Melinte
2012-05-18 18:51 ` Lazy CU expansion (Was: Will therefore GDB utilize C++ or not?) Tom Tromey
2012-04-18 20:34 ` Will therefore GDB utilize C++ or not? Tom Tromey
2012-04-18 19:18 ` Will C++ proponents spend 20 minutes to try what they're proposing? John Gilmore
2012-04-18 19:23 ` Jan Kratochvil
2012-04-18 20:40 ` Tom Tromey
2012-04-18 20:56 ` Mike Frysinger
2012-04-18 20:31 ` Will therefore GDB utilize C++ or not? Tom Tromey
2012-04-18 20:25 ` Tom Tromey
2012-05-21 18:11 ` Pedro Alves
2012-05-21 18:36 ` Jan Kratochvil
2012-11-21 20:18 ` Jan Kratochvil
2012-04-10 0:23 ` Yao Qi
2012-04-10 9:47 ` Yao Qi
2012-04-18 20:11 ` Tom Tromey
2012-04-18 20:31 ` Can it really be ok to map GPL'd code into any old process? John Gilmore
2012-04-18 20:36 ` Pedro Alves
2012-04-23 18:03 ` Will therefore GDB utilize C++ or not? Tom Tromey
2012-05-18 19:55 ` Tom Tromey
2012-05-18 21:56 ` Joel Brobecker
2012-05-19 2:17 ` Tom Tromey
2012-05-19 15:21 ` Daniel Jacobowitz
2012-05-19 21:36 ` Joel Brobecker
2012-05-20 12:16 ` Frank Ch. Eigler
2012-05-21 15:56 ` Pedro Alves
2012-05-21 16:15 ` Jan Kratochvil
2012-05-21 17:37 ` Paul_Koning
2012-05-21 17:58 ` Jan Kratochvil
2012-05-22 18:03 ` Paul_Koning
2012-05-21 18:08 ` Pedro Alves
2012-05-21 18:08 ` Tom Tromey
2012-05-21 18:10 ` Jan Kratochvil
2012-05-21 18:54 ` Matt Rice
2012-05-26 15:50 ` Jan Kratochvil
2012-06-02 7:01 ` Russell Shaw
2012-06-02 7:13 ` Jan Kratochvil
2012-06-02 10:47 ` Russell Shaw
2012-06-02 11:10 ` Jan Kratochvil
2012-06-02 11:15 ` Russell Shaw
2012-06-02 11:15 ` Jan Kratochvil
2012-11-22 18:46 ` Jan Kratochvil
2012-11-22 21:42 ` John Gilmore
2012-11-23 15:26 ` Jan Kratochvil
2012-11-27 1:29 ` Stan Shebs
2012-11-27 2:02 ` Paul_Koning
2012-11-27 2:59 ` Stan Shebs
2012-11-27 15:17 ` Paul_Koning
2012-11-27 21:14 ` Tom Tromey
2012-04-09 23:23 ` Stan Shebs
2012-04-18 14:22 ` Pedro Alves
2012-04-18 18:12 ` Stan Shebs
2012-04-18 18:32 ` Paul_Koning
2012-04-18 18:37 ` Pedro Alves
2012-04-19 8:43 ` Yao Qi
2012-12-04 14:17 ` Jan Kratochvil
2012-12-04 14:44 ` Mark Kettenis
2012-12-04 14:52 ` Jan Kratochvil
[not found] ` <CACTLOFof0v6NJe8WemS--Q3iMSXjHciwASxBAED5ki3scaNZuw@mail.gmail.com>
2012-12-07 12:57 ` Jan Kratochvil
2012-12-07 13:25 ` Yao Qi
2012-12-11 6:25 ` Matt Rice
2012-12-13 15:12 ` Jan Kratochvil
2012-12-14 11:03 ` Matt Rice
2012-12-14 12:16 ` Jan Kratochvil
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120416065456.GA30097@host2.jankratochvil.net \
--to=jan.kratochvil@redhat.com \
--cc=gdb@sourceware.org \
--cc=palves@redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox