Efficency and the standard library

[spinoza1111]

With a canonical linked list, one must always start traversing the
list at the head, and continue following links until one has got the
data one wants.

However it's possible to store additional pointers to points along the
list. So, for instance, if we have a linked list of 1000 entries, we
could have extra pointers at 100, 200, 300 and so on. To get to link
202, one simply checks the extra pointers (two comparisons), jumps
into the list at node 200, and carries along to 202 (3 comparisons),
thous retrieving the information in 5 comparisons instead of 203.

That's what I was thinking, Malcolm.

 

[Julienne Walker]

No no no no no. LINKS, please. A pointer to the segment in mallocated
space and its length.

A detail quite irrelevant to my point. Now you're managing a linked
list, blocks of contiguous characters, *and* the relationship between
them to represent a single string. If the original goal is easy
modification, I'd be dubious about how successful this design is
compared to the simpler list of characters or block of characters.

My entire point was that Richard's approach is wrong. In fact, a
programmer with uni compsci would never have done what he did.

I went home and checked my copy of the book. Personally, I think
you're overreacting. The C Unleashed design is a viable one in that
the data structure owns its data, as opposed to having the data owned
by something else and merely storing pointers to said data. In the
former case the data structure can make specific claims of correctness
and integrity while in the latter case you can end up with dangling
pointers and unexpected aliasing. On the down side, in the former case
you end up copying data around when it might not be necessary, and
making copies might not be desirable from a functionality standpoint.

There are advantages and disadvantages to both, which is typical in
software design. Choose the one that best suits your needs, and you'll
end up with higher quality software. Being dogmatic about one or the
other limits your options.

Neither. What concerns me is that in nearly all offices, a language
game is played that produces crumby software. Here, it's resistance to
good solutions which are hard for some to think about based on false
appeals to a misapprehension of "structured programming" and the false
inference from "it is difficult for me to think about this" to "this
must be an inefficient kludge".

May I direct you to the irony of this statement and your resistance to
the solution from C Unleashed (which is no worse than your stated
alternative, just different)? While I prefer not to presume to say
*why* someone is resistant to alternatives, it often strikes me as a
matter of ego rather than logic. In a manner of speaking: "I'd do it
this way, so this way is right. Your way isn't how I'd do it, so your
way is wrong".

And I reserve the right to answer the excessive bullying that occurs
in this newsgroup.

I'd recommend that you take care not to cause too much collateral
damage then. But I'm not sure that recommendation is worth the
bandwidth from me to you because, if I recall correctly, one of your
stated goals was to damage this newsgroup as much as possible.

 

[spinoza1111]

A detail quite irrelevant to my point. Now you're managing a linked
list, blocks of contiguous characters, *and* the relationship between
them to represent a single string. If the original goal is easy
modification, I'd be dubious about how successful this design is
compared to the simpler list of characters or block of characters.

Verbiage, Julienne, of the sort that torpedoes good ideas in
structured walkthroughs, because it is HARD to "modify" strings
maintained as what you seem to mean by "the simpler list of characters
or block of characters" (your meaning is not clear.

If you mean that strings should be maintained in the current way, if a
NUL terminated string is a "simpler" list of characters or block, then
making deletions and insertions is actually quite difficult and time-
consuming. It requires that the entire string, no matter how long, be
completely reallocated.

Whereas deletions and insertions in a linked list are always simple,
both conceptually (once you get the hang of it) and in terms of
computational complexity. It involves no excess or wasted movement of
characters.

I went home and checked my copy of the book. Personally, I think
you're overreacting. The C Unleashed design is a viable one in that
the data structure owns its data, as opposed to having the data owned
by something else and merely storing pointers to said data. In the
former case the data structure can make specific claims of correctness
and integrity while in the latter case you can end up with dangling
pointers and unexpected aliasing. On the down side, in the former case
you end up copying data around when it might not be necessary, and
making copies might not be desirable from a functionality standpoint.

This type of "ownership" is overrated.

If the data pointed to by the linked list is unexpectedly changed, you
most assuredly end up with what you call "dangling" pointers, and
usually a pretty obvious runtime error.

However, using Richard's solution, quite apart from its performance,
if the copied data changed, you end up in many scenarios with
what .Net authority and nice guy Dan Appleman calls the worst kind of
error...one that you don't know about.

Although corporate programmers without excess university training are
somewhat biased, in my experience, towards copying data, I'd say it's
usually better given my compiler experience in addition to my business
experience to link to it.

When programmers start talk, in my experience, about "buffering" data
or making a "work file", this is often a sign of incompetence and
anxiety.

There are advantages and disadvantages to both, which is typical in
software design. Choose the one that best suits your needs, and you'll
end up with higher quality software. Being dogmatic about one or the
other limits your options.

