d31 Subj : Re: Win98 error To : borland.public.cpp.borlandcpp From : Bob Gonder Date : Tue Mar 16 2004 09:46 am Thomas Maeder [TeamB] wrote: >Bob Gonder writes: > >My experience tells me that programmers are notoriously wrong about where the >bottlenecks of their programs are. You are right about bottlenecks. But I don't really worry about bottlenecks, just writting the fastest code I can throughout. I only look for bottlenecks if I can notice something amiss at runtime. > The code you posted was an example; there >was an "optimization" that actually doesn't change anything to the good, as >the assembler output I posted demonstrates. Didn't demonstrate the original intention of the example, which was #define i27 27 Verses const int i27 = 27; When used in if( ByteB < i27 ) /* promotion?? comparing signed/unsigned??*/ if( WordW < i27 ) /* promotion?? comparing signed/unsigned??*/ if( LongL < i27 ) /* ok until int changes size, then same ?? */ Whereas you demonstrated BYTE const b27 Your contention was that '27' (the define) is an 'int' and that ByteB would be promoted (it wasn't). So, '27' when compared to a BYTE is a BYTE. Is "const int i27" compared as a BYTE or an int? By your standards, there would be 3 consts, one for each size. Which would be more confusing? One number to change or Many? Comparing Bytes/ Words/ Longs to "const int" or to a define? >Therefore, I consider every attempt to complicate code without evidence >of any payback a premature optimization. Athiests need evidence. Have Faith! ;-) There's a difference in philosophy. IMO, Good Enough often isn't. Best Practices rarely are. Industry Standard is usually SubStandard. Having said that, I will admit to occasionally, and with regret, intentionally bloating my code to make it easier to code/read, crossing my fingers that it won't slow things down _too_ much. Oh, and the evidence was gained way back when I was teaching myself C. I had the darndest time getting C to do what I told it to do. So I looked at a _lot_ of ASM output, and became quite familiar with what code produced what. These days, it's pretty much by rote from what I learned back then. I know things change, but just as depression era folks have trouble letting go of a penny, I prefer to write efficient code. It's hard to let go of the shoehorn. >But more complicated and less readable. I don't find it so (in my code). At least I'm not comparing "const int" to BYTE (which, even if the compiler doesn't complain, and actually does byte compares, just plain looks wrong). >ints in structs don't cause them to break on different platforms. Why do you >think they do? They're different sizes, no? Write a struct on one platform, read it on another, and not-so-good things happen. If you can use fixed-size values short, long, int64, of what use is a variable sized int in a struct? Other than, as I said, for something which will never ever leave the local module(s), and perhaps needs to cache some indexes: for( int i=0; i