Endless arguing
Morris Keesan
-"Remember, if you choose to argue with an idiot, the best possible
outcome is that you've won an argument with an idiot."-
--
Morris Keesan -- mke...@post.harvard.edu
James Harris
> 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."-
There's some truth in the quote but there are other factors to
consider.
For example, if none of the careful deceits and misrepresentations are
challenged someone reading the words - either now or at some time in
the future - may believe them to be true.
James
osmium
No single human could possibly have any effect on the amount of faulty
information that exists. You might as well decide to stop the ocean tides.
Army1987
>> For example, if none of the careful deceits and misrepresentations are
>> challenged someone reading the words - either now or at some time in
>> the future - may believe them to be true.
>
> No single human could possibly have any effect on the amount of faulty
> information that exists. You might as well decide to stop the ocean
> tides.
It is possible to clean all the streets in Paris in one quarter of an
hour: all that is needed is for everybody to clean the street they live
in.
stan
Do you honestly think that can justify the S/N here?
Kenny McCormack
Right or wrong, that *is* the justification given for why the "regs"
can't resist talking to the "trolls". In fact, that's the basic reason
why we "trolls" post in the first place - because we can't stand to see
the nonsense that the "regs" post go unchallenged.
--
(This discussion group is about C, ...)
Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...
Seebs
> No single human could possibly have any effect on the amount of faulty
> information that exists. You might as well decide to stop the ocean tides.
Is that true? You should check snopes.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
jameskuyper
That's a bad analogy. Responding to a troll does not remove the
garbage he's already produced; it's more closely analogous to putting
up a flag next to the garbage, warning people of it's presence.
Furthermore, that "flag" has a nasty side-effect: it encourages the
troll to produce more garbage.
Fixing up your analogy to match this reality would involve having the
people of Paris act like idiots (and I'm not trying to suggest that
they are): instead of removing the garbage, each one would have to put
out a piece of food next to each piece of garbage they found on their
own street - to warn people that there's a piece of garbage there.
Various animals would come by to eat the food, adding their own fresh
contribution to the garbage. The citizens of Paris would put out more
food to mark the fresh garbage, etc... How quickly would the streets
of Paris be cleaned up by that approach?
Trying to combat trolls by pointing out their errors may not seem as
stupid as the above behavior. However, it's equally counterproductive,
and the "end" results are of comparable quality.
jacob navia
> 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."-
>
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.
Yes, TWO, much less than the guy that asked the answer of 0.5*0.5. This
shows the priorities of people here. Most of them aren't able to follow
a technical discussion or have no interest in technical discussions, the
C language or whatever. Their only interest is showing off, inflating
their (already bloated) egos, and similar nonsense.
jacob
Richard Heathfield
Do you honestly think the S/N ratio will improve if the noisemakers go
unchallenged?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Seebs
> When I posted a request about allocators for the container library, I
> received 2 answers.
I don't know about the recent one, but I know I've responded to previous
questions on that topic.
It's not a topic I am hugely invested in, just because I don't think a
container library is a good fit for the way I've usually seen C used, but
I think it's interesting, and I have certainly made suggestions about it.
Fundamentally, though, you're working on something that most of the people
here don't think they need, and you aren't saying things which are hilariously
over the top and obviously wrong. When you do say things which are obviously
wrong, you get more responses, but they're all corrections.
I suspect some of what you're seeing is inertia of various forms; most of us
already have or don't need a list library, for instance. I quite simply
can't comprehend when I'd end up wanting a "container". I can see when I
want lists, or when I want arrays, but I can't conceive of ever writing a
piece of code in which I want a container but don't care which of those it
is, or in which my choice of list or array would change. As a result, I
simply don't see "container" as a useful abstraction for writing code.
A similar design for, say, a hash library, which was unambiguously a library
for hashes and not for any other sort of thing, might be very interesting
to me, because I've not been especially happy with the hash libraries I've
seen.
osmium
> 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.
Seebs
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.
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!
Keith Thompson
> stan wrote:
>> James Harris wrote:
>>> On 12 Apr, 05:00, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
>>>
>>>> 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."-
>>> There's some truth in the quote but there are other factors to
>>> consider.
>>>
>>> For example, if none of the careful deceits and misrepresentations are
>>> challenged someone reading the words - either now or at some time in
>>> the future - may believe them to be true.
>>
>> Do you honestly think that can justify the S/N here?
>
> Do you honestly think the S/N ratio will improve if the noisemakers go
> unchallenged?
YES!
The vast majority of Nilges' posts are responses to responses to his
earlier posts. Attempts to address his technical errors, even while
ignoring his crap, result in more of his crap.
I don't know whether he would stop posting if everyone ignored him,
but I suspect his volume would drop considerably, and what we're doing
now certainly isn't working.
--
Keith Thompson (The_Other_Keith) ks...@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"
Seebs
> The vast majority of Nilges' posts are responses to responses to his
> earlier posts. Attempts to address his technical errors, even while
> ignoring his crap, result in more of his crap.
Yes. Perhaps more importantly, they almost never result even in
*improved* crap. It's not as if he's improving.
> I don't know whether he would stop posting if everyone ignored him,
> but I suspect his volume would drop considerably, and what we're doing
> now certainly isn't working.
Usually, they escalate further and further to try to continue to
elicit narcissistic supply (responses, especially responses which
appear to imply that he's got some kind of point or qualification),
and eventually melt down completely and go do something else.
Oddly, critics are nearly as good a response as praise. They at
least imply that he's really participating and shaping outcomes.
Ersek, Laszlo
> On 2010-04-12, jacob navia <ja...@spamsink.net> wrote:
>> When I posted a request about allocators for the container library, I
>> received 2 answers.
> I suspect some of what you're seeing is inertia of various forms; most
> of us already have or don't need a list library, for instance. I quite
> simply can't comprehend when I'd end up wanting a "container". I can
> see when I want lists, or when I want arrays, but I can't conceive of
> ever writing a piece of code in which I want a container but don't care
> which of those it is, or in which my choice of list or array would
> change. As a result, I simply don't see "container" as a useful
> abstraction for writing code.
I concur. Grouping containers by space and time efficiency seems useful,
but only for supporting the programmer in choosing one. Abstracting an
interface from container "backends" that are replaceable between
"performance classes" seems leaky (or, in the other direction,
inflexible).
Looking back:
From: la...@ludens.elte.hu (Ersek, Laszlo)
Subject: Re: Idioms for iterators in C
Date: 28 Jan 2010 20:57:50 +0100
Message-ID: <CKNteOnyVaBo@ludens>
> [...] With the exception of foo_close() and foo_delete(), all foo_*()
> operations should try not to invalidate any existing iterator.
> foo_delete() should take an iterator and try not to invalidate any
> iterator pointing elsewhere. [...]
From: Eric Sosman <eso...@ieee-dot-org.invalid>
Subject: Re: Idioms for iterators in C
Date: Thu, 28 Jan 2010 18:06:09 -0500
Message-ID: <hjt5a9$6b7$1...@news.eternal-september.org>
> On 1/28/2010 5:00 PM, Richard Harter wrote:
>> On 28 Jan 2010 20:57:50 +0100, la...@ludens.elte.hu (Ersek,
>> Laszlo) wrote:
>>> With the exception of foo_close() and foo_delete(), all foo_*()
>>> operations should try not to invalidate any existing iterator.
>>> foo_delete() should take an iterator and try not to invalidate any
>>> iterator pointing elsewhere.
>>
>> Sossman's iterator objects seem appropriate.
>
> Three points: First, concrete iterator objects are by no means
> original with me. Second, I think you'll find it difficult to make an
> iterator behave sensibly if the container is modified while an iteration
> is in progress (think of a hash table that gets re-hashed when an
> insertion makes it too crowded). Third (and most important), there are
> only two S'es in "Sosman."
If I ever intended to unify iterator interfaces at all, that was about the
end of it. As soon as I wanted to bolt something "really useful" on an
iterator interface, it was immediately shown to be container specific. I
took it as proof that my pursuit is futile.
lacos
jacob navia
>
> If I ever intended to unify iterator interfaces at all, that was about
> the end of it. As soon as I wanted to bolt something "really useful" on
> an iterator interface, it was immediately shown to be container
> specific. I took it as proof that my pursuit is futile.
I have found the solution.
There is the "Iterator" object with 3 fields:
GetNext
GetPrevious
GetFirst
This 3 function pointers yield a pointer to each stored object,
or NULL when there are none.
Now, newIterator(container) builds a *container specific* structure
with the "iterator" structure at the start. Then, it returns a pointer
to the start. Get next receives this iterator specific structure
and is iterator specific without the user seeing it.
This way I have the best of both worlds: container specific code
AND generic interface for the user:
Iterator *it = newIterator(list_container);
it is a pointer to the first part of the list iterator. The list
iterator has many other fields that the user doesn't see. When you call
void *obj = it->GetFirst(it);
The it->GetFirst() routine is a list container specific routine that
looks into the hidden fields of "iterator" and does its tricks!
This works like a charm.
I solved your problem. Now, it would be nice if you worked with me
and we could develop this together. I can't do everything alone.
Thanks for your contribution
:-)
Seebs
> GetNext
> GetPrevious
> GetFirst
Hmm.
> This 3 function pointers yield a pointer to each stored object,
> or NULL when there are none.
Okay.
> Now, newIterator(container) builds a *container specific* structure
> with the "iterator" structure at the start. Then, it returns a pointer
> to the start. Get next receives this iterator specific structure
> and is iterator specific without the user seeing it.
Seems reasonable.
> I solved your problem. Now, it would be nice if you worked with me
> and we could develop this together. I can't do everything alone.
An obvious issue suggests itself. One of the most useful containers is
the "hash" -- that's sort of a perlism as a name, but basically, an
associative array in which each member has a key, but keys are not necessarily
a numerically-ordered list.
So, if I call GetFirst() on such a thing, how/where do I find out what key
is associated with the first item?
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!)
Ian Collins
> Morris Keesan a é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.
But you only replied to one, so the debate never got going.
--
Ian Collins
Tim Rentsch
> On 2010-04-12, osmium <r124c...@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.
>
> 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!
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.
Seebs
> 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.
Sometimes, it really *does* matter what you think of the person,
not just what you think of the post. 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.
Seebs
> 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.
(At least, I don't recall having received any acknowledgement of or
response to any of my questions, comments, suggestions, or other feedback
about it in recent months.)
Eric Sosman
> [...]
> An obvious issue suggests itself. One of the most useful containers is
> the "hash" -- that's sort of a perlism as a name, but basically, an
> associative array in which each member has a key, but keys are not necessarily
> a numerically-ordered list.
>
> So, if I call GetFirst() on such a thing, how/where do I find out what key
> is associated with the first item?
For what it's worth, Java deals with this issue in three ways.
First, you can iterate over the "key set" of the hash table, getting
each key once and once only and using it (if you like) to look up the
associated value. Second, you can iterate over the "values," getting
each value exactly as many times as it appears but learning nothing
about the keys (unless the values themselves refer to their own keys,
which is an extra-container mechanism). Finally, you can iterate over
the "mapping," getting each key/value pair exactly once. In all three
styles, the order in which keys/values/pairs are visited is whatever
the hash table feels like.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Ersek, Laszlo
> Ersek, Laszlo a écrit :
>>
>> If I ever intended to unify iterator interfaces at all, that was about the
>> end of it. As soon as I wanted to bolt something "really useful" on an
>> iterator interface, it was immediately shown to be container specific. I
>> took it as proof that my pursuit is futile.
>
>
> [...]
>
> I solved your problem. Now, it would be nice if you worked with me and
> we could develop this together. I can't do everything alone.
>
> Thanks for your contribution
>
> :-)
You made me laugh (in the best sense of the word); great style, thanks :)
I'll respond to the meat of your posting by piggybacking Seebs' answer.
Cheers,
lacos
Ersek, Laszlo
> On 2010-04-12, jacob navia <ja...@spamsink.net> wrote:
>> There is the "Iterator" object with 3 fields:
>
>> GetNext
>> GetPrevious
>> GetFirst
>
> Hmm.
Oh yes, "Hmm" it is! Why not GetLast() too? forward iterator, backward
iterator, bidirectional iterator; one kind to return non-const pointers
(to nodes or to objects, see next point), one kind to return const
pointers. It may not be a simple matter of casting, as the iterator is
stateful, and const and non-const iterators may react differently to
whole-structure modifications. Or something like that.
>> This 3 function pointers yield a pointer to each stored object,
>> or NULL when there are none.
>
> Okay.
Hmm, nope. I wish to be able to store null pointers in the structure.
>> Now, newIterator(container) builds a *container specific* structure
>> with the "iterator" structure at the start. Then, it returns a pointer
>> to the start. Get next receives this iterator specific structure and is
>> iterator specific without the user seeing it.
>
> Seems reasonable.
To an extent, yes. But this is a quite featureless iterator; the
"inflexible" case in my previous post. We didn't talk about what happens
to existing iterators when I delete (a currently pointed-to, or a
completely unrelated) element. Can I assign iterators? Can I fork
iterations? We'll need a bunch of iterator characteristics, organize them
into characteristics-sets, and build a hierarchy of them with the
subset-of operator.
>> I solved your problem. Now, it would be nice if you worked with me
>> and we could develop this together. I can't do everything alone.
>
> An obvious issue suggests itself. One of the most useful containers is
> the "hash" -- that's sort of a perlism as a name, but basically, an
> associative array in which each member has a key, but keys are not necessarily
> a numerically-ordered list.
>
> So, if I call GetFirst() on such a thing, how/where do I find out what key
> is associated with the first item?
>
> 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!)
There, you've said it.
Perhaps we should make the GetIterator() "factory" function to take a
variable argument list. Or we could make concrete containers with concrete
iterators, and allow the programmer to create *ad-hoc* wrappers, like
GetFirst(), GetNext(), GetPrevious(), for containers and iterators he
knows for sure he'll use.
(I'm not necessarily agreeing with myself on this, but it is an
interesting standpoint to explore, I find.)
Cheers,
lacos
Ersek, Laszlo
> 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.
lacos
Default User
"stan" <smo...@exis.net> wrote in message news:jmob97-...@invalid.net...
> James Harris wrote:
>> For example, if none of the careful deceits and misrepresentations are
>> challenged someone reading the words - either now or at some time in
>> the future - may believe them to be true.
>
> Do you honestly think that can justify the S/N here?
I agree. You can't beat trolls by arguing. The only way is to completely
freeze them out.
Brian
Ersek, Laszlo
> On 2010-04-12, Ian Collins <ian-...@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.
> (At least, I don't recall having received any acknowledgement of or
> response to any of my questions, comments, suggestions, or other feedback
> about it in recent months.)
Willfully ignoring the actual question of Seebs being present in jacob's
killfile or not, this is *exactly* my problem. I planned to follow up on
Richard Heathfield's posting, but now I'm drawn to do it here instead:
On Mon, 12 Apr 2010, Richard Heathfield wrote:
> Do you honestly think the S/N ratio will improve if the noisemakers go
> unchallenged?
Yes, I do. I have a simplistic view which seems to work:
- noisemakers tend to make noise wherever they go:
killfile entry -> From: noisemaker, Subject: *
- others tend to contribute to the noise only if they follow-up on noisy
threads:
killfile entry -> From: non-noisemaker, Subject: noise
The first type of entry has a long TTL and the *group* of those entries as
a whole rarely needs editing. The second type has a short TTL and the
group of those entries needs incessant editing. It also bears the risk of
losing occasional pearls posted to noisy threads by contributors I esteem
highly. So I'm forced to cherry pick until I conclude the thread has
regressed beyond repair. This is very tiresome. If we could eliminate the
second group, it would be great.
How this relates to Seebs potentially being killfiled by jacob; IOW, why
I'm following up on Richard's question here: I can imagine a scenario
where jacob grew tired of Seebs' noise posted *only* to noisy threads
(second category), and instead of constantly updating his subject-based
kill filter, he modified his other filter (first category), permanently
making the risk of losing those pearls I talked about above actually
manifest with probability 1.
My From:-based killfile works great across subjects and even different
groups. The Subject:-based one produces both false positives (if I add a
thread, I may lose valuable contributions) and false negatives (I don't
add a whole thread but cherry-pick postings based on From:, and to my
dismay, I find noise nonetheless).
Cheers,
lacos
Alan Curry
Richard Heathfield <r...@see.sig.invalid> wrote:
|
|Do you honestly think the S/N ratio will improve if the noisemakers go
|unchallenged?
As much as I'm about to hate myself for posting to a meta thread:
Yes!
Yes, yes, and more yes.
--
Alan Curry
jacob navia
>
> An obvious issue suggests itself. One of the most useful containers is
> the "hash" -- that's sort of a perlism as a name, but basically, an
> associative array in which each member has a key, but keys are not necessarily
> a numerically-ordered list.
>
> 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.
The GetNext() routine takes the list pointer and advances it. If NULL,
the it goes on scanning the next non-empty slot.
Easy. The Getlast() routine does the same stuff backwards. (Together with
"GetPreviuos()"
> 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
jacob
jacob navia
Yes: unspecified order.
jacob navia
>
> 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...
jacob navia
I am serious. I need help, and it would be nice if many people would
review that code.
jacob
Seebs
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.
Seebs
>> 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.
Seebs
> 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.
jacob navia
> On 2010-04-12, jacob navia <ja...@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...
Ersek, Laszlo
> Ersek, Laszlo a écrit :
>>
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
Keith Thompson
> On 2010-04-12, Ersek, Laszlo <la...@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.
Ian Collins
> On 2010-04-12, Ersek, Laszlo<la...@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
Ian Collins
> On 2010-04-12, Ian Collins<ian-...@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
Seebs
> 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.
Tim Rentsch
> On 2010-04-12, Tim Rentsch <t...@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.
Ian Collins
> On 2010-04-12, jacob navia<ja...@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
Tim Rentsch
> 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.
Ersek, Laszlo
> 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
Seebs
> 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.
spinoza1111
> 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?
> > 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!
Tim Rentsch
> On 2010-04-12, Tim Rentsch <t...@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.
Someone reviewing the posting history over the last
several months might reach a different conclusion.
>> 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.
What matters to me is how much garbage traffic I have to
wade through to get to the material of some interest.
Lately there's been a lot more traffic just generally
disparaging of certain folks than there has been from
people who didn't know what was going on.
>> 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.
I'm sorry you see it that way. In my perception there
certainly is a difference between the two kinds of
comments, and my experience has been that the difference is
borne out in terms of what sorts of responses tend to follow
afterwards.
Uno
> Fixing up your analogy to match this reality would involve having the
> people of Paris act like idiots (and I'm not trying to suggest that
> they are): instead of removing the garbage, each one would have to put
> out a piece of food next to each piece of garbage they found on their
> own street - to warn people that there's a piece of garbage there.
> Various animals would come by to eat the food, adding their own fresh
> contribution to the garbage. The citizens of Paris would put out more
> food to mark the fresh garbage, etc... How quickly would the streets
> of Paris be cleaned up by that approach?
>
I think you've got it all backwards here, james. The finger food in
Paris is why grande's like me walk around while the significant other
darts in and out of shops.
The streets of paris require no cleaning. Last time I was there, we
named a restaurant "Place de 20 euro beer." They just need more beer.
They almost give wine away, which gives me heartburn.
Meanwhile there's london, where the only thing that holds food down is
copius and extraordinary beer.
--
Uno
Seebs
> I'm sorry you see it that way. In my perception there
> certainly is a difference between the two kinds of
> comments, and my experience has been that the difference is
> borne out in terms of what sorts of responses tend to follow
> afterwards.
It hasn't been my experience. In my experience, people are quite aware that
stating that a given person's posts are substance-free baiting, or that there
is no benefit to responding to them, is precisely equivalent to asserting that
they're trolling, or that they're a troll. It's like stating that someone
sometimes kills people for money, because that's much more polite than calling
them an assassin.
There is a secondary problem, which is that in some cases, a community
which never does anything about trolls creates a perception that the behaviors
of the trolls are permissible. The trick is that namecalling back tends to
make it a question of whose insults are welcome, rather than whether insults
are welcome. On message-board forums, there can be moderators who can do
something about it; on Usenet, you're just stuck accepting that trolling
and harassment are de facto permissible.
jacob navia
Yes, boost is VERY interesting. Thanks for pointing me to that libbrary.
By the way, the bug I pointed out wasn't in the library but in the
example. I fixed it and now that example works.
jacob navia
I have always said that I have no killfile. I did not answer because you
just replied a short sentence. In general you (and Seebs) always say
that there is no point in doing a container library. You because you
want us to use C++, Seebs because he can't see the advantages of having
code reuse.
Seebs
> I have always said that I have no killfile. I did not answer because you
> just replied a short sentence. In general you (and Seebs) always say
> that there is no point in doing a container library. You because you
> want us to use C++, Seebs because he can't see the advantages of having
> code reuse.
This kind of response is why I tend not to try to help you.
I see HUGE advantages in code reuse. I am not opposed to reusable
libraries. I love reusable libraries. I wrote one list library
and one string library and have pretty much used those two ever
since.
But.
"Container" is the wrong level of abstraction. If you make everything
generic, you can't do any of the things that make individual container
types attractive.
There is simply no point to a library to allow you to not decide which
fundamentally completely-different data structure is a good fit for
your project. It's like designing a car which doesn't have a steering
wheel on the grounds that putting the steering wheel on a specific
side of the car prevents it from being used in both the US and the UK.
When you misrepresent my position as "because he can't see the advantages
of having code reuse", how the hell am I supposed to take you seriously?
If you won't do me even the most fundamental courtesy of not outright lying
about what I have said and why, why should I try to help you?
How would you like it if, every time you mentioned your container library,
people said "oh, don't pay any attention to jacob's library, he's just
doing it because he doesn't think C is a good enough language and wants
to turn it into a Java clone"? I'd guess you'd be offended, given that
it's the OPPOSITE of what you've said.
So why do you do that to other people?
Ian Collins
> Ian Collins a écrit :
>> On 04/13/10 08:41 AM, Seebs wrote:
>>> On 2010-04-12, Ian Collins<ian-...@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!
>>
>
> I have always said that I have no killfile. I did not answer because you
> just replied a short sentence.
I thought I offered some useful suggestions and simplifications. The
reply was a couple of finely tuned paragraphs!
> In general you (and Seebs) always say
> that there is no point in doing a container library.
No, I don't.
> You because you
> want us to use C++, Seebs because he can't see the advantages of having
> code reuse.
I don't want you, or anyone else to use anything. I just point to
alternatives when C might not be the best solution in some environments.
--
Ian Collins
Nick Keighley
> James Harris wrote:
> > On 12 Apr, 05:00, "Morris Keesan" <mkee...@post.harvard.edu> wrote:
> >> 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."-
>
> > There's some truth in the quote but there are other factors to
> > consider.
>
> > For example, if none of the careful deceits and misrepresentations are
> > challenged someone reading the words - either now or at some time in
> > the future - may believe them to be true.
>
> No single human could possibly have any effect on the amount of faulty
> information that exists. You might as well decide to stop the ocean tides.
the attempt was only to correct gross errors on comp.lang.c
Do you *never* correct incorrect information you come across?
I won't be inviting you to any code reviews...
Nick Keighley
> On 2010-04-12, jacob navia <ja...@spamsink.net> wrote:
>
> > When I posted a request about allocators for the container library, I
> > received 2 answers.
>
> questions on that topic.
>
> It's not a topic I am hugely invested in, just because I don't think a
> container library is a good fit for the way I've usually seen C used, but
> I think it's interesting, and I have certainly made suggestions about it.
>
> Fundamentally, though, you're working on something that most of the people
> here don't think they need, and you aren't saying things which are hilariously
> over the top and obviously wrong. When you do say things which are obviously
> wrong, you get more responses, but they're all corrections.
>
> I suspect some of what you're seeing is inertia of various forms; most of us
> already have or don't need a list library, for instance. I quite simply
> can't comprehend when I'd end up wanting a "container". I can see when I
> want lists, or when I want arrays, but I can't conceive of ever writing a
> piece of code in which I want a container but don't care which of those it
> is, or in which my choice of list or array would change. As a result, I
> simply don't see "container" as a useful abstraction for writing code.
oddly, I do. I can well imagine an aplication where the bulk of the
code treated a container as a black box abstraction having, perhaps
add(), remove() and find(). How the container does that the user cares
not. Obviously there has to be some code inside the box which *does*
care.
Containers work well in C++ and are widely used so some programmers
plainly find "containers" useful. I admit it is rare even in C++ to
change container type in mid stream (and sometimes non-trivial).
Of course C isn't C++.
> A similar design for, say, a hash library, which was unambiguously a library
> for hashes and not for any other sort of thing, might be very interesting
> to me, because I've not been especially happy with the hash libraries I've
> seen.
Nick Keighley
> Ersek, Laszlo a écrit :
> > If I ever intended to unify iterator interfaces at all, that was about
> > the end of it. As soon as I wanted to bolt something "really useful" on
> > an iterator interface, it was immediately shown to be container
> > specific. I took it as proof that my pursuit is futile.
>
> I have found the solution.
>
> There is the "Iterator" object with 3 fields:
>
> GetNext
> GetPrevious
might that be expensive with some containers?
> GetFirst
<snip>
Ian Collins
Very.
Trying to be too abstract is a flaw in the design. Containers are
chosen based on their properties. If you want a container that is
efficient to append and you only want to iterate forward, a singly
linked list will be appropriate. If you want reverse iteration as well,
a doubly linked list will be required. That extra functionality has a
cost, but potentially significantly less than the cost of reverse
iteration of a singly linked list.
As I mentioned else-thread, the C++ library's split of containers into
categories makes a lot of sense. If the iterator interface is too
abstract, there may as well only be one container type.
--
Ian Collins
Nick Keighley
> On 04/13/10 06:57 PM, jacob navia wrote:
>
> > Ian Collins a écrit :
> >> On 04/13/10 08:41 AM, Seebs 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!
>
> > I have always said that I have no killfile. I did not answer because you
> > just replied a short sentence.
>
> I thought I offered some useful suggestions and simplifications. The
> reply was a couple of finely tuned paragraphs!
>
> > In general you (and Seebs) always say
> > that there is no point in doing a container library.
>
> No, I don't.
>
> > You because you
> > want us to use C++, Seebs because he can't see the advantages of having
> > code reuse.
>
> I don't want you, or anyone else to use anything. I just point to
> alternatives when C might not be the best solution in some environments.
so he lied about both you
Ian Collins
>
> so he lied about both you
Oh no, let's not start another one of those threads, spinny might be
watching :)
--
Ian Collins
Noob
> Sure. But if everyone else does it, and I don't, then I have an almost
> entirely clean city at no cost to me. So if I'm selfish, where's my
> incentive?
Richard Harter
<ian-...@hotmail.com> wrote:
>
>Trying to be too abstract is a flaw in the design. Containers are
>chosen based on their properties. If you want a container that is
>efficient to append and you only want to iterate forward, a singly
>linked list will be appropriate. If you want reverse iteration as well,
>a doubly linked list will be required. That extra functionality has a
>cost, but potentially significantly less than the cost of reverse
>iteration of a singly linked list.
As a note sometimes it is more efficient to reverse a single list
by iteratively reversing links, iterating through the reversed
list, and then restoring it by a second reversal. There are some
obvious caveats.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
It's not much to ask of the universe that it be fair;
it's not much to ask but it just doesn't happen.
Tim Rentsch
> On 2010-04-13, Tim Rentsch <t...@alumni.caltech.edu> wrote:
>> I'm sorry you see it that way. In my perception there
>> certainly is a difference between the two kinds of
>> comments, and my experience has been that the difference is
>> borne out in terms of what sorts of responses tend to follow
>> afterwards.
>
> It hasn't been my experience. In my experience, people are quite aware that
> stating that a given person's posts are substance-free baiting, or that there
> is no benefit to responding to them, is precisely equivalent to asserting that
> they're trolling, or that they're a troll. It's like stating that someone
> sometimes kills people for money, because that's much more polite than calling
> them an assassin.
I would like to suggest, as respectfully as possible, that
there's a level of social nuance that you're overlooking.
Certainly it has been the experience in comp.lang.c that posters
who some would describe as "trolls" respond differently to
different styles of followup. No one likes reading irrelevant
messages, but only the "anti-trolls" (if you will allow me a
somethat tongue-in-cheek phrase) become targets. Obviously
different ways of commenting on postings considered to be
irrelevant can evoke different kinds of responses.
> There is a secondary problem, which is that in some cases, a community
> which never does anything about trolls creates a perception that the behaviors
> of the trolls are permissible. [snip elaboration]
This statement mischaracterizes my comments. I am not advocating
doing nothing (nor in fact am I advocating doing something).
That decision is up to each individual as he or she sees fit.
What I am advocating is that, _if_ one has chosen to post
something because of any kind of articles posted to the
newsgroup, confine the comments to being about what was written,
and avoid commenting (either directly or obliquely) about the
personality, or any other qualities, of the writer rather than
about the writing.
Seebs
> I would like to suggest, as respectfully as possible, that
> there's a level of social nuance that you're overlooking.
Quite likely.
One of the reasons it can matter who you're talking to is that, statistically,
an awfully large number of people are going to have cognitive abnormalities,
which you need to know about to deal with them effectively. In particular,
for instance, "autistic" isn't just a label spinny can use to harass me; it's
also a functional description. Such that you don't need qualifiers like
"as respectfully as possible", because I don't really experience that layer
of social stuff to begin with. :)
> Certainly it has been the experience in comp.lang.c that posters
> who some would describe as "trolls" respond differently to
> different styles of followup. No one likes reading irrelevant
> messages, but only the "anti-trolls" (if you will allow me a
> somethat tongue-in-cheek phrase) become targets. Obviously
> different ways of commenting on postings considered to be
> irrelevant can evoke different kinds of responses.
That's true.
> This statement mischaracterizes my comments. I am not advocating
> doing nothing (nor in fact am I advocating doing something).
:)
> That decision is up to each individual as he or she sees fit.
> What I am advocating is that, _if_ one has chosen to post
> something because of any kind of articles posted to the
> newsgroup, confine the comments to being about what was written,
> and avoid commenting (either directly or obliquely) about the
> personality, or any other qualities, of the writer rather than
> about the writing.
You have a point. In theory, saying that a person's posts are
meaningless and offered only to obtain results ought to have the same
effect as asserting that the person is a troll, but in practice, people
sometimes react differently.
Certainly, people can react to that kind of comment about their posts with
a great deal of hostility. However, come to think of it, except for the
real crazies, they usually don't react as badly to the comments about their
posts when those comments are accurate, as they do to comments about their
person when those comments are accurate.