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

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

comp.lang.c@googlegroups.com

Today's topics:

* Endless arguing - 14 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/a99361379a499175?hl=en
* small question - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/08850414dcd0b366?hl=en
* C the complete nonsense - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/fee08dfa5e4cbaaa?hl=en
* Son of Snarky Tirade: a response to Seebach's new CTCN: part 1 - 2 messages,
1 author
http://groups.google.com/group/comp.lang.c/t/383e6d5a95dc3f75?hl=en
* lvalues and rvalues - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/0bcad112a3ad97f0?hl=en
* Generic linked list with internal storage? - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/d36ff63bef634bcc?hl=en
* Application Arch / Houston, TX - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/2e3d574e24a0f03d?hl=en

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

== 1 of 14 ==
Date: Mon, Apr 12 2010 1:38 pm
From: Seebs

On 2010-04-12, Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Step 4: Refrain from making any kind of ad hominem remark,
> against anyone, in any posting. Assuming the choice has
> been made to write a response/followup, write about what
> was written, not about the person who wrote it. Calling
> someone a "troll" (or any other such appellation) is just
> as much part of the problem as whatever it was the "troll"
> did in the first place.

I'm not convinced of that. Overall, DNFTT seems to rely to
some extent on convincing people that a given person is, in
fact, a troll. People who don't believe that are unlikely to
participate in avoiding/ignoring the troll.

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.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

== 2 of 14 ==
Date: Mon, Apr 12 2010 1:41 pm
From: Seebs

On 2010-04-12, Ian Collins <ian-news@hotmail.com> wrote:
> But you only replied to one, so the debate never got going.

I'm pretty sure he's killfiled me, which turns out to remove about
half of the responses to his container library posts and discussion.
(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.)

== 3 of 14 ==
Date: Mon, Apr 12 2010 1:50 pm
From: Eric Sosman

On 4/12/2010 4:11 PM, Seebs wrote:
> [...]
> 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
esosman@ieee-dot-org.invalid

== 4 of 14 ==
Date: Mon, Apr 12 2010 2:09 pm
From: "Ersek, Laszlo"

On Mon, 12 Apr 2010, jacob navia wrote:

> 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

== 5 of 14 ==
Date: Mon, Apr 12 2010 2:20 pm
From: "Ersek, Laszlo"

On Mon, 12 Apr 2010, Seebs wrote:

> On 2010-04-12, jacob navia <jacob@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

== 6 of 14 ==
Date: Mon, Apr 12 2010 2:24 pm
From: "Ersek, Laszlo"

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.

lacos

== 7 of 14 ==
Date: Mon, Apr 12 2010 11:10 am
From: "Default User"

"stan" <smoore@exis.net> wrote in message news:jmob97-o76.ln1@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

== 8 of 14 ==
Date: Mon, Apr 12 2010 2:41 pm
From: "Ersek, Laszlo"

On Mon, 12 Apr 2010, Seebs wrote:

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

== 9 of 14 ==
Date: Mon, Apr 12 2010 2:51 pm
From: pacman@kosh.dhis.org (Alan Curry)

In article <R4GdnW2kkdan0l7WnZ2dnUVZ8uBi4p2d@bt.com>,
Richard Heathfield <rjh@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

== 10 of 14 ==
Date: Mon, Apr 12 2010 2:52 pm
From: jacob navia

Seebs a �crit :
>
> 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

== 11 of 14 ==
Date: Mon, Apr 12 2010 2:52 pm
From: jacob navia

Ersek, Laszlo a écrit :
> 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.
>
> lacos

Yes: unspecified order.

== 12 of 14 ==
Date: Mon, Apr 12 2010 2:55 pm
From: jacob navia

Ersek, Laszlo a �crit :
>
> Hmm, nope. I wish to be able to store null pointers in the structure.
>

You can store NULL pointers.

You get a POINTER to an object. That object can be anything, but to
access it you have to dereference the pointer you got. When you
dereference it you CAN get NULL pointers OF COURSE...

== 13 of 14 ==
Date: Mon, Apr 12 2010 2:56 pm
From: jacob navia

Ersek, Laszlo a écrit :
> On Mon, 12 Apr 2010, jacob navia wrote:
>
>> 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

I am serious. I need help, and it would be nice if many people would
review that code.

jacob

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

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

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

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

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

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

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

== 1 of 1 ==
Date: Mon, Apr 12 2010 1:45 pm
From: Keith Thompson

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message
> news:lny6gssboy.fsf@nuthaus.mib.org...
>> You might also consider trying to *understand* how it's done.
>
> memset() takes as its first parameter a void* and that mean to pass any
> type since void is the generic type with the & in front of it. And that's
> how it's done.

Since you've shown *some* understanding here, I'll reply.

