comp.lang.c - 22 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:

* Implementing strstr - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/a3fe05ab352d5774?hl=en
* Idiotic programming style edicts - 7 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
* Cryptic Syntax - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/3c0bd77fdf5ec98c?hl=en
* C vs C++ - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
* Container library (continued) - 8 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en

==============================================================================
TOPIC: Implementing strstr
http://groups.google.com/group/comp.lang.c/t/a3fe05ab352d5774?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Mar 19 2010 6:07 pm
From: spinoza1111

On Mar 20, 2:24 am, "bartc" <ba...@freeuk.com> wrote:
> spinoza1111wrote:
> > On Mar 20, 1:38 am, "Scott Fluhrer" <sfluh...@ix.netcom.com> wrote:
> >> Maybe one hour and fifty minutes was taken writing the poem in the
> >> comments???
>
> > Probably forty minutes to code, forty minutes to document, forty
> > minutes to write the poem. But only in nasty little business offices
> > is time taken the sole measure of quality. In my book, someone who
> > takes extra time loves his work and is trying to do a better job.
>
> You might be interested in this language then instead:
>
> http://en.wikipedia.org/wiki/Shakespeare_(programming_language)
>
> (you might need to add ")" on url)
>
> --
> Bartc

Thanks, very interesting link and "esoteric" programming language.

== 2 of 3 ==
Date: Fri, Mar 19 2010 9:00 pm
From: Ben Bacarisse

spinoza1111 <spinoza1111@yahoo.com> writes:

> The first two releases had a bug: after a one character "handle" is
> found we set the ptrIndex to the master string at one past the handle:
> this is incorrect, for the start of the main loop will then search for
> the first character of the NEXT occurence, missing the overlapping
> occurence.

You have a == vs = type that makes this explanation unlikely. As far
as I can tell, ptrHandle is never anything other a null pointer and
none of the code involving it as any effect at all. That includes
this supposed fix.

<snip>
--
Ben.

== 3 of 3 ==
Date: Fri, Mar 19 2010 10:30 pm
From: spinoza1111

On Mar 20, 12:00 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > The first two releases had a bug: after a one character "handle" is
> > found we set the ptrIndex to the master string at one past the handle:
> > this is incorrect, for the start of the main loop will then search for
> > the first character of the NEXT occurence, missing the overlapping
> > occurence.
>
> You have a == vs = type that makes this explanation unlikely.  As far
> as I can tell, ptrHandle is never anything other a null pointer and
> none of the code involving it as any effect at all.  That includes
> this supposed fix.

if (ptrHandle = 0 <- wrong, should be ==
&&
ptrMaster > strMaster
&&
*ptrMaster == *strTarget)
ptrHandle = ptrTarget;

Oops....very good call, thanks. I clearly need more test cases: the
overlaps are never found.

I will post a fixed version after I get back from class.

>
> <snip>
> --
> Ben.

==============================================================================
TOPIC: Idiotic programming style edicts
http://groups.google.com/group/comp.lang.c/t/99bc3aa427fc7518?hl=en
==============================================================================

== 1 of 7 ==
Date: Fri, Mar 19 2010 6:11 pm
From: "Joe Morris"

BruceS wrote:

> According to The C Standard, 6.4.9p2, C allows comments that *do*
> automatically terminate at the end of the line, just as this style of
> comment works in C++. One could avoid the bug in the earlier code by
> writing it:
>
> x // The variable x
> = // is assigned
> x // its value
> + // plus
> 2 // pi
> ; // .
>
> Oh, I'd better put in a :) or we'll have started another pointless
> whinefest.

Thread drift warning...

My (non-parity-checked) memory tells me that there was a code block in the
MFT-1 (OS/360 release 14 or maybe 13) nucleus that had register equates
named the traditional Rn (0 <= n <= 15),
but with Rn set equal to a value other than n. I *think* it was in the FLIH
(First-Level Interrupt Handler), in code assembled at sysgen. I always
assumed (as speculation) that when the code was written there was one
register use convention that was later changed, and someone was too lazy to
chase all of the register references in the code and rename them.

Does this sound familiar to anyone?

