comp.lang.c - 7 new messages in 4 topics - digest

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

comp.lang.c@googlegroups.com

Today's topics:

* Efficency and the standard library - 3 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
* derived-type object - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/cfab7b19dac62701?hl=en
* Experiment: functional concepts in C - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
* substring finding problem! - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en

==============================================================================
TOPIC: Efficency and the standard library
http://groups.google.com/group/comp.lang.c/t/ad9fea19f2f7dd61?hl=en
==============================================================================

== 1 of 3 ==
Date: Sat, Feb 20 2010 10:10 pm
From: spinoza1111

On Feb 21, 1:00 am, Malcolm McLean <malcolm.mcle...@btinternet.com>
wrote:
> On Feb 20, 9:45 am, Richard Heathfield <r...@see.sig.invalid> wrote:>spinoza1111wrote:
>
> > > In the example, you just take out malloc.h and test everything.
>
> > That's your job.
>
> So we've got version 1 which uses malloc.h. The person who receives
> the code say "Oh Oh, no good" and makes it stdlib.h.
> Now the code isn't the same. So if we give a bug report to the writer
> of version 1, we have to say that we were using a different version,
> and he might say "well it's no longer my problem". So you need to
> repeat the bug with version 1, which takes an extra day. Even with
> perfect goodwill, you create layers of bureaucracy.
>
> Naturally, when you make a change, you test everything. The problem is
> that the person doing the testing "knows" that all he's done is
> repalce a non-standard header. So nothing can go wrong, right? And 99%
> of the time, he'll be right. So it creates a sort of sense of
> unnecessary work, mandated by pointless regulations. We need the code
> urgently, so tester skimps on the unit tests. Again 99% of the time
> he's right. But discipline has slipped. We no longer have a bullet-
> proof testing system.
>
> That's the way with code. The trivial is important, because the whole
> point of computers is that they can perform trivial tasks, without
> human intervention.

All very true, and well-expressed. But my conclusion has already been
expressed: don't use C for this level of industrial code. When you
have OO languages, "including the right libraries" simply isn't as big
of a problem. Libraries, as compared to objects, are too crude for
modern development because they redefine too much.

Were we doing the sort of collaborative development for which Richard
and Seebs aren't qualified, we would have to agree to include a high-
level .h file which would do all of the standard includes in turn, and
we'd then forget what's needed and have to look it up when outside of
the collaborative development environment. The industrial and
collaborative development of C code in my view always requires
considerable work on idiomatic approaches to the point that shippable
source code looks nothing at all what people here think is C. It looks
more like my code, in fact, minus trivial blunders like malloc.h
(which was removed when Heathfield pointed it out).

== 2 of 3 ==
Date: Sat, Feb 20 2010 10:21 pm
From: spinoza1111

On Feb 21, 12:22 am, blm...@myrealbox.com <blm...@myrealbox.com>
wrote:
> In article <b9d0fe28-bdd6-4f9d-82f1-bf9692fe1...@w27g2000pre.googlegroups.com>,
>
>
>
>
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Feb 19, 9:28 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
> > wrote:
> > > On 19 Feb, 07:08,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > > On Feb 19, 12:48 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> > > > > spinoza1111wrote:
>
> > > <snip>
>
> > > > > > Heathfield wrote a "linked list tool"
> > > > > > without pointing to data,
>
> > > <snip>
>
> > > > [...] my point was that the DATA in the list is the DATA and
> > > > not a link, and nobody with a halfway decent education in data
> > > > structures would have proposed such a stupid design, save, perhaps,
> > > > for a linked list of data elements whose type is simple and fixed in
> > > > length...not a "reusable tool".
>
> > > Alex Stepanov, the designer of the C++ STL library is untutored in
>
> > Again, these constant appeals to older men "untutored"
>
> Did you read Nick's whole sentence before starting to type your
> response?  he said
>
> > > Alex Stepanov, the designer of the C++ STL library is untutored in
> > > computer science?
>
> which to me says nothing at all about whether he thinks Stepanov
> is "untutored in computer science", but is instead an attempt to
> suggest that if Heathfield's approach is indeed faulty, he's in
> good company.

