twitter: comp.lang.c - 25 new messages in 6 topics

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

comp.lang.c@googlegroups.com

Today's topics:

* Endless arguing - 15 messages, 7 authors
http://groups.google.com/group/comp.lang.c/t/a99361379a499175?hl=en
* small question - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/08850414dcd0b366?hl=en
* Son of Snarky Tirade: a response to Seebach's new CTCN: part 1 - 1 messages,
1 author
http://groups.google.com/group/comp.lang.c/t/383e6d5a95dc3f75?hl=en
* seebs/schildt II - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/c86133d7ad6b90c2?hl=en
* Generic linked list with internal storage? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/d36ff63bef634bcc?hl=en
* Test of a preprocessor symbol defined as nothing vs. zero - 2 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/8e4236bf3f19c661?hl=en

==============================================================================
TOPIC: Endless arguing
http://groups.google.com/group/comp.lang.c/t/a99361379a499175?hl=en
==============================================================================

== 1 of 15 ==
Date: Mon, Apr 12 2010 2:55 pm
From: Seebs

On 2010-04-12, Ersek, Laszlo <lacos@caesar.elte.hu> wrote:
> On Mon, 12 Apr 2010, Eric Sosman wrote:
>> In all three styles, the order in which keys/values/pairs are visited is
>> whatever the hash table feels like.

> Yes, this is the correct wording, "unspecified order". Not "random order",
> because then some poor bloke will start to rely on GetNext() jumping among
> values, and then somebody will implement the interface with a red-black
> tree.

Interestingly, the major hash implementations I know of are now all
consistent in order; if you request a walk of the hash, you get the items
in insertion order unless you've sorted them into a different order. Thus,
ordering is separate from keys.

This turns out to be sufficiently useful that it's now standard in at
least Ruby and PHP, and I think modern perl may be doing it too now, or
maybe that was for next release.

Basically, the performance gain of the "we don't specify" turns out to be
dwarfed by the performance costs of forcing users to do the sorting all
the time when they want to sort it.

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

== 2 of 15 ==
Date: Mon, Apr 12 2010 2:53 pm
From: Seebs

On 2010-04-12, jacob navia <jacob@spamsink.net> wrote:
>> So, if I call GetFirst() on such a thing, how/where do I find out what key
>> is associated with the first item?

> I use a hash table with collisions handled in linked lists.

> Then, GetFirst() goes to the start of the hash table until it finds
> a non-empty slot. Then, it returns that object and stores two things
> (1) the index of the non-empty slot
> (2) the list element within that slot.

Okay. But I'm confused. I want to know, not just the value in the slot,
but the key for it. How do I get that?

>> Another thing to consider: Trees. Do you want to have something like
>> Iterator *it = GetIterator(tree, ITERATE_DEPTH_FIRST);
>> or what? (It is not necessarily an attribute of the tree itself whether
>> you want to iterate over it depth-first or breadth-first!)

> You can store the way you want the sree scanned in the Flags field
> with tree->VTable->GetFlags and tree->VTable->SetFlags

I don't think that's the right way to do it -- it should be an attribute
of the iterator, not of the tree.

I don't know. I'm still not sure the underlying premise (that there's
measurable utility to C programs in having this kind of shared interface
to things so different that there is no way to swap one in for another
in a well-designed program to begin with) is valid.

== 3 of 15 ==
Date: Mon, Apr 12 2010 3:04 pm
From: Seebs

On 2010-04-12, jacob navia <jacob@spamsink.net> wrote:
> I am serious. I need help, and it would be nice if many people would
> review that code.

The problem is, the code started out going in a direction that is, so far
as I can tell, completely contrary to anything I want or need. Imagine
that I was sort of interested in tool design, and someone announced a plan
to work on the hammerscrewdriversaw, a device which is a hammer, a
screwdriver, and a saw. I might be able to point out things like "you
are going to need wildly incompatible material characteristics for these
three tasks", but I can't do much to help. Yes, it's hard. It's extremely
hard. It's also not something I want to begin with, so it's not clear
why I should help.

It might be rewarding to start by looking at how you'd make a really good
interface for each of two or three common container types, and then examining
the resulting interfaces to see whether there is really enough commonality
to justify trying to build a hybrid. My guess is that there simply isn't,
and there's also no reason for one. There simply aren't that many cases
where it would make sense to switch from one to another.

== 4 of 15 ==
Date: Mon, Apr 12 2010 3:07 pm
From: jacob navia