Joe Morris

== 2 of 7 ==
Date: Fri, Mar 19 2010 6:43 pm
From: Charles Richmond

Seebs wrote:
> On 2010-03-19, jmfbahciv <jmfbahciv@aol> wrote:
>>> does the name Edward Nilges ring a bell?
>
>> Nope.
>
> Ahh, you're missing... well.
>
> Edward Nilges is this guy. He's spent the last couple of years railing
> against the Cruele And Unjust Turns Of Fate by which Herbert Schildt has
> acquired a negative reputation. For instance, because every competent
> programmer who's ever commented on his books says they're pants.
>
> He recently responded to my posting of a quick one-off solution to a problem
> (figure 10-15 lines of code) with a >100 line version which took him a couple
> of hours to write, and several hours to debug. To demonstrate by complete
> incompetence at choosing variable names, he had variables named ptrIndex0,
> ptrIndex1, ptrIndex2, and ptrIndex3.
>
> The amazing thing is that, so far as anyone can tell, he actually believes
> himself to be serious. Never mind that he has repeatedly sworn to sue various
> people for defamation and never yet gotten to it.
>
> Here's a fairly representative example:
>> In particular, Stroustrup had learned about
>> object oriented programming using Simula in Denmark before coming to
>> the US, because in Denmark labor unions had real power and demanded
>> that factory automation be documented for union oversight.
>
> That was on one of his comparatively lucid days.
>
> (Posting in detail just because afc people might find this amusing.)
>
> -s

You can tell when Nigles is off his medication... :-)

--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+

== 3 of 7 ==
Date: Fri, Mar 19 2010 8:19 pm
From: ArarghMail003NOSPAM@NOT.AT.Arargh.com

On Fri, 19 Mar 2010 21:11:04 -0400, "Joe Morris"
<j.c.morris@verizon.net> wrote:
<snip>
>
>Thread drift warning...
>
>My (non-parity-checked) memory tells me that there was a code block in the
>MFT-1 (OS/360 release 14 or maybe 13) nucleus that had register equates
>named the traditional Rn (0 <= n <= 15),
>but with Rn set equal to a value other than n. I *think* it was in the FLIH
>(First-Level Interrupt Handler), in code assembled at sysgen. I always
>assumed (as speculation) that when the code was written there was one
>register use convention that was later changed, and someone was too lazy to
>chase all of the register references in the code and rename them.
>
>Does this sound familiar to anyone?
>
I don't know about the location you mentioned, but I think I have seen
it in other parts of the source. Can't find any examples, though.
If you should happen to remember the source file name, I could look.

However, a lot of the routines I looked at appear as if somebody at
some point in time said: "Thou shall not use hard coded numbers",
because I see a lot of equates like "d1 equ 1". :-)

--
ArarghMail003 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

== 4 of 7 ==
Date: Fri, Mar 19 2010 9:27 pm
From: Andrew Swallow

ArarghMail003NOSPAM@NOT.AT.Arargh.com wrote:
> On Fri, 19 Mar 2010 21:11:04 -0400, "Joe Morris"
> <j.c.morris@verizon.net> wrote:
> <snip>
>> Thread drift warning...
>>
>> My (non-parity-checked) memory tells me that there was a code block in the
>> MFT-1 (OS/360 release 14 or maybe 13) nucleus that had register equates
>> named the traditional Rn (0 <= n <= 15),
>> but with Rn set equal to a value other than n. I *think* it was in the FLIH
>> (First-Level Interrupt Handler), in code assembled at sysgen. I always
>> assumed (as speculation) that when the code was written there was one
>> register use convention that was later changed, and someone was too lazy to
>> chase all of the register references in the code and rename them.
>>
>> Does this sound familiar to anyone?
>>
> I don't know about the location you mentioned, but I think I have seen
> it in other parts of the source. Can't find any examples, though.
> If you should happen to remember the source file name, I could look.
>
> However, a lot of the routines I looked at appear as if somebody at
> some point in time said: "Thou shall not use hard coded numbers",
> because I see a lot of equates like "d1 equ 1". :-)
>
That is a common one. What happens is that
d1 equ 1
but m1 changes
m1 equ 2

