* Re: Hungarian notation [not found] ` <4cd8fc$oud@news.manawatu.gen.nz> @ 1996-01-08 0:00 ` Joachim Durchholz 0 siblings, 0 replies; 13+ messages in thread From: Joachim Durchholz @ 1996-01-08 0:00 UTC (permalink / raw) Mike.Palmer@tus.ssi1.com wrote 06.01.96 on Re: Hungarian notation: > Joachim Durchholz wrote: > > > > > Consider also that variable names may be misleading anyway. In that > > > sense there's no great difference between > > > > > > someProc(MyString) > > > > > > and > > > > > > someProc(pszMyString) > > > > > > either could quite happily refer to any other data type. > > > > > > > This example does not occur in real life. Or rather, it better should not! > > Anybody using meaningless names like "MyString" should be thrown out of > > the programming business. Depending on the actual semantics of "someProc", > > the parameter should be called "Message" or "Options" or "ParserInput" or > > whatever. > > > > -Joachim > > One hopes you just missed the point here. Hungarian notation does not > attempt to help you keep track of _what_ your variable is, it gives you a > framework to keep track of what _kind_ of variable it is. One would also > note that someProc is not a very descriptive name, but so what? In the first > example, I have _no_ clue what type of variable MyString is, although I > could probably deduce that it is a string. In the second example, the prefix That's exactly what I meant. Sorry that I didn't make my point clear. > tells me that it is a Pointer to a Zero terminated String. -Joachim -- Im speaking for myself here. ## CrossPoint v3.02 ## ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <marnoldDJEvtJ.1Lx@netcom.com>]
[parent not found: <4aleun$jlk@ns.RezoNet.NET>]
[parent not found: <marnoldDJMDBG.CFz@netcom.com>]
[parent not found: <4asnkr$7b0@solutions.solon.com>]
[parent not found: <4ath75$e7i@barnacle.iol.ie>]
[parent not found: <4b4kij$svt@news.microsoft.com>]
[parent not found: <dewar.819489496@schonberg>]
[parent not found: <4bd <4cne0e$1020@seminole.gate.net>]
* Re: Hungarian notation [not found] ` <4bd <4cne0e$1020@seminole.gate.net> @ 1996-01-08 0:00 ` Bob Kitzberger 1996-01-08 0:00 ` Adam Beneschan 1 sibling, 0 replies; 13+ messages in thread From: Bob Kitzberger @ 1996-01-08 0:00 UTC (permalink / raw) Michael Feathers (feathers@gate.net) wrote: : : If anyone does not think that type is important information that ought : to kept in mind for semantic purposes, just consider this: someone : anonymously offers you sex. The type of person offering it should : be important to you, unless you are bisexual, and even then you : might like to know as some casting may be required. :-) C, no HN: you directly attempt to mate regardless of target sex C, HN: you rely on the name of the person to determine their sex, and then attempt to mate if the name matches. Roberta and Robert live interesting lives. Ada,C++ w tools: you ask your tricorder about the sex of the person before attempting to mate. : -Mike (master of silly analogies) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Hungarian notation [not found] ` <4bd <4cne0e$1020@seminole.gate.net> 1996-01-08 0:00 ` Bob Kitzberger @ 1996-01-08 0:00 ` Adam Beneschan 1 sibling, 0 replies; 13+ messages in thread From: Adam Beneschan @ 1996-01-08 0:00 UTC (permalink / raw) feathers@gate.net (Michael Feathers) writes: > > If anyone does not think that type is important information that ought > to kept in mind for semantic purposes, just consider this: someone > anonymously offers you sex. The type of person offering it should > be important to you, unless you are bisexual, and even then you > might like to know as some casting may be required. :-) > > > -Mike (master of silly analogies) I agree with your last point--i.e. that this is a silly analogy. To carry the silliness even further: you probably care what gender a person is before you have sex with them, but if you're an employer looking for someone to fill a position, you probably don't, or shouldn't, care; all you're concerned with is what purpose you're going to be using the person for. Now, which of these analogies corresponds more closely to how variables in a program are used? (1) Using the variables for a purpose (2) Having sex with the variables :-) -- Adam ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Hungarian notation [not found] ` <dewar.819489496@schonberg> [not found] ` <4bd <4cne0e$1020@seminole.gate.net> @ 1996-01-08 0:00 ` Michael Feathers 1 sibling, 0 replies; 13+ messages in thread From: Michael Feathers @ 1996-01-08 0:00 UTC (permalink / raw) Bob Kitzberger (rlk@rational.com) wrote: : Michael Feathers (feathers@gate.net) wrote: : : : : If anyone does not think that type is important information that ought : : to kept in mind for semantic purposes, just consider this: someone : : anonymously offers you sex. The type of person offering it should : : be important to you, unless you are bisexual, and even then you : : might like to know as some casting may be required. :-) : : C, no HN: you directly attempt to mate regardless of target sex : : C, HN: you rely on the name of the person to determine their sex, and : then attempt to mate if the name matches. Roberta and Robert : live interesting lives. Naa... mlRobert is male and flRobert is female :) ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <30EF0415.6FE1@tus.ssi1.com>]
[parent not found: <1996Jan7.045815.8676@ohstpy>]
[parent not found: <4cpb00$nqk@news.xmission.com>]
* Re: Hungarian notation [not found] ` <4cpb00$nqk@news.xmission.com> @ 1996-01-08 0:00 ` Michael Feathers 1996-01-08 0:00 ` vancleef 1996-01-09 0:00 ` Todd Knarr [not found] ` <hawkfish-0801960904580001@blv-pm3-ip24.halcyon.com> 1 sibling, 2 replies; 13+ messages in thread From: Michael Feathers @ 1996-01-08 0:00 UTC (permalink / raw) Todd Knarr (tknarr@xmission.com) wrote: : In <1996Jan7.045815.8676@ohstpy>, vancleef@ohstpy.mps.ohio-state.edu writes: : : >How often do you use NON-ZERO terminated strings??? HN is : >useless garbage in C++, or for ANSI C compilers. Not so. I use HN in C++ all the time. It is excellent in the presence of polymorphism. : That's the big downside to HN: it simply cannot be sensibly extended to : deal with an arbitrarily large number of types, and it goes completely : insane dealing with polymorphism. I doubt anyone could come up with a : reasonable HN prefix to accomodate a variable that can be one of 9 : different types at any given time. I've never seen a variable that can be any of 9 different types in C++. All variables have a type. Period. A type can be a union or a base class, but all variables have one and only one type in C++. If you don't believe me, check the ARM. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Hungarian notation 1996-01-08 0:00 ` Michael Feathers @ 1996-01-08 0:00 ` vancleef 1996-01-09 0:00 ` Todd Knarr 1 sibling, 0 replies; 13+ messages in thread From: vancleef @ 1996-01-08 0:00 UTC (permalink / raw) In article <4crm6i$24mi@navajo.gate.net>, feathers@gate.net (Michael Feathers) writes: > Todd Knarr (tknarr@xmission.com) wrote: > : In <1996Jan7.045815.8676@ohstpy>, vancleef@ohstpy.mps.ohio-state.edu writes: > : > : >How often do you use NON-ZERO terminated strings??? HN is > : >useless garbage in C++, or for ANSI C compilers. > > Not so. I use HN in C++ all the time. It is excellent in the presence > of polymorphism. Huh? How? > > : That's the big downside to HN: it simply cannot be sensibly extended to > : deal with an arbitrarily large number of types, and it goes completely > : insane dealing with polymorphism. I doubt anyone could come up with a > : reasonable HN prefix to accomodate a variable that can be one of 9 > : different types at any given time. > > I've never seen a variable that can be any of 9 different types in C++. > All variables have a type. Period. A type can be a union or a base > class, but all variables have one and only one type in C++. If you don't > believe me, check the ARM. > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Hungarian notation 1996-01-08 0:00 ` Michael Feathers 1996-01-08 0:00 ` vancleef @ 1996-01-09 0:00 ` Todd Knarr 1996-01-09 0:00 ` Michael Feathers 1 sibling, 1 reply; 13+ messages in thread From: Todd Knarr @ 1996-01-09 0:00 UTC (permalink / raw) In <4crm6i$24mi@navajo.gate.net>, feathers@gate.net (Michael Feathers) writes: >I've never seen a variable that can be any of 9 different types in C++. >All variables have a type. Period. A type can be a union or a base >class, but all variables have one and only one type in C++. If you don't >believe me, check the ARM. You haven't worked with polymorphic classes as reference arguments or pointers much, then. I have the following class heirarchy: Stall AvailableStall AssignedStall OccupiedStall DirtyStall BeingCleanedStall BrokenStall OutOfServiceStall AlarmStall OfflineStall That's 9 subclasses of Stall. I do, though, routinely have arguments that are pointers or references to Stall. The actual object may be any one of those 9 subclasses. Give me an HN prefix that tells me that, in the following prototype Stall *HardwareChangeSignalled( Stall& ExistingStall, int ByteCount, unsigned char *aHardwareData ); the ExistingStall argument is one of the 9 subclasses and never a Stall, and the returned pointer is one of the 9 subclasses and never a pointer to Stall. Without such a prefix, you can readily get the obnoxious situation of a new programmer depending on the prefix and not realizing that he is dealing with a polymorphic type. This can cause him problems if he refers to the source code for Stall, depending on the HN prefix to be the actual type. -- Todd Knarr : tknarr@xmission.com | finger for PGP public key | Member, USENET Cabal Seriously, I don't want to die just yet. I don't care how good-looking they are, I! don't! want! to! die!" -- Megazone ( UF1 ) ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Hungarian notation 1996-01-09 0:00 ` Todd Knarr @ 1996-01-09 0:00 ` Michael Feathers 0 siblings, 0 replies; 13+ messages in thread From: Michael Feathers @ 1996-01-09 0:00 UTC (permalink / raw) Todd Knarr (tknarr@xmission.com) wrote: : In <4crm6i$24mi@navajo.gate.net>, feathers@gate.net (Michael Feathers) writes: : >I've never seen a variable that can be any of 9 different types in C++. : >All variables have a type. Period. A type can be a union or a base : >class, but all variables have one and only one type in C++. If you don't : >believe me, check the ARM. : : You haven't worked with polymorphic classes as reference arguments or : pointers much, then. I have the following class heirarchy: Yeah, I have. In your example (deleted for space) you mention that a reference can stand in place for objects of any of its derived types. I said that all variables have one-and-only-one-type. The reference itself is a variable (as pointers are) and it has a type. This may seem like a quibbling point, but in OOP it should be a natural assumption (because of polymorphism) that all objects of derived classes should perform in a manner appropriate to their class in the context of their base classes interfaces. This is information hiding, in much the same way as function names hide implementation yet provide semantic information. If this is not the case, then the inheritance should be suspect. : Give me an HN prefix that tells me that, in the following prototype : : Stall *HardwareChangeSignalled( Stall& ExistingStall, int ByteCount, : unsigned char *aHardwareData ); : : the ExistingStall argument is one of the 9 subclasses and never a Stall, : and the returned pointer is one of the 9 subclasses and never a pointer to : Stall. Why never a Stall? If Stall's interface is present in any of its derived classes, Stall calls should be resolved. : Without such a prefix, you can readily get the obnoxious situation of a new : programmer depending on the prefix and not realizing that he is dealing with : a polymorphic type. This can cause him problems if he refers to the source : code for Stall, depending on the HN prefix to be the actual type. True enough, but I think that new OOP programmers should drill it into their heads that references==pointers as far as polymorphism goes (and in other ways too). Polymorphism has to change the way that you understand code. We are not in Kansas any more. ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <hawkfish-0801960904580001@blv-pm3-ip24.halcyon.com>]
* Re: Hungarian notation [not found] ` <hawkfish-0801960904580001@blv-pm3-ip24.halcyon.com> @ 1996-01-09 0:00 ` Todd Knarr 0 siblings, 0 replies; 13+ messages in thread From: Todd Knarr @ 1996-01-09 0:00 UTC (permalink / raw) In <hawkfish-0801960904580001@blv-pm3-ip24.halcyon.com>, hawkfish@punchdeck.com (Richard Wesley) writes: >I've found it useful to use typedefs for all sorts of things like this. >Looping through a FooArray with a FooIndex is much more robust than using >a long or something. I try to avoid syntactic-saccharine typedefs when possible. There's no language-level gain from typedef'ing an int or long to something else just for that, and it virtually requires an explosion of variables to deal with multiple arrays of different types. The result of using several different variables to step through several different arrays at different times, just because those arrays have elements of different types, tends to be confusion. When the index is really significant then it makes sense to use seperate variables ( eg. when nCurrentMerchItem holds the index of the current item as other processing is done ), but as was pointed out there are a lot of constructions where the index is only significant for a line or two of code ( where your code is saying, basically, "Do >this< to every item in the array." ). One of my rules is that, when I do something like that, I use integer variables like i and j. That maps nicely to the uses of such letters in math classes and the like. I can then tell instantly whether the indexes are significant or just grind work. >This is reasonable for C, but these days I find myself using auto_ptr and >my own auto_array templates to deal with this problem. On the other hand, >it could still be useful inside a class that used an array to represent >something (e.g. a string). Even in a lot of higher-level things like your auto_array it makes sense to index things by an integral value. There's a significant gain in safety at times, but at others you simply introduce redundant checks. If, for instance, an index is validated once and never altered after that, there is no need to revalidate it on every access. ( NB: being certain the index will never become invalid is, of course, the trick. ) -- Todd Knarr : tknarr@xmission.com | finger for PGP public key | Member, USENET Cabal Seriously, I don't want to die just yet. I don't care how good-looking they are, I! don't! want! to! die!" -- Megazone ( UF1 ) ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <4fc157$jsf@goanna.cs.rmit.EDU.AU>]
[parent not found: <dewar.823793746@schonberg>]
[parent not found: <4fms62$c0p@goanna.cs.rmit.EDU.AU>]
[parent not found: <4ft1ruINN6dr@keats.ugrad.cs.ubc.ca>]
* Re: Hungarian notation - whoops! [not found] ` <4ft1ruINN6dr@keats.ugrad.cs.ubc.ca> @ 1996-02-19 0:00 ` Richard A. O'Keefe 1996-02-21 0:00 ` Lawrence Kirby 1996-02-22 0:00 ` Kazimir Kylheku 0 siblings, 2 replies; 13+ messages in thread From: Richard A. O'Keefe @ 1996-02-19 0:00 UTC (permalink / raw) I wrote: The underlying base is not something I usually have to think about. Most of my C code would work just as well in base 2, 3, 10, or even balanced ternary. c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) writes: >But that is irrelevant since the standard restricts C to binary architectures. Irrelevant to what? I *know* what the C standard requires. I keep a copy of the C standard (and the draft C++ standard, and Pascal, and Pascal Extended, and Ada 83, and Ada 95) close by my desk for handy reference. (The Fortran standards I have read on microfiche in the library.) Of necessity, my Fortran and Pascal code cannot depend on the machine base. The fact that most of my C code turns out not to depend on the machine base even though it _could_ is most certainly relevant to a discussion of arithmetic in programming languages. The form of my argument was "how much more". It so happens that the C standard was carefully crafted to allow 2s complement, 1s complement, AND sign-and-magnitude. I wrote: But the fact that abs(x) may deliver a negative number is something I have to live with the whole time. Kazimir Kyheku again completely misses the point by a country mile. >Not true. If you use the unsigned type, there is no such thing as overflow. >It's called residue math. No operation between two unsigned numbers yields >undefined results. The "X % Y" operation between unsigned numbers gives you the >smallest positive residue of X with respect to Y. Nothing undefined or >overflown about that. Kazimir, you will get a LOT further in life if you realise that people who disagree with you sometimes know what they are talking about. The abs function in C is defined by the standard to take SIGNED int as parameter and deliver SIGNED int as result. I am not claiming now, did not claim in the quoted message, and have never claimed in the past that C has no arithmetic types which cannot overflow. (Actually, in UNIX Version 6, C _didn't_ have unsigned arithmetic; one did arithmetic on pointers to get unsigned. I kid you not.) By the way, "X % 0" is still undefined in unsigned arithmetic, so the claim that there is "nothing undefined" about it is not true. Let me say it again: C, like many programming languages, has two mathematically simple functions on ***SIGNED*** integers: -x abs(x) An implementation of C, or any other such language, using ones-complement or sign-and-magnitude arithmetic, easily delivers correct outputs for all legal inputs to these operations. An implementation of C, or any other such language, using twos-complement arithmetic, EITHER delivers incorrect outputs for some legal inputs OR requires checking which is in practice seldom offered. Now, it so happens that a C compiler _is_ free to generate overflow checks for signed integer arithmetic, so a twos-complement implementation COULD guarantee "correct result or exception in all cases". This is occasionally done for Pascal compilers. I have access to three C compilers (lcc, gcc, and SPARCompiler cc) and if any of them has an option to check that signed arithmetic is done correctly I would be most grateful to be told what it is. The practical consequence of this is that responsibility for ensuring that the input to unary minus or absolute value is in range is passed onto the programmer. It is that which I am complaining about. It doesn't make my life as a programmer one teeny tiny bit easier. >The unsigned type is the ticket for portable integer modulo arithmetic. Modular arithmetic in Ada 95 *is* the ticket for portable hackery. Unsigned arithmetic in C is indeed defined to be modulo 2**n for some n, but the bounds on n are very very loose, and the price of portability is much programmer-inserted masking. More importantly, while overflow in signed arithmetic is a run-time error, unsigned arithmetic is very often a design-time error. For example, suppose I want to count the number of times some event occurs. Unless I can *prove* at design time that the event can occur no more than 65535 times, use of 'unsigned int' in C is a design-time error. There is at least one "commodity ISA" with a 300Mhz implementation getting close. How long is a 32-bit unsigned counter usable with 3e8 events per second? A little over 14 seconds. Overflows aren't the problem. Restricted machine arithmetic is the problem. >You need unaligned access if you want to have packed character arrays. Sorry, but this simply isn't true. It may surprise you to know that Pascal (the programming language which introduced the term 'packed') was first implemented on a machine which did not have unaligned access. The machine in question had 60-bit words, 6 bit characters, and no character addressing, only word addressing (which made unaligned access impossible to express). >If you >don't allow any sort of unaligned access, allowing only contiguous 32-bit words >to be accessed individually, you force size N arrays of characters to be 4N >bytes long. That is seen by some people as a waste of memory. You are confusing *unaligned* access with *byte* access. Like it or not, it is a fact that the machines I was talking about DID support byte access, DID support packed arrays of character, but did NOT support unaligned access. (Kazimir Kylheku) then contradicts himself and writes >Just because a machine does enforce alignment doesn't mean that C cannot >operate on packed byte arrays. >Chances are that you may even be working on an architecture whose compiler does >this, and not even know it! :) I am working on a SPARC. I also keep the SPARC V8 ABI manual close to my desk, and know it pretty well. Architectures don't have unique compilers. I use three compilers. I've only read one of them (lcc), but I occasionally check the output of the others (gcc, cc). There are several other compilers for this architecture, including one which doesn't use register windows. -- Election time; but how to get Labour _out_ without letting Liberal _in_? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Hungarian notation - whoops! 1996-02-19 0:00 ` Hungarian notation - whoops! Richard A. O'Keefe @ 1996-02-21 0:00 ` Lawrence Kirby 1996-02-22 0:00 ` Kazimir Kylheku 1 sibling, 0 replies; 13+ messages in thread From: Lawrence Kirby @ 1996-02-21 0:00 UTC (permalink / raw) In article <4g9255$74s@goanna.cs.rmit.EDU.AU> ok@goanna.cs.rmit.EDU.AU "Richard A. O'Keefe" writes: >Let me say it again: > > C, like many programming languages, has two mathematically > simple functions on ***SIGNED*** integers: > -x > abs(x) > An implementation of C, or any other such language, using > ones-complement or sign-and-magnitude arithmetic, easily > delivers correct outputs for all legal inputs to these operations. > > An implementation of C, or any other such language, using > twos-complement arithmetic, EITHER delivers incorrect outputs > for some legal inputs OR requires checking which is in practice > seldom offered. Checking against overflow is required whatever representation is used. Once this is established using 2's complement is no worse than any other representation. Did you see my earlier reply in the thread on this subject? If nothing else it seems to me that 2's complement is a big win with regards to implementing multiple-precision arithmetic since lower order bits of the result of most operations don't depend on the signs of the operands or the sign of the result. >The practical consequence of this is that responsibility for ensuring that >the input to unary minus or absolute value is in range is passed onto the >programmer. It is that which I am complaining about. It doesn't make my >life as a programmer one teeny tiny bit easier. It doesn't make it any harder either - see my earlier post. >>The unsigned type is the ticket for portable integer modulo arithmetic. > >Modular arithmetic in Ada 95 *is* the ticket for portable hackery. >Unsigned arithmetic in C is indeed defined to be modulo 2**n for some >n, but the bounds on n are very very loose, and the price of portability >is much programmer-inserted masking. Well, a small amount of masking. >More importantly, while overflow in signed arithmetic is a run-time error, >unsigned arithmetic is very often a design-time error. True, modulo arithmetic isn't useful in contexts where it simply generates the wrong result (however it does make it easy to test for overflow after an unsigned operation). >For example, suppose I want to count the number of times some event occurs. >Unless I can *prove* at design time that the event can occur no more than >65535 times, use of 'unsigned int' in C is a design-time error. Only if the code doesn't test for wrap to zero. Unsigned types make this test very easy. > There is >at least one "commodity ISA" with a 300Mhz implementation getting close. >How long is a 32-bit unsigned counter usable with 3e8 events per second? > >A little over 14 seconds. True, it has become important that contemporary languages mandate support for types longer than 32 bits. >Overflows aren't the problem. Restricted machine arithmetic is the problem. It depends on where you put the limit. Language support for multiple-precision arithmetic or specified precision beyond 64 bits (or possibly 128 bits) has some uses but they are rare across the whole spectrum of code. >>If you >>don't allow any sort of unaligned access, allowing only contiguous 32-bit > words >>to be accessed individually, you force size N arrays of characters to be 4N >>bytes long. That is seen by some people as a waste of memory. > >You are confusing *unaligned* access with *byte* access. Like it or not, it >is a fact that the machines I was talking about DID support byte access, >DID support packed arrays of character, but did NOT support unaligned >access. And there are yet other systems (e.g. Crays) which don't support byte access but compilers can still support characters arrays where the character unit is smaller than the machine word unit by bit twiddling tricks. -- ----------------------------------------- Lawrence Kirby | fred@genesis.demon.co.uk Wilts, England | 70734.126@compuserve.com ----------------------------------------- ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Hungarian notation - whoops! 1996-02-19 0:00 ` Hungarian notation - whoops! Richard A. O'Keefe 1996-02-21 0:00 ` Lawrence Kirby @ 1996-02-22 0:00 ` Kazimir Kylheku 1 sibling, 0 replies; 13+ messages in thread From: Kazimir Kylheku @ 1996-02-22 0:00 UTC (permalink / raw) In article <4g9255$74s@goanna.cs.rmit.EDU.AU>, Richard A. O'Keefe <ok@goanna.cs.rmit.EDU.AU> wrote: >It so happens that the C standard was carefully crafted to allow >2s complement, 1s complement, AND sign-and-magnitude. > >I wrote: > But the fact that abs(x) may deliver a negative > number is something I have to live with the whole time. It does so for the largest negative value. This is documented. Unfortunately, as you claim, you do have to check that yourself. And of course, to know what the largest negative value is, you can use the standard #defined manifest constants. It's not like abs() returns a negative value for any old random input. The fact of the matter is that the additive inverse of the largest negative value under two's complement simply can't be represented in a two's complement word of the same size, yet the return value from abs() is a signed quantity. Shrug. I hear what you are saying though. >Kazimir Kyheku again completely misses the point by a country mile. > >>Not true. If you use the unsigned type, there is no such thing as overflow. >>It's called residue math. No operation between two unsigned numbers yields >>undefined results. The "X % Y" operation between unsigned numbers gives you the >>smallest positive residue of X with respect to Y. Nothing undefined or >>overflown about that. > >Kazimir, you will get a LOT further in life if you realise that people who >disagree with you sometimes know what they are talking about. > >The abs function in C is defined by the standard to take SIGNED int as >parameter and deliver SIGNED int as result. I am not claiming now, did You can cast it to an unsigned type. From K&R2 (A6.2): Any integer is converted to a given unsigned type by finding the smallest non-negative value that is congruent to that integer, modulo one more than the largest value that can be represented in the unsigned type. In a two's complement representation, this is equivalent to left-truncation if the bit pattern of the unsigned type is narrower, and to zero-filling unsigned values and sign-extending signed values if the unsigned type is wider. If the unsigned type you convert to is the same size as the signed return type from abs(), you will catch the the right absolute value in the conversion to unsigned without invoking undefined, or implementation-defined behavior. If the unsigned type is wider, of course, the sign extension will mess you up! And this does not address the "-x" problem, to which there is no solution under two's complement arithmetic. >pointers to get unsigned. I kid you not.) By the way, "X % 0" is still >undefined in unsigned arithmetic, so the claim that there is "nothing >undefined" about it is not true. That goes without saying. >Let me say it again: > > C, like many programming languages, has two mathematically > simple functions on ***SIGNED*** integers: > -x > abs(x) > An implementation of C, or any other such language, using > ones-complement or sign-and-magnitude arithmetic, easily > delivers correct outputs for all legal inputs to these operations. > An implementation of C, or any other such language, using > twos-complement arithmetic, EITHER delivers incorrect outputs > for some legal inputs OR requires checking which is in practice > seldom offered. For _one_ legal input. :) >Now, it so happens that a C compiler _is_ free to generate overflow checks >for signed integer arithmetic, so a twos-complement implementation COULD >guarantee "correct result or exception in all cases". This is occasionally >done for Pascal compilers. I have access to three C compilers (lcc, gcc, >and SPARCompiler cc) and if any of them has an option to check that signed >arithmetic is done correctly I would be most grateful to be told what it is. > >The practical consequence of this is that responsibility for ensuring that >the input to unary minus or absolute value is in range is passed onto the >programmer. It is that which I am complaining about. It doesn't make my >life as a programmer one teeny tiny bit easier. > >>The unsigned type is the ticket for portable integer modulo arithmetic. > >Modular arithmetic in Ada 95 *is* the ticket for portable hackery. >Unsigned arithmetic in C is indeed defined to be modulo 2**n for some >n, but the bounds on n are very very loose, and the price of portability >is much programmer-inserted masking. I didn't say that it wasn't. But the Ada compiler has to also do a little ``code explosion'' to ensure the same portability as your C with programmer inserted masking. >More importantly, while overflow in signed arithmetic is a run-time error, >unsigned arithmetic is very often a design-time error. > >For example, suppose I want to count the number of times some event occurs. >Unless I can *prove* at design time that the event can occur no more than >65535 times, use of 'unsigned int' in C is a design-time error. There is True. >at least one "commodity ISA" with a 300Mhz implementation getting close. >How long is a 32-bit unsigned counter usable with 3e8 events per second? > >A little over 14 seconds. > >Overflows aren't the problem. Restricted machine arithmetic is the problem. Not much you can do about the machine, as a programmer and supporting multi-precision arithmetic in any language imposes a lot of overhead and code explosion. The C standard does give you a minimum maximum unsigned integer of 2^32-1. If you need a counter that has more precision, you can use more such numbers. That it's a pain and inconvenience, I will not deny. I also won't deny that it will give poor performance on a machine where higher precision quantities can be directly manipulated. Hence we have C progams littered with #ifdefs. Ideally, you should be able to specify in a program the expected range for an integer, so that the compiler will either fail to translate, or generate the extra arithmetic code for maintaining the given precision. That sort of goes against the spirt of C, which is that operations are usually implemented using suitable idioms of the target architecture. It seems that this philosophy is ultimately the source of your (and other people's) understandable frustrations. >>You need unaligned access if you want to have packed character arrays. > >Sorry, but this simply isn't true. It may surprise you to know that Pascal You are right. I don't know why I wrote that, when later on I clearly contradicted that by saying that such access can be emulated with inline code, so you don't need the addressability or unaligned access at the hardware level. Let the second statement be taken as official. BTW do you have some sort of specific gripe with two's complement representations of integer arithmetic? -- ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Number representation (was: Hungarian notation - whoops!) [not found] <30C40F77.53B5@swsbbs.com> ` (3 preceding siblings ...) [not found] ` <4fc157$jsf@goanna.cs.rmit.EDU.AU> @ 1996-02-19 0:00 ` Richard A. O'Keefe 4 siblings, 0 replies; 13+ messages in thread From: Richard A. O'Keefe @ 1996-02-19 0:00 UTC (permalink / raw) tsw@3do.com (Tom Watson) writes: >In article <4fms62$c0p@goanna.cs.rmit.EDU.AU>, ok@goanna.cs.rmit.EDU.AU >(Richard A. O'Keefe) wrote: >> >> >By the way, S&M is of course the right representation of floating-point, >> >using 2's complement for floating-point is a goof that only a designer >> >not understanding fpt would make! >> I did _not_ write that, I _quoted_ it. >I'm not so sure. With sign & magnitude you get TWO representations of the >same number (zero). In the B6700, you did indeed get two representations of 0, but unless you used some non-standard extensions (-0 .EQ. 0) but (.NOT.(-0 .IS. 0)) nothing in your program could depend on this fact. The presence of two signed integer zeros (which were the same as the two signed floating point zeros) was something that a programmer could and did completely ignore. All the hardware had to do was to make sure that -0 and +0 acted the same in ordinary comparisons. >Some may argue that the difference is that negative >zero is what a very small negative number decays into, and positive zero >is what a very small positive number decays into. That is not the way it worked in the B6700 or the DECsystem-10. So you have two representations of 0 with identical arithmetic properties. So what? Comparison hardware has to worry, programmers don't. The VAX uses (used?) a sign-and-magnitude format, but never generated -0.0 and regarded the "-0.0" representation as an "illegal operand". As for IEEE arithmetic, I find that it helps to think of it as having NO representation for 0. Instead, it can represent -1/epsilon, <negative finite numbers>, -epsilon <NO zero> +epsilon <positive finite numbers> +1/epsilon >My understanding of numbers (no, I'm not an expert at this!) is that >zero is only ONE number (basically without sign). Most numbering >systems (like two's complement integers) have put in the positive >domain. >Programs didn't need to test for >multiple incantations of zero (which needs to be done with IEEE numbers if >the hardware doesn't detect BOTH forms). Should "incantations" be "incarnations"? If the hardware doesn't process +0 and -0 and process them distinctly, isn't IEEE. >As far as I can see, the only good thing (tm) that multiple (+ & -) zeros >gets you is multiple infinities when you divide by it (which may be the >object). As long as both positive and negative numbers exist, and there >is SOME method of making a bit pattern happen for each of them that are >defined, it probably doesn't mean much which bits are turned on (use gray >code, I don't care). Just make sure that all the operations necessary are >working, and give proper (documented) results. I think I should make it clear that when I criticised twos-complement as silly because it significantly complicates the arithmetic model that the programmer has to work with, I was not particularly concerned about the hardware representation of numbers. To a programmer who "grew up" with a machine having 48 data bits of which numbers used only 47, it is obvious that the connection between numbers and bits is only conventional. (For example, you could pack 6 EBCDIC characters per word using bit instructions, but try to do it using integer arithmetic and you were sure of an overflow.) What I care about is programs running on "hopefully sufficiently large" machines that turn out _not_ to be "sufficiently large" being quietly given wrong answers. There are occasions when Ada 95's modular types are exactly the right thing to use. There are many more when plain integer types are right, and I'm glad that Ada _encourages_ overflow detection. From ok Mon Feb 19 18:10 EST 1996 Received: (from ok@localhost) by goanna.cs.rmit.EDU.AU (8.7.1/8.6.9) id SAA15322; Mon, 19 Feb 1996 18:10:40 +1100 (EST) Date: Mon, 19 Feb 1996 18:10:40 +1100 (EST) From: "Richard A. O'Keefe" <ok> Message-Id: <199602190710.SAA15322@goanna.cs.rmit.EDU.AU> To: ok Subject: follow failed Content-Type: text Content-Length: 1504 posted, but mailed to the moderator for approval. Your response has been saved in ~/dead.letter Your article follows: Newsgroups: comp.lang.c.moderated Subject: Re: But DO C hackers code concisely? References: <4fa7e7$2pu@solutions.solon.com> <4fst4u$2f1@solutions.solon.com> <4fvh88$e3l@solutions.solon.com> "Robert F. Monroe" <Robert@hever.demon.co.uk> writes: >What conceivable use could there be for either printf or scanf in a >Windows DLL? The very nature of Windows I/O would cause them to only >produce garbage. Well, the C standard *requires* them. If you haven't got printf() and scanf(), you haven't got a "hosted" C implementation. printf(~~1~~) === fprintf(stdout, ~~1~~) and scanf(~~2~~) === fscanf(stdin, ~~2~~) so the problem is not printf and scanf per se but stdin and stdout, and if you haven't got _them_ you haven't got a conforming "hosted" C implementation either. One very good reason for having them in the library is precisely to catch code which has been ported to Windows but incompletely. Since Microsoft C has exceptions, I would think it appropriate for - input from stdin, however expressed - output to stdout, however expressed to raise an exception, and for the library to define printf &c so that user code cannot accidentally rely on defining them to do something different. getchar, putchar, printf, scanf, could all share the same few "raise exception" bytes. In any case, this is irrelevant to the original example, which used sprintf not printf. From ok Mon Feb 19 18:17 EST 1996 Received: (from ok@localhost) by goanna.cs.rmit.EDU.AU (8.7.1/8.6.9) id SAA15797; Mon, 19 Feb 1996 18:17:38 +1100 (EST) Date: Mon, 19 Feb 1996 18:17:38 +1100 (EST) From: "Richard A. O'Keefe" <ok> Message-Id: <199602190717.SAA15797@goanna.cs.rmit.EDU.AU> To: ok Subject: follow failed Content-Type: text Content-Length: 1348 posted, but mailed to the moderator for approval. Your response has been saved in ~/dead.letter Your article follows: Newsgroups: comp.lang.c.moderated Subject: Re: But DO C hackers code concisely? References: <4fa7e7$2pu@solutions.solon.com> <4fst4u$2f1@solutions.solon.com> I gave the example of complex code that could have been replaced by tiny calls to sprintf. Michael Smith <msmith@mpx.com.au> writes: >Yes I do think that MS leaving these functions out is realy stupid, >but you have to work with the tools you have. This doesn't in the least spoil my argument. Assume that leaving the printf() and scanf() _families_ out of the library used with DLLs is a good decision, and ignoring wsprintf(), (a) This wasn't a DLL, it was a complete program. (b) Converting integers from binary to text is pretty useful. If sprintf() is not available, or if efficiency is a concern and sprintf() proves slow, the answer is to write functions struct Integer_Format { unsigned char base; /* 2, 8, 10, 16 */ unsigned char pad ; unsigned char width; /* a minimum value */ }; static const struct Integer_Format plain = {10, ' ', 1}; ltostr(char *buf, long val, struct Integer_Format *); ultostr(char *buf, unsigned long val, struct Integer_Format *); or something similar, and stick them in your personal library. -- Election time; but how to get Labour _out_ without letting Liberal _in_? Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci. ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~1996-02-22 0:00 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <30C40F77.53B5@swsbbs.com> [not found] ` <4cd8fc$oud@news.manawatu.gen.nz> 1996-01-08 0:00 ` Hungarian notation Joachim Durchholz [not found] ` <marnoldDJEvtJ.1Lx@netcom.com> [not found] ` <4aleun$jlk@ns.RezoNet.NET> [not found] ` <marnoldDJMDBG.CFz@netcom.com> [not found] ` <4asnkr$7b0@solutions.solon.com> [not found] ` <4ath75$e7i@barnacle.iol.ie> [not found] ` <4b4kij$svt@news.microsoft.com> [not found] ` <dewar.819489496@schonberg> [not found] ` <4bd <4cne0e$1020@seminole.gate.net> 1996-01-08 0:00 ` Bob Kitzberger 1996-01-08 0:00 ` Adam Beneschan 1996-01-08 0:00 ` Michael Feathers [not found] ` <30EF0415.6FE1@tus.ssi1.com> [not found] ` <1996Jan7.045815.8676@ohstpy> [not found] ` <4cpb00$nqk@news.xmission.com> 1996-01-08 0:00 ` Michael Feathers 1996-01-08 0:00 ` vancleef 1996-01-09 0:00 ` Todd Knarr 1996-01-09 0:00 ` Michael Feathers [not found] ` <hawkfish-0801960904580001@blv-pm3-ip24.halcyon.com> 1996-01-09 0:00 ` Todd Knarr [not found] ` <4fc157$jsf@goanna.cs.rmit.EDU.AU> [not found] ` <dewar.823793746@schonberg> [not found] ` <4fms62$c0p@goanna.cs.rmit.EDU.AU> [not found] ` <4ft1ruINN6dr@keats.ugrad.cs.ubc.ca> 1996-02-19 0:00 ` Hungarian notation - whoops! Richard A. O'Keefe 1996-02-21 0:00 ` Lawrence Kirby 1996-02-22 0:00 ` Kazimir Kylheku 1996-02-19 0:00 ` Number representation (was: Hungarian notation - whoops!) Richard A. O'Keefe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox