Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #76081 > unrolled thread

Array manipulation techniques

Back to article view | Back to comp.lang.c

Contents

  Array manipulation techniques "Morten W. Petersen" <morphex@gmail.com> - 2015-11-15 09:44 +0100
    Re: Array manipulation techniques Barry Schwarz <schwarzb@dqel.com> - 2015-11-15 01:56 -0800
      Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-15 10:43 -0800
        Re: Array manipulation techniques Chad <cdalten@gmail.com> - 2015-11-15 10:54 -0800
          Re: Array manipulation techniques Ian Collins <ian-news@hotmail.com> - 2015-11-16 08:13 +1300
            Re: Array manipulation techniques Chad <cdalten@gmail.com> - 2015-11-15 12:50 -0800
          Re: Array manipulation techniques Les Cargill <lcargill99@comcast.com> - 2015-11-15 14:07 -0600
        Re: Array manipulation techniques Barry Schwarz <schwarzb@dqel.com> - 2015-11-15 15:12 -0800
    Re: Array manipulation techniques glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-15 09:57 +0000
    Re: Array manipulation techniques Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-15 03:02 -0800
    Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 12:02 -0800
      Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 12:05 -0800
        Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 12:28 -0800
          Re: Array manipulation techniques Chad <cdalten@gmail.com> - 2015-11-15 12:48 -0800
          Re: Array manipulation techniques Geoff <geoff@invalid.invalid> - 2015-11-15 17:05 -0800
            Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-15 19:09 -0800
            Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 22:52 -0800
              Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 23:00 -0800
                Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 07:17 +0000
                  Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-15 23:41 -0800
                    Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 07:47 +0000
                      Re: Array manipulation techniques David Brown <david.brown@hesbynett.no> - 2015-11-16 09:51 +0100
                        Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 16:49 +0000
                  Re: Array manipulation techniques BartC <bc@freeuk.com> - 2015-11-16 11:10 +0000
                    Re: Array manipulation techniques Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 03:33 -0800
                      Re: Array manipulation techniques Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 13:09 +0000
                        Re: Array manipulation techniques Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 05:59 -0800
                          Re: Array manipulation techniques Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 15:22 +0000
                    Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 16:57 +0000
                    Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-16 10:29 -0800
                      Re: Array manipulation techniques David Brown <david.brown@hesbynett.no> - 2015-11-17 09:02 +0100
                        Re: Array manipulation techniques BartC <bc@freeuk.com> - 2015-11-17 10:46 +0000
                        Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-17 07:05 -0800
                          Re: Array manipulation techniques David Brown <david.brown@hesbynett.no> - 2015-11-17 16:47 +0100
                            Re: Array manipulation techniques supercat@casperkitty.com - 2015-11-17 12:33 -0800
                Development Best Practices and C "nomenclature" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-16 12:15 -0500
                  Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 10:33 -0800
                    Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 10:51 -0800
                      Re: Development Best Practices and C "nomenclature" "Morten W. Petersen" <morphex@gmail.com> - 2015-11-16 20:14 +0100
                        Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 11:28 -0800
                          Re: Development Best Practices and C "nomenclature" "Morten W. Petersen" <morphex@gmail.com> - 2015-11-17 00:20 +0100
                        Re: Development Best Practices and C "nomenclature" David Brown <david.brown@hesbynett.no> - 2015-11-17 10:03 +0100
                          Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-17 08:54 -0800
                            Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-17 20:12 +0000
                              Re: Development Best Practices and C "nomenclature" Robert Wessel <robertwessel2@yahoo.com> - 2015-11-17 23:38 -0600
                                Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-18 08:22 +0000
                      Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 20:25 +0000
                      Re: Development Best Practices and C "nomenclature" Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-11-16 16:20 -0500
                        Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-16 13:28 -0800
                        Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 21:30 +0000
                        Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 14:38 -0800
                          Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-16 14:52 -0800
                            Re: Development Best Practices and C "nomenclature" asetofsymbols@gmail.com - 2015-11-17 22:51 -0800
                              Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-18 06:59 +0000
                    Re: Development Best Practices and C "nomenclature" Richard Heathfield <rjh@cpax.org.uk> - 2015-11-16 20:24 +0000
                    Re: Development Best Practices and C "nomenclature" David Brown <david.brown@hesbynett.no> - 2015-11-17 09:55 +0100
                      Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-17 23:00 +0000
                  Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:55 +0000
                    Re: Development Best Practices and C "nomenclature" Ian Collins <ian-news@hotmail.com> - 2015-11-18 12:07 +1300
                      Re: Development Best Practices and C "nomenclature" James Kuyper <jameskuyper@verizon.net> - 2015-11-17 18:45 -0500
                        Re: Development Best Practices and C "nomenclature" David Brown <david.brown@hesbynett.no> - 2015-11-18 15:50 +0100
                          Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-18 08:39 -0800
                            Re: Development Best Practices and C "nomenclature" Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:07 -0800
                              Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-20 14:16 -0800
                                [OT] Re: Development Best Practices and C "nomenclature" Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 17:30 -0500
                                  Re: [OT] Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-20 19:29 -0800
                                  Re: [OT] Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-21 22:44 +0000
                            Re: Development Best Practices and C "nomenclature" jacobnavia <jacob@jacob.remcomp.fr> - 2015-11-22 00:09 +0100
                              Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-21 15:57 -0800
                                Re: Development Best Practices and C "nomenclature" James Kuyper <jameskuyper@verizon.net> - 2015-11-21 20:49 -0500
                                  Re: Development Best Practices and C "nomenclature" Rosario19 <Ros@invalid.invalid> - 2015-11-25 10:13 +0100
                                    Re: Development Best Practices and C "nomenclature" "J. Clarke" <j.clarke.873638@gmail.com> - 2015-11-25 18:58 -0500
                                      Re: Development Best Practices and C "nomenclature" Rosario19 <Ros@invalid.invalid> - 2015-11-26 12:13 +0100
                                        Re: Development Best Practices and C "nomenclature" "J. Clarke" <j.clarke.873638@gmail.com> - 2015-11-26 07:22 -0500
                                Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-22 14:51 +0000
                                  Re: Development Best Practices and C "nomenclature" "Charles Richmond" <numerist@aquaporin4.com> - 2015-11-23 15:53 -0600
                          Re: Development Best Practices and C "nomenclature" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-18 08:55 -0800
                            Re: Development Best Practices and C "nomenclature" Keith Thompson <kst-u@mib.org> - 2015-11-18 09:17 -0800
                          Re: Development Best Practices and C "nomenclature" James Kuyper <jameskuyper@verizon.net> - 2015-11-18 13:19 -0500
                          Re: Development Best Practices and C "nomenclature" raltbos@xs4all.nl (Richard Bos) - 2015-11-20 11:32 +0000
                  Re: Development Best Practices and C "nomenclature" Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:17 -0800
                    Re: Development Best Practices and C "nomenclature" glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-21 07:08 +0000
                      Re: Development Best Practices and C "nomenclature" Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-22 13:52 -0800
        Re: Array manipulation techniques Geoff <geoff@invalid.invalid> - 2015-11-15 17:03 -0800
      Re: Array manipulation techniques Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-15 15:09 -0500
      Re: Array manipulation techniques Richard Heathfield <rjh@cpax.org.uk> - 2015-11-15 21:47 +0000
      Re: Array manipulation techniques Geoff <geoff@invalid.invalid> - 2015-11-15 17:02 -0800
      Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-16 10:44 -0800
        Re: Array manipulation techniques asetofsymbols@gmail.com - 2015-11-16 11:13 -0800
          Re: Array manipulation techniques Keith Thompson <kst-u@mib.org> - 2015-11-16 11:57 -0800
            Re: Array manipulation techniques Ian Collins <ian-news@hotmail.com> - 2015-11-17 10:30 +1300
          Re: Array manipulation techniques Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-17 08:11 -0500
            Re: Array manipulation techniques BartC <bc@freeuk.com> - 2015-11-17 13:24 +0000
            Re: Array manipulation techniques Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:09 -0800
              Re: Array manipulation techniques Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-11-20 16:20 -0500

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