Heathfield's crude code is nothing like Stepanov's accomplishment.
>
> > are sickeningly
> > ignorant excuses for ignorance, because many of them (such as
> > Dijkstra) went to universities before universities had computer
> > science programmes, and others (such as Stepanov) were self-educated
> > because of life events. Dijkstra most certainly, and probably
> > Stepanov, never engaged in anti-intellectual assaults and the politics
> > of personality which are in this newsgroup the tropes of the
> > malignantly uninformed.
>
> [ snip ]
>
> > > computer science? The STL is "value based" and copies the data. You
> > > can make the data a pointer if you want to, but you don't have to.
>
> (And you even retained the text ....  "Whatever", maybe.)

I would not dignify Heathfield as "value based". Instead, I think he
didn't know how to do the job, since to do it you have to use the
preprocessor *safely* to abstract the node pointer type.

A competent programmer would have reasoned:

1. Although some C programmers use pointers to void, this is not safe

2. But copying the bytes in unpredictable code makes node creation
O(n) in all cases

3. I can use the preprocessor to make the node type an abstraction

4. There might be applications where my caller wants node values in
nodes, so this will be an option

5. Using the preprocessor avoids any void* pointers.

But note that the above propositions have a form radically different
from the usual corporate programming proposition, which is today more
expressed with NOT as a major operator owing to the destruction of
knowledge by institutions and money, or, when positive in form, is
grave and folkloric in tone and content. To issue propositions in the
above form is in fact dangerous in corporations, because Enlightenment
knowers kneed kno longer apply to corporations in which irrationality
reigns...as in the bank bailout.
>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer:  I don't speak for my employers; they return the favor.

== 3 of 3 ==
Date: Sat, Feb 20 2010 11:52 pm
From: spinoza1111

On Feb 21, 4:46 am, Kelsey Bjarnason <kbjarna...@gmail.com> wrote:
> [snips]
>
> On Sat, 13 Feb 2010 22:17:10 -0800,spinoza1111wrote:
> > No argument there, none whatsoever. But lemme ask you a question. Where
> > the fuck do you get off criticising people who are, if not perfect,
> > better than you? People like Schildt?
>
> Would that be the same Schildt who thinks main can be declared however
> you damn well please,

He doesn't believe that, but most competently written OSen allow you
to declare main in different ways.

> who thinks feof should be checked _after_ using the
> value read from the file,

This isn't what he "believes" in the worst case. In the worst case, he
may have believed, as have many competent C programmers, that feof's
design wasn't fucked up, and that you could use it BEFORE the read
that fails owing to eof.

> rather than before, who thinks bytes are always
> 8 bits,

Most sane programmers *know* that most bytes are 8 bits, and that
precisely because C is a low-level language, it should not be ported
to other environments without considerable diligence of the sort that
most code monkeys don't have.

> who thinks C is restricted to the ASCII character set, who
> thinks...
>
> Anyone who has read even a basic introductory text on C is qualified to
> critize Schildt.

It's spelled "criticize", Mr. Foaming at the Mouth.

One document, which should have been submitted to McGraw Hill prior to
publication, created a distorted image of Schildt-as-scapegoat for the
very real incompetence of most C programmers, using the insane logic
that "because Schildt made so many errors, I make fewer". The author
of that document, Peter Seebach, is present here in these discussions
as I write. Last week, he submitted an implementation of strlen which
was gravely approved by another reg here (Keith Thompson) but which
contained an obvious off by one bug, which I found in seconds.

The problems in the Schildt books are an artifact of the way in which
McGraw-Hill dev edits books at worst. Their philosophy, which is
shared by most other computer publishers, is that bugs in printed code
are not really important, since "no warranty, express or implied" is
made of this code. Although buggy code in printed books (as opposed to
shipped software systems which are also under the "no warranty" rule)
is regrettable, no professional programmer uses such code blindly,
because "no warranty" is made.

Arguably, McGraw Hill should (or should have, when the book was
published) devote/d more resources to debugging, and that they were
inclined to do so was indicated that they offered Peter Seebach, who
they did not know, money to participate. He refused their offer, he
tells us, because it wasn't enough...money. Instead, he created one
silly document of errata and coined the neologism "Bullschildt" in an
unwarranted personal attack in order to make him seem more qualified
than he actualy is (he has NO academic preparation in CS, whereas
Schildt has both a BS and MS in CS).

This document went "viral" and became the sole source of the Schildt
canard. It lists 20 "errors", most of which are matters of style and
interpretation and dishonestly implies that because Seebach identified
these, there must be hundreds more, and that Schildt doesn't "know C".

There are better books on C. However, the feof() issue and others make
it clear that there's something like knowing TOO MUCH about C in the
sense that it teaches a mistaken approach towards programming.