Seebs a écrit :
> On 2010-04-12, jacob navia <jacob@spamsink.net> wrote:
>>> So, if I call GetFirst() on such a thing, how/where do I find out what key
>>> is associated with the first item?
>
>> I use a hash table with collisions handled in linked lists.
>
>> Then, GetFirst() goes to the start of the hash table until it finds
>> a non-empty slot. Then, it returns that object and stores two things
>> (1) the index of the non-empty slot
>> (2) the list element within that slot.
>
> Okay. But I'm confused. I want to know, not just the value in the slot,
> but the key for it. How do I get that?
>

I wrote a function GetKeys() that returns a string collection with all
stored keys. Is that what you need?

>>> Another thing to consider: Trees. Do you want to have something like
>>> Iterator *it = GetIterator(tree, ITERATE_DEPTH_FIRST);
>>> or what? (It is not necessarily an attribute of the tree itself whether
>>> you want to iterate over it depth-first or breadth-first!)
>
>> You can store the way you want the sree scanned in the Flags field
>> with tree->VTable->GetFlags and tree->VTable->SetFlags
>
> I don't think that's the right way to do it -- it should be an attribute
> of the iterator, not of the tree.

Impossible because that would be container specific (trees) and would
not work with lists.

What is important to remember is basic software design principles.
Information hiding means that the user doesn't NEED to know if the
container is a tree or a list. This is a central point in the design of
the library.

>
> I don't know. I'm still not sure the underlying premise (that there's
> measurable utility to C programs in having this kind of shared interface
> to things so different that there is no way to swap one in for another
> in a well-designed program to begin with) is valid.
>

The learning curve is MUCH smaller. The surface that the library
uses in your memory is smaller. as you know, we can buy memory
extensions for our computers any time. There is no shop (yet) to buy a
brain memory extension however...

== 5 of 15 ==
Date: Mon, Apr 12 2010 3:08 pm
From: "Ersek, Laszlo"

On Mon, 12 Apr 2010, jacob navia wrote:

> Ersek, Laszlo a écrit :
>>
>> Hmm, nope. I wish to be able to store null pointers in the structure.
>>
>
> You can store NULL pointers.
>
> You get a POINTER to an object. That object can be anything, but to
> access it you have to dereference the pointer you got. When you dereference
> it you CAN get NULL pointers OF COURSE...

Now that you put it this way: sure. Original text was:

> This 3 function pointers yield a pointer to each stored object, or NULL
> when there are none.

I think I misunderstood the word "stored" in "stored object". The
intrusive/non-intrusive dichotomy, again. You meant non-intrusive, ie.
deep copies. I meant intrusive, ie. links.

lacos

== 6 of 15 ==
Date: Mon, Apr 12 2010 3:24 pm
From: Keith Thompson

Seebs <usenet-nospam@seebs.net> writes:
> On 2010-04-12, Ersek, Laszlo <lacos@caesar.elte.hu> wrote:
>> On Mon, 12 Apr 2010, Eric Sosman wrote:
>>> In all three styles, the order in which keys/values/pairs are visited is
>>> whatever the hash table feels like.
>
>> Yes, this is the correct wording, "unspecified order". Not "random order",
>> because then some poor bloke will start to rely on GetNext() jumping among
>> values, and then somebody will implement the interface with a red-black
>> tree.
>
> Interestingly, the major hash implementations I know of are now all
> consistent in order; if you request a walk of the hash, you get the items
> in insertion order unless you've sorted them into a different order. Thus,
> ordering is separate from keys.
>
> This turns out to be sufficiently useful that it's now standard in at
> least Ruby and PHP, and I think modern perl may be doing it too now, or
> maybe that was for next release.

Perl hashes still give you an unspecified (the documentation says
"seemingly random") order. Recent versions of Perl deliberately give
you different orders from one run to the next of the same program.
the older algorithm was susceptible to attacks that could generated
degenerate internal data structures, resulting in very expensive
operations on the resulting hashes. Deliberate randomization was the
solution to that (whether it was the best one is another question).

You can't even determine the order in which the items were inserted
unless you store it yourself.

For the Perl-specific details (which might be illuminating for
designing something similar in C) "perldoc perlsec" and search for
"Algorithmic Complexity Attacks".

> Basically, the performance gain of the "we don't specify" turns out to be
> dwarfed by the performance costs of forcing users to do the sorting all
> the time when they want to sort it.