#76677 — Re: Development Best Practices and C "nomenclature"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> For decades, I worked as a professional programmer, both developing new code
> and maintaining already-written code.  It did not take me long in my job to
> learn that
>  - Computers do not care how verbose your nomenclature is;  nomenclature only
>    (marginally) affects compile time, and /rarely/ (if ever) affects run time.
>
>  - Programmers, on the other hand, /do/ care how verbose your nomenclature is.
>    Readable code with a clear, understandable naming convention allows /any/
>    programmer conversant in the language (including the original author of the
>    code) to read, analyze and revise the code as necessary.  Often, it even
>    permits programmers who are /not/ conversant in the language to read and
>    understand the intent (if not the actual operation) of the code.
>
> Thus, from my professional standpoint, readable code is much better than
> compact code.

A problem I often have with statements like this is that they
don't really say very much.  What is "readable" to one person is
often mystifying to another person, and what is "not too compact"
to one is long-winded and overly verbose to another.  It's sort
of the programming equivalent of motherhood and apple pie.

Just an impression, not trying to start anything.

[toc] | [prev] | [next] | [standalone]

#76736 — Re: Development Best Practices and C "nomenclature"

Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
 
>> For decades, I worked as a professional programmer, both 
>> developing new code and maintaining already-written code.  
>> It did not take me long in my job to learn that
>>  - Computers do not care how verbose your nomenclature is;  