==============================================================================
TOPIC: derived-type object
http://groups.google.com/group/comp.lang.c/t/cfab7b19dac62701?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 20 2010 10:20 pm
From: frank

On Feb 17, 12:21 am, pac...@kosh.dhis.org (Alan Curry) wrote:
> In article <7u1ajdFam...@mid.individual.net>,
> Phred Phungus  <Ph...@example.invalid> wrote:
> |
> |What is the warning trying to say?  I do see braces and think that the
> |statement could be called one of initialization.  Of what horrible thing
> |does it want to make me mindful?
>
> Mind that you don't accidentally provide an initializer of 8 values for a
> struct that has 9 members, and everything gets the wrong value because you
> added a member in the middle and forgot to update the initializer.
>
> Designated initializers fix most of that. Note that gcc never gives the
> "missing initializer" warning when designated initializers are used.

What is a designated initializer?

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

== 1 of 2 ==
Date: Sat, Feb 20 2010 10:33 pm
From: Ertugrul Söylemez

jacob navia <jacob@nospam.org> wrote:

> You are completely WRONG.

You could use some improvement in your reasoning. =)

> A small program has many advantages:
>
> [a lot of irrelevant crap]

I'm not coding like a pig. Cleaning up properly is not bloat, and
that's all I'm talking about.

However, even if I were talking about bloat, your reasoning is still
nonsense. You're programming in C after all. To get maximum speed, you
need to program in Assembler.

> o It fits more program in the processor caches. As you (may) know
> processor caches are much more limited than RAM. A smaller program
> will run FASTER than a bloated one because costly RAM access will
> be fewer.

So? Ah yes, I understand. A nanosecond slower response time, because I
freed memory unnecessarily. Laughable.

> o There is nothing that runs FASTER than a DELETED instruction. Yes,
> sometimes you need to add code to make it run faster, but in most
> cases eliminating unneeded operations accelerates the program.

In most cases, this acceleration is neglible.

> o Your point of view is the one of most programers today. Do not care
> about efficiency. That means that instead of passing the results
> of hardware progress to the user and making programs that
> effectively run FASTER in today's hardware we KEEP those advances
> for us programmers and we run as slow as 20 years ago. Read about
> the contest between a MAcintosh 512K and a Vista AMD64, and you
> will see that in many aspects that are important to the end user,
> the Mac 512K run faster than vista.
>
> Why?
>
> Because of your mentality: BLOATED IS BETTER. Just do not use your
> brain and program like a pig. Nobody cares.

Complete nonsense. You don't know my mentality, obviously. Neither do
you know the mentality of modern software industry. Instead of making
the same program with the same functionality faster, we make a better
program doing much more things in the same time.

I'm not saying that this is a good in any way. I'm saying that this is
how the majority of programmers think.

> o I presented an article about code bloat with the JAVA example in
> this group several weeks ago. Re-read it. There I show why I like C
> and think that C has a bright future.

This is why you like C over Java. I don't like Java either, and I think
that neither of those two languages have a bright future. C is still
widely used, partly because the old school programmers, not willing to
learn/evaluate anything new, are still there and partly because a lot of
software is already written in C, so using C to extend them makes sense.

> > I'm sure your IDE/compiler suite isn't going to run on small
> > embedded systems, so you may want to reconsider your priorities.
> > Nobody will complain about your program, if it has 3 MiB instead of
> > 800 KiB.
>
> Of course not, but they will complain about slow response times, and
> long download time!

Because you freed resources? ;)

> > After all modern IDEs take hundreds of megabytes of disk space and
> > nobody complains about them either.
>
> Yes. Take for instance Eclipse, that took around 5 minutes to start in
> an AIX system. Yes, that's right: 5 minutes. Nice isn't it?
>
> And yes, I did not complain. There was no point in complaining.
> Java is like that.

We are not arguing about 5 minutes startup times, but about 5
nanoseconds response times and 20 ms exit time.

> Everybody in Java thinks like you:
>
> PROGRAM LIKE A PIG!
> Nobody cares.

I'm not like that.

> Then, to read a 4 digit year from character into an integer you use
> several temporary objects, by reading the characters into a list
> container temp, that calls a general routine to convert a list
> container into a boxed multi-precision integer that gives a boxed
> integer that is converted into an unboxed one... eventually.
>
> Obviously nobody cares until this is used in an inner loop and then...
>
> Well then, the user waits, or they buy yet another server box.

