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