comp.lang.c - 25 new messages in 5 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* What is on topic here - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/a91a80117d377f7f?hl=en
* Experiment: functional concepts in C - 16 messages, 7 authors
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
* A tool that suggests optimized logic for a piece of code/module/function - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/8dc0c7e3c216aa24?hl=en
* The #include directive - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/b037b9e374cda1b0?hl=en
* OT: Real Programmers drink ... - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/25280f3feeb4a199?hl=en

==============================================================================
TOPIC: What is on topic here
http://groups.google.com/group/comp.lang.c/t/a91a80117d377f7f?hl=en
==============================================================================

== 1 of 4 ==
Date: Mon, Jan 25 2010 2:36 pm
From: Nick <3-nospam@temporary-address.org.uk>

lacos@ludens.elte.hu (Ersek, Laszlo) writes:

> In article <87vdepvr3t.fsf@temporary-address.org.uk>, Nick <3-nospam@temporary-address.org.uk> writes:
>> Seebs <usenet-nospam@seebs.net> writes:
>>
>>> The big win for me has been compound literals, actually. I love them.
>>> Very handy, very idiomatic.
>>
>> Good point. I don't use them a lot, but where I do they are great.
>> Particularly for some of those strange unix functions like setitimer. I
>> used one to great effect there (I had one parameter that came to my
>> function, all the rest being pre-defined).
>
> In my opinion, that's not portable, unless you combine the compound
> literal with designated initializers.

Well obviously it's not portable, that's why it's in my "adjust this bit
of code depending on your system file".

Really, though, thanks for that. I think you're right, it's not even
portable across SUS systems. Shame!
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

== 2 of 4 ==
Date: Mon, Jan 25 2010 2:39 pm
From: Seebs

On 2010-01-25, Anand Hariharan <mailto.anand.hariharan@gmail.com> wrote:
> Jacob's wording relating to make was "makefile problems related to the
> building of a c program". I fully support that.

I don't.

Let me explain why.

I am trying to build a C program.

As part of that process, I need to debug the following hunk of GNU make
code:

$$(foreach i,$$($(1)_LDAT_indexes),@$$(foreach j,$$(wordlist $$(word $$i,$$($(1)_LDAT_starts)),$$(word $$i,$$($(1)_LDAT_ends)),$$($(1)_LDAT_list)),$$(call $(1),$$j) ; )$$(LDAT_nl))

This is absolutely in the path I use to end up causing make to invoke a C
compiler. I'm pretty sure, though, that it hasn't got a thing to do with
C.[*]

> Header file and source code organisation should be (is?) very much
> topical, and 'make' pertaining to C is fundamentally tied to how
> source files depend upon one another.

I don't think so; see above.

> I for one do not know where to ask "How do I setup the makefile to
> resolve a cyclic dependency between P.h and Q.h?" or "'make' does not
> trigger a build of X.c when I changed file Y.h. How do I determine
> what all source file X.c depends upon?", or "make triggers rebuilding
> source that is up to date" and so on. Answers to such questions can
> come only from experience and most definitely /not/ found in the
> standard.

If I were running into stuff like that, I'd probably ask in
comp.unix.programmer, if I were using make on a UNIX system... and if
I weren't, I'd probably want a group where people were likely to be using
the same "make" I was.

-s
[*] It is part of the solution to the general question "what do you do if you
want to expand a macro for each item in a large list, but the resulting
expansion may exceed the allowed length of a shell command, but you don't
want to start a separate shell for each item in the list".
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 3 of 4 ==
Date: Mon, Jan 25 2010 2:40 pm
From: Seebs

On 2010-01-25, Ersek, Laszlo <lacos@ludens.elte.hu> wrote:
> In my opinion, that's not portable, unless you combine the compound
> literal with designated initializers.

Right.

But designated initializers are in there too, and as a result, I saved
a ton of time and visual complexity in some otherwise hairy code.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 4 of 4 ==
Date: Mon, Jan 25 2010 4:40 pm
From: gazelle@shell.xmission.com (Kenny McCormack)

In article <lnvdepzyth.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.org> wrote:
...
>Note that this is a least as much about helping questioners find the
>best possible answers as it is about maintaining a good signal/noise
>ratio here in clc.