That's complete nonsense and you know it.

Greets
Ertugrul

--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://blog.ertes.de/

== 2 of 2 ==
Date: Sat, Feb 20 2010 10:59 pm
From: Richard

Ertugrul Söylemez <es@ertes.de> writes:

> jacob navia <jacob@nospam.org> wrote:
>
>> You are completely WRONG.
>
> You could use some improvement in your reasoning. =)
>
>> A small program has many advantages:
>>
>> [a lot of irrelevant crap]
>
> I'm not coding like a pig. Cleaning up properly is not bloat, and
> that's all I'm talking about.
>
> However, even if I were talking about bloat, your reasoning is still
> nonsense. You're programming in C after all. To get maximum speed, you
> need to program in Assembler.

No you dont. More often than not a modern compiler will pick better
instruction sequences than you will. Sure you might revert to assembler
in some corner cases where it makes sense and you know certain tricks
or have certain needs that compiler can not be hinted at.

>
>> o It fits more program in the processor caches. As you (may) know
>> processor caches are much more limited than RAM. A smaller program
>> will run FASTER than a bloated one because costly RAM access will
>> be fewer.
>
> So? Ah yes, I understand. A nanosecond slower response time, because I
> freed memory unnecessarily. Laughable.
>
>> o There is nothing that runs FASTER than a DELETED instruction. Yes,
>> sometimes you need to add code to make it run faster, but in most
>> cases eliminating unneeded operations accelerates the program.
>
> In most cases, this acceleration is neglible.

In one instance yes. Not in millions of iterations. Are you a student?

==============================================================================
TOPIC: substring finding problem!
http://groups.google.com/group/comp.lang.c/t/cf9bd97208e0c3a3?hl=en
==============================================================================

== 1 of 1 ==
Date: Sat, Feb 20 2010 11:57 pm
From: spinoza1111

On Feb 21, 1:57 am, blm...@myrealbox.com <blm...@myrealbox.com> wrote:
> In article <65456f81-71e0-4ddb-8da2-04c67e9e2...@y7g2000prc.googlegroups.com>,
>
>
>
>
>
> spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Feb 20, 12:55 am, Seebs <usenet-nos...@seebs.net> wrote:
> > > On 2010-02-19, blmblm  myrealbox.com <blm...@myrealbox.com> wrote:
>
> > > >> An interesting factoid about this discussion is that no American or
> > > >> British posters, save one, have solved the problem I set (write
> > > >> replace without using string.H).
> > > > Oh, it's string.H we're to avoid?  is it okay to use string.h?
> > > > Yeah, yeah, nitpick ....
>
> > > It's also a silly challenge.  If I were going to do that, my first pass
> > > would just be to put "my" in front of the str* functions I use, and
> > > define them.
>
> > That sounds like (1) unethical behavior and (2) to be expected from
> > you.
>
> How is this unethical?  In essence what he's doing is implementing
> a standard interface, but in a way that can't collide with an
> existing implementation.

I said last week that my replace function integrates two different
things.
>
>
>
>
>
> > Look, why not just admit it. You had no clue how to solve the
> > challenged problem, which could easily arise in any number of
> > circumstances. You're really not contributing much to the discussion.
>
> > > But why would I do that?  How about we set a new challenge, which is to
> > > do matrix multiplication without using the '*' operator.  Or, better yet,
> > > how about we iterate through an array without using a for loop, and write
> > > our own routines to interpolate numbers into textual strings, so we don't
> > > have to rely on printf()?
>
> > Those of us who can (who like Schildt have written compilers) do this
> > for fun, for the same reason classical pianists play Czerny finger
> > exercises, and Bach wrote the Art of Fugue. There are some of us who
> > don't advance our careers by destroying reputations and buying our way
> > onto standards boards without any academic qualifications.
>
> > Furthermore, if I were doing matrix multiplication times a power of
> > two, I wouldn't use the * operator. Do you even know what operator I
> > would use?
>
> "Matrix multiplcation times a power of two?"  Could you explain what
> you mean by that?  In my usage "matrix multiplication" is a binary
> operation on matrices, so I don't understand how one of the operands
> can be a power of two.  ?

It contains a power of two in each element in the scenario where you
wouldn't use * you would use shift. Look, I was just having a little
fun with Seebie.
>
> [ snip ]
>
> --
> B. L. Massingill
> ObDisclaimer:  I don't speak for my employers; they return the favor.

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

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