Another approach is to treat unordered hashes and ordered hashes as
different data structures. Sometimes you need ordering, but when you
don't there's no point in paying the cost to maintain the information.
Whether this justifies the additional complexity of having two
different data structures rather than one is yet another question.

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

== 7 of 15 ==
Date: Mon, Apr 12 2010 3:37 pm
From: Ian Collins

On 04/13/10 09:55 AM, Seebs wrote:
> On 2010-04-12, Ersek, Laszlo<lacos@caesar.elte.hu> wrote:
>> On Mon, 12 Apr 2010, Eric Sosman wrote:
>>> In all three styles, the order in which keys/values/pairs are visited is
>>> whatever the hash table feels like.
>
>> Yes, this is the correct wording, "unspecified order". Not "random order",
>> because then some poor bloke will start to rely on GetNext() jumping among
>> values, and then somebody will implement the interface with a red-black
>> tree.
>
> Interestingly, the major hash implementations I know of are now all
> consistent in order; if you request a walk of the hash, you get the items
> in insertion order unless you've sorted them into a different order. Thus,
> ordering is separate from keys.

The new C++ unordered containers have unspecified order. At least with
the boost versions, the order depends on the number of items in the
container and the hash bucket size.

--
Ian Collins

== 8 of 15 ==
Date: Mon, Apr 12 2010 3:39 pm
From: Ian Collins

On 04/13/10 08:41 AM, Seebs wrote:
> On 2010-04-12, Ian Collins<ian-news@hotmail.com> wrote:
>> But you only replied to one, so the debate never got going.
>
> I'm pretty sure he's killfiled me, which turns out to remove about
> half of the responses to his container library posts and discussion.

He appears to have done the same to me, so that removes half of the rest!

--
Ian Collins

== 9 of 15 ==
Date: Mon, Apr 12 2010 3:56 pm
From: Seebs

On 2010-04-12, jacob navia <jacob@spamsink.net> wrote:
> I wrote a function GetKeys() that returns a string collection with all
> stored keys. Is that what you need?

No. Think of the Lua:
for i,v in pairs(table) do
-- i is index, v is table[i]
end

or the Ruby
table.each_pair do |i,v|
# i is index, v is table[i]
end

or the PHP
foreach ($table => $i, $v) {
# you get the idea
}

That is by FAR the most common way for me to iterate on a hash.

>> I don't think that's the right way to do it -- it should be an attribute
>> of the iterator, not of the tree.

> Impossible because that would be container specific (trees) and would
> not work with lists.

And this is why I don't think a container library is viabel.

> What is important to remember is basic software design principles.
> Information hiding means that the user doesn't NEED to know if the
> container is a tree or a list. This is a central point in the design of
> the library.

That makes it "worst-of-all-worlds". I'd probably go for a design
where GetIterator() has an interface akin to the UNIX fcntl(), where
the available options and flags depend on the kind of thing you're
working with.

The point, I guess, is... Yes, I *DO* need to know whether I'm working with
a tree or a list, because I'm going to pick one that fits my application.

If all I get is a completely generic interface, it's going to be incapable
of doing the things that would make one or another of them useful!

> The learning curve is MUCH smaller. The surface that the library
> uses in your memory is smaller.

And the functionality is much smaller.

Enough smaller that you might as well just pick one of them, implement
only that, and leave the others out of it, since they won't be good
enough anyway.

That, I think, is the problem with the "only those features which are
completely generic can be implemented" philosophy that a generic "container"
imposes on you.

== 10 of 15 ==
Date: Mon, Apr 12 2010 4:21 pm
From: Tim Rentsch

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-04-12, Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Step 4: Refrain from making any kind of ad hominem remark,
>> against anyone, in any posting. Assuming the choice has
>> been made to write a response/followup, write about what
>> was written, not about the person who wrote it. Calling
>> someone a "troll" (or any other such appellation) is just
>> as much part of the problem as whatever it was the "troll"
>> did in the first place.
>
> I'm not convinced of that. Overall, DNFTT seems to rely to
> some extent on convincing people that a given person is, in
> fact, a troll. People who don't believe that are unlikely to
> participate in avoiding/ignoring the troll.

It sounds like you're assuming that people won't conclude that
person X is engaging in anti-social behavior unless someone
posts a message saying "person X engages in anti-social
behavior." I submit that this assumption is false; most people
realize who engages in egregious behavior (by their own
standards of course) without needing to have it pointed out. I
encourage you to run an experiment to test out this hypothesis.
Simply refrain from making ad hominem remarks for a month or two
and see if the average quality in the newsgroup goes up. I have
been running my own personal experiment along these lines for
several years now, and I am quite satisfied.

