Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Uncle Steve Newsgroups: comp.lang.c Subject: Re: Types in C Date: Wed, 25 May 2011 10:13:56 -0400 Organization: Friends of the Galactic Collective Lines: 115 Message-ID: References: <46bfca6e0cc73cf-bd09a@gmail.com> <819d842d7a02c5d-7005a@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: mx04.eternal-september.org; posting-host="HoLaDevQz+VWJX9t0+Um9g"; logging-data="15913"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/t6RVMtyHRBRq64w3Fw7s5" User-Agent: nn 6.7.3 Content-Length: 4804 Cancel-Lock: sha1:UAp8T9cEUoFhfO40l9UCetZXPjU= Xref: x330-a1.tempe.blueboxinc.net comp.lang.c:4753 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 writes: > >>>On Tue, May 24, 2011 at 04:50:42PM +0000, Seebs wrote: > >>>>On 2011-05-24, Uncle Steve 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?