[pooma-dev] domain architecture diagram

Scott Haney scotth at proximation.com
Mon Jul 2 14:41:13 UTC 2001


Documenting the architecture is a great first step. Thanks Allan.

The next step is to write down the *essential* requirements for domains. 
Then, use these requirements to analyze the design and remove every 
architectural feature that doesn't exist to support an essential 
requirement. Allan, please proceed with this analysis.

As an example, is avoiding the zero base-class penalty essential for 
domains?

If it is essential, we need to provide a workaround for compilers that 
don't support it. This is not the case if it is simply nice for domains 
or if it would be really cool to implement a zero base class workaround.

I would like to hear people's thoughts on this question.

Scott

On Monday, July 2, 2001, at 12:18 AM, Mark Mitchell wrote:

> I don't know if
>> this issue of the empty base class is important anymore
>> with current C++ compilers.
>
> This was the only part of this discussion I was smart enough to
> understand, so I decided to reply to it. :-)
>
> In G++ 3.0, there is no empty base class penalty.  The same will
> be true for any IA64 C++ ABI compliant compiler.  Modern versions
> of the EDG front end (used in KCC, the Intel compiler, the SGI
> compiler, the DEC/Compaq compiler, and elsewhere) are capable of
> avoiding the penalty.  However, I do now know if the vendors were
> willing to turn on this feature, since it will break compatibility
> with previous versions of their compilers.  And, I do not know
> whether VC++ is capable of avoiding the penalty.
>
> Irrelevant compilers for computers named after fruit are mentioned
> only because I know that the mere presence of this sentence will
> get people's adrenalin pumping in New Mexico. :-)  Seriously, I
> know nothing of whether Metrowerks can do this or not.
>
> It would be great if someone could try out:
>
> struct S { };
> struct T : public S { char c; };
>
> int main () { return sizeof (T); }
>
> with KCC.  If things are good, the program will return 1; if bad,
> some greater value.
>
> -- Mark Mitchell                mark at codesourcery.com
> CodeSourcery, LLC            http://www.codesourcery.com

--
Scott W. Haney
Development Manager
Proximation LLC
2960 Rodeo Park Drive West
Santa Fe, NM 87505
Voice: 505-424-3809 x101
FAX: 505-438-4161



More information about the pooma-dev mailing list