Related articles |
---|
Semantic difference of source files m.helvensteijn@gmail.com (Michiel) (2008-08-17) |
Re: Semantic difference of source files m.helvensteijn@gmail.com (Michiel) (2008-08-17) |
Re: Semantic difference of source files barry.j.kelly@gmail.com (Barry Kelly) (2008-08-18) |
Re: Semantic difference of source files DrDiettrich1@aol.com (Hans-Peter Diettrich) (2008-08-18) |
Re: Semantic difference of source files gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-08-18) |
Re: Semantic difference of source files gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-08-19) |
Re: Semantic difference of source files marcov@stack.nl (Marco van de Voort) (2008-08-20) |
Re: Semantic difference of source files gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-08-20) |
[4 later articles] |
From: | Michiel <m.helvensteijn@gmail.com> |
Newsgroups: | comp.compilers |
Date: | Sun, 17 Aug 2008 23:16:43 +0200 |
Organization: | Wanadoo |
References: | 08-08-025 |
Keywords: | parse, analysis |
Posted-Date: | 18 Aug 2008 10:28:48 EDT |
John wrote:
> [If you're only going to compare the ASTs to see if they're the same,
> all you need to save is a hash.
Ah, but then you lose the ability to selectively compare, which is the
biggest advantage of the method I propose. The programmer could write
a whole class (or various global functions), including implementation,
in the same file. Then it can still be automatically determined if
only the implementation has changed, or if the interface has changed
as well. (All private members of the class belong to the
implementation. All public members belong to the interface.)
However, I suppose you could save a separate hash for the interface
and for the implementation. Also a separate pair for each class and/or
each function in the file, maybe. It's a good idea.
> The question of why nobody seems to
> care about compilation speed any more. -John]
Are you saying nobody cares about compilation speed anymore? (Your
sentence seems to be gramatically ambiguous.)
It's one of the big annoyances during development, I'd say. Especially
for the really big projects. The compiler I'm working on is relatively
small. Still, I have to wait a minute or two if I change an
implementation detail or even a comment in an often used header file.
If people didn't care about compilation speed, why do they use the PIMPL
idiom? I see plenty of people using it for exactly that reason.
--
Michiel Helvensteijn
Return to the
comp.compilers page.
Search the
comp.compilers archives again.