Why is it in corporations that the most vague admonitions are used to
make irrevocable and costly decisions, whereas knowledge is equated
with dogma? This type of thinking caused the crash of two Space
Shuttles: in the case of Challenger, its engineers knew to a moral
certainty that the o-rings that failed were not tested "live" in low
temperatures, and in the case of Columbia, its engineers knew to a
moral certainty that the Space Shuttle was operating outside of its
acceptable performance bounds when it shed insulation parts on lift-
off...and this was admitted in the official review of the accident.

People died, Julienne, because vague admonitions ("think like a
manager and not an engineer") overrode hard engineering facts. As they
died in Iraq because Donald Rumsfeld's corporate BULLSHIT (which he
honed at Searle during the 1990s) overrode the hard requirements of a
respected military officer (Shinseki) for enough troops to secure
Iraq. And reading about incidents like this, which echo my own
experiences at Bell Northern Research, I thank my lucky stars that I
no longer work in corporate programming.

It is *unacceptable* to copy data from a place pointed-to by a pointer
to void into a structure, and call the result "reusable software". As
I have said, preprocessor macros can be used to create a type-safe
reusable linked list manager that uses no pointers to void. However,
the real problem isn't in the use of a pointer to void. It is that the
"reusable" tool is unnecessarily copying a completely unpredictable
number of bytes.

May I direct you to the irony of this statement and your resistance to

My dear Julienne, let us not simulate, even in dulcet tones, the
corporate situation in which independence thought is reduced to a bad
attitude, irrational resistance and behavior. Thank you.

the solution from C Unleashed (which is no worse than your stated
alternative, just different)? While I prefer not to presume to say
*why* someone is resistant to alternatives, it often strikes me as a
matter of ego rather than logic. In a manner of speaking: "I'd do it
this way, so this way is right. Your way isn't how I'd do it, so your
way is wrong".

Bullshit. There's a scene in Hamlet in which two "corporate" types,
Rosencrantz and Guildenstern, two creeps who are the Renaissance
equivalent, being courtiers, are posing as Hamlet's friends while
spying for his mortal enemy, Claudius. Hamlet, who seems "crazy" only
to the ignorant and evil characters of the play, and equally ignorant
high school English teacher, hands Guildenstern a transverse flute,
and asks him to play it. When Guildenstern says "I have not the art",
Hamlet says:

"Why looke you now, how vnworthy a thing you make of me: you would
play vpon mee; you would seeme to know my stops: you would pluck out
the heart of my Mysterie; you would sound mee from my lowest Note, to
the top of my Compasse: and there is much Mu-sicke, excellent Voice,
in this little Organe, yet cannot you make it. Why do you thinke, that
I am easier to bee plaid on, then a Pipe? Call me what Instrument you
will, though you can fret me, you cannot play vpon me. God blesse you
Sir."

In other words, my dear Julienne, I think that of all people,
corporate data processors are amongst the least qualified to do even
Pop psychology and to start ascribing all sorts of childish and
irrational motives to programmers who don't like Richard's kind of
unprofessional crap.

I'd recommend that you take care not to cause too much collateral
damage then. But I'm not sure that recommendation is worth the
bandwidth from me to you because, if I recall correctly, one of your
stated goals was to damage this newsgroup as much as possible.

That is not the case. In fact, I am usually responsible for the most
interesting and well-attended threads.

 

[Seebs]

why so insistent? Whats wrong with variable sized nodes?

Hard to reuse and quite likely to end up in different malloc pools.

As I recall, mbufs use a static-size node, but indicate how many octets
are currently in it. The nodes can thus live in a pool and be shuffled
and reused as needed. If you pick a "reasonable" size -- one such that
you don't waste too much space on short strings, or need too many links
for normal-sized strings -- that can be very efficient, especially because
it makes allocating and freeing nodes EXTREMELY cheap. (You just shove
them back on the "list of free nodes", etcetera.)

-s

 

[Malcolm McLean]

Hard to reuse and quite likely to end up in different malloc pools.

As I recall, mbufs use a static-size node, but indicate how many octets
are currently in it.  The nodes can thus live in a pool and be shuffled
and reused as needed.  If you pick a "reasonable" size -- one such that
you don't waste too much space on short strings, or need too many links
for normal-sized strings -- that can be very efficient, especially because
it makes allocating and freeing nodes EXTREMELY cheap.  (You just shove
them back on the "list of free nodes", etcetera.)

There's code to do this on my website

http://www.personal.leeds.ac.uk/~bgy1mm

It's in the Basic Algorithms supporting webpages, under "Memory
Games".

 

[bartc]

You are absolutely right. Few if any Haitians died by act of God, but
because humans chose to build unstable structures, knowing that
earthquakes occasionally happen.

To put this back on topic, what's a professional Haitian architect to
do?

I still think you're a little way off...

 

[Chris M. Thomasson]

I don't know why Richard implemented a simple linked-list that way.
I
take
it he is not that fond of intrusive linked lists.
But his solution IS intrusive, unless by "intrusive" you mean
something else.

I mean why not embed the list node directly into a data-structure? The
list
nodes intrudes into the object. [...]