Actually, Keith, it has to be (superficially, i.e., in terms of what you
will publicly admit) *entirely* a matter of "helping questioners" (i.e.,
newbies) "find the best possible answers" to their questions. Because
if it were about (to any extent at all) "maintaining a good signal/noise
ratio here in clc", then you'd have to apply these standards to the
regs.

And that clearly doesn't happen (and never will). The regs are
(obviously) free to yack and yammer about whatever they want, and you'll
never complain at all.

==============================================================================
TOPIC: Experiment: functional concepts in C
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
==============================================================================

== 1 of 16 ==
Date: Mon, Jan 25 2010 2:36 pm
From: Paul Rubin

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> A function returns a value that is passed to another
> function, say
>
> print( read() )

I once wrote an embedded lisp interpreter where you'd write
something like

Lisp_value f() {
mark();
...
print (wrap (read()));
...
release ();
}

Basically the interpreter had a stack of values protected from garbage
collection. wrap(...) would push a value onto the stack and return the
same value. mark() would save a "frame pointer" and push the old frame
pointer onto the stack, and release() would pop back to the saved frame
pointer. Throwing an exception would pop the stack back to the frame
pointer saved by the exception handler. So that temporary value
returned by read() would be protected through the dynamic context of
f(), and of course saving any further references would make it reachable
by gc. This really wasn't too bad. If you wanted to use read/print in
a loop you could put the value in a mutable cell in order to avoid
unwanted stack growth, something like:

Lisp_value x = Nil;
wrap_ref(&x);
for (...) {
x = read();
print (x);
}

> - When parts of the argument structure are shared,
> they possibly should not be freed.
>
> - A client of »print« might pass in objects with
> static or automatic storage duration, which
> should not be freed at all.

Well sure, but such sharing would be discovered by a tracing gc.

> In the end, one might invest more time in thinking about
> memory management than about the actual programming problem.

Maybe for a high performance system. The simple-minded thing that I did
was fairly easy to use and worked reliably, though I guess it
may have had some efficiency shortcomings, and couldn't have handled
an evaluation model that allowed (e.g.) saved continuations.

== 2 of 16 ==
Date: Mon, Jan 25 2010 2:55 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)

Paul Rubin <no.email@nospam.invalid> writes:
>Well sure, but such sharing would be discovered by a tracing gc.

Yes, the whole point of my post is that C usually does
/not have/ a GC. So I infer that functional programming,
therefore, is difficult or nearly impossible (beyond a
certain level of complexity) in C.

== 3 of 16 ==
Date: Mon, Jan 25 2010 3:05 pm
From: jacob navia

Stefan Ram a écrit :
> Ertugrul =?UTF-8?B?U8O2eWxlbWV6?= <es@ertes.de> writes:
>> I thought it would be funny to try to bring functional
>> concepts into the C language.
>
> To me, a lack of automatic memory management makes
> functional programming difficult in C.
>

snip...
>
> In the end, one might invest more time in thinking about
> memory management than about the actual programming problem.
>
> So, I believe, this is the real problem, when one tries
> to do functional programming in C.
>

It depends what "C" you are using.

lcc-win proposes a garbage collector in its standard distribution.
All the problems above are solved with a gc

== 4 of 16 ==
Date: Mon, Jan 25 2010 3:08 pm
From: jacob navia

Stefan Ram a �crit :
> Paul Rubin <no.email@nospam.invalid> writes:
>> Well sure, but such sharing would be discovered by a tracing gc.
>
> Yes, the whole point of my post is that C usually does
> /not have/ a GC. So I infer that functional programming,
> therefore, is difficult or nearly impossible (beyond a
> certain level of complexity) in C.
>

I have been proposing a garbage collector forC since 2004. The
garbage collector is a part of thestandard lcc-win distribution.

The same collector is available for most workstation environments.

jacob

== 5 of 16 ==
Date: Mon, Jan 25 2010 3:12 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)

jacob navia <jacob@nospam.org> writes:
>It depends what "C" you are using.

I thought about something along the lines of
ISO/IEC 9899:1999 (E).