This means that a third of the +1 become +2. Without the use of
macros there is plenty of room to get that edit wrong.

Andrew Swallow

== 5 of 7 ==
Date: Fri, Mar 19 2010 9:09 pm
From: Jonathan de Boyne Pollard

>
>>>
>>> does the name Edward Nilges ring a bell?
>>>
>> Nope.
>>
> Ahh, you're missing [... See original post for lengthy details,
> within, fore, and aft. Look away now if you don't want to hear the
> result. ...]
>
> (Posting in detail just because afc people might find this amusing.)
>
You might be confusing AFC with AUK.

== 6 of 7 ==
Date: Fri, Mar 19 2010 9:23 pm
From: Jonathan de Boyne Pollard

>
>>>
>>> int strlen(char *strString) // Of strings I sing, and their Length
>>> { // Oh muse, give me strength
>>> int intIndex1 = 0; // To not fuck it up, like that Pup
>>> for (; // Seebach, coder extraordinaire
>>> *(strString+intIndex1);// Who doesn't care
>>> intIndex1++); // That he makes us tear our hair.
>>> return intIndex1; // And so my code is Done
>>> } // And all had great fun
>>>
>> int daysinmonth (int month, year) [...]
>>
> Good, but my poem was original and I wrote it while coding the simple
> strlen.
>
> I can walk and simultaneously chew Nicorette Gum
> Can you, chum?
>
This is an interesting question that we might all care to ponder. I
don't know, myself. The last time that I chummed was over a decade
ago. I might have lost the knack.

== 7 of 7 ==
Date: Fri, Mar 19 2010 10:21 pm
From: Aratzio

On Sat, 20 Mar 2010 04:23:26 +0000, in the land of alt.usenet.kooks,
Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.COM>
got double secret probation for writing:

>>
>>>>
>>>> int strlen(char *strString) // Of strings I sing, and their Length
>>>> { // Oh muse, give me strength
>>>> int intIndex1 = 0; // To not fuck it up, like that Pup
>>>> for (; // Seebach, coder extraordinaire
>>>> *(strString+intIndex1);// Who doesn't care
>>>> intIndex1++); // That he makes us tear our hair.
>>>> return intIndex1; // And so my code is Done
>>>> } // And all had great fun
>>>>
>>> int daysinmonth (int month, year) [...]
>>>
>> Good, but my poem was original and I wrote it while coding the simple
>> strlen.
>>
>> I can walk and simultaneously chew Nicorette Gum
>> Can you, chum?
>>
>This is an interesting question that we might all care to ponder. I
>don't know, myself. The last time that I chummed was over a decade
>ago. I might have lost the knack.

Nilges doesn't but Pavlov does.

==============================================================================
TOPIC: Cryptic Syntax
http://groups.google.com/group/comp.lang.c/t/3c0bd77fdf5ec98c?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 19 2010 6:18 pm
From: Gene

On Mar 19, 8:09 pm, WD <liamym...@yahoo.com> wrote:
> Can anybody explain what's going on in the extremely cryptic syntax
> found in the return statement below?  Based on observed program
> functionality, it appears this statement directly launches a program
> (that was created in memory during the /*create a program in memory
> before returning*/ section) after main exits, but how?
>
> main(x,y)
> {
>     /*create a program in memory before returning*/
>
>     return(*(int(*)())*(int*)(z))(x,y);
>
> }
>
> Thanks,
> William

Hard to say what it does because it's nonsense. There is no
declaration for z. The comment is meaningless.

If z were declared to be a pointer of any kind, then the (int*) would
cast it to a pointer to int. The * dereferences this pointer.
Consequently
*(int*)(z)
has type int. The
(int (*)())
casts this to a pointer to function returning int. The leftmost *
dereferences this to a function type. The function (if z actually
pointed to one) would be applied to x and y. The value of x is the
program argument count. The value of y is undefined, but in many
implementations, will be an integer version of the pointer argv.

Of course we know z doesn't point to anything because it's undefined.
The code would only make a rough, ugly kind of non-compliaent sense if
z contained a pointer to a pointer to a function accepting an int and
a pointer to pointer to char. Here:

#include <stdio.h>

f(x, y)
char **y;
{
printf("Hello! x=%d and y[0]=\"%s\"\n", x, y[0]);
return 0;
}

main(x,y)
{
int w = &f;
int *z = &w;
return(*(int(*)())*(int*)(z))(x,y);
}

C:\>gcc foo.c -o foo.exe
foo.c: In function 'main':
foo.c:12: warning: initialization makes integer from pointer without a
cast

C:\>foo
Hello! x=1 and y[0]="foo"

C:\>

== 2 of 2 ==
Date: Fri, Mar 19 2010 8:01 pm
From: WD

On Mar 19, 7:18 pm, Gene <gene.ress...@gmail.com> wrote:
> On Mar 19, 8:09 pm, WD <liamym...@yahoo.com> wrote:
>
>
>
>
>
> > Can anybody explain what's going on in the extremely cryptic syntax
> > found in the return statement below?  Based on observed program
> > functionality, it appears this statement directly launches a program
> > (that was created in memory during the /*create a program in memory
> > before returning*/ section) after main exits, but how?
>
> > main(x,y)
> > {
> >     /*create a program in memory before returning*/
>
> >     return(*(int(*)())*(int*)(z))(x,y);
>
> > }
>
> > Thanks,
> > William
>
> Hard to say what it does because it's nonsense. There is no
> declaration for z.  The comment is meaningless.
>
> If z were declared to be a pointer of any kind, then the (int*) would
> cast it to a pointer to int.  The * dereferences this pointer.
> Consequently
> *(int*)(z)
> has type int.  The
> (int (*)())
> casts this to a pointer to function returning int. The leftmost *
> dereferences this to a function type.  The function (if z actually
> pointed to one) would be applied to x and y.  The value of x is the
> program argument count.  The value of y is undefined, but in many
> implementations, will be an integer version of the pointer argv.
>
> Of course we know z doesn't point to anything because it's undefined.
> The code would only make a rough, ugly kind of non-compliaent sense if
> z contained a pointer to a pointer to a function accepting an int and
> a pointer to pointer to char.  Here:
>
> #include <stdio.h>
>
> f(x, y)
> char **y;
> {
>   printf("Hello! x=%d and y[0]=\"%s\"\n", x, y[0]);
>   return 0;
>
> }
>
> main(x,y)
> {
>     int w = &f;
>     int *z = &w;
>     return(*(int(*)())*(int*)(z))(x,y);
>
> }
>
> C:\>gcc foo.c -o foo.exe
> foo.c: In function 'main':
> foo.c:12: warning: initialization makes integer from pointer without a
> cast
>
> C:\>foo
> Hello! x=1 and y[0]="foo"
>
> C:\>- Hide quoted text -
>
> - Show quoted text -

z is declared as an int, not a pointer, and it really works as I
described. After creating a program in memory (like a compiler, only
no executable is written to disk) it appears that the return statement
somehow invokes the compiled (in memory) program. The full program
compiles with gcc and runs in the Linux environment, if that somehow
makes a difference.

William

==============================================================================
TOPIC: C vs C++
http://groups.google.com/group/comp.lang.c/t/bf4e0288d8537985?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Mar 19 2010 7:10 pm
From: Branimir Maksimovic

On Fri, 19 Mar 2010 14:43:57 -0700
"Robbie Hatley" <see.my.signature@for.my.contact.info> wrote:

>
> "Dr Malcolm McLean" wrote of C++ (as compared to C):
>
> > The problem is that basic structure, like arrays / vectors,
> > act as a protocol by which components of programs communicate
> > with each other. If some use plain C-style arrays and some
> > use vectors for essentially the same job, you've got a similar
> > situation to having three or four different plugs and sockets.
> > Of course you can mess about with adapters and usually get
> > things to work, but it's messy and inefficient
>
> Well, yah. C++ is messy and inefficient. C is less messy,
> but also less efficient in some ways (such as effort required
> to set up data structures such as multimap of struct objects),
Hm, assembler is less messy then C , but also less efficient
then C in some ways(such as effort....)