> Sometimes, it really *does* matter what you think of the person,
> not just what you think of the post.

Of course it does, but having it matter to me personally
and saying that it also should matter to other people
are two very different things. People are welcome to hold
any personal opinions they choose, but when they start
trying to convince me that I should hold the same opinions
they do I consider that a verbal assault at some level.

> As an example, look at
> Bill Cunningham's endless series of combinations of newbie
> questions. A reasonable response to those from someone who has
> never seen one before is *very* different from a resaonable response
> to them from someone who's seen his last decade or so of asking
> questions and then ignoring the answers, or "learning" something
> only to have no idea even what the words used to describe it are
> a few months later.

Note that we don't have to make any ad hominem remark about Bill
Cunningham to communicate the important information here. Saying
"postings from Bill Cunningham have been asking basically the same
questions and getting the same answers for the last 15 years" (or
whatever fits the actual history) is only a comment about what
he's written, not about him. Saying things about the _writing_
should always be appropriate; saying things about the _writer_
almost never is.

== 11 of 15 ==
Date: Mon, Apr 12 2010 4:21 pm
From: Ian Collins

On 04/13/10 10:56 AM, Seebs wrote:
> On 2010-04-12, jacob navia<jacob@spamsink.net> wrote:
>
>> What is important to remember is basic software design principles.
>> Information hiding means that the user doesn't NEED to know if the
>> container is a tree or a list. This is a central point in the design of
>> the library.
>
> That makes it "worst-of-all-worlds". I'd probably go for a design
> where GetIterator() has an interface akin to the UNIX fcntl(), where
> the available options and flags depend on the kind of thing you're
> working with.
>
> The point, I guess, is... Yes, I *DO* need to know whether I'm working with
> a tree or a list, because I'm going to pick one that fits my application.
>
> If all I get is a completely generic interface, it's going to be incapable
> of doing the things that would make one or another of them useful!

True, consider reverse iteration as a concrete example.

This is one reason why C++ container are split into four (soon to be
five) categories: containers, reversible containers, sequence containers
and associative containers. Each category has a common set of interface
requirements.

>> The learning curve is MUCH smaller. The surface that the library
>> uses in your memory is smaller.
>
> And the functionality is much smaller.
>
> Enough smaller that you might as well just pick one of them, implement
> only that, and leave the others out of it, since they won't be good
> enough anyway.

Quite.

--
Ian Collins

== 12 of 15 ==
Date: Mon, Apr 12 2010 4:30 pm
From: Tim Rentsch

jacob navia <jacob@spamsink.net> writes:

> Morris Keesan a @C3{A9}crit :
>> Quoting someone on a BBC radio programme from a few weeks ago:
>>
>> -"Remember, if you choose to argue with an idiot, the best possible
>> outcome is that you've won an argument with an idiot."-
>>
> Well, there were around 270 messages in the first thread about
> Schildt's book, and there are several hundreds in the following
> messages.
>
> When I posted a request about allocators for the container library, I
> received 2 answers. [snip elaboration]

Hi Jacob,

If you wouldn't mind a personal suggestion --

if you could manage to be more temperate in your writing, you
might find more people would participate in the discussions
you're interested in. Just an idea for further meditation.

== 13 of 15 ==
Date: Mon, Apr 12 2010 4:31 pm
From: "Ersek, Laszlo"

On Tue, 13 Apr 2010, jacob navia wrote:

> the user doesn't NEED to know if the container is a tree or a list

(I don't really know about the context, but that won't hold me back.)

I do need to know if the container is a tree or a list. They offer
different time complexities.

I claim that once you've chosen your operations and clarified your time
complexity expectations, perhaps also considering the highest number of
elements and the constant factors, you might as well have chosen the exact
data structure. I further claim that you (should) never choose a container
without clarifying your complexity expectations.

lacos

== 14 of 15 ==
Date: Mon, Apr 12 2010 4:34 pm
From: Seebs

On 2010-04-12, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> It sounds like you're assuming that people won't conclude that
> person X is engaging in anti-social behavior unless someone
> posts a message saying "person X engages in anti-social
> behavior." I submit that this assumption is false; most people
> realize who engages in egregious behavior (by their own
> standards of course) without needing to have it pointed out.

