All of lore.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
	dent@cosy.sbg.ac.at, adilger@clusterfs.com, da-x@gmx.net,
	patch@luckynet.dynu.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.5.21 - list.h cleanup
Date: Tue, 11 Jun 2002 07:52:56 -0700	[thread overview]
Message-ID: <3D060EC8.321A0D66@mvista.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0206110128130.1987-100000@home.transmeta.com>

Linus Torvalds wrote:
> 
> On Tue, 11 Jun 2002, Rusty Russell wrote:
> >
> > Worst sin is that you can't predeclare typedefs.  For many uses (not the
> > list macros of course):
> >       struct xx;
> > is sufficient and avoids the #include hell,
> 
> True.
> 
> However, that only works for function declarations.
> 
> typedefs are easy to avoid.
> 
> The real #include hell comes, to a large degree, from the fact that we
> like inline functions. Which have many wonderful properties, but they have
> the same nasty property typedefs have: they require full type information
> and cannot be predeclared.
> 
> And while I'd like to avoid #include hell, I'm not willing to replace
> inline functions with #define's to avoid it ;^p

On wonders if it might be useful to split header files into
say for example, list_d.h and list_i.h with the declarations
in the "_d.h" and inlines in the "_i.h".  Then we could move
the "_i.h" includes to the end of the include list.  Yeah, I
know, too many includes in includes to work.  

By the way, my reading of the C standard indicates that they
don't _have to_ compile the inlines when they are found, but
_may_ defer the compile until they are referenced by
non-inline code.  This change would fix the problem.
-- 
George Anzinger   george@mvista.com
High-res-timers: 
http://sourceforge.net/projects/high-res-timers/
Real time sched:  http://sourceforge.net/projects/rtsched/
Preemption patch:
http://www.kernel.org/pub/linux/kernel/people/rml

  parent reply	other threads:[~2002-06-11 14:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-09 11:09 [PATCH][2.5] introduce list_move macros Lightweight patch manager
2002-06-09 11:23 ` Mark Zealey
2002-06-10 14:17   ` Thunder from the hill
2002-06-09 11:48 ` OGAWA Hirofumi
2002-06-09 12:02   ` Thomas 'Dent' Mirlacher
2002-06-09 12:01 ` Russell King
2002-06-09 12:42 ` [PATCH][2.5] introduce list_move macros (revisited) Lightweight patch manager
2002-06-10 15:14   ` Dan Aloni
2002-06-10 15:28   ` [PATCH] 2.5.21 - list.h cleanup Dan Aloni
2002-06-10 15:45     ` Thunder from the hill
2002-06-10 16:37     ` Andreas Dilger
2002-06-10 16:50       ` Thomas 'Dent' Mirlacher
2002-06-10 17:02         ` Linus Torvalds
2002-06-10 17:07           ` Thomas 'Dent' Mirlacher
2002-06-10 17:21             ` Linus Torvalds
2002-06-11  8:00               ` Rusty Russell
2002-06-11  8:33                 ` Linus Torvalds
2002-06-11  8:48                   ` Martin Dalecki
2002-06-11  9:04                   ` Martin Dalecki
2002-06-11  9:14                   ` Rusty Russell
2002-06-12 19:45                     ` Ingo Molnar
2002-06-13  5:51                       ` Rusty Russell
2002-06-13 14:18                         ` Ingo Molnar
2002-06-11 14:52                   ` george anzinger [this message]
2002-06-11 16:03                     ` Daniel Phillips
2002-06-12  1:10                     ` Rusty Russell
2002-06-12  1:29                       ` Linus Torvalds
2002-06-12  6:02                         ` Rusty Russell
2002-06-12  7:11                         ` Martin Dalecki
2002-06-12  7:27                           ` Andrew Morton
2002-06-11 17:54                   ` Gerrit Huizenga
2002-06-12  3:49                     ` Rusty Russell
2002-06-12 17:30                       ` Gerrit Huizenga
2002-06-10 17:26           ` Manik Raina
2002-06-10 17:51           ` Dan Aloni
2002-06-10 21:28     ` Thunder from the hill

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=3D060EC8.321A0D66@mvista.com \
    --to=george@mvista.com \
    --cc=adilger@clusterfs.com \
    --cc=da-x@gmx.net \
    --cc=dent@cosy.sbg.ac.at \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patch@luckynet.dynu.com \
    --cc=rusty@rustcorp.com.au \
    --cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.