comp.lang.c - 25 new messages in 7 topics - digest
comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en
Today's topics:
* Garbage - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/e540ba3bcd7a281f?hl=en
* Wholesale GHD MK4 MK5, CHI free shipping(www.dotradenow.com) - 1 messages, 1
author
http://groups.google.com/group/comp.lang.c/t/a9695c7acdd06eef?hl=en
* ۞__۞__۞paypal wholesale cheap replica hangbags & purse at www.ecyaya.com - 1
messages, 1 author
http://groups.google.com/group/comp.lang.c/t/a97d9497b1538c8f?hl=en
* a gift for the mortensens - 4 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/1911197d173cd869?hl=en
* arithmetic on a void * pointer - 14 messages, 6 authors
http://groups.google.com/group/comp.lang.c/t/451b17d19dcc5236?hl=en
* Comparision of C Sharp and C performance - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/4cf78a2afa73b77a?hl=en
* On answering homework - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/fc4c3ccfd56dd962?hl=en
==============================================================================
TOPIC: Garbage
http://groups.google.com/group/comp.lang.c/t/e540ba3bcd7a281f?hl=en
==============================================================================
== 1 of 1 ==
Date: Mon, Jan 11 2010 11:44 pm
From: gwowen
On Jan 11, 8:59 pm, Antoninus Twink <nos...@nospam.invalid> wrote:
> Your arrogance certainly marks you out as exactly one of those
> "regulars" that Kenny is talking about.
Oh please, Sockpuppet. Your opinion on yourself is not enlightening.
==============================================================================
TOPIC: Wholesale GHD MK4 MK5, CHI free shipping(www.dotradenow.com)
http://groups.google.com/group/comp.lang.c/t/a9695c7acdd06eef?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 12 2010 12:47 am
From: yoyotrade
Free shipping GHD MK4 MK5 cheap Wholesale, GHD hair straightener
Wholesale(www.dotradenow.com)
Cheap Benefit GHD (www.dotradenow.com)
Cheap Black GHD (www.dotradenow.com)
Cheap Dark GHD (www.dotradenow.com)
Cheap pink GHD (www.dotradenow.com)
Cheap new style Leopard GHD (www.dotradenow.com)
Cheap IV mini styler GHD (www.dotradenow.com)
Cheap rare Leopard GHD (www.dotradenow.com)
Cheap rare newest Leopard style (www.dotradenow.com)
Cheap Gold GHD (www.dotradenow.com)
Cheap Kiss GHD (www.dotradenow.com)
Cheap pink MK5 (www.dotradenow.com)
Cheap black GHD (www.dotradenow.com)
Cheap limited edition MK5 (www.dotradenow.com)
Cheap pure black GHD MK5 (www.dotradenow.com)
Cheap pure white GHD (www.dotradenow.com)
Cheap Pink style GHD (www.dotradenow.com)
Cheap Purple style GHD with dryer (www.dotradenow.com)
Cheap Salon GHD (www.dotradenow.com)
CHI
Cheap Ammy green CHI (www.dotradenow.com)
Cheap Black style CHI (www.dotradenow.com)
Cheap Blue style CHI (www.dotradenow.com)
Cheap Camouflage Blue CHI (www.dotradenow.com)
Cheap Camouflage pink CHI (www.dotradenow.com)
Cheap Peachblow CHI (www.dotradenow.com)
Cheap Pink style CHI (www.dotradenow.com)
Cheap Red-black CHI (www.dotradenow.com)
Cheap Wide red-black CHI(www.dotradenow.com)
Cheap crimping iron (www.dotradenow.com)
==============================================================================
TOPIC: ۞__۞__۞paypal wholesale cheap replica hangbags & purse at www.ecyaya.
com
http://groups.google.com/group/comp.lang.c/t/a97d9497b1538c8f?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 12 2010 1:03 am
From: hero
۞__۞__۞paypal wholesale cheap replica hangbags & purse at www.ecyaya.com
replica bag replica prada bag replica new prada bag replica claasic
prada bag replica prada handbag replica shoulder bags replica Prada
Cervo Pleat Hobo Bag on www.ecyaya.com
Replica Prada Cervo Pleat Hobo Bag detail below:
The replica Prada Cervo Pleat hobo Bag is an ordinary deerskin
handbag www.ecyaya.com
with a pleated top, but the option of the stunning clear-ocean
turquoise color makes this handbag stand out.The great thing about
this replica Prada cervo pleat Bag is the slouch along with the
removable shoulder strap, which gives the option to wear it cross-
body. It feels very LA or SoHo. There are open pockets on the side
and www.ecyaya.com
the dimensions are ample to wear and lug the daily necessities. www.ecyaya.com
The dimension of this Prada cervo pleat hobo bag is 16 1/2″H x 10″W x
5″D approximately. www.ecyaya.com
replica bag replica prada bag replica new prada bag replica claasic
prada bag replica prada handbag replica prada shoulder bags replica
Prada Cervo Pleat Hobo Bag on www.ecyaya.com
The replica Prada Handbags ang bag come with serial number,
authenticity card, Prada dust bag, and care booklet. you will get is
same as the original.www.ecyaya.com
we can make sure that all of replica bag replica prada bag replica
new prada bag replica claasic prada bag replica prada handbag replica
shoulder bags replica Prada Cervo Pleat Hobo Bag come with high
quality. www.ecyaya.com
you need not worry about the quality of our replic prada bag or other
replica bags. www.ecyaya.com
we also offer best sale service to you .
i suggest you to buy one for you friend or you or your lover.
if you buy replica bag replica prada bag replica new prada bag
replica www.ecyaya.com
Classic prada bag replica prada handbag replica shoulder bags replica
Prada Cervo Pleat Hobo Bag from www.ecyaya.com
i think you will be very satisfied with our replica bag.
we will sent you the goods to you within 48 hours after we get your
payment. www.ecyaya.com
you will get the package in 5-7 working day.
waitting for your order about replica bag replica prada bag replica
new prada bag replica claasic prada bag replica prada handbag replica
shoulder bags replica Prada Cervo Pleat Hobo Bag on www.ecyaya.com
==============================================================================
TOPIC: a gift for the mortensens
http://groups.google.com/group/comp.lang.c/t/1911197d173cd869?hl=en
==============================================================================
== 1 of 4 ==
Date: Tues, Jan 12 2010 1:04 am
From: Richard Heathfield
Keith Thompson wrote:
<snip>
> I find that I'm a little uncomfortable
> with the way the constant 1.0 imposes its type on the rest of the
> expression, bubbling up through multiple levels of the tree.
But you get that "bubbling up" anyway, with (double)RAND_MAX, so I don't
see why 1.0 should worry you.
--
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 4 ==
Date: Tues, Jan 12 2010 3:46 am
From: Ben Bacarisse
frank <frank@example.invalid> writes:
> Ben Bacarisse wrote:
<snip>
>> ... There are
>> probably better ways to do this, but the best of all would be a
>> floating-point random function in C. Such a function could rely on
>> the internal representation of a floating point number to give a
>> properly uniform distribution. Many C libraries include such a
>> function as an extension.
>
> Is gcc one of them?
glibc (rather than gcc) includes drand48. It is a POSIX function.
Someone else posted about this as well (sorry I forget who).
<snip>
--
Ben.
== 3 of 4 ==
Date: Tues, Jan 12 2010 3:52 am
From: Ben Bacarisse
Keith Thompson <kst-u@mib.org> writes:
> frank <frank@example.invalid> writes:
<snip>
>> People like me, who read his collection
>> while sitting in a parking lot, are always grateful for his
>> contribution, but useless casts make code unreadable.
>
> What useless casts? There were several in the earlier code you
> posted; there aren't very many in the FAQ. In question 13.16, we see:
>
> (int)((double)rand() / ((double)RAND_MAX + 1) * N)
>
> and
>
> (int)(drand48() * N)
>
> The double casts *are* necessary. The int casts may or may not be,
> depending on what's done with the result.
Surely only one of the casts to double is needed? I'm not sure it's
clearer to omit one, but I don't think they are both needed. I have
also seen the expression with neither cast and 1 replaced by 1.0.
<snip>
--
Ben.
== 4 of 4 ==
Date: Tues, Jan 12 2010 3:53 am
From: Ben Bacarisse
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
re: (int)((double)rand() / ((double)RAND_MAX + 1) * N)
<snip>
> Surely only one of the casts to double is needed? I'm not sure it's
> clearer to omit one, but I don't think they are both needed. I have
> also seen the expression with neither cast and 1 replaced by 1.0.
Sorry. I see that got covered in another sub-thread.
--
Ben.
==============================================================================
TOPIC: arithmetic on a void * pointer
http://groups.google.com/group/comp.lang.c/t/451b17d19dcc5236?hl=en
==============================================================================
== 1 of 14 ==
Date: Tues, Jan 12 2010 1:56 am
From: spinoza1111
On Jan 12, 3:09 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> spinoza1111 wrote:
> > On Jan 12, 11:33 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> <snip>
>
> >> If the OP can't see the point of void *, it may be that this is simply a
> >> facet of the way he approaches programming - in other words, maybe for
> >> him there isn't any point to it. It is certainly true that, for his
> >> compression needs, he doesn't actually need void * - he could easily
> >> make do with unsigned char * instead.
>
> > Not if the size of the character is larger than the byte.
>
> We're talking about chars, not characters. I do not expect you to
> understand the difference.
Pompous fool.
>
> A char is guaranteed to occupy exactly one byte of storage, and the byte
> is guaranteed to be at least 8 bits wide (but it can be wider).
That's silly, because it means that I can't program the IBM 1401
second-generation transistor computer being reconstructed at the
Computer Museum in Mountain View in C! Its "byte" is six bits, seven
bits if you count the word mark.
Although C was invented on the DEC 10 (I think) during the 1401's
useful life, a search for "C programming on the IBM 1401" gets no
hits.
Alternatively, how would you write a simulator for a machine whose
basic addressable unit is six bits?
You pretend that these conventions are knowledge.
Silly bastard.
>
> > News flash,
>
> > Heathfield. The "smallest addressable unit" of most modern platforms
> > is no longer == char,
>
> Olds flash: the fact that the smallest addressable unit of storage is
> the byte, and one char requires exactly one byte of storage, remains
> true for all conforming C implementations, even on modern platforms.
So let the void have sizeof one
And with this nonsense, be done.
>
> > because of internationalization: the wide char
>
> > IS the char in reality. Therefore Adler needs to code what he MEANS,
> > which is the calculation of byte and not character addresses.
>
> Which is precisely what unsigned char * will give him.
That's absurd, because there's no meaning to signing a character
outside of C. The only question is whether enough bits are in the
character to represent all possible languages world-wide.
>
> --
> 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 14 ==
Date: Tues, Jan 12 2010 2:08 am
From: Richard Heathfield
spinoza1111 wrote:
> On Jan 12, 3:09 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
<nonsense snipped>
>> A char is guaranteed to occupy exactly one byte of storage, and the byte
>> is guaranteed to be at least 8 bits wide (but it can be wider).
>
> That's silly, because it means that I can't program the IBM 1401
> second-generation transistor computer being reconstructed at the
> Computer Museum in Mountain View in C! Its "byte" is six bits, seven
> bits if you count the word mark.
No, it doesn't mean that at all. It does mean, however, that a
conforming implementation for such a machine would have to do some extra
work.
<nonsense snipped>
>>> because of internationalization: the wide char
>>> IS the char in reality. Therefore Adler needs to code what he MEANS,
>>> which is the calculation of byte and not character addresses.
>> Which is precisely what unsigned char * will give him.
>
> That's absurd, because there's no meaning to signing a character
> outside of C.
We're talking about chars, not characters. I do not expect you to
understand the difference.
> The only question is whether enough bits are in the
> character to represent all possible languages world-wide.
No, that isn't the question: we're talking about chars, not characters.
--
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 14 ==
Date: Tues, Jan 12 2010 2:17 am
From: Ian Collins
Richard Heathfield wrote:
> spinoza1111 wrote:
>>
>> That's absurd, because there's no meaning to signing a character
>> outside of C.
>
> We're talking about chars, not characters. I do not expect you to
> understand the difference.
Why do you bother?
--
Ian Collins
== 4 of 14 ==
Date: Tues, Jan 12 2010 2:23 am
From: Richard Heathfield
Ian Collins wrote:
> Richard Heathfield wrote:
>> spinoza1111 wrote:
>>>
>>> That's absurd, because there's no meaning to signing a character
>>> outside of C.
>>
>> We're talking about chars, not characters. I do not expect you to
>> understand the difference.
>
> Why do you bother?
Very good question. The guy seems to be completely incapable of
understanding even the simplest things.
--
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
== 5 of 14 ==
Date: Tues, Jan 12 2010 2:51 am
From: Nick Keighley
On 12 Jan, 03:33, Richard Heathfield <r...@see.sig.invalid> wrote:
> spinoza1111 wrote:
> > But congratulations to the growing number of people
> > who are calling Heathfield on his <rubbish>
>
> [...] let's count them, shall we? [...] Judging by the
> lack of feedback, Han appears to have gone, so it seems that either
> the number has actually reduced [...] or everybody simultaneously
> killfiled Han some months ago.
I don't use a kill file. Han really has gone.
> And if
> we reduce the number to those who actually post under their real name,
> that number shrinks to one.
using/not using a pseudoname isn't a 100% indication of quality of
postings
<snip>
> The rest of this article addresses the original subject of the thread,
> "arithmetic on a void * pointer".
>
> It may well be that the OP's attitude to void * stems from what might be
> called a "pigeon-hole" approach to programming - memory is a bunch of
> pigeon-holes, and a program is just a list of instructions for visiting
> them (and modifying their contents) in a particular, dynamic, order.
> This very low-level approach is absolutely fine and highly justifiable
> for some people (especially writers of object code!). One can see why
> such a person might have little patience with restrictions on pointer
> arithmetic (and indeed with other forms of abstraction).
>
> For those who have a higher level approach, however, the abstract
> machine (AM) comes to the fore - and the AM doesn't define arithmetic on
> void pointers because it can't be sure of the outcome of such arithmetic
> on the real machines on which the AM sits.
yes, but that was a design choice. They could have defined the AM
differently if they'd wanted to.
> The Standard's definition of p++ can be thought of as "increment p by
> sizeof *p" - i.e. if p's object representation is 0xF000 and it's a
> pointer to an int where int is known to be 6 bytes, then we should not
> be entirely surprised if p's object representation changes to 0xF006.
> Now, if p is a void *, then we're asking for p to be incremented by the
> value of sizeof(void), which is obviously meaningless, since void is an
> incomplete type that cannot be completed and so there is no way to know
> how big it is.
>
> The point of void* is not to be a mere synonym for char*,
there wouldn't be much point in introducing it if it had been.
> but to allow
> us to abstract away the differences between types when performing
> operations on objects for which their type is immaterial, or to allow us
> to process them so far, and then hand on their type-specific part to a
> function that knows about their type. Obvious examples are mem*, qsort,
> bsearch, fread, fwrite, and abstract container libraries.
>
> If the OP can't see the point of void *,
...then perhaps he should use unsigned char* instead. I usually define
a type Byte or Octet if I want to manipulate buffers of bytes.
> it may be that this is simply a
> facet of the way he approaches programming - in other words, maybe for
> him there isn't any point to it. It is certainly true that, for his
> compression needs, he doesn't actually need void * - he could easily
> make do with unsigned char * instead.
compression seems a very good candidate for operating on bytes/octets.
--
We recommend, rather, that users take advantage of the extensions of
GNU C and disregard the limitations of other compilers. Aside from
certain supercomputers and obsolete small machines, there is less
and less reason ever to use any other C compiler other than for
bootstrapping GNU CC.
(Using and Porting GNU CC)
== 6 of 14 ==
Date: Tues, Jan 12 2010 2:57 am
From: spinoza1111
On Jan 12, 6:17 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> Richard Heathfield wrote:
> > spinoza1111 wrote:
>
> >> That's absurd, because there's no meaning to signing a character
> >> outside of C.
>
> > We're talking about chars, not characters. I do not expect you to
> > understand the difference.
>
> Why do you bother?
> --
> Ian Collins
That's another one for the Red Book, Dickie.
"comp.programming is not about programmers"
"Nilges isn't in comp.risks"
"I am smarter than Peter Neumann"
"chars aren't characters"
You see, the referents of your language are fantasies and the words
themselves, which you foolishly have learned to fit together without
troubling to see if they have any relationship to reality.
Adler's and GCC's usage reflects a possibility of which you are
unaware. This is that while on most computers, the smallest
addressible piece of memory is a character (where this is a Western
letter or ideogram), this wasn't the case in the second and first
generation of computers, and given the reality that "retro" computing
is practised at places like the Computer Museum in Mountain View, we
need to program physically reconstructed or simulated machines. And
not only for shits and giggles: especially in military applications,
the baby-killers might want to reprogram older baby-killing machines
(I don't like it but it's a "need", and they might be beating swords
into plowshares or reprogramming older land mines so they don't go off
when touched by a kid).
For example, the IBM 7094 had a 36 bit word with six 6 bit characters
packed inside words using BCD. The smallest addressable unit of memory
was the word, not the character. Implementing C on the 7094 means that
the sizeof the character is 1/6, a double or single precision value.
This means that you want foolishly to conflate char* and void*, but on
the 7094, Adler's default (void points to sizeof 1) is not the same as
char, and on the 7094, sizeof has to return a float. You foolishly
confuse C with a language like Lisp or Java, not seeing how much (bad)
history is incorporated in it. And like Seebach you try to destroy
reputations of people far more qualified than you based on your
Sophistry.
This is foolish because you think that C is "portable" whereas it is
tied to a machine in which the smallest addressable unit of memory is
the character.
Of course, this is a "retro" issue, but going forward, multibyte
characters mean that "the smallest addressable unit of memory" is no
longer the character.
C can of course be "hacked" to accomodate both retro and multibyte
computing, but you think foolishly that this shows the power of C.
What it shows is the power of Turing machines no matter how silly they
are. C is a Turing machine...one that sucks and that obscures what
goes on.
But hey don't go changin'. Your world is self-referential and you are
hopeless when it comes to the possibility of retraining. This was
clear to me in 2003 when you made a big whoop tee doo about an
invariant in a for loop. That is, when you can't dominate the agenda,
you do ANYTHING to invent agenda items, you lie about people, and you
deny your own lies.
== 7 of 14 ==
Date: Tues, Jan 12 2010 3:08 am
From: gwowen
On Jan 12, 10:23 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> Very good question. The guy seems to be completely incapable of
> understanding even the simplest things.
So stop. What are you trying to prove anyway? That you're smarter
that Nilges? I would suggest that stopping would go some way to
prove that, whereas not stopping provides strong counter-evidence.
It's not as if this hasn't been going on for the best part of a
decade. What's that they say about the definition of insanity is
doing the same thing over and over again and expecting different
results?
== 8 of 14 ==
Date: Tues, Jan 12 2010 3:09 am
From: Nick Keighley
On 12 Jan, 06:45, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Jan 12, 11:33 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> > spinoza1111 wrote:
<snip longish post by Richard heathfield>
learn to trim posts you idiot
> Pompous and content-free, since if you were really interested in
> abstraction and type safety you would not use C.
C is less abstract than some but probably more so than you appeciate.
The quite portable Linux Kernel is written in (a dialect of) C
> You would learn an
> object oriented language,
well, no, not necessarily. OO is the be all and end all of programming
technology
"The statement [Dealing with large numbers of interrelated types while
still preserving modularity in the design of large systems is very
difficult, and is an area of much current research.], [...] is just as
true now as it was when we wrote it twelve years ago. Developing a
useful, general framework for expressing the relations among different
types of entities (what philosophers call ``ontology'') seems
intractably difficult. The main difference between the confusion that
existed ten years ago and the confusion that exists now is that now a
variety of inadequate ontological theories have been embodied in a
plethora of correspondingly inadequate programming languages. For
example, much of the complexity of object-oriented programming
languages -- and the subtle and confusing differences among
contemporary object-oriented languages -- centers on the treatment of
generic operations on interrelated types. Our own discussion of
computational objects in chapter 3 avoids these issues entirely.
Readers familiar with object-oriented programming will notice that we
have much to say in chapter 3 about local state, but we do not even
mention ``classes'' or ``inheritance.'' In fact, we suspect that these
problems cannot be adequately addressed in terms of computer-language
design alone, without also drawing on work in knowledge representation
and automated reasoning."
Structure And Interpretation of Computer Programs.
> but you refuse to be vulnerable and to learn.
>
> The original poster is in fact a competent C programmer. You're not.
>
> Object oriented languages allow both "incomplete classes" and
> "abstract classes" and they separate these notions, whereas void is
> neither.
quite, so why mention them? void* is more like an opaque type. Only
Ada (that I'm aware of) dealt with these explicitly.
> In C Sharp, for example, an incomplete class definition is simply part
> of its source code.
what?
> An abstract class is one that cannot be
> instantiated but must be inherited.
and so not an opaque type
> But void is-not inherited in any meaningful sense in C.
unsurprising as C doesn't have inheritance.
> You cannot say
> than an int is-a void with additional properties and additional
> restrictions.
no you can't. And more importantly ***you don't want to*** as that is
not the appropriate semantic abstraction.
> Which means in C that the GCC option makes perfect sense and provides
> the ability to do arithmetic on pure pointers which point to sod-all.
doing arithmatic on pointer that point to sod all seems at best
pointless and at worst dangerous. Typically in C this will lead to
undefined behaviour. Good.
> This is in fact the world of assembler: Never-Never land, a dream time
> when programmers had Fun
well assembler can be fun but it takes a long time to get anything
done. This is why things like C hash were invented.
<snip>
> Most of you creeps flunked English, which is part of your problem, so
> at this point I can see you saying WTF.
I've got 2 O Levels (though my spelling doesn't give it away)
== 9 of 14 ==
Date: Tues, Jan 12 2010 3:18 am
From: spinoza1111
On Jan 12, 2:17 pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-01-12, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > The point of void* is not to be a mere synonym for char*, but to allow
> > us to abstract away the differences between types when performing
> > operations on objects for which their type is immaterial, or to allow us
> > to process them so far, and then hand on their type-specific part to a
> > function that knows about their type. Obvious examples are mem*, qsort,
> > bsearch, fread, fwrite, and abstract container libraries.
>
> In particular:
>
> I find that it's *USEFUL* to get warned if I try to do arithmetic on
> a (void *), because it means I think I know what I have a pointer to, and
> that either I should change the type of the pointer to reflect what I know
> it points to, or I don't know enough to do that arithmetic.
If you had enough education and experience, Petey, you'd know that
sometimes you need to forget what you know in order to write software.
That should be easy for you IF forgetting takes the same amount of
energy as learning (and there are neurochemical reasons for thinking
that it may), since you haven't learned much.
If C were truly a portable and safe programming language, then I could
write ONE data compression program that wouldn't have to "know or
care" whether it was compressing bytes or structs or whatever. All I
want is a void pointer that points to the smallest addressable unit of
memory. If I am compressing 16 bit international characters then I can
use multiplication by two (by means of shifting) after calculating the
offset. I don't want some clown porting it to a source code ecosystem
where the char is multibyte, because then my calculations will be off
by two times.
I don't have much experience in Adler's area but it appears to me that
GCC is a good tool if he must use C, since it separates the idea of a
character from the idea of a pure memory pointer. If you want to use
strong types at all times, go back to school and learn Java. But if
C's claims to be "close to the machine" are at all true, then it needs
to provide a pure assembler mode, in which we are Noble Savages
innocent of anything except computer memory. We don't know the sizeof
its units, and we don't know if they contain characters, parts of
characters, or several characters.
This is where I think void* would come in handy. In fact, I am
beginning to think its inclusion in GCC was a stroke of genius. You
see, the GCC developers didn't have greedy vendors on their ass.
But hey what do I know, I just have thirty years of experience, and
shit.
ROTFLMFAO
>
> If I want a buffer of unsigned chars, I know where to find it.
>
> -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!
== 10 of 14 ==
Date: Tues, Jan 12 2010 3:22 am
From: Nick Keighley
On 12 Jan, 09:56, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Jan 12, 3:09 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> > spinoza1111 wrote:
> > > On Jan 12, 11:33 am, Richard Heathfield <r...@see.sig.invalid> wrote:
<snip>
> > A char is guaranteed to occupy exactly one byte of storage, and the byte
> > is guaranteed to be at least 8 bits wide (but it can be wider).
by (I consider) an unfortunate historical accident C made a byte the
same as a char ***by definition***. And a byte/char must be at least 8
bits. C implementaions must respect this definition.
> That's silly, because it means that I can't program the IBM 1401
> second-generation transistor computer being reconstructed at the
> Computer Museum in Mountain View in C! Its "byte" is six bits, seven
> bits if you count the word mark.
you can't make the char type equal to the native byte, no. They'll
have to use some larger "object".
<snip>
> Alternatively, how would you write a simulator for a machine whose
> basic addressable unit is six bits?
I'd use a char to represent the basic addressable unit and make sure
it never used more than 6 bits. Since a 6 bit byte machine is likely
pretty old I don't expect I'd get a memory problem. My key ring
contains more than 2000 Vaxs.
> You pretend that these conventions are knowledge.
they're handy if you want to write C programs. If you don't they are
pretty esoteric.
<snip>
> > > because of internationalization: the wide char
> > > IS the char in reality. Therefore Adler needs to code what he MEANS,
> > > which is the calculation of byte and not character addresses.
>
> > Which is precisely what unsigned char * will give him.
>
> That's absurd, because there's no meaning to signing a character
> outside of C. The only question is whether enough bits are in the
> character to represent all possible languages world-wide.
a C char is only very loosly related characters in natural written
languages. C was written by Americans before unicode was even a dream.
They think a pound symbol is some sort of noughts and crossses grid.
--
Unicode is an international standard character set that can be used
to write documents in almost any language you're likely to speak,
learn or encounter in your lifetime, barring alien abduction.
(XML in a Nutshell)
== 11 of 14 ==
Date: Tues, Jan 12 2010 3:24 am
From: Nick Keighley
On 12 Jan, 10:23, Richard Heathfield <r...@see.sig.invalid> wrote:
> Ian Collins wrote:
> > Richard Heathfield wrote:
> >> spinoza1111 wrote:
> > [spinoza stuff]
>
> >> [technical C stuff]
>
> >> I do not expect you to understand the difference.
>
> > Why do you bother?
>
> Very good question. The guy seems to be completely incapable of
> understanding even the simplest things.
for The Lurkers
== 12 of 14 ==
Date: Tues, Jan 12 2010 3:34 am
From: spinoza1111
On Jan 12, 7:09 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 12 Jan, 06:45, spinoza1111 <spinoza1...@yahoo.com> wrote:
>
> > On Jan 12, 11:33 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> > > spinoza1111 wrote:
>
> <snip longish post by Richard heathfield>
>
> learn to trim posts you idiot
>
> > Pompous and content-free, since if you were really interested in
> > abstraction and type safety you would not use C.
>
> C is less abstract than some but probably more so than you appeciate.
> The quite portable Linux Kernel is written in (a dialect of) C
I agree that Linux was ported at light speed, but I'd ask whether this
was because it was ported by virtual slaves who didn't know they were
slaves. I can see that Windows generated despair and anguish: when I
read about OS/360, I wanted to write my own operating system. It was
cool that Linux got done, but its developers should have been paid
more, say a fraction of the 2008 bailout.
>
> > You would learn an
> > object oriented language,
>
> well, no, not necessarily. OO is the be all and end all of programming
> technology
You mean it's NOT, and it is NOT. But this argument (which I've heard
more than once in corporate nurseries and kinder-gartens) is
fallacious: "because your better solution is not best, my inferior
solution is preferable and therefore (ta da) the best, or (sighs and
flute notes) better than yours:
Let A be "my solution such as C"
Let B be "your solution such as C Sharp"
Let P be "the language of the gods such as Lisp, Scheme, Haskell or
what ev er"
Let .orEven. be an or operator connotative of rude astonishment
Let quality(x) be "the quality of x"
1. quality(B) < quality(P)
2. ergo quality(A) > quality(B) .orEven. quality(A) == quality(P)
This is of course an invalid argument.
>
> "The statement [Dealing with large numbers of interrelated types while
> still preserving modularity in the design of large systems is very
> difficult, and is an area of much current research.], [...] is just as
> true now as it was when we wrote it twelve years ago. Developing a
> useful, general framework for expressing the relations among different
> types of entities (what philosophers call ``ontology'') seems
> intractably difficult. The main difference between the confusion that
> existed ten years ago and the confusion that exists now is that now a
> variety of inadequate ontological theories have been embodied in a
> plethora of correspondingly inadequate programming languages. For
> example, much of the complexity of object-oriented programming
> languages -- and the subtle and confusing differences among
> contemporary object-oriented languages -- centers on the treatment of
> generic operations on interrelated types. Our own discussion of
> computational objects in chapter 3 avoids these issues entirely.
> Readers familiar with object-oriented programming will notice that we
> have much to say in chapter 3 about local state, but we do not even
> mention ``classes'' or ``inheritance.'' In fact, we suspect that these
> problems cannot be adequately addressed in terms of computer-language
> design alone, without also drawing on work in knowledge representation
> and automated reasoning."
>
> Structure And Interpretation of Computer Programs.
They may be right, but it's silly to quote Abelson et al. in defense
of C, as you seem to be doing. They would replace OO not by C by
logic programming in Lisp and in Scheme, and both of those languages
(especially Lisp) also reflect their origins. And when you get a
language that does "knowledge representation and automated reasoning"
your troubles have only begun, since the Logical Positivists like
Carnap and Nelson Goodman discovered that knowledge is hard to
represent. The problem becomes in fact an unsolved philosophical
problem.
The best is the enemy of the good. Sure, I might migrate to F Sharp
and I should probably learn a lot more about lisp. But it's INSANE to
quote these guys to defend C. They'd laugh at you.
>
> > but you refuse to be vulnerable and to learn.
>
> > The original poster is in fact a competent C programmer. You're not.
>
> > Object oriented languages allow both "incomplete classes" and
> > "abstract classes" and they separate these notions, whereas void is
> > neither.
>
> quite, so why mention them? void* is more like an opaque type. Only
> Ada (that I'm aware of) dealt with these explicitly.
>
> > In C Sharp, for example, an incomplete class definition is simply part
> > of its source code.
>
> what?
>
> > An abstract class is one that cannot be
> > instantiated but must be inherited.
>
> and so not an opaque type
>
> > But void is-not inherited in any meaningful sense in C.
>
> unsurprising as C doesn't have inheritance.
>
> > You cannot say
> > than an int is-a void with additional properties and additional
> > restrictions.
>
> no you can't. And more importantly ***you don't want to*** as that is
> not the appropriate semantic abstraction.
>
> > Which means in C that the GCC option makes perfect sense and provides
> > the ability to do arithmetic on pure pointers which point to sod-all.
>
> doing arithmatic on pointer that point to sod all seems at best
> pointless and at worst dangerous. Typically in C this will lead to
> undefined behaviour. Good.
>
> > This is in fact the world of assembler: Never-Never land, a dream time
> > when programmers had Fun
>
> well assembler can be fun but it takes a long time to get anything
> done. This is why things like C hash were invented.
>
> <snip>
>
> > Most of you creeps flunked English, which is part of your problem, so
> > at this point I can see you saying WTF.
>
> I've got 2 O Levels (though my spelling doesn't give it away)
You're the exception that proves the rule
I congratulate you on your performance in school
== 13 of 14 ==
Date: Tues, Jan 12 2010 4:00 am
From: Richard Heathfield
spinoza1111 wrote:
<nonsense snipped>
> "chars aren't characters"
Right. They're chars.
<nonsense snipped>
> This is that while on most computers, the smallest
> addressible piece of memory is a character
In C, which is what we discuss in comp.lang.c, it's a byte, not a character.
<nonsense snipped>
> For example, the IBM 7094 had a 36 bit word with six 6 bit characters
> packed inside words using BCD. The smallest addressable unit of memory
> was the word, not the character. Implementing C on the 7094 means that
> the sizeof the character is 1/6, a double or single precision value.
On machines in which the smallest addressable unit is 36 bits wide,
either the byte is 36 bits wide too, or the implementation has to do
extra work (e.g. if the implementor wants to use 9-bit bytes, then there
has to be some mechanism for translating "C bytes" into "machine bytes"
- those aren't formal terms, by the way; I'm just trying to find a way
to express it that's easy to understand).
> This means that you want foolishly to conflate char* and void*,
The whole point of my reply was that we should *not* conflate char* (or
rather unsigned char *) and void *.
> but on
> the 7094, Adler's default (void points to sizeof 1)
void doesn't point anywhere, since it's an incomplete type that cannot
be completed. sizeof 1 is equivalent to sizeof(int), which is typically
4 on modern desktop systems (but needn't be).
> is not the same as
> char, and on the 7094, sizeof has to return a float.
sizeof yields a size_t, which is guaranteed to be an unsigned integral type.
<nonsense snipped>
> This is foolish because you think that C is "portable" whereas it is
> tied to a machine in which the smallest addressable unit of memory is
> the character.
C is indeed portable - in fact, it's the most portable language
available. It is not tied to any machine, and the smallest addressable
unit of memory is called a byte, not a character.
> Of course, this is a "retro" issue, but going forward, multibyte
> characters mean that "the smallest addressable unit of memory" is no
> longer the character.
In C, it never was. It was, and remains, the byte.
<nonsense snipped>
--
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
== 14 of 14 ==
Date: Tues, Jan 12 2010 4:11 am
From: Richard
Richard Heathfield <rjh@see.sig.invalid> writes:
> spinoza1111 wrote:
>
> <nonsense snipped>
>
>> "chars aren't characters"
>
> Right. They're chars.
>
I think at that point any one should realise you are not someone to
discuss anything with.
==============================================================================
TOPIC: Comparision of C Sharp and C performance
http://groups.google.com/group/comp.lang.c/t/4cf78a2afa73b77a?hl=en
==============================================================================
== 1 of 3 ==
Date: Tues, Jan 12 2010 2:18 am
From: richard@cogsci.ed.ac.uk (Richard Tobin)
In article <e2a4841f-453d-472c-a224-bea4f96bd5f0@m3g2000yqf.googlegroups.com>,
spinoza1111 <spinoza1111@yahoo.com> wrote:
>Thanks for the clarification, if indeed this is a "clarification" in
>the sense of being "clear" and therefore true. I don't have time,
>right now, to work through your example. But is it fair to say that
>the preprocessor rescans until all define symbols are gone? If this is
>the case, can source code loop the preprocesssor? If this is the case,
>does this not suck?
Rescanning is done, but not in a way that can cause indefinite
recursion. See section 6.10.3.4 of C99, "Rescanning and further
replacement".
>And do you know whether there is any difference
>between inside out expansion and rescanning?
The very article you were replying to showed an example of this. But
if you "didn't have time to work through it" - it should only take a
few seconds - I'm not going to spend my time spelling it out to you.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
== 2 of 3 ==
Date: Tues, Jan 12 2010 3:49 am
From: Nick Keighley
On 11 Jan, 15:20, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Jan 11, 4:16 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
> > On 10 Jan, 13:35, Richard <rgrd...@gmail.com> wrote:
> > > Richard Heathfield <r...@see.sig.invalid> writes:
> > > >spinoza1111wrote:
> > > >> He didn't want to explain "my" 1990 rule (parenthesize formal
> > > >> parameters in macro definitions, decide whether to return an
> > > >> expression or a statement, return nothing else, if you return an
> > > >> expression return it in its own set of round parentheses, if you
> > > >> return a statement return the statement list in its own set of braces)
> > > >> because there might have been counter-examples and the rule is rather
> > > >> complicated.
>
> > > > There is no sensible rule, simple or complicated, about what macros
> > > > return, because macros don't return anything. We covered this already.
>
> > > How silly. And for years myself and other long term programmers managed
> > > to understand what "the macro returns X" means.
>
> > to be fair spinoza seems to be using the term in a slightly different
> > fashion. he's talking about the textual expansion of the macro. So
>
> > #define INC(X) (X + 1)
>
> > INC(y);
>
> > "returns" (y + 1)
>
> > I was going to say that spinoza's usage, though non-standard, was
> > clear but perhaps it isn't...
>
> In other words, I'm being trashed and you're afraid of being subject
> to the same treatment.
no. It's surprising how often "in other words" is used to introduce a
phrase that has a radically different meaning from that which it
replaces (a sort of natural language macro).
I was actually trying to spin your post so it made some sort of sense.
Foolish of me.
Your macro rule para-phrased:-
"parenthesize formal parameters in macro definitions, decide whether
to [expand to] an
expression or a statement, [not anything] else, if you [expand to] an
expression [enclose] it in its own set of round parentheses, if you
[expand to] a statement [enclose] the statement list in its own set of
braces"
this rules out expanding to a complete function (I've done this) or
chunk of code. Your rule is more a rule of thumb; that I've seen
violated many times. Sometimes sensibly.
== 3 of 3 ==
Date: Tues, Jan 12 2010 3:51 am
From: Nick Keighley
On 11 Jan, 15:33, Seebs <usenet-nos...@seebs.net> wrote:
> On 2010-01-11, Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
>
> > to be fair spinoza seems to be using the term in a slightly different
> > fashion. he's talking about the textual expansion of the macro. So
>
> > #define INC(X) (X + 1)
>
> > INC(y);
>
> > "returns" (y + 1)
>
> > I was going to say that spinoza's usage, though non-standard, was
> > clear but perhaps it isn't...
>
> If you said it, or Francis said it, I'd probably think that was obviously
> what was meant. Spinny, though, is sufficiently completely incapable of
> getting technical details right (consider that this whole subthread was
> inspired by his assertion that the preprocessor was doing the constant
> folding)
I know, I meant to dig it out but this thread is too long
> that I would not be comfortable guessing as to what he meant...
he also changes what he claims to mean when he realises he's wrong
==============================================================================
TOPIC: On answering homework
http://groups.google.com/group/comp.lang.c/t/fc4c3ccfd56dd962?hl=en
==============================================================================
== 1 of 1 ==
Date: Tues, Jan 12 2010 2:29 am
From: gwowen
On Jan 11, 9:45 pm, superpollo <ute...@esempio.net> wrote:
> curiously, a long forgotten italian writer, beniamino placido, died a
> few days ago. he used to say:
>
> "Conoscenza non e' ricordare le cose,
> ma ricordare in che libro cercarle."
>
> translation:
>
> "knowledge is not to remember things, but to remember the book where to
> look them up."
Clearly a man who knew in which book to look things up. In this case,
if you're after a pithy quotation, try Boswells "Life Of Johnson".
"Knowledge is of two kinds. We know a subject ourselves, or we know
where we can find information upon it." -- Samuel Johnson, quoted in
Boswell's Life Of Johnson. http://www.samueljohnson.com/apocryph.html#12
==============================================================================
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
posted by twitter @ 4:13 AM
0 Comments
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home