Not quite. I'm assuming they won't figure it out very quickly -- and
that means that, as long as there's a regular supply of new users,
the troll has a regular supply of feeders.

> I encourage you to run an experiment to test out this hypothesis.
> Simply refrain from making ad hominem remarks for a month or two
> and see if the average quality in the newsgroup goes up. I have
> been running my own personal experiment along these lines for
> several years now, and I am quite satisfied.

I've experimented with varieties of this in a few cases, and what I've
found is that a reasonably polite and dispassionate reminder to newbies
that a given poster is trolling them and will not engage is usually
productive, while calling someone a troll while addressing them is usually
not productive.

> Of course it does, but having it matter to me personally
> and saying that it also should matter to other people
> are two very different things. People are welcome to hold
> any personal opinions they choose, but when they start
> trying to convince me that I should hold the same opinions
> they do I consider that a verbal assault at some level.

Well, if I want the group to be usable, it *does* matter to me whether
other people spend time responding to the trolls.

> Note that we don't have to make any ad hominem remark about Bill
> Cunningham to communicate the important information here. Saying
> "postings from Bill Cunningham have been asking basically the same
> questions and getting the same answers for the last 15 years" (or
> whatever fits the actual history) is only a comment about what
> he's written, not about him. Saying things about the _writing_
> should always be appropriate; saying things about the _writer_
> almost never is.

The exact boundary is pretty arbitrary. You can talk about writing about
the person, vs. writing about the posts. You can talk about addressing
the person directly, vs. addressing other participants. Any of these
basically come down to the same thing; don't fight with the troll, just
warn people that they're not going to get anywhere. Doesn't seem to
matter much whether the exact phrasing is in terms of "this person is
a troll" or "this person's posts do not lead to productive conversation".
They mean the same thing and everyone knows it.

== 15 of 15 ==
Date: Mon, Apr 12 2010 5:26 pm
From: spinoza1111

On Apr 13, 2:12 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-04-12, osmium <r124c4u...@comcast.net> wrote:
>
> > Richard Heathfield wrote:
> >> Do you honestly think the S/N ratio will improve if the noisemakers go
> >> unchallenged?
> > No question at all about it, yes. Spinoza can make, maybe five posts a day,
> > but attracts responses like a turd in the middle of the street attracts
> > crows. Look at the Spinoza threads and see how many are made by him and how
> > many are made by others.
>
> I think he makes way more than five a day. But yes, he does tend to end up
> with more responses than his original posts. And yes, I would agree that
> at this point, "challenging" the noisemakers isn't doing anything.

This is a (cowardly) response to me. I don't think you really have the
self-discipline to truly ignore a person, because you've been defined
as my anti-particle and you are in a zero-sum game that you're
losing.

Whereas I would pay you no attention whatsoever, because you're not a
good programmer, your ideas are without any merit, and you're a nasty
piece of work, save for the fact that I have found that you're the
source and the perpetrator of an interesting case of Internet bullying
I need to reverse, and possibly document for a book, on Internet
bullying by "professionals".

>
> Step 1: Killfile Nilges.
> Step 2: Encourage other people to do so.
> Step 3: Try to keep responses to anything in his threads strictly topical.
> Step 4: ???
> Step 5: Profit!
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

==============================================================================
TOPIC: small question
http://groups.google.com/group/comp.lang.c/t/08850414dcd0b366?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Apr 12 2010 2:59 pm
From: pete

Bill Cunningham wrote:

> Ok we were talking about &hint being a pointer.
> Then I asked if there
> could be another way of passing this hint as a pointer
> in a different way.
> You replied no why do something else when what works works.
> I tried to say there might be *this* way to do it
> and gave two bad examples concerning pointer arithmetic.

/*
** Here's the long way:
*/
struct addrinfo hints;

int main()
{
struct addrinfo *pointer = &hints;

memset(pointer, '\0', sizeof hints);

--
pete

==============================================================================
TOPIC: Son of Snarky Tirade: a response to Seebach's new CTCN: part 1
http://groups.google.com/group/comp.lang.c/t/383e6d5a95dc3f75?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Apr 12 2010 3:13 pm
From: Tim Rentsch

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On 11 Apr, 15:52, Willem <wil...@turtle.stack.nl> wrote:
>> spinoza1111 wrote:
>>
>> It means "invalid" arguments (arguments in which
>> ) the conclusion doesn't follow from the premises) in which the premise
>> ) is the bad character of the person making the assertion you would like
>> ) to refute in a matter unrelated to his character.
>>
>> And that is exactly what you did.
>> Your 'refutations' were based upon (your perceptions of) Seebach
>> as a person and had nothing to do with the criticisms themselves.
>>
>> Your text is a textbook example of argumentam ad-hominem.
>>
> Ad hominem is a bit more subtle than it might first appear. The ad
> hominem fallacy is to assert that an argument is wrong or invalid
> because of the person who is making it. However we do this all the
> time. No-one's bothered what some schoolkid says about the deficit
> reduction plan. If some central banker says "this is the only policy
> which will reduce the deficit without substantial economic
> dislocation", everyone sits up and takes notice.