What about intrusive data-structures that do not require any copying
and/or
void pointers? I use them all the time.
That was my idea...use a macro for strong typing.

I was thinking of the following technique. Here, let me quickly code up
a
simple example:
_______________________________________________________________ [...]
_______________________________________________________________

The `struct slist' objects intrude upon the `struct foo' objects. Now,
you
can create a generic set of functions that operate on `struct slist'
objects
regardless of what they are embedded within (e.g., see the `slreverse()'
function).

Very clever. I like this idea. Lists remain pure lists. Very elegant.
But: I do not understand how, if I have ONLY a foo, to find the next
foo.

Here is a more advanced example:
________________________________________________________________
#include <stdio.h>
#include <stddef.h>


#define CONTAINS_EX(mp_self, mp_type, mp_offset) \
((mp_type*)(((unsigned char*)(mp_self)) - (mp_offset)))


#define CONTAINS(mp_self, mp_type, mp_member) \
CONTAINS_EX(mp_self, mp_type, offsetof(mp_type, mp_member))


#define CONTAINS_OFFSET(mp_self, mp_tptr) \
((size_t)(((unsigned char*)(mp_tptr)) - \
((unsigned char*)(mp_self))))


struct slist
{
struct slist* next;
};


#define SLIST_SINIT { NULL }


#define slhead(mp_self) ((mp_self)->next)


void
slpush(struct slist* const self,
struct slist* node)
{
node->next = self->next;
self->next = node;
}


struct slist*
slpop(struct slist* const self)
{
struct slist* node = self->next;
if (node) self->next = node->next;
return node;
}


void
slreverse(struct slist* const self)
{
struct slist* head = NULL;
struct slist* node = self->next;

while (node)
{
struct slist* next = node->next;
node->next = head;
head = node;
node = next;
}

self->next = head;
}




struct foo
{
char const* string;
struct slist node1;
struct slist node2;
};


#define FOO_SINIT(mp_string) \
{ (mp_string), SLIST_SINIT, SLIST_SINIT }


void
foo_output_from(struct foo const* const self,
struct slist* node,
FILE* output)
{
struct slist const* cur;
size_t offset = CONTAINS_OFFSET(self, node);

for (cur = node; cur; cur = cur->next)
{
struct foo const* f =
CONTAINS_EX(cur, struct foo, offset);

fprintf(output,
"(%p)->struct foo(%s)\n",
(void*)f,
f->string);
}

fputs("---------------------------------------------\n",
output);
}


int main()
{
struct slist list1 = SLIST_SINIT;
struct slist list2 = SLIST_SINIT;

struct foo foo[] =
{
FOO_SINIT("One"), FOO_SINIT("Two"),
FOO_SINIT("Three"), FOO_SINIT("Four"),
FOO_SINIT("Five"), FOO_SINIT("Six"),
FOO_SINIT("Seven"), FOO_SINIT("Eight"),
FOO_SINIT("Nine"), FOO_SINIT("Ten")
};

size_t i;
size_t depth = sizeof(foo) / sizeof(foo[0]);

for (i = 0; i < depth; ++i)
{
slpush(&list1, &foo.node1);
slpush(&list2, &foo.node2);
}

slreverse(&list2);

for (i = 0; i < depth; ++i)
{
foo_output_from(foo + i, &foo.node1, stdout);
foo_output_from(foo + i, &foo.node2, stdout);
}

return 0;
}
________________________________________________________________




Pay close attention to the `foo_output_from()' procedure. I pass it a
pointer to a `struct foo', a pointer to a node within said `struct foo', and
a pointer to a file stream. First it needs to calculate an offset into a
`struct foo' so that it can extract them from `struct slist' objects. Once
it has the offset, it simply iterates the list starting at the node. Of
course this is a much more complicated example. I expect most usage cases
will simply involve:
________________________________________________________________
struct foo
{
struct slist node;
/* [whatever] */
};
________________________________________________________________