== 6 of 16 ==
Date: Mon, Jan 25 2010 3:21 pm
From: jacob navia

Stefan Ram a écrit :
> jacob navia <jacob@nospam.org> writes:
>> It depends what "C" you are using.
>
> I thought about something along the lines of
> ISO/IEC 9899:1999 (E).
>
The gc is a library, like a graphics library or a network library.

Are you implying that you can't do network programming in C because "network" doesn't appear in the
standard?

The standard doesn't speak a word about graphics either. You can't do graphics in C then?

Your viewpoint of limiting C to what is explicitly said in the standard is just another way of the old:

"You can't do anything serious in C"

and then (implicitly)

"Use C++" or whatever

== 7 of 16 ==
Date: Mon, Jan 25 2010 3:22 pm
From: ld

On 25 jan, 23:55, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Paul Rubin <no.em...@nospam.invalid> writes:
> >Well sure, but such sharing would be discovered by a tracing gc.
>
>   Yes, the whole point of my post is that C usually does
>   /not have/ a GC. So I infer that functional programming,
>   therefore, is difficult or nearly impossible (beyond a
>   certain level of complexity) in C.

I have already answered to this kind of question recently. You don't
need a GC, just a richer set of ownership rules. In the C Object
System (100% C lib) I use new, delete and autoDelete (delayed delete)
for object creation/destruction and retain, release and autoRelease
(delayed release) for object ownership. The reason why there is a
difference between creation and ownership comes from the possibility
to convert a posteriori an existing code back and forth to something
semi-gc where all new do an autoDelete and no delete are required from
the user (and obviously the rule does not apply to retain/release life-
cycle). Since I have adopted these rules with _local_ balance (new <->
delete/autoDelete, retain <-> release/autoRelease), I don't have
anymore memory leaks.

Once you have ownership, you need few more concepts to be able to
program in C as you would in Lisp (and beyond). Another (big) step is
the implementation of generic closures (high order functions and high
order messages) and there you need the full expressive power of COS...

cheers,

ld.

== 8 of 16 ==
Date: Mon, Jan 25 2010 3:31 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)

jacob navia <jacob@nospam.org> writes:
>Are you implying that you can't do network programming in C
>because "network" doesn't appear in the standard?

Given only an implementation of ISO/IEC 9899:1999 (E),
you can not do this. I wrote something about this with C++
in mind, but it applies to C as well:

http://www.purl.org/stefan_ram/pub/c++_standard_extensions_en

>"Use C++" or whatever

The problems apply to C++ as well, but not to Java, because
Java has a GC and a network library /in its standard J2EE/.

== 9 of 16 ==
Date: Mon, Jan 25 2010 3:33 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)

ld <laurent.deniau@gmail.com> writes:
>I have already answered to this kind of question recently.
>You don't need a GC, just a richer set of ownership rules.

Yes, please give me the URI of this set!

== 10 of 16 ==
Date: Mon, Jan 25 2010 3:36 pm
From: Keith Thompson

jacob navia <jacob@nospam.org> writes:
[...]
> Your viewpoint of limiting C to what is explicitly said in the
> standard is just another way of the old:
>
> "You can't do anything serious in C"
>
> and then (implicitly)
>
> "Use C++" or whatever

You wouldn't be waging a campaign against C99, would you?

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 11 of 16 ==
Date: Mon, Jan 25 2010 3:44 pm
From: ld

On 26 jan, 00:33, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> ld <laurent.den...@gmail.com> writes:
> >I have already answered to this kind of question recently.
> >You don't need a GC, just a richer set of ownership rules.
>
>   Yes, please give me the URI of this set!

I mentioned the list of messages in my post. You can find the semantic
explanation in the paper

http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos-draft-dls09.pdf

or in the slides

http://cos.cvs.sourceforge.net/viewvc/cos/doc/slides-cos.pdf

You can also read the doc on ownership and memory management from the
Apple dev center since they use autoRelease pools for more than a
decade in Cocoa (and still nowadays despite of the introduction of the
GC with Objective-C 2.0).

The code can be browsed on the cvs repository (things in CosBase are
stable but on CosStd and CosExt are unstable).

cheers,

ld.