This description glosses over an important distinction. Almost
everyone uses ad hominem judgments in forming their own
opinions, in their own private thoughts. That's quite different
from making an ad hominem argument as part of a public
statement. I choose whom I listen to, and sometimes whom not
to, because it's my decision and I have only so much time to
spend. But making such a statement in a public forum is like
saying, "You shouldn't listen to person X, because _I_ don't
think he's worth listening to." Each person has a right to
choose for themselves which people are worth listening to, using
whatever criteria they think are important. Arguments should be
made based on merit; arguments based on personalities are a
waste of bandwidth.

==============================================================================
TOPIC: seebs/schildt II
http://groups.google.com/group/comp.lang.c/t/c86133d7ad6b90c2?hl=en
==============================================================================

== 1 of 4 ==
Date: Mon, Apr 12 2010 3:18 pm
From: Tim Streater

In article
<75b624af-5e23-49c9-b6a0-f96137959602@g9g2000vba.googlegroups.com>,
William Hughes <wpihughes@hotmail.com> wrote:

> On Apr 12, 1:34 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> <snip>
>
> > ..constructive discourse (such as the fact that
> > the purpose of int main() is to make Linux into a standard, or the
> > fact that C semantics was not defined properly in C99 owing to vendor
> > greed)
>
> The mind boggles.

Even better than that was the bit about DOS being a form of unix.

--
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689

== 2 of 4 ==
Date: Mon, Apr 12 2010 5:10 pm
From: William Hughes

On Apr 12, 7:18 pm, Tim Streater <timstrea...@waitrose.com> wrote:
> In article
> <75b624af-5e23-49c9-b6a0-f96137959...@g9g2000vba.googlegroups.com>,
> William Hughes <wpihug...@hotmail.com> wrote:
>
> > On Apr 12, 1:34 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> > <snip>
>
> > > ..constructive discourse (such as the fact that
> > > the purpose of int main() is to make Linux into a standard, or the
> > > fact that C semantics was not defined properly in C99 owing to vendor
> > > greed)
>
> > The mind boggles.
>
> Even better than that was the bit about DOS being a form of unix.
>

You're joking right ?!? PLEASE tell me you're joking!

- William Hughes

== 3 of 4 ==
Date: Mon, Apr 12 2010 5:27 pm
From: spinoza1111

On Apr 13, 3:20 am, William Hughes <wpihug...@hotmail.com> wrote:
> On Apr 12, 1:34 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> <snip>
>
> > ..constructive discourse (such as the fact that
> > the purpose of int main() is to make Linux into a standard, or the
> > fact that C semantics was not defined properly in C99 owing to vendor
> > greed)
>
> The mind boggles.

...some inferior minds have a tendency to "boggle"; the brain slides
around the brain pan as it shrinks.

>
> - William Hughes

== 4 of 4 ==
Date: Mon, Apr 12 2010 5:33 pm
From: spinoza1111

On Apr 13, 3:59 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-04-12, William Hughes <wpihug...@hotmail.com> wrote:
>
> > On Apr 12, 1:34 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> ><snip>
> >> ..constructive discourse (such as the fact that
> >> the purpose of int main() is to make Linux into a standard, or the
> >> fact that C semantics was not defined properly in C99 owing to vendor
> >> greed)
> > The mind boggles.
>
> Yes, rather. The return type of main predates Linux by upwards of a decade.

Yes, because Torvalds essentially stole unix, a 1970s operating
system, from the author of a book about unix for the PC, a unix called
Minix. I had that book and was shocked that Torvalds would so steal
the work of another, but it seems that computer authors are fair game
for bullying and theft. Gates was right in 1976; most "hackers" are
criminals. Most are common thieves, others are stalkers.