Now, one can avoid all the `CONTAINS' macros and just cast `struct slist'
directly into `struct foo'. That's much simpler indeed!

;^)

 

[Julienne Walker]

Verbiage, Julienne, of the sort that torpedoes good ideas in
structured walkthroughs, because it is HARD to "modify" strings
maintained as what you seem to mean by "the simpler list of characters
or block of characters" (your meaning is not clear.

I'm afraid I can't imagine how my meaning couldn't be clear: A linked
list of characters or an "array" of characters. These are one-
dimensional data structures, completely linear in concept, and easy to
visualize even for the most remedial of comp sci students. Combining
them adds complexity and relatively difficult design decisions.

If you mean that strings should be maintained in the current way, if a
NUL terminated string is a "simpler" list of characters or block, then
making deletions and insertions is actually quite difficult and time-
consuming. It requires that the entire string, no matter how long, be
completely reallocated.

As for reallocation, that really depends on the current capacity and
your needs. Insertion wouldn't require reallocation if the blocks
capacity is already large enough. Deletion would only require
reallocation if you want to trim unused memory. If strings were
immutable, it might be a different story, but that's not the case in
C.

Whereas deletions and insertions in a linked list are always simple,
both conceptually (once you get the hang of it) and in terms of
computational complexity. It involves no excess or wasted movement of
characters.

Agreed. But let's not forget that you have more than just the link
surgery of a linked list. Consider the following data structure you
described. Each node is a pointer to a block of characters:

"this" -> "is" -> "a" -> "test"

If this string representation were to be useful at all, you'd need to
support deleting parts of each block (such as the "hi" from "this")
and inserting inside each block. I have a hard time believing how this
doesn't add complexity, and depending on your design decisions, it
could easily involve excess or wasted movement of characters.

There's nothing wrong with the data structure if it's what you need
(I've written lists like this before), but I'm not buying your
hype. ;-)

This type of "ownership" is overrated.

Please elaborate.

However, using Richard's solution, quite apart from its performance,
if the copied data changed, you end up in many scenarios with
what .Net authority and nice guy Dan Appleman calls the worst kind of
error...one that you don't know about.

Scenarios such as what?

Although corporate programmers without excess university training are
somewhat biased, in my experience, towards copying data, I'd say it's
usually better given my compiler experience in addition to my business
experience to link to it.

"Usually better" may indeed be the case in your experience. In my
experience, linking vs. copying is situational. Now we're entering the
realm of objectivity, which is a good thing. Opinions are clearly
stated as opinion, and words are carefully chosen so as to avoid
making absolute statements.

Why is it in corporations that the most vague admonitions are used to
make irrevocable and costly decisions, whereas knowledge is equated
with dogma?

Failure to apply the full extent of knowledge is equated with dogma.
I'd find it laughable if you weren't aware of the advantages of
copying data and the disadvantages of linking data. But your
statements clearly make it appear as if copying data has no advantages
and linking has no disadvantages. There are no vague admonitions. If
we were actually trying to make a decision, I'd be forcing you to
consider all of the alternatives I could think of so that the best
possible decision could be made.

My dear Julienne, let us not simulate, even in dulcet tones, the
corporate situation in which independence thought is reduced to a bad
attitude, irrational resistance and behavior. Thank you.

Hmm, so you're allowed to defend yourself against bullying yet I'm
not? Your attitude toward me has been hostile despite perfectly civil
discourse on my end. I feel I've been intentionally insulted several
times, and the instant I mention your hypocricy, *you're* the victim?
Sorry, Mr. Nilges, but I cry bullshit. I'm neither stupid nor
ignorant, and if you truly want to discuss technical issues, I expect
you to treat me with at least a modicum of respect.

That is not the case. In fact, I am usually responsible for the most
interesting and well-attended threads.

You're also one of the most vocal participants in flame wars.

 

[spinoza1111]

There was not "me and my mates". There was only me. And I had plenty
other things to do without suddenly being landed with an *unnecessarily*
complex piece of code to look after, clever or not. It was not fucking
academia where I was, it was the real world, something that you, as a
deadbeat, are unable to deal with.

I don't work in fucking academia. But why is the corporation "the real
world"? Why is it any more real than anything else? I found that most
corporate jobs in data processing are a fantasy and welfare for white
males, since it's too risky for management to do anything. Is this
reality?

Of course I was unwilling to maintain it, you fool, that's the whole
point. This was someone who decided to solve the problem his own way and
**** to everyone else. As evidenced by his disinterest in documenting it.

Maybe he just didn't want to work with somebody with a foul mouth and
bad temper.

They certainly are more trouble than they're worth when there's no
fucking doccy. Thanks for noticing.


There are certainly programmers who are unable to communicate
meaningfully. I'm not one of those.

You've given no evidence here.

I resent a pretentious ponce giving me War and Peace when I didn't ask
for it, that's for sure. This was a small step in a longer chain, made
more complex because some selfish bastard decided to do his own thing.


You're making a similar mistake to that I feel is often made by
inventors, especially in this country. They say "I've invented this
widget, why is the world not beating a path to my door in admiration,
begging me to sell it to them?" The answer for them is that the
invention is 1% of the task, getting it to market is the other 99%.
Similarly you seem to feel that creativity and skill are all that
counts. These are important but not the be-all and end-all. A
willingness to see the bigger picture, and to know when to subsume your
"creativity" and do something duller that fits better, are also
important. You seem to lack this ability.

zzzz....

Actually, this isn't true. The people who "subsume their creativity"
and "do something duller that fits better", in my experience, are
simply employees until laid off, retired or dead.

And no, I had no "envy of his skills/creativity". I've worked with
people who've written actual compilers, so I know who is worth admiring
for their skill.

Wow, actual compilers. As opposed to mythical compilers?

 

[spinoza1111]

I'm afraid I can't imagine how my meaning couldn't be clear: A linked
list of characters or an "array" of characters. These are one-
dimensional data structures, completely linear in concept, and easy to
visualize even for the most remedial of comp sci students. Combining
them adds complexity and relatively difficult design decisions.

No, "a linked list of string segments" solves our problem. You do wish
to solve the problem, don't you?

As for reallocation, that really depends on the current capacity and
your needs. Insertion wouldn't require reallocation if the blocks
capacity is already large enough

How do you know this?

. Deletion would only require
reallocation if you want to trim unused memory. If strings were
immutable, it might be a different story, but that's not the case in
C.


Agreed. But let's not forget that you have more than just the link
surgery of a linked list. Consider the following data structure you
described. Each node is a pointer to a block of characters:

"this" -> "is" -> "a" -> "test"

If this string representation were to be useful at all, you'd need to
support deleting parts of each block (such as the "hi" from "this")
and inserting inside each block. I have a hard time believing how this
doesn't add complexity, and depending on your design decisions, it
could easily involve excess or wasted movement of characters.

You have a hard time believing how this doesn't add complexity because
you haven't done this type of work, can be my only conclusion here.
This is mental complexity not "complexity".

There's nothing wrong with the data structure if it's what you need
(I've written lists like this before), but I'm not buying your
hype. ;-)

Hype? What's insane here is that I have no reason to "hype" anything
as I would in a real job, yet you insist on creating a corporate style
situation here because, apparently, you can't think outside the
corporate box.

Please elaborate.

It is purely psychological. You're insecure with my solution because I
am not in authority over you, whereas Richard is a bully who always
wants to get his way, and women have a tendency to defer to bullying.
He has a sort of "virtual" authority. But the fact remains that his
code shows no evidence of education or skill in this matter.

Scenarios such as what?

Richard's code is using the copy in the linked list but the original
data is changed.

"Usually better" may indeed be the case in your experience. In my
experience, linking vs. copying is situational. Now we're entering the
realm of objectivity, which is a good thing. Opinions are clearly
stated as opinion, and words are carefully chosen so as to avoid
making absolute statements.

Such as "oh, I think you should think like a manager and not an
engineer?" Or "in my opinion, the fact that no insulation piece has
been, so far, has caused any damage means it's not a problem". Or, "in
my opinion, General Shinseki, you're asking for too many troops?" Or,
"in my opinion, Saddam Hussein has WMDs".

Those are four opinions which got people killed.

Failure to apply the full extent of knowledge is equated with dogma.
I'd find it laughable if you weren't aware of the advantages of
copying data and the disadvantages of linking data. But your
statements clearly make it appear as if copying data has no advantages
and linking has no disadvantages. There are no vague admonitions. If
we were actually trying to make a decision, I'd be forcing you to
consider all of the alternatives I could think of so that the best
possible decision could be made.

Which at this point is your decision, because that's the shitty little
corporate game: My Way. Well, I don't have to play it.

There is, in fact, no downside to a correctly implemented linked list
of pointers, whereas there IS a considerable downside, which you don't
seem to understand, to a correctly implemented link list of copied
data. I've shown you, but shall repeat: Richard Heathfield's reusable
tool will blow up, performance-wise, if passed large nodes. It also
creates a copy of data which has to be maintained in parallel with the
original.

Hmm, so you're allowed to defend yourself against bullying yet I'm
not?

I'm not bullying you.

Your attitude toward me has been hostile despite perfectly civil

If disagreement is hostility, then who's hostile?

discourse on my end. I feel I've been intentionally insulted several
times, and the instant I mention your hypocricy, *you're* the victim?
Sorry, Mr. Nilges, but I cry bullshit. I'm neither stupid nor
ignorant, and if you truly want to discuss technical issues, I expect
you to treat me with at least a modicum of respect.

By agreeing with you, or even better, seeming to in the accepted,
corporate mold, and then going off and doing whatever needed to be
done. Sorry, I don't have to play that game here, and I won't.

You're also one of the most vocal participants in flame wars.

No, I'm frequently bullied because I attract notice and then envy,
because I am both literate and a great programmer (for let us not
speak falsely now the hour is much too late). And unlike most women in
this situation, I fight back being a guy.

 

[Keith Thompson]

You've given no evidence here.

It is ironic that you, who almost never support your own claims with
hard facts, should ask for someone else to provide evidence. It is the
height of hypocrisy. [snip]
<subsequent nonsense snipped>

Yes, spinoza1111 is wrong again, and on a topic having nothing
to do either with C or with the supposed subject of this thread.
Is pointing it out really a good use of time and bandwidth?

 

[Malcolm McLean]

I'm afraid I can't imagine how my meaning couldn't be clear: A linked
list of characters or an "array" of characters. These are one-
dimensional data structures, completely linear in concept, and easy to
visualize even for the most remedial of comp sci students. Combining
them adds complexity and relatively difficult design decisions.

I'm working on DNA data at the moment. Currently I store it as
conventional strings.

However the data is a long list of ACGTs. A human can't possibly read
it all, even small sections look meaningless after a bit. The eye is
drawn to repeats and chance combinations like 'TAGACAT'.
However genomes are not unstructured. Different areas have different
statistical characteristics, though we don't know exactly what that
means. My job, basically, is to take the raw strings and turn them
into something else, something that humans can talk about in a
sensible way.
So I will need to build extra layers of structure on top of the
strings.

 

[Nick Keighley]

I'm working on DNA data at the moment. Currently I store it as
conventional strings.

However the data is a long list of ACGTs. A human can't possibly read
it all, even small sections look meaningless after a bit. The eye is
drawn to repeats and chance combinations like 'TAGACAT'.
However genomes are not unstructured. Different areas have different
statistical characteristics, though we don't know exactly what that
means. My job, basically, is to take the raw strings and turn them
into something else, something that humans can talk about in a
sensible way.
So I will need to build extra layers of structure on top of the
strings.

are you agreeing or disagreeing?

 

[spinoza1111]

spinoza1111wrote:
<prior nonsense snipped>
There are certainly programmers who are unable to communicate
meaningfully. I'm not one of those.
You've given no evidence here.
It is ironic that you, who almost never support your own claims with
hard facts, should ask for someone else to provide evidence. It is the
height of hypocrisy. [snip]
<subsequent nonsense snipped>

Yes,spinoza1111is wrong again, and on a topic having nothing
to do either with C or with the supposed subject of this thread.
Is pointing it out really a good use of time and bandwidth?

Put it this way - although I haven't measured it, I would estimate that
the number of his errors that I actually address is significantly under
1% of the total errors he posts. (If I were to attempt to address every
error he makes, (a) I wouldn't ever get any real work done, and (b) I'd
be plonked by most of this group's subscribers.)

You're lying. You put matters of opinion under "errors" to get the
result you want, the impression that like you and Seebach, I'm
incompetent, using media in the Fascist way to create a blurred
impression. But your "errors" include an incompetent "linked list"
that puts data in nodes using a void pointer instead of using the
preprocessor for strong typing and pointers in nodes (a very serious
error), and Seebach can't get strlen right without an off by one bug
(low comedy). Whereas my biggest "error" is having more education and
culture than you while being much better as a programmer, which means
you've wasted too much time learning your trade. This is why you bully
and enable bullying here. It's the only place you can get a forum
where people will listen to you.

 

[spinoza1111]

I'm working on DNA data at the moment. Currently I store it as
conventional strings.

However the data is a long list of ACGTs. A human can't possibly read
it all, even small sections look meaningless after a bit. The eye is
drawn to repeats and chance combinations like 'TAGACAT'.
However genomes are not unstructured. Different areas have different
statistical characteristics, though we don't know exactly what that
means. My job, basically, is to take the raw strings and turn them
into something else, something that humans can talk about in a
sensible way.
So I will need to build extra layers of structure on top of the
strings.

In other words, complaining about complexity
In the hopes it will go away
Is to create further perplexity
For others down the way.

Anti-intellectualism is a fashion statement
It makes one seem quite *au courant*
But when the rubber hits the pavement
Someone has to pay, in Reality's restaurant.

Rumsfeld said, nothin' to it,
And he shoo'd Shinseki away,
For saying he needed, to do it,
Several divisions of the infant-ray

And so men died because he lied,
Having learned his trade at Searle,
Where I know for a fact, having friends there
That this is how they made them hurl:

By saying, your real solution,
Seems to work and accounts for everything,
But we didn't think of it, so we're refusin'
To give you time to make it sing.

 

[spinoza1111]

spinoza1111wrote:

<prior nonsense snipped>

It is ironic that you, who almost never support your own claims with
hard facts, should ask for someone else to provide evidence. It is the
height of hypocrisy. [snip]
<subsequent nonsense snipped>

Yes,spinoza1111is wrong again, and on a topic having nothing
to do either with C or with the supposed subject of this thread.
Is pointing it out really a good use of time and bandwidth?

Here's the guy who solemnly approved Seebach's "off by one" attempt to
do strlen, and here, all Kiki knows is that Nilges is "wrong": Yeats
again:

We are closed in, and the key is turned
On our uncertainty; somewhere
A man is killed, or a house burned,
Yet no clear fact to be discerned:
Come build in he empty house of the stare. ...

We had fed the heart on fantasies,
The heart's grown brutal from the fare;
More substance in our enmities
Than in our love; O honey-bees,
Come build in the empty house of the stare.

 

[spinoza1111]

spinoza1111wrote:


It is ironic that you, who almost never support your own claims with
hard facts, should ask for someone else to provide evidence. It is the
height of hypocrisy.

Nevertheless, Tim Streater is not you, and it is not unreasonable to
expect some evidence to exist for his claims (unlike yours). I can
provide some. (It won't convince *you*, obviously, but that doesn't
bother me in the slightest.)

I have been reading Tim Streater's articles for some time now. I have
occasionally participated in discussions with him. In those discussions,
I have never had any cause whatsoever to doubt his ability to
communicate meaningfully. Anyone who wishes to assure themselves of his
ability to communicate meaningfully need only pick a dozen samples of
his articles at random, and read through them. (And anyone who wishes to
discern whether his correspondent can communicate meaningfully need only
do the same to /his/ articles.)

You're unable, as we have seen, to do a competent job at constructing
a linked list, so it stands to reason that you'll think in terms of an
external show of expertise, and make this newsgroup a popularity
contest dominated by bullies willing to lie. It's like the art dealer
told me when some thugs on the island on which I lived threatened to
disrupt my one-man show. People don't care about art anymore, just
wine, food, sex and who's in.

You don't give a flying **** about good programming, Richard, it's
just a meal ticket for you: that's obvious. This is why you're a bully
and an enabler.

 

[Nick Keighley]

No, I don't think so.

though interesting, how does the stuff about DNA add to this sub-
thread?

 

[Julienne Walker]

No, "a linked list of string segments" solves our problem. You do wish
to solve the problem, don't you?

I'm not aware there was a problem that needed to be solved. It seems
to me more like we've been discussing solutions looking for a problem.
Or do you have an application where both C-style strings and Paul's
better string library are woefully unsuitable? Having a concrete
problem to work with would make weighing alternatives a great deal
easier.

How do you know this?

You're not the only one with experience. ;-) But it takes little more
than common sense to see that if there's room left in the glass, you
can add more water. String libraries typically allocate more memory
than needed for that very reason. It avoids excessive calls to the
memory manager.

You have a hard time believing how this doesn't add complexity because
you haven't done this type of work, can be my only conclusion here.
This is mental complexity not "complexity".

I say it adds complexity *because* I've done this type of work. Quite
a bit of it, actually. You have a bad habit of concluding that I don't
know what I'm talking about or haven't "done my homework" when you
disagree with me.

It is purely psychological. You're insecure with my solution because I
am not in authority over you, whereas Richard is a bully who always
wants to get his way, and women have a tendency to defer to bullying.
He has a sort of "virtual" authority. But the fact remains that his
code shows no evidence of education or skill in this matter.

Lots of words and no substance. I asked for a scientific explanation
of why that type of "ownership" is overrated, not some amateur psych
evaluation. I understand both solutions as well as the advantages and
disadvantages of both. I understand that they're suitable in different
situations, but you claim that your solution is better because
"ownership" is overrated and I want to know why.

Richard's code is using the copy in the linked list but the original
data is changed.

If you maintain two copies of the same data but expect only one, the
application's design is fundamentally flawed to begin with. We're
talking about the design of the linked list itself, not stupid uses of
it.

Such as "oh, I think you should think like a manager and not an
engineer?" Or "in my opinion, the fact that no insulation piece has
been, so far, has caused any damage means it's not a problem". Or, "in
my opinion, General Shinseki, you're asking for too many troops?" Or,
"in my opinion, Saddam Hussein has WMDs".

No, such as "take your head out of your ass and stop using your
emotions to guide technical arguments". You make the strangest
connections and then lay them out as if they're conclusive arguments.
Debating by confusing one's opponent only works at the lowest levels.

There is, in fact, no downside to a correctly implemented linked list
of pointers, whereas there IS a considerable downside, which you don't
seem to understand, to a correctly implemented link list of copied
data. I've shown you, but shall repeat: Richard Heathfield's reusable
tool will blow up, performance-wise, if passed large nodes

And your "better" design will blow up if linked to local data that
goes out of scope or memory that is released by unwitting client code.
I'm afraid that's a downside, despite your claim that none exist.

creates a copy of data which has to be maintained in parallel with the
original.

It's easy to make a library design look bad when you assume it's being
used by an idiot. The C++ container libraries take ownership of data
by copying, and nobody seems to have a problem with them. Further, by
copying pointers to the data rather than the data itself you get the
same effect as linking.

If disagreement is hostility, then who's hostile?

You're too intelligent not to realize how insulting and condescending
your posts are. Are you really trying to imply that you've managed to
insult my experience, my intelligence, my ethics, and my gender all
without knowing it? I actually find that impossible to believe. Once
again, I'm not stupid, and I'm not timid. I can see what you're doing
and I'm not afraid to point it out.

 

[spinoza1111]

I'm not aware there was a problem that needed to be solved. It seems

No, Richard Heathfield's code was intended to "solve the problem of a
reusable tool for managing a linked list", but it doesn't, because it
needlessly copies characters and duplicates data. A simpler (both
conceptually and in terms of computational complexity) solution is to
use a strongly typed pointer and preprocessor macros, or void
pointers.

to me more like we've been discussing solutions looking for a problem.
Or do you have an application where both C-style strings and Paul's
better string library are woefully unsuitable? Having a concrete
problem to work with would make weighing alternatives a great deal
easier.

That is separate. Yes, we want to get rid of string.h.

You're not the only one with experience. ;-) But it takes little more
than common sense to see that if there's room left in the glass, you
can add more water. String libraries typically allocate more memory
than needed for that very reason. It avoids excessive calls to the
memory manager.

That makes little sense. You pork out on memory to avoid excessive
calls when a better design would use minimal memory.

I say it adds complexity *because* I've done this type of work. Quite
a bit of it, actually. You have a bad habit of concluding that I don't
know what I'm talking about or haven't "done my homework" when you
disagree with me.

I think corporate life causes programmers to deskill themselves. As
the sociologist Adorno pointed out in a chapter in his 1948 book,
people's flaw first appear "in the organs whose services they sell"
while on an individual basis they remain as individuals charming and
intelligent people. But on the job, vending flawed products, we are
corrupted using a form of even-handedness that refuses to confront the
products in the "organs".

Lots of words and no substance. I asked for a scientific explanation
of why that type of "ownership" is overrated, not some amateur psych
evaluation. I understand both solutions as well as the advantages and
disadvantages of both. I understand that they're suitable in different
situations, but you claim that your solution is better because
"ownership" is overrated and I want to know why.

Because there's absolutely no reason whatsoever to copy data. NEVER,
given the problem statement. If you have a pointer to the data and
there is no concurrent thread that is changing the source, then the
linked list that is based on a pointer will be just as "stable" as a
copy. The programmer, like Heathfield, who makes a copy is wasting
computer time, since IF the data is being altered concurrently, it may
change DURING THE COPY, which would make the copy invalid.

This isn't dogma. Dogma in these threads are statements that deny the
ability to know based on misbegotten standards. The problem in
corporate life is the imposed, monastic, *omerta* and humility that is
imposed on low-level knowers, something ultimately corrupting, and the
effects of which are evident in posters here.

If you maintain two copies of the same data but expect only one, the
application's design is fundamentally flawed to begin with. We're
talking about the design of the linked list itself, not stupid uses of
it.

Which means that the copy is risky in any situation where the source
may change.

No, such as "take your head out of your ass and stop using your
emotions to guide technical arguments". You make the strangest
connections and then lay them out as if they're conclusive arguments.
Debating by confusing one's opponent only works at the lowest levels.

I'm sorry you're confused, but you seem to have missed the class on
linked lists. It seems to me that you're being the emotional one,
where the "emotion" is the reluctance to make a decision based on the
facts, a kind of anomie not thought of, in the corporate world, as an
emotion, but which is one nonetheless.

The willed absence of emotion can itself said to be an emotion (its
name is anhedonia in some contexts, anomie in others) insofar as it
blocks action based on reason.

Furthermore, it is ironic that as a woman you should try a traditional
argument, used against women: that they are thinking "emotionally". In
my experience, too many corporate women use strikingly traditional
memes when talking to men, and the result is that men are scared to be
"emotional", when in my view, good emotion creates energy and
creativity.

And your "better" design will blow up if linked to local data that
goes out of scope or memory that is released by unwitting client code.
I'm afraid that's a downside, despite your claim that none exist.

This is in fact equivalent to the risks of copying data.

If the source of the copied data is released, this may mean that it's
no longer valid. The copy will still exist with no error indication in
this scenario, and the program will not fail...instead "the worst kind
of bug" will result: the one nobody knows about.

This is in fact a greater risk, and added to the slower performance of
the copying solution, it means that the copying solution is almost
never acceptable, except as a documented nondefault alternative to a
linked list that provides copying rather than "hot linking" as an
option.

It's easy to make a library design look bad when you assume it's being
used by an idiot. The C++ container libraries take ownership of data
by copying, and nobody seems to have a problem with them. Further, by
copying pointers to the data rather than the data itself you get the
same effect as linking.







You're too intelligent not to realize how insulting and condescending
your posts are. Are you really trying to imply that you've managed to
insult my experience, my intelligence, my ethics, and my gender all
without knowing it? I actually find that impossible to believe. Once
again, I'm not stupid, and I'm not timid. I can see what you're doing
and I'm not afraid to point it out.

Part of the problem is that male bullying behavior replaces
traditional male (and female: human) arguments based on reason and
facts to such an extent that the latter is classed with bullying. But
I don't accept, not in the slightest, being classed with thugs.

I'm saying you're wrong, and I am explaining it as part of corporate
corruption with which I am familiar: the false even-handedness which
ignores incompetence and bullying.

This is NOTHING like the lies and bullying to which I'm being
subjected to in this newsgroup. In each response to you, I've
addressed the issues, whereas Heathfield and Seebach, as we "speak"
are repeating the canard "Nilges is incompetent and makes errors"
without in any of those posts providing even a precis or summary of
the reasons, for they cannot present any, whereas I have clear
evidence of their incompetence: neither was able to even make a start
on the replace() challenge, Heathfield wrote a "linked list tool"
without pointing to data, Seebach presented a "strlen" with a serious
error, etc.

And don't presume even to say that I've "insulted" your gender. That
is an utter falsehood. I have not patronized nor talked down to you in
the slightest. I am instead arguing for a position: that only an
incompetent would have presented a linked list that copies
unpredictable data into the nodes. This has nothing to do with gender.