"Paul Mensonides"
Edward Diener wrote:
The general user does know how to use preprocessing macros and does understand how the macros may get expanded to code which can be used to accomplish tasks.
This is flat out not true. The general user understands that macros are relatively simple textual expansions. The general user does not understand the details of macro expansion, and these details are extremely important for any effective use of the preprocessor metaprogramming.
That is flat out not true. I have made some effective use of PP metaprogramming without understanding the details of macro expansion.
Preprocessor metaprogramming and, to a large extent, template metaprogramming is all about manipulating/exploiting the "details" of their respective parts of the language. I absolutely guarantee that this level of understanding does not generally exist--for template metaprogramming and especially for preprocessor metaprogramming.
In general libraries like MPL/Type Traits and Boost PP allow users to ignore (or actually be ignorant of) many of those "details" and concentrate on the task at hand. That's in part what makes them so powerful.
The general user does not understand the areas of functionality in the Boost pp-lib, what they are and how they may be used, because there is no good organizational explanation about the various areas in which the Boost pp-lib can be effectively used to accomplish either template programming goals or just useful code generation goals.
Both and more. As I said in the post I just sent a few minutes ago, I will address this this weekend. I'll try to write up a decent overview of the functionality available and send it to you so you can tell me what you think.
Is it done yet? Can I see?
However, there is no getting around the complexity involved because Cpp works against encapsulation.
Do you mean for example the leaking of information like recursion levels and different recursion mechanisms into the library interface? If so, I think that stuff is graspable without having to understand the reasons for it. You can just give people rules to follow and be done with it.
What is needed, even given the difficulty of trying to understand how the macros actually work with various possibly broken preprocessors, is an explanation of the pp-lib from a user's point of view, ie. what is there and what can it accomplish in terms of helping to simplify program code generation and/or use.
What can be accomplished is an open-ended question. I can only provide examples of a few things that can be accomplished--which both Vesa and I have already done.
What you haven't done is to write something like, "C and C++ code (especially library code) often contains lots of boilerplate repetition, leading to fragile systems that are tedious to write and maintain. The Boost PP lib provides a programmatic framework for code generation which can be used to eliminate repeated boilerplate and factor out common textual patterns in code." ...and take it from there.
As an example, I understand that there is part of the Boost pp-lib which deals with easing the specification of repetitive constructs. That could be discussed, macros which solve repetitive generation problems can be discussed and explained, and the general user will now have an idea of what macros in the pp-lib help with repetitive programming problems and how a given macro may be used in that way.
As I've said before, this categorization is already there: docs/headers/repetition/* I agree that this organization is not explicit, but it is there for anybody who cares to look deeply at it.
The problem is that a general sense of the library and its capabilities should be possible without looking deeply.
You may be right that the general user must first attempt to master the arcana of macro expansion and what does and does not work many macros attempt to expand inner macros in different situations in order to even use the pp-lib at all.
This is definitely part of it, but it has more to do with the vertical dependencies associated with the implementation of each primitive in the library. How primitive X is implemented is a direct concern to primitive Y. Expansion order is a significant factor as well. Encapsulation is a huge issue that causes use of the library to be closely tied to the implementation of the library. I have spent an excessive amount of time attempting to minimize these dependancies.
And you did a good job, which means that most users don't need to worry about it. -- Dave Abrahams Boost Consulting www.boost-consulting.com