Subj : Re: Win98 error
To   : borland.public.cpp.borlandcpp
From : maeder@glue.ch (Thomas Maeder [TeamB])
Date : Mon Mar 15 2004 07:32 pm

Bob Gonder <notbg@notmindspring.invalid> writes:

>>I have the feeling that you tend to do premature optimizations.
>
> Not sure what's premature about using your accumulated experience when
> coding instead of writing slopy stuff and relying on a profiler to
> tell you what the worst of it is, or the compiler to make it go away.

You posted code where you were doing this at the cost of simplicity and
readability.

My experience tells me that programmers are notoriously wrong about where the
bottlenecks of their programs are. 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.

Therefore, I consider every attempt to complicate code without evidence
of any payback a premature optimization.


> If I understand "premature optimization", it's going through the code
> and saving a picosecond in code that's executed once.  I agree that's
> not worth it, but... If you _consitantly_ write in an optimum manner,
> you lose little coding time, and your overall code will be
> faster/smaller.

But more complicated and less readable.


>>16bit compares are performed in all three cases. This is with 32bit ints; the
>
> Uh, hate to tell you this, but....  al is 8 bits.

Oops :-)


>>As a general rule, I don't agree. If you have a compelling reason for doing
>>this in particular struct types, then it's certainly good (by definition of
>>"compelling"). Do you have such a reason?
>
> "compelling" is that the structs will break when compiled on different
> platforms.  Though I see your point, that if the structs are "only"
> internal, self-use, non-persistant, you could get away with ints.
> Once again, I err on the side of caution, as I see no good reason _to_
> use ints in strucs.

ints in structs don't cause them to break on different platforms. Why do you
think they do?

.