public inbox for insight@sourceware.org
 help / color / mirror / Atom feed
From: Nick Duffek <nsd@redhat.com>
To: Dautrevaux@microprocess.com
Cc: gdb@sources.redhat.com, insight@sources.redhat.com
Subject: RE: Register group proposal
Date: Sat, 24 Feb 2001 15:43:00 -0000	[thread overview]
Message-ID: <200102242351.f1ONpp704661@rtl.cygnus.com> (raw)
In-Reply-To: <17B78BDF120BD411B70100500422FC6309E214@IIS000>

On 23-Feb-2001, Bernard Dautrevaux wrote:

>Perhaps for avoiding an unneeded dependency, that would trigger superfluous
>recompiles of users of "abc.h" that do not need "xyz.h" if "xyz.h" is
>modified?

I agree that's a pain.  But prohibiting typedefs only avoids a small
subset of superfluous recompiles.  For example, changing a single macro in
gdbarch.h causes a massive rebuild.

Eventually, GCC probably will support header file compilation, which
probably will lead to fully-accurate dependency generation.  This will
eliminate superfluous recompiles.

In the meantime, the problem diminishes as hardware speedups outpace GCC
complexity.

However, humans won't ever get better at writing maintainable code or
understanding existing code.  Typedefs help us achieve both of those
goals.

>Another problem may be seen as "name space pollution": If you don't mind
>about "xyz.h" why should you be prevented using some identifiers colliding
>with the private parts of it?

Regardless of whether we nest include files, global namespace clashes are
  (1) a concern that is
  (2) avoidable by using naming conventions minimizing the likelihood of
      clashes.

Nick

  reply	other threads:[~2001-02-24 15:43 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-23  2:52 Bernard Dautrevaux
2001-02-24 15:43 ` Nick Duffek [this message]
2001-02-26 18:21   ` Andrew Cagney
2001-02-27 10:30     ` Jim Kleck
2001-02-27 11:24       ` Per Bothner
2001-02-27 13:44         ` Jim Kleck
2001-02-27 15:17           ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2001-02-28  1:59 Bernard Dautrevaux
2001-02-26  5:29 Bernard Dautrevaux
2001-02-26  9:28 ` Christopher Faylor
2001-02-26 10:56   ` Andrew Cagney
2001-02-26 11:28     ` Christopher Faylor
2001-02-26 17:02       ` Andrew Cagney
2001-02-22  9:19 Michael Elizabeth Chastain
2001-02-21  3:00 Stephane Carrez
2001-02-21  7:00 ` Nick Duffek
2001-02-21  9:34 ` Andrew Cagney
2001-02-20 20:56 Nick Duffek
2001-02-21  6:44 ` Fernando Nasser
2001-02-21  7:10   ` Nick Duffek
2001-02-21  7:36     ` Fernando Nasser
2001-02-21  7:58     ` Keith Seitz
2001-02-21  8:50 ` Andrew Cagney
2001-02-21 11:43   ` Andrew Cagney
2001-02-25 15:36   ` Nick Duffek
2001-02-21 11:43 ` Andrew Cagney
2001-02-21 12:28   ` Andrew Cagney
2001-02-21 12:18 ` Andrew Cagney
2001-02-22  0:59   ` Eli Zaretskii
2001-02-22  4:29     ` Nick Duffek
2001-02-22  8:46       ` Andrew Cagney
2001-02-22  8:56         ` Keith Seitz
2001-02-22  9:20           ` Andrew Cagney
2001-02-22  5:17   ` Nick Duffek
2001-02-22  6:36     ` Fernando Nasser
2001-02-22  8:23       ` Andrew Cagney
2001-02-22  7:58     ` Andrew Cagney
2001-02-22  8:37       ` Nick Duffek
2001-02-22  9:12         ` Andrew Cagney
2001-02-22 10:15           ` Nick Duffek
2001-02-22 10:25             ` Andrew Cagney
2001-02-22 11:40               ` Eli Zaretskii
2001-02-22  8:16     ` Andrew Cagney

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=200102242351.f1ONpp704661@rtl.cygnus.com \
    --to=nsd@redhat.com \
    --cc=Dautrevaux@microprocess.com \
    --cc=gdb@sources.redhat.com \
    --cc=insight@sources.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).