Path: utzoo!attcan!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: Randomly ordered fields !?!? (Was: "packed" objects)
Message-ID: <56737@microsoft.UUCP>
Date: 20 Aug 90 17:33:37 GMT
References: <56268@microsoft.UUCP> <1070@lupine.NCD.COM> <56638@microsoft.UUCP> <195@dumbcat.sf.ca.us>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 40

In article <195@dumbcat.sf.ca.us> marc@dumbcat.sf.ca.us (Marco S Hyman) writes:
>jimad> = jimad@microsoft.UUCP (Jim ADCOCK)
>	 article <56638@microsoft.UUCP>
>
>jimad> If you want to use C++ to play with machine registers, then
>jimad> portability is not an issue to you anyway.  -- Or alternatively,
>jimad> probably just about any vendors compiler with all optimizations
>jimad> turned off will fullfill your requirements.
>
>Let's make a distinction between code that is portable to different machines
>and code that is portable between different compilers on the same machine.
>Needing to play with machine registers will certainly limit machine
>portability.  But I certainly want to compile my machine dependent code with
>*any* C++ compiler and have the code work.

You've never had anything close to capability in the past, so the changes
I am suggesting aren't taking anything away from you.  Nor is there
anything in the standardization effort I can think of that could even
possibly give you these capabilities.  What might emerge -- eventually --
is defacto standards where vendors of compilers on a particular machine
agree on how things should be done on that machine.  But I claim the
marketplace is the right place to make such decisions.  Let's not ham-string
compilers from the start.

>This means that any special optimizations to make the code faster or tighter
>must not be the compiler's default.  Once I've got things working then I'll
>profile the code, check out better algorithms, and look at the optimizations
>available with the compiler.

Some special optimizations to make code faster or tighter are the default
even in today's C compilers.  Even if you turn off all optimizations, 
typical compilers still perform some particularly 'safe' optimizations.

Historically, optimizations have primarily been applied to callee code --
the body of functions.  In OOP the problem shifts towards caller optimizations
-- the way a function gets called.  So C optimization problems don't carry
over very well to C++ optimization problems.  Also, inline functions and
templates generate pretty 'bad' code -- overly general code, that needs
to be customized by an optimizer to meet the particular needs of the 
calling environment.