Rather than saying that void is the generic type (it really isn't),
it's better to say that void* is the generic pointer type.

Applying unary & to the name of an object gives you a pointer to that
object, which can be passed as an argument to a function with a
parameter of type void*.

The phrase "and that mean to pass any type since void is the generic
type with the & in front of it" is, to be blunt, a bit incoherent; I
can't tell from it whether you really understand or not, or if not,
what your remaining misconceptions might be.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

==============================================================================
TOPIC: C the complete nonsense
http://groups.google.com/group/comp.lang.c/t/fee08dfa5e4cbaaa?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Apr 12 2010 2:39 pm
From: Nick <3-nospam@temporary-address.org.uk>

Willem <willem@turtle.stack.nl> writes:

> Nick wrote:
> ) Looking at these makes me realise that I don't think I've /ever/ used
> ) feof in my life. Trying to read until there is nothing more works so
> ) well.
> )
> ) Does feof have a real use I've somehow missed (the examples above are
> ) clearly not it - they can all be improved by not using the function).
>
> Well,
>
> Euh...
>
> As far as I know, no. I don't think I ever used it either.
>
> Of course, I assume you *do* use ferror() to check for errors when you
> get an EOF on a read. IIRC, the only two reasons you can get EOF is
> when you either have an error (ferror()) or end of file (feof()).
>
> I guess for robustness you could check both.
>
> Feel free to correct me if I'm wrong here.

Well you're wrong that I don't systematically test for errors when I hit
end-of-file. If my system is hosed to the extent that my disk files
aren't reading properly, there isn't going to be a lot of error recovery
I can do anyway. But there are clearly other situations where this is
not as likely.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

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

== 1 of 2 ==
Date: Mon, Apr 12 2010 1:52 pm
From: Phil Carmody

Ian Collins <ian-news@hotmail.com> writes:
> On 04/12/10 05:21 PM, Seebs wrote:
>> On 2010-04-12, Peter Nilsson<airia@acay.com.au> wrote:
>>> Seebs<usenet-nos...@seebs.net> wrote:
>>>> ... So far as I can tell, if people would just ignore
>>>> him and let him be, ...
>>
>>> Well there's a stone from the glass house.
>>
>> I have him killfiled; I haven't yet got the tools to autokill any thread
>> he starts, or anything.
>
> Try Thunderbird.

Do they still make it? If not, I guess there's still cisco
according to http://www.bumwine.com/tbird.html

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

== 2 of 2 ==
Date: Mon, Apr 12 2010 1:56 pm
From: Phil Carmody

blmblm@myrealbox.com <blmblm@myrealbox.com> writes:
> In article <slrnhs4uqc.qlr.usenet-nospam@guild.seebs.net>,
> Seebs <usenet-nospam@seebs.net> wrote:
>> On 2010-04-12, Colonel Harlan Sanders <Harlan@kfc.com> wrote:
>> > On Sun, 11 Apr 2010 17:38:07 -0700 (PDT), spinoza1111
>> ><spinoza1111@yahoo.com> wrote:
>
> [ snip ]
>
>> Please put [NILGES] in subject lines when responding to him or threads
>> about him so people can killfile them more easily,
>
> As I understand it, Google's posting interface strips tags in square
> brackets from subject lines, so your proposed fix here may not be as
> effective as you might like. Just sayin'.

Killfiling anything from googlegroups is always a solution to
that problem.

Phil
--
I find the easiest thing to do is to k/f myself and just troll away
-- David Melville on r.a.s.f1

==============================================================================
TOPIC: lvalues and rvalues
http://groups.google.com/group/comp.lang.c/t/0bcad112a3ad97f0?hl=en
==============================================================================

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

Stephen Sprunk <stephen@sprunk.org> writes:

> On 10 Apr 2010 11:36, Tim Rentsch wrote:
>> Stephen Sprunk <stephen@sprunk.org> writes:
>>> More importantly, assuming a T is a multi-byte object and pointers are
>>> simple memory addresses, is it possible for &T to be the address of a
>>> byte _other than_ the first (i.e. lowest) byte of the object?
>>
>> Certainly it is. Didn't you just explain this yourself
>> in another posting a short time later (or was it earlier)?
>
> After a bit of thinking, I took a stab at how such an implementation
> _might_ work, but I'm not 100% sure that it'd be conforming. Keith's
> responses (to the above) seems to indicate it would be, but I'm still
> not convinced either way.

Certainly there could be a conforming implementation along those
lines, for example for 'T' being 'int'. Any invertible mapping can
be applied to the bits of a memory address to make up the actual
bits in a stored pointer. There are certain constraints related to
certain classes of pointer types (eg, pointers to structs all have
the same representation and alignment), but if we limit ourselves to
the "related" pointer types for a particular scalar type (eg, int *,
const int *, volatile int *, etc), all of those could use the
mapping "base address + sizeof (int)" for the actual stored value.
The key observation is that the mapping is invertible; flipping all
the bits would also work. The trick of adding the size of the
pointed-to type does not work for structs, because pointers to
structs have to have the same representation, and different structs
have different sizes (basically, there is a problem with any kind of
pointer type where what it's pointing at might be an incomplete
type). But pointer to 'int' doesn't have these problems.

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

J de Boyne Pollard <J.deBoynePollard@Tesco.NET> writes:

