Re: [C++] System Requirements

Ben Longbons <[email protected]>
Newsgroups gmane.comp.gdb.devel
Message-ID <CA+XNFZOAwMqVnGy=2XLDheaiUZzKmgY1Ww4G6NNHN-EUuPVXnQ@mail.gmail.com>
On Mon, Dec 16, 2013 at 11:10 AM, Eli Zaretskii <[email protected]> wrote:
> Perhaps you never tried to use outdated versions of GDB too seriously
> for too long.  GDB constantly gets more and more useful features and
> solves more and more bugs, so using an old version is a PITA.
Well, I can state with absolute certainty that there are *some* bugs
in gdb that simply will not be fixed without relying on some subset of
C++11 features.

It's not that they couldn't theoretically be fixed otherwise, they
just wouldn't be detected. For a while I had to maintain two branches
of my own software, and I remember specifically backporting one fix to
the pre-C++11 stable branch for a problem that many users had noticed,
but which eluded bughunts until I used some C++11 stuff.

In some cases it is possible to hide the feature behind the
development mode check, in some cases it is not. GCC 4.3 and 4.4
introduce a lot of features that can't be used conditionally.

> It's
> not like GDB development aims only at supporting newer compiler
> versions, you know.  Just look at the commit logs, and you will see.
I haven't been able to get the specific information I looked for as to
exactly which versions *are* supported and which have been for
previous releases.

>> Regardless of where we set the bounds, do you agree to the *concept*
>> of having two different modes?
>
> I don't.  There's no reason to have that, and it certainly adds to the
> overhead.
I do strongly believe it is beneficial to keep the two modes very
similar, but with the specific differences I have in mind, it would be
rather unlikely to commit something that failed in one mode and worked
in the other.

-Ben
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.