Reading behind Streams in rpp
David Nolden
david.nolden.kdevelop at art-master.de
Wed May 13 10:00:41 UTC 2009
Am Dienstag 12 Mai 2009 23:26:42 schrieb Christoph Bartoschek:
> Hi,
>
> the attached patch adds a check for out of bounds accesses in rpp. It also
> fixes some usages that violate the assertion. However I am not 100% sure
> for the # operator.
Why did you do those changes to the # operator? That operator is supposed to
stringify the text, thus it has to escape stuff. Not sure about the newline
thing, but better leave it as it was.
> One additional question: What is the aim of rpp? Should it implement the
> preprocessor correctly? Or should it only show an approximation of the
> correct behaviour?
It is supposed to correctly model the preprocessor at some point. There is
some subtle problems yet though, that are visible in some boost preprocessor
libraries. I've already fixed quite a few of those, but there's still some
left. I'm not planning to keep working on that part though, so if you want to
improve it, feel free to do so. :-)
About the basic problem: operator++ and the likes are very performance
critical, and we should save every single instruction we can save within that
one.
So maybe it would make sense to just append a zero to each input-vector passed
to the preprocessor, then any loop should terminate without adding new code
all around rpp, because zero does not equal anything that is expected. What do
you think?
Greetings, David
More information about the KDevelop-devel
mailing list