> and also more efficient in other ways (the executables are
> noticably smaller and faster than the same program written
> in C++).
and also more efficient, such as executables are noticeably smaller
and faster the same program written in C.
also not that easily disassembled, but more difficult
to debug ;)

But I like and use both languages, along with others.
>

same. ;)

Greets!

--
http://maxa.homedns.org/

Sometimes online sometimes not

== 2 of 2 ==
Date: Fri, Mar 19 2010 10:45 pm
From: "Default User"

Branimir Maksimovic wrote:

> On Fri, 19 Mar 2010 23:13:51 +0100
> jacob navia <jacob@nospam.org> wrote:

> > I just don't read what carmody writes, and that is much easier. Why
> > bother?
>
> Exactly! you don;t have to read.

If you never plan to read the posts of a certain person, why not
killfile them?

Brian

==============================================================================
TOPIC: Container library (continued)
http://groups.google.com/group/comp.lang.c/t/3763649cc890efcc?hl=en
==============================================================================

== 1 of 8 ==
Date: Fri, Mar 19 2010 7:44 pm
From: "ng2010"

"jacob navia" <jacob@spamsink.net> wrote in message
news:hnr08l$1ev$1@speranza.aioe.org...
> Seebs a écrit :
>> On 2010-03-17, jacob navia <jacob@nospam.org> wrote:
>>> You misunderstand. I am not trying to invent a new way of doing
>>> those things. I am trying to invent a generalized standard way
>>> of doing that in C. This has never been done before for C.
>>
>> It's been done repeatedly, except for the "standard" part.
>>
>> I honestly don't think that generalizing to "container" is going to be
>> useful in C. In a language that doesn't have meaningful inheritance,
>> it's very unusual for this kind of approach to get widespread
>> adoption.
>
>
> I do not know of any other attempt in C.
>
> Inheritance is not necessary at all. The code works without it.

