Re: constant expression analyzer and 'sizeof'

Stefan Seefeld <[email protected]>
Newsgroups gmane.comp.documentation.synopsis
Message-ID <[email protected]>
Hi Nathaniel,

Nathaniel Smith wrote:

> I guess my question is, what are you going to use these numbers for?

Right now I'm looking into the parser, trying to make it 'more correct'
in that I want it to distinguish different types, i.e. in the context
of integrals that means either array types or template instantiations.

I hope people like David Abrahams are able to tell me how far I need to
go with this 'correctness' in order to correctly deal with code such
as boost.

Thus, I don't think I need to produce the same numbers for sizeof
and offsetof as other compilers, as far as some invariants are fulfilled.
Do you know of any documents that provide me with rules I have to
follow when implementing my own sizeof/offsetof operators ?

> If it's just a question of providing better docs, I'd actually be
> tempted to say that docs that said
>   const int BUFFER_SIZE = PAGE_SIZE * 4 / sizeof(block_t)
>      (= 16384/sizeof(block_t))
> would be more useful than
>   const int BUFFER_SIZE = PAGE_SIZE * 4 / sizeof(block_t)
>      (= 2048)

yeah, I fully agree. Keeping a symbolic value is much more expressive
for human readers. I'v no interest into numerical values myself,
but qualitative statements such as comparison and equality (think
about function overloading or template instantiation).

> The only good alternative I see is to somehow parametrize Synopsis on
> the ABI; have an object that knows how to compute object size and
> layout for a particular compiler version on a particular architecture,
> and let people swap in appropriate ones... ew.

yep, that's one possibility. I still hope I can get away without
that. All I need is a device to do proper semantic analysis, i.e.
type lookup etc.

> So maybe instead of an 'evaluator', there should be a 'simplifier',
> that attempts to recursively expressions as far as it can, but at the
> end returns an expression rather than a number?

dunno. I think as a user I either want to look at the expression
without *any* 'simplification', or I do want to see the numeric
value (at least to be able to use it as a discriminator in
type / method / operator lookup)

Regards,
		Stefan
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.