== 12 of 16 ==
Date: Mon, Jan 25 2010 7:04 pm
From: Paul Rubin

ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>Well sure, but such sharing would be discovered by a tracing gc.
>
> Yes, the whole point of my post is that C usually does
> /not have/ a GC. So I infer that functional programming,
> therefore, is difficult or nearly impossible (beyond a
> certain level of complexity) in C.

The functional programming would only work on a certain class of objects
within the C program, that are collected by an internal gc. Sometimes
what this leads to is called "Greenspun's Tenth Law" ;-).

There are also so-called conservative gc's for C and C++ (that treat all
data words as possible heap pointers) but at least as a matter of
principle, those can be considered unsatisfying.

Anyway I came late into this thread, but I don't think anyone was
proposing to embed Haskell as cpp macros or anything like that ;-). The
idea is just that it's possible for one's C programs to be influenced by
functional style, and to implement some nontrivial functional constructs
through a few coding disciplines supported by some utility functions.

== 13 of 16 ==
Date: Mon, Jan 25 2010 7:47 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)

ld <laurent.deniau@gmail.com> writes:
>>>You don't need a GC, just a richer set of ownership rules.
>>Yes, please give me the URI of this set!
>http://cos.cvs.sourceforge.net/viewvc/cos/doc/cos-draft-dls09.pdf

This seems to be a library that either uses garbage collection
or user aided reference counting.

I was hoping for ownership rules for plain C objects or
linked C data structures.

C does not have a garbage collector.

A reference counter is an additional subobject that must be
added to all objects to be managed in this way.

This URI list rules for reference counting with COM (using
"AddRef" and "Release"):

http://en.wikipedia.org/wiki/Component_Object_Model#Reference_counting

And this URI lists some of the problems with reference counting:

http://en.wikipedia.org/wiki/Component_Object_Model#Reference_counting_2

Another URI:

"Bugs caused by incorrect reference counting in COM
systems are notoriously hard to resolve"

http://en.wikipedia.org/wiki/Reference_counting#COM

I believe having read that problems with reference counting
are a reason, why COM does not get so much support from
Microsoft anymore, while many major Windows applications
still use COM. I can not find a direct source for this,
but the following goes into this direction:

»The messiness of COM (Component Object Model) is
removed. (...) .NET addresses many of the shortfalls of
COM, including (...) reference counting (...)«

»The developer controls the lifetime of a COM object.
AddRef and Release live in infamy. They are methods of
the IUnknown interface and control the persistence of
the COM object. If implemented incorrectly, a COM object
could be released prematurely or, conversely, never be
released and be the source of memory leaks. The .NET
memory manager, appropriately named the Garbage
Collector, is responsible for managing component
lifetimes for the application - no more AddRef and Release.«

http://www.codeguru.com/csharp/sample_chapter/article.php/c8245/

== 14 of 16 ==
Date: Mon, Jan 25 2010 8:25 pm
From: "BGB / cr88192"

"Paul Rubin" <no.email@nospam.invalid> wrote in message
news:7x7hr5va65.fsf@ruckus.brouhaha.com...
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>>Well sure, but such sharing would be discovered by a tracing gc.
>>
>> Yes, the whole point of my post is that C usually does
>> /not have/ a GC. So I infer that functional programming,
>> therefore, is difficult or nearly impossible (beyond a
>> certain level of complexity) in C.
>
> The functional programming would only work on a certain class of objects
> within the C program, that are collected by an internal gc. Sometimes
> what this leads to is called "Greenspun's Tenth Law" ;-).
>
> There are also so-called conservative gc's for C and C++ (that treat all
> data words as possible heap pointers) but at least as a matter of
> principle, those can be considered unsatisfying.
>

yeah.
they can tend to be slow and unreliable, and can be rather ill-behaved for
certain usage patterns...

ideally, it would be preferable to avoid a conservative GC (and instead use
precise GC), but alas, for C, this leads to far too much hassle/overhead
(having to mess with registering and unregistering roots, ...).

the JVM seem to use an alternate strategy for JNI:
references are "local" or "global", where local references have a
constrained lifespan (and may be destroyed after the JNI method returns).

for C, I have ended up developing a sort of pseudo-GC strategy (used mostly
in my compiler internals), where the allocator just sort of naively
allocates from sliding buffers, which may be destroyed/reused when done.

any data to preserved then is, manually, copied elsewhere (although, more
often, it is just discarded, with the result having been "transcribed" into
a different form).
if made automatic, I guess this would be a sort of crude copy-collector.

OTOH, this could be made into a "semi-automatic" API, whereby one could
instruct the system to copy the data, but it goes about the actual logistics
of doing so (likely with the help of user-registered "copy" handlers). (in
the "manual" strategy, usually type-specific data-copying functions are
written for any data needing to be copied...).

but, anyways, the main advantage of this strategy is that it does well for
the usage patterns which seem to pop up in my compiler: producing large
volumes of objects in short bursts, which almost all turn into garbage.

this particular usage-cases tend to kill my main GC (which tends to work
best with a gradual accumulation of garbage at a relatively low rate).

> Anyway I came late into this thread, but I don't think anyone was
> proposing to embed Haskell as cpp macros or anything like that ;-). The
> idea is just that it's possible for one's C programs to be influenced by
> functional style, and to implement some nontrivial functional constructs
> through a few coding disciplines supported by some utility functions.

yeah.
Haskell mixed in with C would be nasty...

well, of note:
I do have support for a "closure" facility in my case (via an API call).

however, I haven't really exactly used it much (except in a few edge cases
where it was needed), and generally it would require manually "capturing"
the bindings in the form of a heap-allocated struct (or similar).

so, in general, it has neither the grace nor the elegance of the FP
analogue.

it tends to be actually more usable just to pass an object with the funtion
embedded in a function pointer (even though) you can't simply call this as
if it were a function pointer. this tends actually to be a lot more
convinient, as well as being faster (via lack of crufty "transfer thunks")
and typically generating less garbage...

== 15 of 16 ==
Date: Mon, Jan 25 2010 10:26 pm
From: jacob navia

Stefan Ram a écrit :
>
> C does not have a garbage collector.
>

Many things are left for system libraries, like graphics, network,
garbage collectors, and many other things like (for instance)
directory access, thread management, multiprocessing etc.

All of this can be done in C if you do not arbitrarily restrict
the language to the minimal subset as you are trying to do here.

I have promoted and distributed a garbage collector for C since
several years. People like you (and the other "regs") have always
fought this, so your attitude is not surprising.

What is surprising is that now you refuse even to acknowledge that
a widely distributed implementation of gc exists, and it is used.

Your argument that "it is not part of the text of the standard"
is just ridiculous. The "C" of the standard is not even able to
use a directory effectively and there is NO serious software in C
that uses that minimal subset.

With your attitude there is no software written in C.

== 16 of 16 ==
Date: Mon, Jan 25 2010 10:37 pm
From: jacob navia

Stefan Ram a écrit :
>
> http://en.wikipedia.org/wiki/Reference_counting#COM
>
> I believe having read that problems with reference counting
> are a reason, why COM does not get so much support from
> Microsoft anymore, while many major Windows applications
> still use COM. I can not find a direct source for this,
> but the following goes into this direction:
>
> »The messiness of COM (Component Object Model) is
> removed. (...) .NET addresses many of the shortfalls of
> COM, including (...) reference counting (...)«
>
> »The developer controls the lifetime of a COM object.
> AddRef and Release live in infamy. They are methods of
> the IUnknown interface and control the persistence of
> the COM object. If implemented incorrectly, a COM object
> could be released prematurely or, conversely, never be
> released and be the source of memory leaks. The .NET
> memory manager, appropriately named the Garbage
> Collector, is responsible for managing component
> lifetimes for the application - no more AddRef and Release.«
>
> http://www.codeguru.com/csharp/sample_chapter/article.php/c8245/
>

That is why lcc-win proposes a garbage collector, because is the only
sensible solution.

Obviously your agenda is just to demonstrate that C is unable to do
anything. Granted. Go ahead. But you aren't confusing anyone.

==============================================================================
TOPIC: A tool that suggests optimized logic for a piece of code/module/
function
http://groups.google.com/group/comp.lang.c/t/8dc0c7e3c216aa24?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 9:20 pm
From: karthikbalaguru

On Jan 25, 5:31 am, toby <t...@telegraphics.com.au> wrote:
> On Jan 11, 3:07 pm, karthikbalaguru <karthikbalagur...@gmail.com>
> wrote:
>
> > Hi,
> > There are certain editors that highlight
> > the syntax/color for datatypes/variables
> > or comments etc.
>
> > Similarly,
> > Is there a tool for C language that
> > could suggest an optimized/alternate
> > programming logic for the function that
> > is written ?
>
> IMHO the most effective output it could make is: "Are you really sure
> the best tool for this task is C?"
>

My query is 'A tool that suggests
optimized logic for a piece of
code/module/function' . I am
looking for a tool that suggests
optimized logic for various
modules/functions written in
C language.
The tool can be made of any
language.

>
> > The optimized/alternate logic can be
> > suggested as soon as we finish coding
> > for one function or it can be suggested
> > as soon as the code is compiled/parsed
> > by that tool.
>
> > It will be even more helpful if that tool
> > also provides the cycle counts, cache
> > usage, cache misses and lines of code
> > also.
>
> > It would be better if that tool has an
> > option to enable / disable this feature
> > either through compile time or some
> > other configurations.
>
> > Any ideas ?
>
> > Thx in advans,
> > Karthik Balaguru- Hide quoted text -
>
> - Show quoted text -

Karthik Balaguru

==============================================================================
TOPIC: The #include directive
http://groups.google.com/group/comp.lang.c/t/b037b9e374cda1b0?hl=en
==============================================================================

== 1 of 3 ==
Date: Mon, Jan 25 2010 10:32 pm
From: frank

On Jan 24, 4:26 am, Flash Gordon <s...@spam.causeway.com> wrote:

> Footnote 1: System includes need not actually be files, but the effect
> is always the same.

If they're not necessarliy files, what can they be?
--
frank

== 2 of 3 ==
Date: Mon, Jan 25 2010 10:50 pm
From: Keith Thompson

frank <abqhandyman@gmail.com> writes:
> On Jan 24, 4:26 am, Flash Gordon <s...@spam.causeway.com> wrote:
>
>> Footnote 1: System includes need not actually be files, but the effect
>> is always the same.
>
> If they're not necessarliy files, what can they be?

Anything.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

== 3 of 3 ==
Date: Mon, Jan 25 2010 10:55 pm
From: frank

On Jan 24, 6:52 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 1/24/2010 5:22 AM, jacob navia wrote:

> > This directive has two variants:
> > The first uses angle brackets to enclose the name of the file to include.
> > #include <stdio.h>
> > The second uses quotes to enclose the file name:
> > #include "myfile.h"
>
>      ... and the third of the two is described in 6.10.2p4.
> After macro substitution it must resolve to one of the other
> two forms, so the third form might be considered "transitory"
> or "evanescent" or something, but it deserves at least a
> footnote.

4 A preprocessing directive of the form
# include pp-tokens new-line
(that does not match one of the two previous forms) is permitted. The
preprocessing
tokens after include in the directive are processed just as in normal
text. (Each
identifier currently defined as a macro name is replaced by its
replacement list of
preprocessing tokens.) The directive resulting after all replacements
shall match one of
the two previous forms.148) The method by which a sequence of
preprocessing tokens
between a < and a > preprocessing token pair or a pair of " characters
is combined into a
single header name preprocessing token is implementation-defined.

Apparently pp-tokens is the output from a preprocessor. I think I've
figured out why #includes don't just include files. Doesn't cpp hand
gcc a bunck of tokens that aren't in any file?

==============================================================================
TOPIC: OT: Real Programmers drink ...
http://groups.google.com/group/comp.lang.c/t/25280f3feeb4a199?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Jan 25 2010 11:42 pm
From: gwowen

On Jan 25, 8:44 pm, ralt...@xs4all.nl (Richard Bos) wrote:
> That depends. I know that the Irish are almost and the Scots not quite
> as tea-expertised as the Sais, but I know little or nothing of the
> bibulous habits of the Welsh, as I assume you from your name to be.

We exist solely on coal, Brains Beer and the charitable munificence of
Russell T. Davis.

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en