Jacob: Do you even know C++? Because it sounds like you are burying your
head in the sand and doing wishful thinking and hoping that others would
believe and follow you, but the fact of the matter is that you are the
only one who wants to put lipstick on a pig! Eventually, all the old iron
of detroit will be gone, rusted away. So will C rust away. "A few" still
drive around the old cars, but they are still deathtraps and old,
obsolete technology. Restoring them with new underpinnings like
independent suspensions, doesn't change them much (still deathtraps).
With all your zeal, you should study C++ (if you haven't) and maybe a few
or all other languages and then embark on creating a new language (though
I can generalize and say that those who are good at building compilers
make for crappy language designers, but you know what they say about
generalizations). But you aren't a compiler builder, now are you. You
sound like a young man so I wonder what the fork you are doing with C
other than as a potential intermediate representation. You have time. Use
it wisely.

== 2 of 8 ==
Date: Fri, Mar 19 2010 7:48 pm
From: "ng2010"

"Seebs" <usenet-nospam@seebs.net> wrote in message
news:slrnhq223i.oe0.usenet-nospam@guild.seebs.net...
>
> I have often used list libraries. I'd use hash libraries if I needed a
> hash.
> In neither case would I use a "container" library in C -- it's the
> wrong
> level of abstraction for C, so far as I can tell. I've never in any
> language
> wanted "a container". In OO languages, it's useful that the specific
> things
> I request are also generically "containers". In C, it's not useful,
> because
> I can't do anything with it.
>

This sounds sooo much like thrashing on whether a "Line" should draw
itself or should be drawn by a "Canvas" or other abstraction. Don't walk,
run to the next level: jettison old paradigms.

== 3 of 8 ==
Date: Fri, Mar 19 2010 7:56 pm
From: "ng2010"

"Andrew Poelstra" <apoelstra@localhost.localdomain> wrote in message
news:slrnhq24u8.ls9.apoelstra@localhost.localdomain...

> You can do OO in C. I think most people don't because they have
> it drilled into their heads that "C is not an object-oriented"
> language. Which to be fair, it isn't, but that doesn't mean that
> there are reasonably-elegant[1] ways to do OO.

Your opinion of "reasonably elegant" is just that: an opinion. Apparently
Navia is willing to make the concessions necessary also. It is simply not
necessary to keep hitting one's self in the head with a hammer. OO and C
can never be "elegant". I think maybe Navia's problem is (as is my own)
that the compiler black box is just that: a black box! If you start with
a C compiler, then you end up trying to escape C by extending it and the
complex compiler you started with. It is an error of entry. The way to go
is to start with a clean slate. No baggage, no pain (from that hammer
hitting you on the head). It's sad to see him spinning his wheels and not
getting anywhere because he is stuck in the mud of C.

== 4 of 8 ==
Date: Fri, Mar 19 2010 8:04 pm
From: Seebs

On 2010-03-20, ng2010 <ng2010@att.invalid> wrote:
> This sounds sooo much like thrashing on whether a "Line" should draw
> itself or should be drawn by a "Canvas" or other abstraction. Don't walk,
> run to the next level: jettison old paradigms.

This is pretty useless advice.

Understanding what makes a design work is important regardless of language.

-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!

== 5 of 8 ==
Date: Fri, Mar 19 2010 8:12 pm
From: "ng2010"

Nick Keighley wrote:
> On 17 Mar, 04:22, "ng2010" <ng2...@att.invalid> wrote:
>> So sad to be dying and seeing youth tackling problems already solved
>> in my own youth.
>
> and the solution was? I'm not convinced there *is* a single right
> answer for all situations.

The solution to what? I know the answer to your second question and I
could tell ya, but then I'd have to kill ya. Ya know?

== 6 of 8 ==
Date: Fri, Mar 19 2010 8:06 pm
From: "ng2010"

Nick Keighley wrote:
> On 17 Mar, 15:36, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-03-17, jacob navia <ja...@nospam.org> wrote:
>
>>> You misunderstand. I am not trying to invent a new way of doing
>>> those things. I am trying to invent a generalized standard way
>>> of doing that in C. This has never been done before for C.
>>
>> It's been done repeatedly, except for the "standard" part.
>>
>> I honestly don't think that generalizing to "container" is going to
>> be useful in C. In a language that doesn't have meaningful
>> inheritance, it's very unusual for this kind of approach to get
>> widespread adoption. I think you'd do better to make a list library
>> and a hash library,
>> for instance.
>
> C++ doesn't use inheritance in its container classes. Having seen
> inheritance based conatiner classes I tend to think its the wrong
> mechanism.

Having implemented container libraries, I think that is where the layman
starts out. While I never had something like all containers derived from
a Container class, surely I did think about it (over a decade ago!). I do
think I have the "correct" architecture now (at least it is mature and
not kids stuff like Navia seems to be spouting!). Of course you'd have to
use "my" language (not yet available) to enjoy it. Stay tuned.

== 7 of 8 ==
Date: Fri, Mar 19 2010 8:15 pm
From: "ng2010"

Seebs wrote:
> On 2010-03-20, ng2010 <ng2010@att.invalid> wrote:
>> This sounds sooo much like thrashing on whether a "Line" should draw
>> itself or should be drawn by a "Canvas" or other abstraction. Don't
>> walk, run to the next level: jettison old paradigms.
>
> This is pretty useless advice.

It wasn't advice. It was assessment of the situation of the current
dialog. aka, "been there, done that".

== 8 of 8 ==
Date: Fri, Mar 19 2010 8:52 pm
From: Seebs

On 2010-03-20, ng2010 <ng2010@att.invalid> wrote:
> Seebs wrote:
>> On 2010-03-20, ng2010 <ng2010@att.invalid> wrote:
>>> This sounds sooo much like thrashing on whether a "Line" should draw
>>> itself or should be drawn by a "Canvas" or other abstraction. Don't
>>> walk, run to the next level: jettison old paradigms.

>> This is pretty useless advice.

> It wasn't advice. It was assessment of the situation of the current
> dialog. aka, "been there, done that".

"Don't walk, run..." is an imperative. Unless you're the emperor,
your imperatives are "advice".

The point is, it's not useful -- people need to think about these things
to develop a good map of the problem space. There's good reasons for some
things to be done in C, and thinking about how to do them well in C is
useful.

-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!

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

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