(snip)

>> Thus, from my professional standpoint, readable code is much 
>> better than compact code.
 
> A problem I often have with statements like this is that they
> don't really say very much.  What is "readable" to one person is
> often mystifying to another person, and what is "not too compact"
> to one is long-winded and overly verbose to another.  It's sort
> of the programming equivalent of motherhood and apple pie.

Yes. I suspect that what I find most readable is more compact than
many others. Partly that is from editing with a smaller window than
some others might use.  Also, it is nice for some sized code blocks
to fit on a printer page.
 
> Just an impression, not trying to start anything.

I mostly don't put multiple statements on one line, but for small
enough for() or if(), and one small statement following, I usually
put them on one line. 

-- glen

[toc] | [prev] | [next] | [standalone]

#76923 — Re: Development Best Practices and C "nomenclature"

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>
>>> For decades, I worked as a professional programmer, both 
>>> developing new code and maintaining already-written code.  
>>> It did not take me long in my job to learn that
>>>  - Computers do not care how verbose your nomenclature is;  
>
> (snip)
>
>>> Thus, from my professional standpoint, readable code is much 
>>> better than compact code.
>>
>> A problem I often have with statements like this is that they
>> don't really say very much.  What is "readable" to one person is
>> often mystifying to another person, and what is "not too compact"
>> to one is long-winded and overly verbose to another.  It's sort
>> of the programming equivalent of motherhood and apple pie.
>
> Yes.  I suspect that what I find most readable is more compact than
> many others.  Partly that is from editing with a smaller window than
> some others might use.  Also, it is nice for some sized code blocks
> to fit on a printer page.

I detest functions that don't fit on a single printed page.  It
takes a lot for me to allow such functions to pass my internal
code review.

>> Just an impression, not trying to start anything.
>
> I mostly don't put multiple statements on one line, but for small
> enough for() or if(), and one small statement following, I usually
> put them on one line.

I put "the second half" of if/for/while statements on the same
line when I think of the whole thing as expressing one thought
(and of course, when it fits).  One case that I almost always
write on a single line is an if() whose sub-statement is a
control transfer (eg, break, continue, return).

[toc] | [prev] | [next] | [standalone]

#76147

On Sun, 15 Nov 2015 12:05:39 -0800 (PST), asetofsymbols@gmail.com
wrote:

>I don't know if it is right 
>I forget to close with 0 the array

Bad code, badly obfuscated, corrected badly because the author can't
discern whether his own code is correct or not. Still untested.

[toc] | [prev] | [next] | [standalone]

#76112

On 11/15/2015 3:02 PM, asetofsymbols@gmail.com wrote:
> I don't know if it is right
> #define R return
> #define F for

     It's wrong.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#76131

