[C++] System Requirements

[Ben Longbons <brlongbons at gmail dot com>]

Under the assumption that most active gdb maintainers intend that
future gdb releases be written in C++, I am presenting a possible plan
for the conversion, based on my experience with a conversion about
1/5th the size of gdb.

I have found 3.5 areas of discussion, 2.5 of which I have actually written.
- System Requirements
- Attack Plan
-- Warning Header Proposal
- Style Guide (to be written, probably not by me)

A shared editing pad is available at http://piratepad.net/gdb-cxx, it
will contain links to the archived mails so don't be concerned about
editing what I wrote there.

This thread will discuss system requirements.

This is going to turn into a flamefest, but at the very minimum we
*must* agree that choosing the system requirements is a trade-off
between how many systems meet the requirements and how much effort it
takes to do anything under those requirements. I do not ask for higher
minimum requirements for no reason! Not all Turing machines are equal,
even if in theory they can solve each other's problems.

We have already seen the kind of trouble it takes to support old
systems with Python 2.4 and also new systems with Python3. This would
be much easier if the old systems requirement was Python 2.6, which
can safely be coinstalled. I am glad that gdb's python support is not
my problem.

Unlike python, it is intrusive to upgrade the system gcc, since every
application links to it.

I consider that there are two different sets of requirements:
- The stricter requirements for a system that active gdb developers
have access to ("development mode requirements")
- The looser requirements for a system to deploy ("deploy mode requirements").

As long as we regularly test the "deploy mode", it is reasonable to
have different settings used if you meet the development requirements.
Additionally, it is not absolutely necessary to meet the "developer
mode" to develop gdb.

I propose that the minimum "development requirements" is either gcc
4.6 or 4.7. The rest of this section discusses the deploy
requirements.

What are the current minimum deploy requirements (for gdb 7.6)?
What were the minimum deploy requirements about 5 years ago (for gdb 7.0 or so)?
What were the minimum deploy requirements about 10 years ago (for gdb
6.0 or so)?
What were the minimum deploy requirements about 15 years ago (for gdb
4.18 or so)?

gcc 3.3 is the oldest I've heard anyone tries to support. It is used
by NetBSD 5.1 (2010-11-19)
gcc 3.4 was the last deliberate incompatible ABI change (libstdc++.so.6).
gcc 4.0 is used by older Apple systems
gcc 4.1 is used by RHEL 5
gcc 4.2 is the latest gcc shipped by Apple and OpenBSD because of the
GPL3 thing. However, this is becoming less important now that clang
exists (but I do not think clang will necessarily support the
"development requirements"). And do you *really* want free software to
be help hostage by Apple?

gcc 4.3 is the first release that supports some form of C++11. It is
also the oldest version of gcc that I can actually get to build on my
system.
C++11 is a *huge* mindset change for writing C++ - it's practically a
new language, when taken all together. gcc 4.3 does not support very
much of C++11, but it does support some core things:
- rvalue references (these are huge, both for idiom and performance)
- static_assert
- decltype (not quite the same as gcc's typeof extension)

gcc 4.4 supports more of C++11. It is the compiler shipped with RHEL6
and Debian 6
- initializer lists (much less typing)
- auto
- enum class (much more safety for new code)
- = default and = delete
I recommend gcc 4.4 as the minimum deploy requirements. If people
expect to use the latest and greatest version of gdb, they should be
willing to provided a somewhat recent standards-compliant compiler.
This gcc version is very widely deployed, so relatively few people
will be forced to use an older version of gdb if this is chosen.
If it would make the maintenance burdern lighter, it *would* be
possible to declare 4.2 as the minimum requirement for the initial
conversion and upgrade the requirements for the next release. However,
I do not recommend this unless absolutely needed, and WE MUST NOT
SUPPORT GCC 4.2 INDEFINITELY. If you disagree with my recommendation
for now, what is your plain for dropping gcc 4.2?
At some point, gcc 4.4 will go the way of gcc 4.2, and the requirement
can be raised again.
How will this be defined?

I will continue listing the advantages of each newer version

gcc 4.5 doesn't much to say about it, and I'm not aware of any major
deployments. It does have some less-frequently-used features:
- lambda functions
- explicit conversion operators
- local types as template arguments

gcc 4.6 is the next major step towards C++11 compliance, but since
it's getting closer, I keep seeing its shortcomings. But its benefits
are:
- nullptr (there exist compatibility libraries for this)
- forward declarations of enums (unfortunately these are still buggy
with debuginfo even with the most recent gcc, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58150 )
- constexpr (this is huge)
- range-based for (much less typing; not really compatible with
various macros that emulated this)
- unrestricted unions (not used often, but when you need them, they're
hard to do without)
GCC 4.6 is also the first release that supports #pragma GCC diagnostic
inside a function, which is absolutely essential in my "attack plan"
and can (using _Pragma form) be #define'd out in deployment mode.

gcc 4.7 is the first release that is practically compliant. Note,
however, that gcc 4.7.0 and gcc 4.7.1 must be avoided at all costs due
to an ABI compatibility; gcc 4.7.2 is the requirement in this case
(I'm not sure which point versions are okay for the other versions).
- in-class non-static data initializers
- override and final (can be #define'd out for deployment and used in
development)
- template aliases (these are *incredibly* useful, and among many
other benefits can make debugging sane since gdb doesn't support
operator overloading in the print command yet)
- delegating constructors
- user-defined literals (useful for string-safety)

gcc 4.8.1 is the first fully-compliant C++11 release. At this point,
you only have to worry about bugs and DRs (I recently had some code
that was illegal according to c++11 as written, but legal according to
a DR).
- move this (can be #define'd out for deployment)
- inheriting constructors

The features I listed above are the ones I use regularly in my own
codebase. For a more complete list, see:
http://gcc.gnu.org/projects/cxx0x.html

Thanks for your time,
Ben Longbons (o11c on IRC)