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