Reading behind Streams in rpp

[Christoph Bartoschek]

Am Mittwoch, 13. Mai 2009 schrieb David Nolden:
> 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.

1. The old code was wrong by looking at the variable input instead of the 
vriable is. 

2. Most escapes are done in the for-loop above the while-loop.


> > 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. :-)

Then the preprocessor should match the output of cpp. This is currently not 
the case. Especially the operator # is handled wrong in the old code. I also 
see that rpp does not handle the code I normally work with correctly.

I try to find time to fix rpp. 

>
> 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.

I've removed an unnecessary check in operator++. I assume that the assertions 
are not part of released code.

>
> 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?

An idea worth thinking about. However most checks are necessary anyway to get 
better problem reporting from the preprocessor. For example the two checks in 
pp::handle_include improve the output of the preprocessor in the problem 
section. Additionally the second one prevents a memory leak.

I look what I can do in my limited time and show you the results for 
discussion.

Christoph