Arkadiy Vertleyb wrote:
Just out of curiosity: can you write a library that would require to pre-process your user's C++ text with one of these tools, and then convince anybody to use this library?
If Perl is better then C++ preprocessor, then it should become C++ preprocessor. But it needs to be built-in, otherwise these are apples against oranges.
I was continuing the following discussion: Thorsten Ottosen: "Nevertheless, the preprocessor is a good way to generate some tedious code; just look inside boost.assign." Arkadiy Vertleyb: "And sometimes, I think, it's _the only_ way. If you are interested, please take a look at typeof_internals.htm.zip in the boost sandbox file vault." Yours Truly: "The only way as long as you commit to not look outside C++." etc. etc. The previous context of the conversation was the preprocessor, not library construction. So I felt that within the conversation my perspective made sense. There are other ways to generate C++ code, and that's what I said and substantiated. On the other hand, I agree with your point made in another post: "Preprocessor has an obvious advantage of availability to everybody. I, for instance, am very reluctant in downloading/using tools. I suspect many people are like this, too." But then if someone continued your argument with: "For example, you won't find on my development systems any of awk, sed, perl and I don't know how to use any of them. However, I am a pp lib expert." then I might opine that that person could reshuffle their priorities. Fair enough? Andrei