comp.lang.c - 8 new messages in 4 topics - digest
comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en
Today's topics:
* usage of size_t - 5 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
* Ask for book for efficient coding in C - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/1b697accaac68aeb?hl=en
* good easy to use Free C compiler!! - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/8554a92ab3eece80?hl=en
* Plan 9's c compiler - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/110a62f10b04cea0?hl=en
==============================================================================
TOPIC: usage of size_t
http://groups.google.com/group/comp.lang.c/t/19e0ad96d01b9898?hl=en
==============================================================================
== 1 of 5 ==
Date: Thurs, Feb 25 2010 11:00 pm
From: Richard Heathfield
Chris M. Thomasson wrote:
<snip>
> I would have to pay the penalty of allocating a node, and allocating
> space for a pointer! IMVHO, this is completely unacceptable
Fine, so don't use it.
> and it shows
> how a value-based container is simply no good at all for certain problems.
But for other problems, it's fine. There is no silver bullet.
--
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
== 2 of 5 ==
Date: Thurs, Feb 25 2010 11:18 pm
From: Richard Heathfield
spinoza1111 wrote:
> On Feb 26, 7:53 am, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2010-02-25, Chris M. Thomasson <n...@spam.invalid> wrote:
>>
>>> Humm... I may me misunderstanding you, buy exactly why do the objects need
>>> to be stored elsewhere?
>> If they don't, where does the pointer point?
>>
>>> I mean, the list already stores a reference to the
>>> object and that's good enough for me. For instance, where am I using extra
>>> storage to "store objects" in the following program:
>> "Extra" meaning "in addition to the list objects".
>>
>> In:
>>
>> struct foo {
>> struct foo *next;
>> char data[];
>> };
>> (C99), each allocated "struct foo" contains the associated data.
>
> No, it doesn't. Furthermore, you are representing the problem as one
> of character data only as if that were the only type of linked list.
Um, that's nonsense. What he's doing is explaining to Chris the
difference between containing and indexing in terms of storage, and he's
trying to do so in a way that even you can understand. Clearly, he's
failing at that last bit, but that's hardly surprising. His char example
is just that - an example.
> In this example, as in your second example below, an address is in the
> node!
>
> The two methods are equivalent. char a[] == char *a functionally and
> conceptually.
Rubbish. The first one is a "struct hack" - IMHO ugly, but pragmatic in
C90 and codified (with slightly different syntax, reflected above) in
C99. Usage is as follows:
struct foo *new = malloc(sizeof *new + number_of_extra_bytes_needed);
if(new != NULL)
{
new->next = NULL;
strcpy(new->data, data);
}
You would do better to learn from Seebs than to presume to teach him.
You have nothing to teach but expletives, and I expect he knows those
already.
> struct a { char arr[1]; };
That isn't what he wrote.
> struct b { char* ptr; } bb;
> printf("%d %d\n", sizeof(bb), sizeof(bb));
>
> Prints 4 4 no matter what size arr is or even if the array size is
> removed.
So you're saying that, on systems with 4-byte pointers, if you print out
the size of a structure containing nothing but a pointer, twice, it'll
print out 4, twice? Gee whizz! (Hint: you printed the same size twice.)
Now, please put down your non sequitur and step away from your reply
button, and pop over to a Web browser. Look up "struct hack". You'll
find a zillion hits for it. Read, mark, learn, and inwardly digest. And
it won't be long before you're trying to pretend that you knew about it
all along.
Cue expletive.
>
> struct a { char arr[1000]; };
> struct b { char* ptr; } bb;
> printf("%d %d\n", sizeof(bb), sizeof(bb));
>
> Prints 4 4
You're still printing the same size twice.
> This is a much more egregious error
Very true, your error is much more egregious. Did you really think you
could make a 1000-byte array only four bytes big?
> than any you've proven as regards
> Schildt, and I've added the two errors here (misrepresentation of
> array/pointer relationship
You did indeed add that error. But Seebs didn't.
> and apparently thinking that all linked
> lists must be characters)
Rubbish. Proof by reductio: You just started a sentence with "This".
Therefore, apparently you think all sentences must start with "This".
How ridiculous is that?
> to a growing collection of serious newbie
> errors that you have made. You need to replace "C: the Complete
> Reference" with an APOLOGY for your disgusting behavior and proven
> incompetence.
You don't know what you're talking about, and it shines out from every word.
>
>> In:
>> struct foo {
>> struct foo *next;
>> char *data;
>> };
>> each allocated "struct foo" contains a pointer to data which must be stored
>> elsewhere.
>
> Inadequate. Not all data is string data.
Your criticism is misplaced. He's not showing you how to use a
type-blind list. That's already been done, in the source text under
discussion. Rather, he's showing you (or rather, Chris) the difference
between containing and indexing.
--
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
== 3 of 5 ==
Date: Thurs, Feb 25 2010 11:53 pm
From: spinoza1111
On Feb 26, 3:07 am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-02-25, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> >spinoza1111wrote:
> >> You get JOBS because code is PORTED.
> > Make-work, you mean? Not interested, thanks.
>
> You can't possibly be surprised by this. Consider his assertion that if
> it was hard to write, it should be hard to read. Clearly, this is a man
> devoted to trying to create job security by every possible tactic other
> than actually being good at his job.
You're in a dreamworld, inhabited by cartoon projections of your own
psychological transference, because far from being interested in "job
security", I have, as I have said, left the field in disgust with
people like you. I had, during a career that was three times as long
as the norm in a field where most programmers are laid off after ten
years, quite a lot of job security owing to my willingness to learn
object oriented approaches and the Web.
In your cartoon dreamworld, your pathetic little videogame of a life,
the minor avatars of programmers were trained (in fact, in the
Dreamtime of the 1970s) by a deliberate corporate misinterpretation of
Dijkstra's 1972 Turing lecture to disavow self-interest, and never
imply by word that they were interested in job security.
The material contradiction was that a "free market" based society
preached on the one hand universal self-interest and fuck-you as
morality, while at the same time demanding that corporations be ever
larger in order to best serve a small wealthy elite. Which required
dragooning people like you, who don't count, into large "teams" of
paid slaves who then had to disavow the previous committment to
universal competition and work like a big happy family.
In fact, absent a property right in a job after a trial period,
something which is denied people in our fuckyou society, there could
at a minimum be a right to ensure job security by establishing tenure
through a skill in something objectively determinable, which means
something whose standards are established OUTSIDE the corporation. But
in the interest of the corporation, even this type of job security was
an obstacle to profit, and the result was that through a deliberate
misinterpretation of structured programming, "skill at programming"
became group-subjective. It became in fact the least common
denominator "skill", which meant that even literate comments (in
little shops staffed by attention-disordered psychology majors) became
deviance from normalized deviance, and a "quirk"...from which clowns
like Peter can infer "incompetence".
>
> >> If malloc.h is NOT included it
> >> will fail on some C compilers.
> > Wrong. Any conforming implementation *must* provide malloc's and free's
> > declarations in <stdlib.h>
>
> More importantly: Let's say that we take him to mean "some compilers for
> variants of C, which are not actually conforming".
>
> Okay. Name one. Here's a test program:
>
> #include <stdlib.h>
> /* #include <malloc.h> */
> int main(void) {
> void *p = malloc(1);
> free(p);
> return 0;
> }
>
> Name a compiler on which this fails, but where if you uncommented the
> second line, it would work. The compiler must have shipped some time
> after 1992 -- it can't be old enough to vote.
After getting rid of 0xa0 characters that you so carelessly left in,
apparently, the code compiles and runs with both or either statements
in Microsoft C++ Express in C mode.
>
> -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!
== 4 of 5 ==
Date: Fri, Feb 26 2010 12:00 am
From: spinoza1111
On Feb 26, 3:36 am, Julienne Walker <happyfro...@hotmail.com> wrote:
> On Feb 25, 1:46 pm,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > On Feb 25, 10:54 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> > > spinoza1111wrote:
>
> > > > Look, buddy, your ridiculous linked list can
> > > > unpredictably bring systems down if it is passed large objects.
>
> > > Feel free to demonstrate how. I'm reasonably sure that I've catered for
> > > that possibility using failure codes to indicate where memory is not
> > > available to store an object, but do you have a counter-example?
>
> > I saw no try catch in your code.
>
> Probably because there's no such construct in portable C. You can
> simulate exceptions using standard C, but it gets ugly very quickly.
Pity.
>
> > In cases where there's (just) enough memory, the code will not
> > fail...just run like a pig.
>
> I don't see how the difference between storing an object and
> referencing an object in a linked list makes a difference here.
>
> In your preferred method, the objects are stored in an external
> location from the list and referenced using pointers in the list
> nodes. The objects still need to be stored somewhere, so the cost is N
> + M where N is the storage for objects and M is the storage for
> pointers to the objects.
I'm not talking about the storage complexity of the source copy of the
objects. I referred, quite clearly, to the time complexity of making
the copy, an O(n) operation which is unnecessary unless the
specification requires a duplicate copy of data.
>
> With the copying method, the list will replace the "external location"
> and act as the primary point of storage for the objects. Then if
> references are needed beyond the list, pointers can be used. Once
> again, the cost is N + M.
>
See above.
> The only difference here is swapped roles of storage and reference.
> The storage costs are identical if you want one pointer for each
> object, so if copying brings the system to it's knees, referencing
> will too.
Not true. The copy in Richard's code is an extra cost imposed by his
decision (possibly made in ignorance) that it's proper to copy things
into his linked list.
>
> I suspect you're imagining both the external location *and*
> interdependent copies stored in the list, which is very likely to be a
> flawed design before the implementation details of your list even
> enter into the picture.
Gobbledegook on steroids,
Sesquipedelian, perfectly formed,
In which we search for meaning in voids
Between the spaces where the meaning should lie.
Be that as it may, in this *opera buffa*
Little headway can be made
'Gainst the nonsense storm in which flies the Worm.
The syntax, tho' it appears Chomsky low
Is in fact corporate Chomsky Three:
What's important is not the meaning
Of the quivering naked whole,
No, what's important are keywords,
For that's what people remember these days.
She says it's flawed so it must be flawed
Somehow someway and one fine day
We'll get a round "tuit" and hey, hey hey
Then we'll know, why it's fucked.
== 5 of 5 ==
Date: Fri, Feb 26 2010 12:07 am
From: Richard Heathfield
spinoza1111 wrote:
<snip>
> I'm not talking about the storage complexity of the source copy of the
> objects. I referred, quite clearly, to the time complexity of making
> the copy, an O(n) operation which is unnecessary unless the
> specification requires a duplicate copy of data.
There Is No Duplicate, unless one chooses to make it.
int loadlistfoo(parms)
{
struct foo bar = {0};
while(getrec(&bar, fp))
{
list_add(&list, &bar, sizeof bar);
}
}
Let's say the above loop creates 2000 records. When the function
returns, there are 2000 records in memory. Not 4000. Not 6000. Just
2000. There Is No Duplicate.
It would be pleasant if, occasionally, it would take you less than a
week to understand the blindingly obvious.
<snip>
--
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
==============================================================================
TOPIC: Ask for book for efficient coding in C
http://groups.google.com/group/comp.lang.c/t/1b697accaac68aeb?hl=en
==============================================================================
== 1 of 1 ==
Date: Thurs, Feb 25 2010 11:58 pm
From: Nick <3-nospam@temporary-address.org.uk>
"christian.bau" <christian.bau@cbau.wanadoo.co.uk> writes:
> On Feb 21, 4:08 pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>
>> Not even that: My advice was directed specifically to the O.P.,
>> a person to whom Jackson's Second Law does not yet apply. At his
>> present stage of development, optimization books good or bad can
>> only do him harm.
>
> There's a very simple rule that applies to the most experienced and
> the most novice programmer: Don't optimise it unless you have measured
> it. Measure it first. Decide whether investing time to optimise it
> could possibly improve it buy an amount that is worth the work. If it
> is worth it, optimise it _and measure it again_. If it didn't improve,
> throw the optimisations away.
>
> The important thing: Measure it. If you are not willing to spend the
> time to measure the speed of your code, that on its own proves that
> you shouldn't waste your time optimising it.
Among other things, and not as often spoken of, this will let you be
absolutely sure all the "scaffolding" of your program works - option
reading and parsing, I/O, data preparation etc. Once you have a
"simple" program producing the right output, and it's too slow, /then/
you can start optimising it, and if the difficult code fails to work
properly, you have a reference to compare it to.
--
Online waterways route planner | http://canalplan.eu
Plan trips, see photos, check facilities | http://canalplan.org.uk
==============================================================================
TOPIC: good easy to use Free C compiler!!
http://groups.google.com/group/comp.lang.c/t/8554a92ab3eece80?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Feb 26 2010 12:02 am
From: Branimir Maksimovic
Conor wrote:
>
> Visual C++ 2005/2008 Express is free but you need to download the
> Windows SDK to do anything useful like Win32 programming. Ruddy great
> big install. Looks like you can dynamically link with a sole
> dependency on msvcrt.dll, but you can't. There's MSVCR70.DLL,
> MSVCR80.DLL and MSVCR90.DLL and they can sod off if they think I'm
> distributing them. So static link again. Sigh.
>
> {
> Note Visual C++ 2008 creates an unnecessary dependency by calling
> GetSystemWindowsDirectoryW. So compiled executables will not run on
> Windows 98SE or ME. Now, I don't worry too much about 98SE given its
> age but I'll be damned to hell if I'll let Microsoft dictate to me
> what markets I may not access. It's one thing if I'm knowingly using
> calls that 98SE didn't have but it's quite another to have MS
> arbitrarily remove that market (however big it is). Rant over.
> Sorry :-)
> }
Well, you can always write your own version of crt ;)
Or you don;t have to use crt at all ;)
I like express edition, it's really professional IDE.
No need for commercial editions at all.
VC++ can read typelibs like headers, which is good, too.
Win SDK you have to download if you want 64 bit compiler
and useful tools.
Greets
==============================================================================
TOPIC: Plan 9's c compiler
http://groups.google.com/group/comp.lang.c/t/110a62f10b04cea0?hl=en
==============================================================================
== 1 of 1 ==
Date: Fri, Feb 26 2010 12:12 am
From: Phred Phungus
William Ahern wrote:
> Phred Phungus <Phred@example.invalid> wrote:
>> I've been reading up on the whole Plan 9 thing. Links here:
> <snip>
>> My question is whether I can get Pcc without having to create a Plan 9
>> partition.
>
> Do you want to cross-compile or are you merely interested in the Plan 9
> additions to the C language?
>
> C99 includes designated initializers--similar to "initialization indexes"
> (GCC supports both syntactical forms)--and compound literals--"structure
> display". Many compilers, including GCC, support anonymous unnamed structure
> and union members. MSC, and GCC in MSC-compability mode, support tagged
> unnamed members as well.
>
I'll cross compile sometime after I have
Hello plan 9 world
as output.
One thing I like about a dual-booting computer is that I have the
'merican OS, windows, and the hippy OS, ubuntu as differing platforms
just to see how code runs.
Part of my motivation is that gcc doesn't work for me effectively on
windows. I was hoping plan 9 could expose why I can use outlook express
but not differing combinations of gnu development tools.
--
fred
==============================================================================
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
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home