Thou shalt have no other gods before the ANSI C standard 1396

So do I, when I can make it run better portably.

Not this year, anyway. But a few years down the road, when another vendor makes them an offer they can't refuse, it's amazing how happy they can be when they discover that your code ports painlessly to the new system.

Your crystal ball might be infallible, but mine is not. And I'm the first one to admit it.

If you don't do it beforehand, someone is going to have to do it later. And that someone might be you.

Are you counting only the here-and-now cost, or the total cost, which includes the porting that might have to be done later?

Said generations aren't necessarily identical in behaviour. I spent all my time in the early '80s porting software to the next generation from the same vendor. It was not a trivial task.

Where on earth do you get the idea that we're keeping ourselves ignorant of changes? If we did that, we wouldn't be able to write anything that would work on newer systems. In fact, one of the reasons we eagerly study this stuff is to see whether we can come up with portable solutions.

Neither should we. Knowing about new features enables us to make informed decisions as to whether to use them. There has to be a very strong benefit to justify breaking portability, and these decisions are best not made in ignorance.

We're reading the manual just as thoroughly, let me butture you. One of the reasons we read it is to see whether any changes are going to break our code. If we can find a solution that works on both old and new systems, we consider it a win - doubly so if it gives us insight into writing in a way that will work on the next generation too.

I think you're arguing our case here.

portability != obfuscation

-- I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!