Portability of passing/operating on structures...

[Richard Harter]

In article <1988Oct19.192548.28438 at ateng.ateng.com> chip at ateng.ateng.com (Chip Salzenberg) writes:
>According to mh at wlbr.EATON.COM (Mike Hoegeman):
>>I've worked on alot of machines where you cannot do ANY [structures in
>>assignment, as parameters and as function return values].
>>Maybe that's not "right". Maybe one should boycott such compilers. Any
>>way you look at it though it's still not portable.

>This is a personal decision.  Do you pander to every broken compiler?  Or
>do you concentrate on making the best code that will be accepted by any
>correct compiler?

>As for my opinion:  If your compiler's broken, take it up with your vendor.

	Mild flame on.  [The tone of Chip's comments irritate me.]  If
you have the option of only running on machines with compilers that you
approve of and you can tell all relevant vendors that you want their 
compilers "fixed" and they will do it at your request, then your "personal
decision" makes sense.  Bully for you.

	Yes, I pander to broken compilers.  I have to.  I write software
that runs on customers machines.  It has to work on their machines.  That
is what portability in the real world is all about -- if you can take your
code from machine A to machine B and compile and link it and have it work
correctly then it's portable; if you can't then it is not. 

	And the truth of the matter is that there is no penalty for
writing portable code -- you can still write well structured, well
documented code that is efficient.  The things that make programs non
portable are almost always frills and slop.  Things like passing structures
are frills.

	There are decision points in portability.  When we decide not to
run on system X because its compiler and operating system are too broken
that is not a personal decision -- it is a simple economic decision that
the market in system X is not worth pursuing.
-- 

In the fields of Hell where the grass grows high
Are the graves of dreams allowed to die.
	Richard Harter, SMDS  Inc.