Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!sri-spam!sri-unix!hplabs!pyramid!prls!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: net.lang.c++
Subject: Re: C++ and sizeof
Message-ID: <1896@mmintl.UUCP>
Date: Fri, 24-Oct-86 14:22:04 EST
Article-I.D.: mmintl.1896
Posted: Fri Oct 24 14:22:04 1986
Date-Received: Mon, 27-Oct-86 01:14:56 EST
References: <3522@columbia.UUCP> <1772@clyde.ATT.COM>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT
Lines: 20

In article <1772@clyde.ATT.COM> tk@moss.UUCP (Thomas Kirk) writes:
>In article <3522@columbia.UUCP> eppstein@garfield.columbia.edu (David Eppstein) writes:
>>Is there a good reason why CC expands sizeof itself?  E.g. in
>> ...
>>why does the  sizeof(y)  become  8  and not  sizeof(struct x)?
>>Is there some other use CC makes of the size that makes up for the
>>resulting lack of portability?
>
>What lack of portability? If you're counting on the C++ translator to produce
>"portable C" as its output I think you'll have problems since cfront uses
>machine dependent size and alignment information.

This fails to answer the question.  *What* does cfront use machine
dependant size and alignment information for?  Off hand, I can't think of
anything it does for which this information is necessary, although it is a
simplification to be able to carry around numbers instead of expressions for
sizes.

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Multimate International    52 Oakland Ave North    E. Hartford, CT 06108