Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #4520 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2011-05-22 21:29 +0200 |
| Last post | 2011-06-02 15:26 -0700 |
| Articles | 20 on this page of 123 — 20 participants |
Back to article view | Back to comp.lang.c
Types in C jacob navia <jacob@spamsink.net> - 2011-05-22 21:29 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-22 12:48 -0700
Re: Types in C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-05-22 23:03 +0100
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 10:35 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 08:40 -0700
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 17:19 +0000
Re: Types in C John Gordon <gordon@panix.com> - 2011-05-23 17:54 +0000
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 11:33 -0700
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 11:44 -0700
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 19:08 +0000
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 20:50 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 12:11 -0700
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 19:45 +0000
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 13:03 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 22:25 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 14:38 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 23:45 +0200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:02 +0000
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 00:10 +0200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 22:12 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-23 13:27 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 22:33 +0200
Re: Types in C Martin Ambuhl <mambuhl@earthlink.net> - 2011-05-24 03:17 -0400
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 10:55 +0200
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:29 +1200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 23:42 +0200
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:51 +1200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 00:04 +0200
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:57 +1200
Re: Types in C David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 19:33 -0500
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 08:27 -0700
Re: Types in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 00:40 -0700
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-31 11:32 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-31 11:30 -0700
Re: Types in C Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-01 01:23 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 16:51 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 09:25 +1200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-23 23:40 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 08:36 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 17:53 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:24 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:23 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:57 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:22 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 03:46 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 00:24 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 04:44 +0000
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 07:46 -0400
Re: Types in C James Kuyper <jameskuyper@verizon.net> - 2011-05-24 07:48 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:35 +1200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:38 +0000
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 10:53 +1200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:17 +0000
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 11:24 +1200
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:39 +0000
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-24 11:23 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 08:46 -0700
Re: Types in C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-05-24 09:14 -0700
Re: Types in C Michael Press <rubrum@pacbell.net> - 2011-05-28 21:50 -0700
Re: Types in C "io_x" <a@b.c.invalid> - 2011-06-07 19:50 +0200
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:33 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 12:03 +1200
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:27 -0400
Re: Types in C Ian Collins <ian-news@hotmail.com> - 2011-05-24 13:47 +1200
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 23:45 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 00:07 -0700
Re: Types in C James Kuyper <jameskuyper@verizon.net> - 2011-05-24 08:05 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 19:54 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:03 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 22:12 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 00:03 -0400
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 00:19 -0400
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 00:20 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-24 00:46 -0500
Re: Types in C pete <pfiland@mindspring.com> - 2011-05-24 07:36 -0400
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 10:58 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 09:40 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:36 -0400
Re: Types in C David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 16:50 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:10 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 18:19 -0700
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:42 -0400
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-24 23:47 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-25 10:13 -0400
Re: Types in C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-24 22:19 -0600
Re: Types in C Dr Nick <3-nospam@temporary-address.org.uk> - 2011-05-25 07:04 +0100
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-25 08:53 -0700
Re: Types in C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-25 10:11 -0600
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 09:02 -0700
Re: Types in C James Kuyper <jameskuyper@verizon.net> - 2011-05-24 07:37 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:02 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 18:15 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 22:25 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 19:39 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-23 23:57 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 21:10 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 01:58 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-23 23:56 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 04:32 +0000
Re: Types in C "BartC" <bc@freeuk.com> - 2011-05-25 01:29 +0100
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 22:20 -0500
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-23 22:42 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 00:07 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 04:44 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 10:24 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-24 16:50 +0000
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 21:16 -0400
Re: Types in C Seebs <usenet-nospam@seebs.net> - 2011-05-25 03:36 +0000
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-24 01:26 -0500
Re: Types in C Uncle Steve <stevet810@gmail.com> - 2011-05-24 11:04 -0400
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-24 09:06 -0700
Re: Types in C David Thompson <dave.thompson2@verizon.net> - 2011-06-01 16:33 -0400
Re: Types in C Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-05-30 22:42 +0200
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-30 17:45 -0500
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-05-31 08:47 -0700
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-31 13:54 -0400
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-05-31 00:16 +0200
Re: Types in C Shao Miller <sha0.miller@gmail.com> - 2011-05-30 18:30 -0500
Re: Types in C Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-06-02 22:44 +0200
Re: Types in C jacob navia <jacob@spamsink.net> - 2011-06-02 22:49 +0200
Re: Types in C Keith Thompson <kst-u@mib.org> - 2011-06-02 15:26 -0700
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-24 04:32 +0000 |
| Message-ID | <slrnitmcfj.1niq.usenet-nospam@guild.seebs.net> |
| In reply to | #4662 |
On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: > I suppose it's possible, but that seems a bit like putting the cart > before the horse. If I say "do not blaspheme" because it might > piss-off God, I am presupposing the existence of God, which could very > well be false. You are presupposing that a hardware manufacturer is > going to build a CPU with those characteristics. How likely is that? I've used several. There have been MANY systems where larger types were faster than smaller types. It's common. Idle question: Have you ever used an Intel processor? Like, an x86? I wrote a little routine which does a trivial tight loop on objects. chars: 4.084635 secs. shorts: 4.161859 secs. ints: 2.729034 secs. longs: 3.284039 secs. quads: 3.134092 secs. So, if you "knew" that you needed a 16-bit type, and used short, you'd be taking a 50% performance hit for picking an inefficient type. If all you need is "can store values up to 30000", that would be silly. Heck, you'd get better performance on *64-bit* objects than you would on 16-bit shorts. Use specific types when you are solving a problem which needs them. Otherwise, favor "int", it's usually fast. > Well now. I think I said (or implied) that I was attempting to avoid > constructs that break when assumptions about type sizes are wrong. > You seem to be saying that program correctness is subordinate to > performance in this instance. I beg to differ. No. I'm saying that you should never pick an exact type size when an "at least N" will do. To put it in terms of the C99 spec, the following types exist: int_least32_t int32_t The former type MUST exist and will have at least 32 bits. It may have more than 32 bits, if that's more convenient and expressive. The latter type MAY exist, and if it does will have exactly 32 bits. It may be painfully slow, though. What I'm saying is I don't think I've yet written a program where I would have used int32_t instead of int_least32_t. > Exploding software hurts too. At any rate, I'm not being > machine-specific, I am attempting to be type-specific within an > arbitrary algorithm across multiple platforms. Those are two > very different approaches. I don't think type-specific buys you anything. You know the required range. Pick a type guaranteed to be large enough, but don't demand an exact number of bits. -s -- Copyright 2011, 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! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2011-05-25 01:29 +0100 |
| Message-ID | <irhijf$ibt$1@dont-email.me> |
| In reply to | #4668 |
"Seebs" <usenet-nospam@seebs.net> wrote in message news:slrnitmcfj.1niq.usenet-nospam@guild.seebs.net... > On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: >> I suppose it's possible, but that seems a bit like putting the cart >> before the horse. If I say "do not blaspheme" because it might >> piss-off God, I am presupposing the existence of God, which could very >> well be false. You are presupposing that a hardware manufacturer is >> going to build a CPU with those characteristics. How likely is that? > > I've used several. There have been MANY systems where larger types were > faster than smaller types. It's common. > > Idle question: Have you ever used an Intel processor? Like, an x86? > > I wrote a little routine which does a trivial tight loop on objects. > > chars: 4.084635 secs. > shorts: 4.161859 secs. > ints: 2.729034 secs. > longs: 3.284039 secs. > quads: 3.134092 secs. > > So, if you "knew" that you needed a 16-bit type, and used short, you'd > be taking a 50% performance hit for picking an inefficient type. If all > you need is "can store values up to 30000", that would be silly. Heck, I've just written a routine where using short is 10% faster than int, because it allocates a large number of them and therefore uses half the memory (and half the bandwidth). Not much difference, but in other cases using a wider type than is necessary can cause more severe problems ... > you'd get better performance on *64-bit* objects than you would on > 16-bit shorts. ... such as running out of memory completely. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-23 22:20 -0500 |
| Message-ID | <irf4l8$q0p$1@dont-email.me> |
| In reply to | #4642 |
On 5/23/2011 8:10 PM, Uncle Steve wrote: > I think you're going to have to show how your logic > works on this point. Just intended as some kind words of advice as you appear to be frequenting this newsgroup these days: Whatever you do, please avoid use of the word "claims" with the poster who you replied to with the above. You haven't made this "mistake," so far. :)
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-23 22:42 -0500 |
| Message-ID | <irf5v3$vci$1@dont-email.me> |
| In reply to | #4652 |
On 5/23/2011 10:20 PM, Shao Miller wrote: > On 5/23/2011 8:10 PM, Uncle Steve wrote: >> I think you're going to have to show how your logic >> works on this point. > > Just intended as some kind words of advice as you appear to be > frequenting this newsgroup these days: Whatever you do, please avoid use > of the word "claims" with the poster who you replied to with the above. > You haven't made this "mistake," so far. :) Oh, and please don't quote this. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-24 00:07 -0400 |
| Message-ID | <f802314c0062acb-dc847@gmail.com> |
| In reply to | #4652 |
On Mon, May 23, 2011 at 10:20:17PM -0500, Shao Miller wrote: > On 5/23/2011 8:10 PM, Uncle Steve wrote: > >I think you're going to have to show how your logic > >works on this point. > > Just intended as some kind words of advice as you appear to be > frequenting this newsgroup these days: Whatever you do, please avoid use > of the word "claims" with the poster who you replied to with the above. > You haven't made this "mistake," so far. :) What, is 'claim' some sort of trigger word that makes your skin turn green and drives you to throw stray automobiles all over the place? Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-24 04:44 +0000 |
| Message-ID | <slrnitmdgs.1oni.usenet-nospam@guild.seebs.net> |
| In reply to | #4666 |
On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: > What, is 'claim' some sort of trigger word that makes your skin turn > green and drives you to throw stray automobiles all over the place? In many cases, the word "claim" is used to indicate that you do not accept a statement. For instance, if you said "I'm a pretty smart guy" and I said "Uncle Steve claims to be a pretty smart guy", there is an implication that I disbelieve it. (Note: Purely an example; I do not disbelieve that claim.) At one point, Shao made some remark to me which used the word "claim" in that way and I pointed out that this was, IMHO, rude. (I plonked him quite a while back for being, so far as I could tell, not interested in sincere discussions of technical issues. Nothing I've seen quoted since has changed my mind.) So he's probably pointing out that you challenged something I said, and that I have a history of being touchy about things. The distinction being, I don't expect people to take my word on technical claims, just on claims about who I am or what I do. :) Technical claims are by nature subject to dispute or argumentation. -s -- Copyright 2011, 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! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-24 10:24 -0400 |
| Message-ID | <3623466319a1ab1-b7914@gmail.com> |
| In reply to | #4669 |
On Tue, May 24, 2011 at 04:44:16AM +0000, Seebs wrote: > On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: > > What, is 'claim' some sort of trigger word that makes your skin turn > > green and drives you to throw stray automobiles all over the place? > > In many cases, the word "claim" is used to indicate that you do not accept > a statement. For instance, if you said "I'm a pretty smart guy" and I said > "Uncle Steve claims to be a pretty smart guy", there is an implication that > I disbelieve it. (Note: Purely an example; I do not disbelieve that claim.) Language lawyering... Hmm. Dictionary.com does not seem to contain a definition that supports your imputation of the pejorative. 2.) Assert that one has gained or achieved (something) If someone claims something it does not require that they use the word 'claim' in order to make the assertion. If you say that I claim something, that does not perforce disbelief. You are merely stating that I made a claim of some sort, and without further qualification we cannot know whether you accept it or not. It is in fact a mundane statement of fact (that there is a claim). > At one point, Shao made some remark to me which used the word "claim" in > that way and I pointed out that this was, IMHO, rude. (I plonked him > quite a while back for being, so far as I could tell, not interested > in sincere discussions of technical issues. Nothing I've seen quoted since > has changed my mind.) It's so hard to tell, though. More than half of of the Usenet population seems to be concerned primarily with argumentation for the sake of argumentation, and the nominal topic du jour is merely an excuse to engage in the activity. But as many of them are clever enough to affect sincerity it is not always obvious who the defective trolls really are. > So he's probably pointing out that you challenged something I said, and > that I have a history of being touchy about things. The distinction being, > I don't expect people to take my word on technical claims, just on claims > about who I am or what I do. :) Technical claims are by nature subject > to dispute or argumentation. Ha, well on Usenet nothing can be taken for granted. What say you do and who you say you are is always subject to verification. "Trust, but verify' is the necessary heuristic when there are so many rabid FUD-spinners on the 'net. Not all of them present as loons either. Many of them have mastered the art of faking normality for short stretches at a time, and so Eternal Vigilance is the necessary rule. As I'm new here I'll reserve my opinions on individual posters for the time being. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-24 16:50 +0000 |
| Message-ID | <slrnitno0f.2fgi.usenet-nospam@guild.seebs.net> |
| In reply to | #4695 |
On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: > Language lawyering... Hmm. Dictionary.com does not seem to contain a > definition that supports your imputation of the pejorative. Huh? It's got nothing to do with the definitions; it's to do with Gricean maxims. Language is used to communicate. If people say something, they thought it was adding information. If instead of saying: Uncle Steve is a millionaire I say Uncle Steve claims he is a millionaire I have added words; the added words are logically presumed to add information. > Ha, well on Usenet nothing can be taken for granted. What say you do > and who you say you are is always subject to verification. I think the difference is... If I make a technical claim, and you think I'm wrong, it's perfectly possible that I'm wrong but not lying. If I make a claim about my qualifications or experience, and you think I'm wrong, it's not in general possible that I'm wrong but not lying. So one of them is an accusation of lying, while one of them is an accusation of error-or-lying. It admits a charitable interpretation. And I don't know any competent computer people who are offended by the allegation that they could be mistaken. We make mistakes. There is a reason that there is a category of software tools called "debuggers". -s -- Copyright 2011, 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! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-24 21:16 -0400 |
| Message-ID | <ae3d4bae7c0e123-47b76@gmail.com> |
| In reply to | #4715 |
On Tue, May 24, 2011 at 04:50:43PM +0000, Seebs wrote: > On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: > > Language lawyering... Hmm. Dictionary.com does not seem to contain a > > definition that supports your imputation of the pejorative. > > Huh? > > It's got nothing to do with the definitions; it's to do with Gricean maxims. > > Language is used to communicate. If people say something, they thought it > was adding information. > > If instead of saying: > Uncle Steve is a millionaire > I say > Uncle Steve claims he is a millionaire > I have added words; the added words are logically presumed to add > information. So long as you aren't being redundant, and there's no shortage of redundant English from poor writers. But I like the suggestion anyways. Don't forget about the mansion and yacht. > > Ha, well on Usenet nothing can be taken for granted. What say you do > > and who you say you are is always subject to verification. > > I think the difference is... > > If I make a technical claim, and you think I'm wrong, it's perfectly > possible that I'm wrong but not lying. > > If I make a claim about my qualifications or experience, and you think > I'm wrong, it's not in general possible that I'm wrong but not lying. > > So one of them is an accusation of lying, while one of them is an accusation > of error-or-lying. It admits a charitable interpretation. And I don't > know any competent computer people who are offended by the allegation that > they could be mistaken. We make mistakes. There is a reason that there > is a category of software tools called "debuggers". Opinions are divided on the subject of debuggers. I believe Linus is said to have opposed an in-kernel debugger for the reason that its availability would lead to lazy programming practices. I don't know whether the anecdote is true, but it is an interesting thought. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-25 03:36 +0000 |
| Message-ID | <slrnitosfv.emn.usenet-nospam@guild.seebs.net> |
| In reply to | #4737 |
On 2011-05-25, Uncle Steve <stevet810@gmail.com> wrote: > So long as you aren't being redundant, and there's no shortage of > redundant English from poor writers. But I like the suggestion > anyways. Don't forget about the mansion and yacht. :) > Opinions are divided on the subject of debuggers. Sure. But the fact that they're there to have opinions about testifies that bugs are a reality. -s -- Copyright 2011, 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! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-24 01:26 -0500 |
| Message-ID | <irffig$btl$1@dont-email.me> |
| In reply to | #4666 |
On 5/23/2011 11:07 PM, Uncle Steve wrote: > What, is 'claim' some sort of trigger word that makes your skin turn > green and drives you to throw stray automobiles all over the place? No. It's really too bad that I didn't have the request not to quote that in the very same post, as it seems you didn't read it in time not to quote the post. Thus it has already begun to back-fire. Hopefully that's the end of it. I was merely offering some advice which was intended to be friendly, as your prolonged argument/discussion with a particular poster triggered a memory. Even worse than "claim" is "invent". Obviously you are free to use or discard any advice. :) Have a nice day.
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-24 11:04 -0400 |
| Message-ID | <191501fc25c5909-fd31e@gmail.com> |
| In reply to | #4673 |
On Tue, May 24, 2011 at 01:26:28AM -0500, Shao Miller wrote: > On 5/23/2011 11:07 PM, Uncle Steve wrote: > >What, is 'claim' some sort of trigger word that makes your skin turn > >green and drives you to throw stray automobiles all over the place? > > No. It's really too bad that I didn't have the request not to quote > that in the very same post, as it seems you didn't read it in time not > to quote the post. Thus it has already begun to back-fire. Hopefully > that's the end of it. > > I was merely offering some advice which was intended to be friendly, as > your prolonged argument/discussion with a particular poster triggered a > memory. Possibly it would be better to use email in such cases, but that is a minor quibble. > Even worse than "claim" is "invent". Obviously you are free to use or > discard any advice. :) True enough. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-24 09:06 -0700 |
| Message-ID | <lnlixwytfa.fsf@nuthaus.mib.org> |
| In reply to | #4632 |
Seebs <usenet-nospam@seebs.net> writes:
> On 2011-05-23, Uncle Steve <stevet810@gmail.com> wrote:
>> Um, no. I care about the "size" of a type so I don't misuse it in the
>> program. If a counter rolls over because I assumed an int was 32 bits
>> wide, that's a problem. If I use an int type of known size, I'll be
>> much less likely to run into that problem.
>
> You're doing it wrong.
>
> Don't know the size. Know the *minimum* size. You don't actually need
> to know whether something is 32 bits, you just need to know that it's at
> least big enough to hold some particular value. For all you know you're
> getting a 64-bit type because that's what's fast on this hardware.
>
> If you specify a specific type when a less specific type would do, you hurt
> performance on a fair variety of hardware.
Which is why int_least32_t and int_fast32_t exist.
--
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"
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2011-06-01 16:33 -0400 |
| Message-ID | <np7du6psmhi53jlvij7aab9ucije6na5nv@4ax.com> |
| In reply to | #4574 |
From jacob_navia reply to Seebs (sorry, I lost the exact attribution):
> \subsection{What is a type?}
> A first tentative, definition for what a type is, could be “a type is a
> definition of an algorithm for understanding a sequence of storage
> bits”. It gives the meaning of the data stored in memory. If we say
> that the object a is an int, it means that the bits stored at that
> location are to be understood as a natural number that is built by
> consecutive additions of powers of two as specified by its bits.
First, a nit: 'definition of an algorithm' is redundant; 'algorithm'
is sufficient. For a tutorial reader, I think it would be enough to
just say 'rule' or 'set of rules'. (To a formalist or mathematician,
'algorithm' must be effectively computable where 'rules' might not be,
but the rules here are so simple this distinction is uninteresting.)
Second, more significant, to someone who knows what 'natural number'
means this is very misleading. Naturals exclude negative, while C int
includes them. To *some* mathematicians, naturals also exclude zero;
if zero is included, naturals are a reasonable mathemetical analog to
C _unsigned_ integer types. And unsigned-int might be a better
tutorial example, because you don't have to explain the asymmetric
behavior of two's-complement, much less the different behavior of
ones'-complement and sign&magnitude.
Third, a nit: the additions here are mathematical ones and behave
properly, so order doesn't matter and 'consecutive' adds nothing.
> If we say that the type of a is a double, it means that the bits are to
> be understood as the IEEE 754 (for instance) standard sequences of bits
> representing a double precision floating point value.
>
Yes. And some-integer versus some-floating is the easiest example to
explain for C. In some other languages, characters are a completely
different type than integers, and in some so are enumerations. But in
C these are just variants or as you say 'refinements' of integers, so
using them to explain types would be more difficult and less clear.
In addition to definining the values of representations (and the
representations of values), types also define the _operations_ on
those values. In particular, addition and multiplication of unsigned
int are (and must be) quite different from those for double. Addition
of pointer and integer is somewhat different, but less dramatically.
> A second, more refined definition would encompass the first but add the
> notion of "concept" behind a type. For instance in some machines
> the type "size_t" has exactly the same bits as an unsigned long, yet,
> it is a different type. The difference is that we store sizes in
> size_t objects, and not some arbitrary integer. The type is associated
> with the concept of size. We use types to convey a concept to the
> reader of the program.
>
The sizes of objects, or in simple terms of memory areas. And often
also offsets or subscripts within those obects, although you may not
want to go into that here. But not the sizes of, for examples, a box
to be shipped by post, or a floor to be covered with tiles.
I sometimes talk about this as 'purpose' rather than 'concept'.
I think that's slightly more specific, although not much.
> The base of C's type hierarchy are the machine types, i.e. the types
> that the integrated circuit understands. C has abstracted from the
> myriad of machine types some types like 'int' or 'double' that are
> almost universally present in all processors.
>
> There are many machine types that C doesn't natively support, for
> instance some processors support BCD coded data but that data is
> accessible only through special libraries in C.
>
I'm not sure about 'many', at least in comparison to those supported,
but certainly some. BCD is a good example. Actually it needs either
library(ies) or extension(s) -- I've used one compiler that did a
core-language extension. But either way it's not standard C.
<snip rest>
[toc] | [prev] | [next] | [standalone]
| From | Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> |
|---|---|
| Date | 2011-05-30 22:42 +0200 |
| Message-ID | <is0vfg$vqg$1@dont-email.me> |
| In reply to | #4520 |
jacob navia wrote:
>[...]
> A C type can be either a function type, an incomplete type or an object
> type.
Recently the Committee agreed with Clive Feather that completeness is a
scoped property of object types (there are no incomplete function types,
after all), and the latest C1X draft says the following under 6.2.5
("Types"):
# Types are partitioned into object types (types that describe objects)
# and function types (types that describe functions). At various points
# within a translation unit an object type may be incomplete (lacking
# sufficient information to determine the size of objects of that type)
# or complete (having sufficient information).
I, too, believe it is a clearer way of describing how the C type system
works. (For Clive's rationale, see the WG14 document N1439).
--
Marcin Grzegorczyk
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-30 17:45 -0500 |
| Message-ID | <is136f$pdt$1@dont-email.me> |
| In reply to | #5053 |
On 5/30/2011 3:42 PM, Marcin Grzegorczyk wrote:
> jacob navia wrote:
>> [...]
>> A C type can be either a function type, an incomplete type or an object
>> type.
>
> Recently the Committee agreed with Clive Feather that completeness is a
> scoped property of object types (there are no incomplete function types,
> after all), and the latest C1X draft says the following under 6.2.5
> ("Types"):
>
> # Types are partitioned into object types (types that describe objects)
> # and function types (types that describe functions). At various points
> # within a translation unit an object type may be incomplete (lacking
> # sufficient information to determine the size of objects of that type)
> # or complete (having sufficient information).
>
> I, too, believe it is a clearer way of describing how the C type system
> works. (For Clive's rationale, see the WG14 document N1439).
Though I think the obsolescence under the N1494's 6.11.6p1 is
intuitively akin to an "incomplete function type," though such a term is
not defined in a standard sense, perhaps.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-31 08:47 -0700 |
| Message-ID | <ln62oqrhwf.fsf@nuthaus.mib.org> |
| In reply to | #5055 |
Shao Miller <sha0.miller@gmail.com> writes:
> On 5/30/2011 3:42 PM, Marcin Grzegorczyk wrote:
>> jacob navia wrote:
>>> [...]
>>> A C type can be either a function type, an incomplete type or an object
>>> type.
>>
>> Recently the Committee agreed with Clive Feather that completeness is a
>> scoped property of object types (there are no incomplete function types,
>> after all), and the latest C1X draft says the following under 6.2.5
>> ("Types"):
>>
>> # Types are partitioned into object types (types that describe objects)
>> # and function types (types that describe functions). At various points
>> # within a translation unit an object type may be incomplete (lacking
>> # sufficient information to determine the size of objects of that type)
>> # or complete (having sufficient information).
>>
>> I, too, believe it is a clearer way of describing how the C type system
>> works. (For Clive's rationale, see the WG14 document N1439).
>
> Though I think the obsolescence under the N1494's 6.11.6p1 is
> intuitively akin to an "incomplete function type," though such a term is
> not defined in a standard sense, perhaps.
For those who don't have a copy of N1494:
6.11.6 Function declarators
The use of function declarators with empty parentheses (not
prototype-format parameter type declarators) is an obsolescent
feature.
I don't see much resemblance between that and incomplete type.
The obsolecence itself is irrelevant; until they're removed from
the language (and when is the committee finally going to get around
to that?), they're a required language feature.
A function type declared without a prototype is fully usable; you can
declare a pointer to it and use such a pointer in a function call.
I suppose it's "incomplete" in the sense that some information is
missing, but it's not the same kind of incompleteness that applies
to void.
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-31 13:54 -0400 |
| Message-ID | <is3a1l$a1p$1@dont-email.me> |
| In reply to | #5115 |
On 5/31/2011 11:47, Keith Thompson wrote:
> Shao Miller<sha0.miller@gmail.com> writes:
>> On 5/30/2011 3:42 PM, Marcin Grzegorczyk wrote:
>>> jacob navia wrote:
>>>> [...]
>>>> A C type can be either a function type, an incomplete type or an object
>>>> type.
>>>
>>> Recently the Committee agreed with Clive Feather that completeness is a
>>> scoped property of object types (there are no incomplete function types,
>>> after all), and the latest C1X draft says the following under 6.2.5
>>> ("Types"):
>>>
>>> # Types are partitioned into object types (types that describe objects)
>>> # and function types (types that describe functions). At various points
>>> # within a translation unit an object type may be incomplete (lacking
>>> # sufficient information to determine the size of objects of that type)
>>> # or complete (having sufficient information).
>>>
>>> I, too, believe it is a clearer way of describing how the C type system
>>> works. (For Clive's rationale, see the WG14 document N1439).
>>
>> Though I think the obsolescence under the N1494's 6.11.6p1 is
>> intuitively akin to an "incomplete function type," though such a term is
>> not defined in a standard sense, perhaps.
>
> For those who don't have a copy of N1494:
>
> 6.11.6 Function declarators
>
> The use of function declarators with empty parentheses (not
> prototype-format parameter type declarators) is an obsolescent
> feature.
>
In the future, I ought to include the point, given similar brevity. Thanks.
> I don't see much resemblance between that and incomplete type.
> The obsolecence itself is irrelevant; until they're removed from
> the language (and when is the committee finally going to get around
> to that?), they're a required language feature.
Heheh.
>
> A function type declared without a prototype is fully usable; you can
> declare a pointer to it and use such a pointer in a function call.
> I suppose it's "incomplete" in the sense that some information is
> missing, but it's not the same kind of incompleteness that applies
> to void.
>
I was thinking of precisely the likeness you point out. To further
illustrate:
#define NO_WAY 0
/*** Types */
/* Incomplete */
struct s_foo;
/* Completed */
struct s_foo {
int x;
};
/* Illegal */
#if NO_WAY
struct s_foo {
int x;
double y;
};
#endif
/* Incomplete, cannot be completed */
typedef int a_bar[];
/* Complete, compatible with a_bar */
typedef int a_bar2[10];
/* Different size specifier (element count) */
typedef int a_bar3[20];
/* "Incomplete", cannot be "completed" */
typedef void f_baz();
/* "Complete" and compatible with f_baz */
typedef void f_baz2(int);
/* Different parameter specification */
typedef void f_baz3(double);
/*** Objects */
/* "Partial" */
a_bar obj_bar;
/* "Complete" */
a_bar2 obj_bar;
/* Illegal */
#if NO_WAY
a_bar3 obj_bar;
#endif
/*** Functions */
/* "Partial" */
f_baz func_baz;
/* "Complete" */
f_baz2 func_baz;
/* Illegal */
#if NO_WAY
f_baz3 func_baz;
#endif
int main(void) {
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2011-05-31 00:16 +0200 |
| Message-ID | <is14v9$f62$1@speranza.aioe.org> |
| In reply to | #5053 |
Le 30/05/11 22:42, Marcin Grzegorczyk a écrit :
> jacob navia wrote:
>> [...]
>> A C type can be either a function type, an incomplete type or an object
>> type.
>
> Recently the Committee agreed with Clive Feather that completeness is a
> scoped property of object types (there are no incomplete function types,
> after all), and the latest C1X draft says the following under 6.2.5
> ("Types"):
>
> # Types are partitioned into object types (types that describe objects)
> # and function types (types that describe functions). At various points
> # within a translation unit an object type may be incomplete (lacking
> # sufficient information to determine the size of objects of that type)
> # or complete (having sufficient information).
>
> I, too, believe it is a clearer way of describing how the C type system
> works. (For Clive's rationale, see the WG14 document N1439).
After reading N1439 I would tend to agree with what it says but
where should go the void type?
It is void an object type?
What was easy to understand in the original classification is that void
had a natural neighborhood: incomplete types.
I deduce (indirectly) that Mr Cleaver thinks void is an object type
because he says:
6.3.2.1#1
Change “an object or incomplete type other than void” to “an object
type other than void”.
If "an object type other than void" is accepted it would mean that
void is an object type.
The problem is that N1429 is difficult to read because it only
refers to what should be patched and doesn't display the patched
text.
In any case thanks a lot for taking the time to answer.
jacob
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-30 18:30 -0500 |
| Message-ID | <is15pu$ahd$1@dont-email.me> |
| In reply to | #5058 |
On 5/30/2011 5:16 PM, jacob navia wrote:
> Le 30/05/11 22:42, Marcin Grzegorczyk a écrit :
>> jacob navia wrote:
>>> [...]
>>> A C type can be either a function type, an incomplete type or an object
>>> type.
>>
>> Recently the Committee agreed with Clive Feather that completeness is a
>> scoped property of object types (there are no incomplete function types,
>> after all), and the latest C1X draft says the following under 6.2.5
>> ("Types"):
>>
>> # Types are partitioned into object types (types that describe objects)
>> # and function types (types that describe functions). At various points
>> # within a translation unit an object type may be incomplete (lacking
>> # sufficient information to determine the size of objects of that type)
>> # or complete (having sufficient information).
>>
>> I, too, believe it is a clearer way of describing how the C type system
>> works. (For Clive's rationale, see the WG14 document N1439).
>
> After reading N1439 I would tend to agree with what it says but
> where should go the void type?
>
> It is void an object type?
>
Yes. But it can never be completed.
> What was easy to understand in the original classification is that void
> had a natural neighborhood: incomplete types.
>
> I deduce (indirectly) that Mr Cleaver
(Nit-pick: Mr. Clive Feather.)
> thinks void is an object type
> because he says:
>
> 6.3.2.1#1
> Change “an object or incomplete type other than void” to “an object
> type other than void”.
>
> If "an object type other than void" is accepted it would mean that
> void is an object type.
>
Agreed.
> The problem is that N1429 is difficult to read because it only
> refers to what should be patched and doesn't display the patched
> text.
>
> In any case thanks a lot for taking the time to answer.
In the N1494 draft, we have 6.2.5p19:
"The void type comprises an empty set of values; it is an incomplete
object type that cannot be completed."
Similarly:
typedef char a_incomplete[];
could never be completed, if I'm not mistaken.
[toc] | [prev] | [next] | [standalone]
Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web