Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@cygnus.com>
To: Nick Duffek <nsd@redhat.com>
Cc: gdb@sources.redhat.com, insight@sources.redhat.com
Subject: Re: Register group proposal
Date: Thu, 22 Feb 2001 09:12:00 -0000	[thread overview]
Message-ID: <3A9547ED.E7CFE51C@cygnus.com> (raw)
In-Reply-To: <200102221645.f1MGjUu03076@rtl.cygnus.com>

Nick Duffek wrote:

> I've noticed, and I've spent time scratching my head over why structs are
> used in various places.

A struct is a poor persons opaque object.

> >Regarding typedefs.  Per my e-mail
> > http://sources.redhat.com/ml/gdb-patches/2001-02/msg00325.html it
> >encouraging a tangled web of includes.
> 
> The example you quoted in that email:
> 
>    Try declaring something like:
> 
>        xyz.h:
>            struct xyz;
>            exter void xyz_foo (struct xyz *self, ...);
> 
>        abc.h:
>            struct xyz;
>            struct abc;
>            extern abc_on_xyz (struct abc *self, struct xyz *on);
> 
>    using typedefs.  It ends up creating include spaghetti :-(
> 
> is very easy to declare using typedefs.  Here's abc.h:

Hmm, I think like MichaelC you may have missed the point.

> is very easy to declare using typedefs.  Here's abc.h:
> 
>    #include "xyz.h"
> 
>    typedef struct {
>      int i;
>    } Abc;
> 
>    extern int abc_on_xyz (Abc *self, Xyz *on);

And that illustrates the problem - why should "abc.h" suck in "xyz.h"
when clients of "abc.h" may not use any of "xyz"'s methods.  If a file
needs to use the method ``xyz_foo()'' then that file should explicitly
include "xyz.h".

It is actually a shame that libremote isn't yet available (yes it is
being worked on ...) Its architecture has everything implemented as
opaque objects.  The header files that define the exported interface are
all fully independant of each other - you don't need to include "abc.h"
to use "xyz.h" and conversely including "abc.h" doesn't quietly suck in
"xyz.h" when its methods are not being used.

> Do we have an official policy prohibiting typedefs in include files?

Using typedefs for things like function declarations? No.

The use of ``typedef struct'' in new interfaces, however, is strongly
discouraged.  You'll notice that all the recently added interfaces have
followed the convention:

	<OBJECT>.h
		struct <OBJECT>;
		<OBJECT>_method (struct <OBJECT> *);

enjoy,
	Andrew


  reply	other threads:[~2001-02-22  9:12 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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
     [not found]     ` <200102221237.f1MCbtX02766@rtl.cygnus.com>
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 [this message]
2001-02-22 10:15           ` Nick Duffek
2001-02-22 10:25             ` Andrew Cagney
2001-02-22 11:40               ` Eli Zaretskii
2001-02-22 11:02           ` Kevin Buettner
2001-02-22 12:08             ` Andrew Cagney
2001-02-22  8:16     ` Andrew Cagney
2001-02-21  3:00 Stephane Carrez
2001-02-21  7:00 ` Nick Duffek
2001-02-21  9:34 ` Andrew Cagney
2001-02-22  9:19 Michael Elizabeth Chastain
2001-02-23  2:52 Bernard Dautrevaux
2001-02-24 15:43 ` Nick Duffek
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
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-27  8:53         ` Christopher Faylor
2001-02-27  9:57           ` Andrew Cagney
2001-02-28  1:59 Bernard Dautrevaux

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=3A9547ED.E7CFE51C@cygnus.com \
    --to=ac131313@cygnus.com \
    --cc=gdb@sources.redhat.com \
    --cc=insight@sources.redhat.com \
    --cc=nsd@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