>> > For what it's worth: Several authorities consider "whether or not"
>> > to be synonymous with "whether", and the "or not" to be, as M.
>> > Uno might have been enquiring, superfluous.
>>
>> In informal English, or in formal technical English?
>
> The authorities that I've seen don't make a distinction
> when talking about "whether or not".

Ahhh. This strengthens my belief that this rule makes more sense in
informal English than it does in formal technical English.

>> In formal technical English, saying "whether or not"
>> clearly removes a possible ambiguity; [...]
>
> What ambiguity?

When "whether" is part of a statement of implication, the distinction
between a one-way implication and a two-way implication.

>> For example, we can know for sure that a given
>> program has no uninitialized variables, but we
>> can't always know for sure that a program
>> _doesn't_ have uninitialized variables.
>
> You've just apparently said the same thing twice
> ("has no uninitialized variables" "does not have
> uninitialized variables") and cast the twain as
> opposites. Did you make a typing error there?

Although I probably could have found better phrasing, I meant what I
said as I typed it, and it illustrates the kind of ambiguity I
referred to. Given a conservative algorithm for detection of
uninitialized variables, we can, for some programs, be sure that
those programs have no uninitialized variables. What we _cannot_ do
is to look at an arbitrary program and then either (a) state with
certainty that it has no uninitialized variables, or (b) state with
certainty that some variables are used without being given initial
values. In other words this is a one-way implication; _if_ we say
a program has no uninitialized variables, then we can be sure that
it has no such variables, but if we _don't_ say a program has no
uninitialized variables then can't be sure either that it does or
doesn't have uninitialized variables. The algorithm can't be smart
enough in all cases to say Yea or Nay with absolute certainty.

Getting back to the original issue, the algorithm tells us _whether_
there is no problem, but it doesn't tell us _whether or not_ there
is no problem, because if it doesn't say there is no problem, there
might be a problem or there might not be, but we can't be sure which.

Does that make more sense now?

== 3 of 3 ==
Date: Mon, Apr 12 2010 2:54 pm
From: "Ersek, Laszlo"

On Mon, 12 Apr 2010, Tim Rentsch wrote:

> Although I probably could have found better phrasing, I meant what I
> said as I typed it, and it illustrates the kind of ambiguity I referred
> to. Given a conservative algorithm for detection of uninitialized
> variables, we can, for some programs, be sure that those programs have
> no uninitialized variables. What we _cannot_ do is to look at an
> arbitrary program and then either (a) state with certainty that it has
> no uninitialized variables, or (b) state with certainty that some
> variables are used without being given initial values. In other words
> this is a one-way implication; _if_ we say a program has no
> uninitialized variables, then we can be sure that it has no such
> variables, but if we _don't_ say a program has no uninitialized
> variables then can't be sure either that it does or doesn't have
> uninitialized variables. The algorithm can't be smart enough in all
> cases to say Yea or Nay with absolute certainty.

Similarly, "testing can prove only the presence of bugs, not their
absence".

Cheers,
lacos

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

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

jacob navia <jacob@jacob.remcomp.fr> writes:

> [snip]
>
> This reinforces my argument: even if lists are "trivial" to implement,
> it is better to avoid reimplementing the wheel...

Simple linked lists predate the wheel. Historically
there is some question about whether the wheel was
invented before or after circular linked lists.

(Sorry, I wouldn't resist. :)

== 2 of 2 ==
Date: Mon, Apr 12 2010 2:28 pm
From: Nick <3-nospam@temporary-address.org.uk>

Jef Driesen <jefdriesen@hotmail.com.invalid> writes:

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

But you write generic functions that work on a simple structure with
just the next and prev pointers. You just cast your specific structures
to these, and cast back to the specific types in your callback function.

The only constraint is that you have to have the same next/prev pointers
order in any structure that the generic functions work on.

This works because all structure pointers can be cast to others, and all
structures with common initial sequences have the same alignment for
that part.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk

==============================================================================
TOPIC: Application Arch / Houston, TX
http://groups.google.com/group/comp.lang.c/t/2e3d574e24a0f03d?hl=en
==============================================================================

== 1 of 1 ==
Date: Mon, Apr 12 2010 2:33 pm
From: kutti

Title: Application Arch

Location: Houston, TX

Description:

Following skills are required:

1) Agile or Scrum
2) Webservices
3) Fidelity or Hogan
4) Quicken or QuickBooks - Pref.

Responsible for the definition, design, construction, integration,
testing, and support of reliable and reusable software solutions,
addressing business opportunities. Includes systems analysis, creation
of specifications, coding, testing, and implementation of application
programs and data interfaces.
Requires a previous domain of experience in applications development.
Responsible for overall application design, including interfaces with
other applications and systems. Assures that application designs are
consistent with industry best practices application attributes
(including scalability, availability, maintainability, and
flexibility).

5+ years experience with Financial Services clients
Oversight
Coordinating others work while involved with multiple work streams

For more job Description click on the link:

http://globalitjobs.com/job_view.php?id=290

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

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Monday, April 12, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts