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 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-24 16:50 +0000 |
| Message-ID | <slrnitnnn7.2fgi.usenet-nospam@guild.seebs.net> |
| In reply to | #4696 |
On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote:
> It's a cognitive semantic quirk. Return kind-of looks like it is a
> special function that transfers control to the original caller, and so
> I put return values in parenthesis because that's what you do with
> real functions. I know it's not a function, but try to tell that to
> my brain.
That is, in fact, exactly why I *don't* use () on it; because it's the
opposite of a function call.
> I was mostly taking issue with the idea that a derived type is
> qualitatively equivalent to a /de-novo/ basic type, which was the
> implication given in the way some were using the term 'type' in their
> statements -- by my reckoning of their meaning. When the word 'type'
> is used with precision similar to a word like 'run' ("the computer
> runs"), it is difficult to be entirely sure what is really meant.
Heh.
Yeah, I think:
> I was mostly taking issue with the idea that a derived type is
> qualitatively equivalent to a /de-novo/ *basic* type, which was the
(emphasis mine)
is where the gap came in. I wouldn't claim you could define a basic
type, because the set of basic types is listed exhaustively. :)
> Actual printed copies are fairly expensive from what I gather.
> Available from Global Engineering Documents, as per the C-FAQ, section
> 5.2.
The modern one can be gotten for $20ish, as I recall, as a PDF.
-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:10 -0400 |
| Message-ID | <cbf0ad7a57359f4-15019@gmail.com> |
| In reply to | #4714 |
On Tue, May 24, 2011 at 04:50:42PM +0000, Seebs wrote:
> On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote:
> > It's a cognitive semantic quirk. Return kind-of looks like it is a
> > special function that transfers control to the original caller, and so
> > I put return values in parenthesis because that's what you do with
> > real functions. I know it's not a function, but try to tell that to
> > my brain.
>
> That is, in fact, exactly why I *don't* use () on it; because it's the
> opposite of a function call.
As far as bad coding habits go, it's fairly benign.
> > I was mostly taking issue with the idea that a derived type is
> > qualitatively equivalent to a /de-novo/ basic type, which was the
> > implication given in the way some were using the term 'type' in their
> > statements -- by my reckoning of their meaning. When the word 'type'
> > is used with precision similar to a word like 'run' ("the computer
> > runs"), it is difficult to be entirely sure what is really meant.
>
> Heh.
>
> Yeah, I think:
>
> > I was mostly taking issue with the idea that a derived type is
> > qualitatively equivalent to a /de-novo/ *basic* type, which was the
> (emphasis mine)
>
> is where the gap came in. I wouldn't claim you could define a basic
> type, because the set of basic types is listed exhaustively. :)
That's just asking for trouble...
> > Actual printed copies are fairly expensive from what I gather.
> > Available from Global Engineering Documents, as per the C-FAQ, section
> > 5.2.
>
> The modern one can be gotten for $20ish, as I recall, as a PDF.
I wouldn't mind a printed copy, if only for the reason that reading
books on a smallish LCD screen is still difficult.
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 18:19 -0700 |
| Message-ID | <lnsjs3y3tr.fsf@nuthaus.mib.org> |
| In reply to | #4736 |
Uncle Steve <stevet810@gmail.com> writes:
> On Tue, May 24, 2011 at 04:50:42PM +0000, Seebs wrote:
>> On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote:
>> > It's a cognitive semantic quirk. Return kind-of looks like it is a
>> > special function that transfers control to the original caller, and so
>> > I put return values in parenthesis because that's what you do with
>> > real functions. I know it's not a function, but try to tell that to
>> > my brain.
>>
>> That is, in fact, exactly why I *don't* use () on it; because it's the
>> opposite of a function call.
>
> As far as bad coding habits go, it's fairly benign.
As benign coding habits go, it's fairly bad. 8-)}
[...]
>> Yeah, I think:
>>
>> > I was mostly taking issue with the idea that a derived type is
>> > qualitatively equivalent to a /de-novo/ *basic* type, which was the
>> (emphasis mine)
>>
>> is where the gap came in. I wouldn't claim you could define a basic
>> type, because the set of basic types is listed exhaustively. :)
>
> That's just asking for trouble...
I don't know what you mean by that.
>> > Actual printed copies are fairly expensive from what I gather.
>> > Available from Global Engineering Documents, as per the C-FAQ, section
>> > 5.2.
>>
>> The modern one can be gotten for $20ish, as I recall, as a PDF.
>
> I wouldn't mind a printed copy, if only for the reason that reading
> books on a smallish LCD screen is still difficult.
It would probably be cheaper to get a PDF (either the standard for about
$30 or N1256 for free) and print it yourself, than to buy a printed copy
from ISO or ANSI. And then you'd have both the PDF and the paper copy.
Personally, I find the PDF much more useful than a paper copy would be;
I prefer "cut and paste" to be figurative rather than literal.
--
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 | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-24 21:42 -0400 |
| Message-ID | <819d842d7a02c5d-7005a@gmail.com> |
| In reply to | #4738 |
On Tue, May 24, 2011 at 06:19:28PM -0700, Keith Thompson wrote: > Uncle Steve <stevet810@gmail.com> writes: > > On Tue, May 24, 2011 at 04:50:42PM +0000, Seebs wrote: > >> On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: > >> > It's a cognitive semantic quirk. Return kind-of looks like it is a > >> > special function that transfers control to the original caller, and so > >> > I put return values in parenthesis because that's what you do with > >> > real functions. I know it's not a function, but try to tell that to > >> > my brain. > >> > >> That is, in fact, exactly why I *don't* use () on it; because it's the > >> opposite of a function call. > > > > As far as bad coding habits go, it's fairly benign. > > As benign coding habits go, it's fairly bad. 8-)} Should I cry "uncle" at this point? Maybe not, it might confuse people. I'll just add it to the list of pending corrections I have to make to my code. I'll review it all eventually, at least. > [...] > >> Yeah, I think: > >> > >> > I was mostly taking issue with the idea that a derived type is > >> > qualitatively equivalent to a /de-novo/ *basic* type, which was the > >> (emphasis mine) > >> > >> is where the gap came in. I wouldn't claim you could define a basic > >> type, because the set of basic types is listed exhaustively. :) > > > > That's just asking for trouble... > > I don't know what you mean by that. There's apparently something going on between Mr. Seebach and Mr. Miller having to do with prior claims. I don't know the details, but it at least it seems they have a history of taking jabs at each other, which is what the above appeared to be. > >> > Actual printed copies are fairly expensive from what I gather. > >> > Available from Global Engineering Documents, as per the C-FAQ, section > >> > 5.2. > >> > >> The modern one can be gotten for $20ish, as I recall, as a PDF. > > > > I wouldn't mind a printed copy, if only for the reason that reading > > books on a smallish LCD screen is still difficult. > > It would probably be cheaper to get a PDF (either the standard for about > $30 or N1256 for free) and print it yourself, than to buy a printed copy > from ISO or ANSI. And then you'd have both the PDF and the paper copy. > > Personally, I find the PDF much more useful than a paper copy would be; > I prefer "cut and paste" to be figurative rather than literal. I have a thing for bound volumes, except that I can rarely afford to buy the damn things. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2011-05-24 23:47 -0500 |
| Message-ID | <irhu5a$bi1$1@dont-email.me> |
| In reply to | #4740 |
On 5/24/2011 8:42 PM, Uncle Steve wrote:
> On Tue, May 24, 2011 at 06:19:28PM -0700, Keith Thompson wrote:
>> Uncle Steve<stevet810@gmail.com> writes:
>>> On Tue, May 24, 2011 at 04:50:42PM +0000, Seebs wrote:
>>>> On 2011-05-24, Uncle Steve<stevet810@gmail.com> wrote:
>>>>> On Tue, May 24, 2011 at 12:46:29AM -0500, Shao Miller wrote:
>>>>>> On 5/23/2011 11:03 PM, Uncle Steve wrote:
>>>>>>> int function(void) {
>>>>>>> return(42);
>>>>>>> }
>>>>>>>
>>>>>>
>>>>>> Just out of curiosity, do you ever override the 'return' keyword with a
>>>>>> function-like macro? That's one possible reason for wrapping return
>>>>>> values with parentheses and it'd be interesting to get a sense of how
>>>>>> many people have that habit for that intention.
>>>>>
>>>>> It's a cognitive semantic quirk. Return kind-of looks like it is a
>>>>> special function that transfers control to the original caller, and so
>>>>> I put return values in parenthesis because that's what you do with
>>>>> real functions. I know it's not a function, but try to tell that to
>>>>> my brain.
>>>>
>>>> That is, in fact, exactly why I *don't* use () on it; because it's the
>>>> opposite of a function call.
>>>
>>> As far as bad coding habits go, it's fairly benign.
>>
>> As benign coding habits go, it's fairly bad. 8-)}
>
> Should I cry "uncle" at this point? Maybe not, it might confuse
> people. I'll just add it to the list of pending corrections I have to
> make to my code. I'll review it all eventually, at least.
>
Well, it could be considered "ugly" just as the redundant parentheses in
'sizeof (obj)' or 'x = (y * 2) + 1' might be ugly, and I don't ever use
it, but it could be handy for debug-builds... After including standard
headers, you could:
#if DEBUG
# define return(x_) return (returning(__LINE__), (x_))
#endif
Or some other such fun.
>> [...]
>>>> Yeah, I think:
>>>>
>>>>> I was mostly taking issue with the idea that a derived type is
>>>>> qualitatively equivalent to a /de-novo/ *basic* type, which was the
>>>> (emphasis mine)
>>>>
>>>> is where the gap came in. I wouldn't claim you could define a basic
>>>> type, because the set of basic types is listed exhaustively. :)
>>>
>>> That's just asking for trouble...
>>
>> I don't know what you mean by that.
>
> There's apparently something going on between Mr. Seebach and Mr.
> Miller having to do with prior claims. I don't know the details, but
> it at least it seems they have a history of taking jabs at each
> other, which is what the above appeared to be.
>
I sincerely doubt his use of "claim" there has anything to do with the
friendly advice I attempted to offer you earlier. And no, no jabs intended.
But I believe he's mistaken (not lying!) about "listed exhaustively,"
anyway. "Basic types" include[6.2.5p14] "...char, the signed and
unsigned integer types, and the floating types..." "Signed integer
types" include[6.2.5p4] "...standard and extended signed integer
types..." "Extended signed integer types", if any, are
implementation-defined[6.2.5p4], so they're not exhaustively listed in
the Standard, but I'd expect them to be documented with the
implementation. Same with "extended unsigned integer types".
In fact, perhaps it'd still be conforming for an implementation to
include a documented extension which _does_ allow user-defined basic
types. How would you like that? :)
Enjoy.
[toc] | [prev] | [next] | [standalone]
| From | Uncle Steve <stevet810@gmail.com> |
|---|---|
| Date | 2011-05-25 10:13 -0400 |
| Message-ID | <b79eadcf15144cb-3ed6e@gmail.com> |
| In reply to | #4742 |
On Tue, May 24, 2011 at 11:47:49PM -0500, Shao Miller wrote:
> On 5/24/2011 8:42 PM, Uncle Steve wrote:
> >On Tue, May 24, 2011 at 06:19:28PM -0700, Keith Thompson wrote:
> >>Uncle Steve<stevet810@gmail.com> writes:
> >>>On Tue, May 24, 2011 at 04:50:42PM +0000, Seebs wrote:
> >>>>On 2011-05-24, Uncle Steve<stevet810@gmail.com> wrote:
> >>>>>On Tue, May 24, 2011 at 12:46:29AM -0500, Shao Miller wrote:
> >>>>>>On 5/23/2011 11:03 PM, Uncle Steve wrote:
> >>>>>>>int function(void) {
> >>>>>>> return(42);
> >>>>>>>}
> >>>>>>>
> >>>>>>
> >>>>>>Just out of curiosity, do you ever override the 'return' keyword with
> >>>>>>a
> >>>>>>function-like macro? That's one possible reason for wrapping return
> >>>>>>values with parentheses and it'd be interesting to get a sense of how
> >>>>>>many people have that habit for that intention.
> >>>>>
> >>>>>It's a cognitive semantic quirk. Return kind-of looks like it is a
> >>>>>special function that transfers control to the original caller, and so
> >>>>>I put return values in parenthesis because that's what you do with
> >>>>>real functions. I know it's not a function, but try to tell that to
> >>>>>my brain.
> >>>>
> >>>>That is, in fact, exactly why I *don't* use () on it; because it's the
> >>>>opposite of a function call.
> >>>
> >>>As far as bad coding habits go, it's fairly benign.
> >>
> >>As benign coding habits go, it's fairly bad. 8-)}
> >
> >Should I cry "uncle" at this point? Maybe not, it might confuse
> >people. I'll just add it to the list of pending corrections I have to
> >make to my code. I'll review it all eventually, at least.
> >
>
> Well, it could be considered "ugly" just as the redundant parentheses in
> 'sizeof (obj)' or 'x = (y * 2) + 1' might be ugly, and I don't ever use
> it, but it could be handy for debug-builds... After including standard
> headers, you could:
>
> #if DEBUG
> # define return(x_) return (returning(__LINE__), (x_))
> #endif
>
> Or some other such fun.
That would be handy to track down a silent deadlock, such as an
endless loop in a function, or a wait on a system call that somehow
never returns.
> >>[...]
> >>>>Yeah, I think:
> >>>>
> >>>>>I was mostly taking issue with the idea that a derived type is
> >>>>>qualitatively equivalent to a /de-novo/ *basic* type, which was the
> >>>>(emphasis mine)
> >>>>
> >>>>is where the gap came in. I wouldn't claim you could define a basic
> >>>>type, because the set of basic types is listed exhaustively. :)
> >>>
> >>>That's just asking for trouble...
> >>
> >>I don't know what you mean by that.
> >
> >There's apparently something going on between Mr. Seebach and Mr.
> >Miller having to do with prior claims. I don't know the details, but
> >it at least it seems they have a history of taking jabs at each
> >other, which is what the above appeared to be.
>
> I sincerely doubt his use of "claim" there has anything to do with the
> friendly advice I attempted to offer you earlier. And no, no jabs intended.
>
> But I believe he's mistaken (not lying!) about "listed exhaustively,"
> anyway. "Basic types" include[6.2.5p14] "...char, the signed and
> unsigned integer types, and the floating types..." "Signed integer
> types" include[6.2.5p4] "...standard and extended signed integer
> types..." "Extended signed integer types", if any, are
> implementation-defined[6.2.5p4], so they're not exhaustively listed in
> the Standard, but I'd expect them to be documented with the
> implementation. Same with "extended unsigned integer types".
>
> In fact, perhaps it'd still be conforming for an implementation to
o> include a documented extension which _does_ allow user-defined basic
> types. How would you like that? :)
That might be interesting, but I don't know how you'd do it. IIAC,
gcc (obviously) uses a huge number of builtin functions to handle
operations on it's large range of basic types. The compiler would
have to define a way to expose those interfaces to user code, which
sounds like it might require serious layer violations. I hope I've
got the terminology correct there.
But the ability to define arbitrary types would be neat. I previously
asked whether Perl or Python allowed this sort of thing; perhaps I
should expand the question to ask whether there are any languages at
all that make this possible? I can't imagine that it hasn't been
done before, but C is not an obvious fit for that kind of thing.
Dynamic modification of the language itself (which is what we are
talking about here) to add basic capabilities is not something C was
designed to do.
Possibly Ruby -- I'll look in to it if I find the time.
Regards,
Uncle Steve
--
Should a professional politician be charged with molestation if he
kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2011-05-24 22:19 -0600 |
| Message-ID | <1bmxibl8d5.fsf@snowball.wb.pfeifferfamily.net> |
| In reply to | #4736 |
Uncle Steve <stevet810@gmail.com> writes: > On Tue, May 24, 2011 at 04:50:42PM +0000, Seebs wrote: >> On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: >> > It's a cognitive semantic quirk. Return kind-of looks like it is a >> > special function that transfers control to the original caller, and so >> > I put return values in parenthesis because that's what you do with >> > real functions. I know it's not a function, but try to tell that to >> > my brain. >> >> That is, in fact, exactly why I *don't* use () on it; because it's the >> opposite of a function call. > > As far as bad coding habits go, it's fairly benign. It was within the last decade or so that I learned the parens weren't required! Hmmm, I wonder.... looking at Kernighan's original C tutorial (which was what I learned the language from, before K&R was published), I see he used them. Anybody know whether they were actually required back then? -- "It used to be that the USA was pretty good at producing stuff teenaged boys could lose a finger or two playing with." -- James Nicoll
[toc] | [prev] | [next] | [standalone]
| From | Dr Nick <3-nospam@temporary-address.org.uk> |
|---|---|
| Date | 2011-05-25 07:04 +0100 |
| Message-ID | <8739k348ph.fsf@temporary-address.org.uk> |
| In reply to | #4714 |
Seebs <usenet-nospam@seebs.net> writes: > On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: >> It's a cognitive semantic quirk. Return kind-of looks like it is a >> special function that transfers control to the original caller, and so >> I put return values in parenthesis because that's what you do with >> real functions. I know it's not a function, but try to tell that to >> my brain. > > That is, in fact, exactly why I *don't* use () on it; because it's the > opposite of a function call. The "it's not a function call" argument has never really stacked up for me. I know it's not a function call, but neither are 'if' or 'for' and try writing those without them. On the other hand, 'exit' is about as close to return as you can get (from main anyway) and yet does need them. The argument that works for me is "you don't need them, they don't add anything to readability, so why put them in?". I did use them in my early days; I think I picked it up from K&R 1 and picked up not using them from here. -- Online waterways route planner | http://canalplan.eu Plan trips, see photos, check facilities | http://canalplan.org.uk
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-25 08:53 -0700 |
| Message-ID | <lnoc2qydwu.fsf@nuthaus.mib.org> |
| In reply to | #4745 |
Dr Nick <3-nospam@temporary-address.org.uk> writes:
> Seebs <usenet-nospam@seebs.net> writes:
>> On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote:
>>> It's a cognitive semantic quirk. Return kind-of looks like it is a
>>> special function that transfers control to the original caller, and so
>>> I put return values in parenthesis because that's what you do with
>>> real functions. I know it's not a function, but try to tell that to
>>> my brain.
>>
>> That is, in fact, exactly why I *don't* use () on it; because it's the
>> opposite of a function call.
>
> The "it's not a function call" argument has never really stacked up for
> me. I know it's not a function call, but neither are 'if' or 'for' and
> try writing those without them. On the other hand, 'exit' is about as
> close to return as you can get (from main anyway) and yet does need
> them.
Yes, parentheses are heavily overloaded in C.
The "it's not a function call" argument is why I distinguish between
function calls and if/while/for by whitespace:
if (cond) ...
while (cond) ...
func(arg);
In my own style, a function call has the '(' immediately following the
function name; adding a space between 'if' and '(' makes it look less
like a function call. And I've been trying to develop the habit of
writing "sizeof (int)" rather than "sizeof(int)".
Oh, and exit(0) *is* a function call, regardless of how it happens to
behave.
> The argument that works for me is "you don't need them, they don't add
> anything to readability, so why put them in?". I did use them in my
> early days; I think I picked it up from K&R 1 and picked up not using
> them from here.
That works too.
--
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 | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2011-05-25 10:11 -0600 |
| Message-ID | <1bhb8ivjyk.fsf@snowball.wb.pfeifferfamily.net> |
| In reply to | #4760 |
Keith Thompson <kst-u@mib.org> writes:
>
> Yes, parentheses are heavily overloaded in C.
And overused :)
> The "it's not a function call" argument is why I distinguish between
> function calls and if/while/for by whitespace:
>
> if (cond) ...
> while (cond) ...
> func(arg);
>
> In my own style, a function call has the '(' immediately following the
> function name; adding a space between 'if' and '(' makes it look less
> like a function call. And I've been trying to develop the habit of
> writing "sizeof (int)" rather than "sizeof(int)".
I've always followed the same convention, but never really thought about
why I adopted it.
--
"It used to be that the USA was pretty good at producing stuff teenaged
boys could lose a finger or two playing with." -- James Nicoll
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-05-24 09:02 -0700 |
| Message-ID | <lnpqn8ytm2.fsf@nuthaus.mib.org> |
| In reply to | #4671 |
Shao Miller <sha0.miller@gmail.com> writes:
[...]
> * I hope to some day purchase some actual standards. The efforts that
> have gone into them can certainly save me some time == money while
> attempting to write portable C. :)
For almost all purposes, a copy of n1256.pdf is more useful than a
copy of the actual standard. n1256.pdf consists of the C99 standard
with the three Technical Corrigenda merged into it, and marked with
change bars. It's a more accurate depiction of the current state
of the language standard than the C99 standard itself.
For *complete* accuracy, you'd want the C99 standard (costs about
$30, I think) plus the three Technical Corrigenda (available at no
change), but it's difficult to tell where in the C99 standard the
changes have been made; n1256 does that work for you.
--
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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-05-24 07:37 -0400 |
| Message-ID | <irg5a8$vh6$1@dont-email.me> |
| In reply to | #4606 |
On 05/23/2011 05:53 PM, Uncle Steve wrote: > On Tue, May 24, 2011 at 09:25:29AM +1200, Ian Collins wrote: >> On 05/24/11 08:51 AM, Uncle Steve wrote: >>> On Mon, May 23, 2011 at 07:45:24PM +0000, Seebs wrote: >>>> On 2011-05-23, Keith Thompson<kst-u@mib.org> wrote: >>>>> Just a quibble: size_t may be exactly the same type as unsigned long, >>>>> since a typedef merely creates an alias for an existing type, not >>>>> a new and distinct type. plain char and signed char (for example) >>>>> are distinct in a way that size_t and unsigned long (for example) >>>>> are not. >>>> >>>> True. Although, possibly confusingly, there are places where it seems >>>> that the thing a typedef creates is itself then called "a type". The >>>> wording is a bit fuzzy. >>>> >>>> We all know what we mean, I think. You could say it several ways: >>>> >>>> Typedef does not actually create types; instead, it creates >>>> names which refer to existing types. >>>> >>>> Typedef creates types, but those types are identical to existing >>>> types and can be used interchangably with them. >>> >>> How about the idea that typedefs create aliases for the basic built-in >>> types supplied by the language spec.? >> >> A typedef may provide an alias to any existing type, built-in, user >> defined or even incomplete. > > There are no "user defined" types in C. Structures and unions are > aggregates of basic types (and structures/unions). True, structures, unions are aggregates of other types, which in no way contradicts the fact that they are two of the three categories of user-defined types in C (the third category is enumerations). The only requirement for "user-defined types" is that they be user-defined (which is definitely permitted for all three categories), and types (which is true for all three categories). I expect you to disagree, so please clarify the nature of your disagreement: do you think that someone other than the user has defined these types, or do you think that they are not types? > ... I believe > incomplete types are a (usually temporary) artifact of the compilation > process and you won't ever see them in a running program. Types in general are compile-time constructs; but an imcomplete type can reach the end of the compilation process without ever having been completed. ... > Correct me if I'm wrong, but I've never heard of a C compiler that > allows you to define something like a BCD integer type when the > compiler has no built-in support for it. Even if true, that doesn't change the fact that the struct, union, and enumeration types which C does allow you to define are types, and are user-defined. However, nothing in C prevents the declaration of a structure containing the representation of a BCD integer, nor the definition of functions implementing all of the standard operations on such an integer. Without operator overloading, C cannot make such a type behave the same as a built-in type: operator expressions would have to be replaced with function call expressions. However, the explicit function calls needed to implement such a type in C need not be any less efficient than the implicit function calls that could be used to implement it in C++. In both cases, a heavy reliance on inlining would be needed for best results. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-05-23 22:02 +0000 |
| Message-ID | <slrnitlm2t.131i.usenet-nospam@guild.seebs.net> |
| In reply to | #4592 |
On 2011-05-23, Uncle Steve <stevet810@gmail.com> wrote: > How about the idea that typedefs create aliases for the basic built-in > types supplied by the language spec.? Not just those; you can typedef struct types. > A language that protects you from doing dumb things is good, but > flexibility is sacrificed as a consequence. I don't think so. If you allow conversions of pointers, and assert that the "new types" do not participate in the aliasing magic rules (it's not undefined behavior to access an unsigned int through a pointer to size_t if size_t is the same underlying type as unsigned int), I think it would probably be just as flexible a language as it is now, but less error-prone. People who do a lot of 64-bit development would probably find it very helpful. :) -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-23 18:15 -0400 |
| Message-ID | <b4946f705a2a1ad-881ab@gmail.com> |
| In reply to | #4608 |
On Mon, May 23, 2011 at 10:02:04PM +0000, Seebs wrote: > On 2011-05-23, Uncle Steve <stevet810@gmail.com> wrote: > > How about the idea that typedefs create aliases for the basic built-in > > types supplied by the language spec.? > > Not just those; you can typedef struct types. > > > A language that protects you from doing dumb things is good, but > > flexibility is sacrificed as a consequence. > > I don't think so. If you allow conversions of pointers, and assert that > the "new types" do not participate in the aliasing magic rules (it's not > undefined behavior to access an unsigned int through a pointer to size_t > if size_t is the same underlying type as unsigned int), I think it would > probably be just as flexible a language as it is now, but less error-prone. > People who do a lot of 64-bit development would probably find it very > helpful. :) I don't know anything about 64-bit development, I only hope that when I do eventually get around to trying out my code on x86_64 that my type usage is consistent enough to avoid major breakage. To this end I often define integer types by size, and code from there. 'u32' is a convenient representation of a 32-bit unsigned int, and will never change from platform to platform if the platform specific typedefs are written properly in their respective headers. I know I've used 'int' in lots of places, and I don't know if that's really the best thing yet given the variation in sizeof(int) that apparently exists out there. 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-23 22:25 +0000 |
| Message-ID | <slrnitlnoa.14m7.usenet-nospam@guild.seebs.net> |
| In reply to | #4612 |
On 2011-05-23, Uncle Steve <stevet810@gmail.com> wrote: > I don't know anything about 64-bit development, I only hope that when > I do eventually get around to trying out my code on x86_64 that my > type usage is consistent enough to avoid major breakage. The big issue is that a lot of code which assumes that int and long are interchangeable tends to break. > To this end > I often define integer types by size, and code from there. 'u32' is a > convenient representation of a 32-bit unsigned int, and will never > change from platform to platform if the platform specific typedefs > are written properly in their respective headers. I know I've used > 'int' in lots of places, and I don't know if that's really the best > thing yet given the variation in sizeof(int) that apparently exists > out there. In practice, it's a great thing, because you don't actually *care* whether something is the same size on all machines, you just care whether it's working well. I find very little need for int32_t, and very much for int and long. -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-23 19:39 -0400 |
| Message-ID | <848fd4a481072a3-7a4d3@gmail.com> |
| In reply to | #4618 |
On Mon, May 23, 2011 at 10:25:21PM +0000, Seebs wrote: > On 2011-05-23, Uncle Steve <stevet810@gmail.com> wrote: > > I don't know anything about 64-bit development, I only hope that when > > I do eventually get around to trying out my code on x86_64 that my > > type usage is consistent enough to avoid major breakage. > > The big issue is that a lot of code which assumes that int and long are > interchangeable tends to break. I can see that, and if programmers don't check INT_MAX etc. it's their own damn fault when their code breaks. > > To this end > > I often define integer types by size, and code from there. 'u32' is a > > convenient representation of a 32-bit unsigned int, and will never > > change from platform to platform if the platform specific typedefs > > are written properly in their respective headers. I know I've used > > 'int' in lots of places, and I don't know if that's really the best > > thing yet given the variation in sizeof(int) that apparently exists > > out there. > > In practice, it's a great thing, because you don't actually *care* whether > something is the same size on all machines, you just care whether it's > working well. 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. > I find very little need for int32_t, and very much for int and long. That probably speaks to radically different coding styles. 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-23 23:57 +0000 |
| Message-ID | <slrnitlt2f.19ga.usenet-nospam@guild.seebs.net> |
| In reply to | #4629 |
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. -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-23 21:10 -0400 |
| Message-ID | <5e3bc1901a4e1d6-bdea9@gmail.com> |
| In reply to | #4632 |
On Mon, May 23, 2011 at 11:57:11PM +0000, Seebs wrote: > 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. Maybe. > 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 I define a variable as a 32-bit integer, by definition I know what its range of values are. If I try to exceed that range, it is programmer error. If I port my code to a different platform, the typedefs for those types will get made so they are consisted with the x86 port, if possible. I don't see how that can be bad. > If you specify a specific type when a less specific type would do, you hurt > performance on a fair variety of hardware. I think platform specific code will (almost?) always be quicker than generalized code that compiles and runs on multiple architectures unmodified. I think you're going to have to show how your logic works on this point. 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 01:58 +0000 |
| Message-ID | <slrnitm1l4.1hcs.usenet-nospam@guild.seebs.net> |
| In reply to | #4642 |
On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: > On Mon, May 23, 2011 at 11:57:11PM +0000, Seebs wrote: >> 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 I define a variable as a 32-bit integer, by definition I know what > its range of values are. If I try to exceed that range, it is > programmer error. If I port my code to a different platform, > the typedefs for those types will get made so they are consisted with > the x86 port, if possible. I don't see how that can be bad. It can be bad because you might end up on a machine where 32-bit types are intrinsically slower than 64-bit types, so by mandating that ONLY 32 bits be used, you're slowing the program down. > I think platform specific code will (almost?) always be quicker than > generalized code that compiles and runs on multiple architectures > unmodified. Sometimes! > I think you're going to have to show how your logic > works on this point. See above. Imagine that you have something that you know only needs to be 16 bits, so you specify i16 for it. You have an array of them. You're on a machine where access on anything other than 64-bit boundaries adds noticeable latency. Poof! This kind of thing really does happen. There's a reason C gives minimum ranges for the basic types. Machine-specific code which does something that's stupid on a particular machine is not faster than portable code which lets the compiler pick something smart. In general, the vast majority of code does not gain any performance from trying to be more machine-specific, and the cases where it hurts, it hurts BADLY. -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-23 23:56 -0400 |
| Message-ID | <3f20bcd1c8b23d8-db1ae@gmail.com> |
| In reply to | #4649 |
On Tue, May 24, 2011 at 01:58:03AM +0000, Seebs wrote: > On 2011-05-24, Uncle Steve <stevet810@gmail.com> wrote: > > On Mon, May 23, 2011 at 11:57:11PM +0000, Seebs wrote: > >> 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 I define a variable as a 32-bit integer, by definition I know what > > its range of values are. If I try to exceed that range, it is > > programmer error. If I port my code to a different platform, > > the typedefs for those types will get made so they are consisted with > > the x86 port, if possible. I don't see how that can be bad. > > It can be bad because you might end up on a machine where 32-bit types > are intrinsically slower than 64-bit types, so by mandating that ONLY > 32 bits be used, you're slowing the program down. 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 think platform specific code will (almost?) always be quicker than > > generalized code that compiles and runs on multiple architectures > > unmodified. > > Sometimes! > > > I think you're going to have to show how your logic > > works on this point. > > See above. Imagine that you have something that you know only needs to > be 16 bits, so you specify i16 for it. You have an array of them. You're > on a machine where access on anything other than 64-bit boundaries adds > noticeable latency. Poof! 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. > This kind of thing really does happen. There's a reason C gives minimum > ranges for the basic types. I suppose it does, but I am not going to assume something for which there is no supporting evidence, in relation to this particular topic. > Machine-specific code which does something that's stupid on a particular > machine is not faster than portable code which lets the compiler pick > something smart. > In general, the vast majority of code does not gain any performance from > trying to be more machine-specific, and the cases where it hurts, it hurts > BADLY. 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. Regards, Uncle Steve -- Should a professional politician be charged with molestation if he kisses babies while attending political rallies?
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web