> The "vendor greed" thing... well, he's been asked before, and he's never
> produced a shred of evidence, nor addressed the obvious fact that, if vendors
> wanted to save work, there are a lot of features that would not have been
> proposed and expanded on by vendors.

Can you identify some of them? They are outweighed by the situations
in which you declared that common constructs such as the void main
were invalid even when the final standard says (clumsily) that they
are, hosted v freestanding being the clumsy result of the Linux bigots
insistence on a crazy legacy feature. They are outweighed by the
instances of nondeterministic semantics.
>
> -s
> --
> Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nos...@seebs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny pictureshttp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

==============================================================================
TOPIC: Generic linked list with internal storage?
http://groups.google.com/group/comp.lang.c/t/d36ff63bef634bcc?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Apr 12 2010 3:35 pm
From: Tim Rentsch

Nick <3-nospam@temporary-address.org.uk> writes:

> Jef Driesen <jefdriesen@hotmail.com.invalid> writes:
>
>> From: Jef Driesen <jefdriesen@hotmail.com.invalid>
>> Subject: Re: Generic linked list with internal storage?
>> Newsgroups: comp.lang.c
>> Date: Fri, 09 Apr 2010 13:47:49 +0200
>> Organization: BELNET - The Belgian Research Network
>>
>> On 9/04/2010 12:45, bartc wrote:
>>>> A typical (double) linked list is implemented with these two data
>>>> structures:
>>>>
>>>> typedef struct node_t {
>>>> node_t *prev;
>>>> node_t *next;
>>>> void *data;
>>>> } node_t;
>>>>
>>>> typedef struct list_t {
>>>> node_t *head;
>>>> node_t *tail;
>>>> } list_t;
>>>>
>>>> typedef struct mydata_t {
>>>> ...
>>>> } mydata_t;
>>>>
>>>> The major disadvantage of this approach is that the data contents of the
>>>> list needs to be stored outside of the list data structures. Thus if you
>>>> want to store some user defined data in the list, you end up with two
>>>> memory allocations per node: one for the node_t structure, and one for the
>>>> user defined mydata_t structure.
>>>>
>>>> Is there a way to avoid this additional allocation, but without loosing
>>>> the ability to store custom data?
>>>
>>> Why not include a node_t (or just next and prev pointers) at the start of
>>> the mydata_t struct?
>>>
>>> (The list_t stuff would have to be a bit different though, either a
>>> dedicated list_t for each mydata_t, or discrete head/tail pointers of type
>>> *mydata_t)
>>
>> That makes the list is non generic, and that's not what I want.
>
> But you write generic functions that work on a simple structure with
> just the next and prev pointers. You just cast your specific structures
> to these, and cast back to the specific types in your callback function.
>
> The only constraint is that you have to have the same next/prev pointers
> order in any structure that the generic functions work on.
>
> This works because all structure pointers can be cast to others, and all
> structures with common initial sequences have the same alignment for
> that part.

Actually I'm pretty sure that's not guaranteed. That is,
even though the offsets of the corresponding members might
have to be the same, the alignment of the struct as a whole
might be different. For example, if we have

struct foo { int i; double d; char b[4]; };
struct bas { int i; double d; char b[1]; };

I believe it's allowed for the alignment of a 'struct foo'
to be 4 even though the alignment of a 'struct bas' might
be only 1. I doubt any implementations actually do this,
but it's allowed (isn't it?) and not really so far-fetched
that an implementation that had made such a choice could
go badly wrong if a (struct bas*) were being used as a
(struct foo*).

== 2 of 2 ==
Date: Mon, Apr 12 2010 5:05 pm
From: Gene