On 15/11/15 20:02, asetofsymbols@gmail.com wrote:
> I don't know if it is right
> #define R return

It's already wrong.

<snip>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#76146

On Sun, 15 Nov 2015 12:02:57 -0800 (PST), asetofsymbols@gmail.com
wrote:

>I don't know if it is right 

Bad code, badly obfuscated. Untested.

[toc] | [prev] | [next] | [standalone]

#76193

asetofsymbols@gmail.com writes:
> I don't know if it is right 
> #define R return
> #define F for
[...]

Several people have told you that this is incorrect.  I'm not sure
that you understand why.

I'm not aware that there's anything actually *wrong* with your code
in the sense of violating any language rules.  The point is that
most of us will not bother reading code that uses those silly little
macro definitions.  They make the code more difficult to read, and
it simply isn't worth the effort to mentally translate R to return
and F to for as we're reading it.  You save yourself a few keystrokes
at the expense of clarity for anyone else reading your code.

If you want anyone to read  your code write it more clearly.
(And that doesn't mean "more clearly for *you*".)  If you are unwilling
to do that, you can write whatever you like, but you might as well not
bother to hit "send".

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

[toc] | [prev] | [next] | [standalone]

#76195

I do not mentally traslate R to return.
The symbols 'R' or 'return' 
in what they really mean for
the machine use only convention;
but it would be convenient the first
because is more short and allow
to use the space of the line
better for indent or show
 redundancy in code
(and allow a line to be <80 characters) 

[toc] | [prev] | [next] | [standalone]

#76198

asetofsymbols@gmail.com writes:
> I do not mentally traslate R to return.
[...]

Regardless of what you do mentally, my point is that if you use
your one-letter macros in code that you post here, you are wasting
your time (and not much of ours, since skipping to the next message
is easy enough).  I just want to make sure you're aware of that.
You have not yet acknowleged that point, and I will not spend any
more time or effort asking you to do so.

Incidentally, are you and Rosario19 the same person?

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

[toc] | [prev] | [next] | [standalone]

#76206

Keith Thompson wrote:
> asetofsymbols@gmail.com writes:
>> I do not mentally traslate R to return.
> [...]
>
> Regardless of what you do mentally, my point is that if you use
> your one-letter macros in code that you post here, you are wasting
> your time (and not much of ours, since skipping to the next message
> is easy enough).  I just want to make sure you're aware of that.
> You have not yet acknowleged that point, and I will not spend any
> more time or effort asking you to do so.

Is it worth arguing with one who can't even form a Usenet post?

> Incidentally, are you and Rosario19 the same person?

That an other aliases...

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#76238

On 11/16/2015 2:13 PM, asetofsymbols@gmail.com wrote:
> I do not mentally traslate R to return. [...]

     This fragment convinces me that there may be, after all, some
value in asetofsymbols' approach: Perhaps it can ease the tedious
task of proofreading.  Proofreading is *hard*, because the brain is
trained to correct errors on the fly, for all the world like a hard
drive's firmware applying ECC to a noisy signal.  The brain supplies
the missing N above, and it takes serious effort to notice that it's
actually not there.

     Proofreading is particularly difficult when repetitive or even
strongly patterned material is involved.  The eye may be alert for
an error in something's first appearance, but is preconditioned to
see correctness in the second, glazes over by the third, and when
it comes to the fourth, fifth, sixth, sevanth, ...  It grows easier
and easier to auto-correct the errors, harder and harder to see them.

     asetofsymbols uses macros purely for abbreviation and obfuscation,
but a slight modification of the technique can, I think, offer some
advantages in preparing material for proofreading:

     - It can separate the structure from the content, allowing it
       to be audited from a purely structural perspective and without
       contextual distractions.  No more tedious and error-prone
       cross-checking!

     - It can eliminate much of the repetition found in ordinary text.
       The proofreader can inspect each content element once and with
       care, and can thereafter rely on the computer's infallible
       symbol manipulations.

     - It can achieve a modest compression of the material, thus
       shortening the proofreader's task.  Less work, less drudgery,
       more alertness.

     As a short example I offer the following.  Careful readers will
note that I have eschewed the Oxford comma; it could be supported as
a special case if desired.  But this would entail a disruption, albeit
small, in the pattern of the solution, and I prefer to follow the Unix
development philosophy: "It's not quite right, but it's oh! so elegant!"

#define S I. II. III. IV. V. VI. VII. VIII. IX. X. XI. XII
#define I Y(G1,first)
#define II Y(G2,second)
#define III Y(G3,third)
#define IV Y(G4,fourth)
#define V Y(G5,fifth)
#define VI Y(G6,sixth)
#define VII Y(G7,seventh)
#define VIII Y(G8,eighth)
#define IX Y(G9,ninth)
#define X Y(G10,tenth)
#define XI Y(G11,eleventh)
#define XII Y(G12,twelfth)
#define G1 a partridge in a pear tree
#define G2 two turtledoves and G1
#define G3 three French hens, G2
#define G4 four calling birds, G3
#define G5 five gold rings, G4
#define G6 six geese a-laying, G5
#define G7 seven swans a-swimming, G6
#define G8 eight maids a-milking, G7
#define G9 nine ladies dancing, G8
#define G10 ten lords a-leaping, G9
#define G11 eleven pipers piping, G10
#define G12 twelve drummers drumming, G11
#define Y(what,which) On the which day of Christmas my true love gave to 
me what
S!

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#76239

On 17/11/2015 13:11, Eric Sosman wrote:
> On 11/16/2015 2:13 PM, asetofsymbols@gmail.com wrote:
>> I do not mentally traslate R to return. [...]
>
>      This fragment convinces me that there may be, after all, some
> value in asetofsymbols' approach: Perhaps it can ease the tedious
> task of proofreading.  Proofreading is *hard*, because the brain is
> trained to correct errors on the fly, for all the world like a hard
> drive's firmware applying ECC to a noisy signal.  The brain supplies
> the missing N above, and it takes serious effort to notice that it's
> actually not there.

I think asetofsymbols is Italian.

In Italian, many words that start with "trans..." in English, have 
translations starting with "tras...",  without the 'n' (such as 
trasporto for transport).

'Translate' is not one of those, but a missing 'n' probably wouldn't 
stand out as much is it does to a English speaker in proof-reading mode.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#76674

Eric Sosman <esosman@comcast-dot-net.invalid> writes:

> [...]
>
> #define S I.  II.  III.  IV.  V.  VI.  VII.  VIII.  IX.  X.  XI.  XII
> #define I Y(G1,first)
> #define II Y(G2,second)
> #define III Y(G3,third)
> #define IV Y(G4,fourth)
> #define V Y(G5,fifth)
> #define VI Y(G6,sixth)
> #define VII Y(G7,seventh)
> #define VIII Y(G8,eighth)
> #define IX Y(G9,ninth)
> #define X Y(G10,tenth)
> #define XI Y(G11,eleventh)
> #define XII Y(G12,twelfth)
> #define G1 a partridge in a pear tree
> #define G2 two turtledoves and G1
> #define G3 three French hens, G2
> #define G4 four calling birds, G3
> #define G5 five gold rings, G4
> #define G6 six geese a-laying, G5
> #define G7 seven swans a-swimming, G6
> #define G8 eight maids a-milking, G7
> #define G9 nine ladies dancing, G8
> #define G10 ten lords a-leaping, G9
> #define G11 eleven pipers piping, G10
> #define G12 twelve drummers drumming, G11
> #define Y(what,which) On the which day of Christmas my true love gave
> to me what
> S!

I must congratulate you on a truly inspiring example!

[toc] | [prev] | [next] | [standalone]

#76678

On 11/20/2015 4:09 PM, Tim Rentsch wrote:
>[...]
> I must congratulate you on a truly inspiring example!

     Thank you.  After I composed it, I began to wonder whether
I'd thought it up myself or had seen it somewhere before -- and
I'm still not sure.  Didn't find anything like it at IOCCC, but
maybe I didn't look hard enough.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [standalone]

Page 5 of 5 — ← Prev page 1 2 3 4 [5]

Back to top | Article view | comp.lang.c

csiph-web