On Apr 12, 6:35 pm, Tim Rentsch <t...@alumni.caltech.edu> wrote:
> Nick <3-nos...@temporary-address.org.uk> writes:
> > Jef Driesen <jefdrie...@hotmail.com.invalid> writes:
>
> >> From: Jef Driesen <jefdrie...@hotmail.com.invalid>
> >> Subject: Re: Generic linked list with internal storage?
> >> Newsgroups: comp.lang.c
> >> Date: Fri, 09 Apr 2010 13:47:49 +0200
> >> Organization: BELNET - The Belgian Research Network
>
> >> On 9/04/2010 12:45, bartc wrote:
> >>>> A typical (double) linked list is implemented with these two data
> >>>> structures:
>
> >>>> typedef struct node_t {
> >>>> node_t *prev;
> >>>> node_t *next;
> >>>> void *data;
> >>>> } node_t;
>
> >>>> typedef struct list_t {
> >>>> node_t *head;
> >>>> node_t *tail;
> >>>> } list_t;
>
> >>>> typedef struct mydata_t {
> >>>> ...
> >>>> } mydata_t;
>
> >>>> The major disadvantage of this approach is that the data contents of the
> >>>> list needs to be stored outside of the list data structures. Thus if you
> >>>> want to store some user defined data in the list, you end up with two
> >>>> memory allocations per node: one for the node_t structure, and one for the
> >>>> user defined mydata_t structure.
>
> >>>> Is there a way to avoid this additional allocation, but without loosing
> >>>> the ability to store custom data?
>
> >>> Why not include a node_t (or just next and prev pointers) at the start of
> >>> the mydata_t struct?
>
> >>> (The list_t stuff would have to be a bit different though, either a
> >>> dedicated list_t for each mydata_t, or discrete head/tail pointers of type
> >>> *mydata_t)
>
> >> That makes the list is non generic, and that's not what I want.
>
> > But you write generic functions that work on a simple structure with
> > just the next and prev pointers. You just cast your specific structures
> > to these, and cast back to the specific types in your callback function.
>
> > The only constraint is that you have to have the same next/prev pointers
> > order in any structure that the generic functions work on.
>
> > This works because all structure pointers can be cast to others, and all
> > structures with common initial sequences have the same alignment for
> > that part.
>
> Actually I'm pretty sure that's not guaranteed. That is,
> even though the offsets of the corresponding members might
> have to be the same, the alignment of the struct as a whole
> might be different. For example, if we have
>
> struct foo { int i; double d; char b[4]; };
> struct bas { int i; double d; char b[1]; };
>
> I believe it's allowed for the alignment of a 'struct foo'
> to be 4 even though the alignment of a 'struct bas' might
> be only 1. I doubt any implementations actually do this,
> but it's allowed (isn't it?) and not really so far-fetched
> that an implementation that had made such a choice could
> go badly wrong if a (struct bas*) were being used as a
> (struct foo*).

But the structs having different alignments don't cause a problem for
the "generic" list implementation. The Standard requires that a
pointer to one will access the common initial fields of the other.

==============================================================================
TOPIC: Test of a preprocessor symbol defined as nothing vs. zero
http://groups.google.com/group/comp.lang.c/t/8e4236bf3f19c661?hl=en
==============================================================================

== 1 of 2 ==
Date: Mon, Apr 12 2010 5:11 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>If you are really trying to get something that works for pre-ANSI C then
>you need to remember that K&R C does not say what happens in case A
>where FOO is not defined.

I remember that in the 80s, I had some (well, at least
one - I am not sure how many) compilers that only would
accept »#ifdef« or »#ifnder«, but not »#if«.

There also were those »Tiny-C« compilers (maybe with source
code listed in the Byte Magazine?), who implemented subsets
of C.

The C of 1972 did not had a preprocessor.

1972 - 1973 the preprocessor was added

The C of 1974 only had »#define« and »#include«.

Conditional compilation was added not much later, but I
was not able to find a specific date.

== 2 of 2 ==
Date: Mon, Apr 12 2010 5:28 pm
From: ram@zedat.fu-berlin.de (Stefan Ram)

Mark Adler <madler@alumni.caltech.edu> writes:
>Age doesn't necessarily have anything to do with it. I would very much
>like to live in a world where compilers (and preprocessors) that
>claimed to conform to a standard actually did.

Amazon recently partially refunded a customer 20 percent of
the price

http://www.neogaf.com/forum/showthread.php?s=1581adddabd67ea3e7650581cbfa3ec0&p=20573361#post20573361

of a product after the customer has advised Amazon of the EU
directive

http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX%3A31999L0044%3Ade%3AHTML

, which says that a retail-dealer (not the manufacturer) has
to give a two-year warranty that a product sold really has
the features that are advertised for it. The customer had
bought a playstation 3, which was advertised to support
Linux, but now will not support Linux anymore.

According to German law, when a retail dealer sells you a
software said to compile C programs, but it does not compile
C programs, you are possibly entitled to a partial refund or
to a rescission of the purchase or to a remediation of the
defect. But due to the diffulty of the application of such
laws, one can not be sure what really will happen, when a
customer tries to get such a refund in the case of a C
compiler.

(The contents of this post follows a recent news report of
the »Heise Zeitschriften Verlag«.)

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

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

twitter

Monday, April 12, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts