On 9/13/2014 9:44 AM, Paul Mensonides wrote:
(apologies for the late review)
-- Design --
Many of the utility components of the library have decent design. There are, however, a couple of aspects of the design that I dislike, and they touch on a large chunk of the library. These concerns all revolve around the registration, recognition, parsing, and limitations of various "v-types" and "v-sequences".
I do not yet see a strong use case for the "v-key"/"v-identifier" recognition scenario, as opposed to just registering a "v-identifier". For example,
#define BOOST_VMD_MAP_<v-key><v-identifier> // ...
BOOST_VMD_IS_IDENTIFIER(<v-seq>, <tuple-of-v-keys>)
Perhaps Edward can enlighten me about the use-cases for which this is ideal. I do see some use-cases, but in most cases it requires dispatch based on what the particular "v-identifier" it is anyway.
One could do better for this low-level part with registrations such as (without a BOOST_VMD_ prefix for brevity)
#define IDENTIFIER_CIRCLE (CIRCLE), #define IDENTIFIER_SQUARE (SQUARE), #define IDENTIFIER_TRIANGLE (TRIANGLE), #define IDENTIFIER_RECTANGLE (RECTANGLE),
These definitions don't allow one to directly test for specific "v-identifiers", but they do allow one to extract registered "v-identifiers" from a "v-sequence".
If all such registrations are required to be the same, there is no need for separate per-library prefixes. Macros can be defined multiple times if they are defined the same way.
Similarly, the "v-numbers" could be pre-registered by the library as
#define NUMBER_0 (0), #define NUMBER_1 (1), #define NUMBER_2 (2), // ...
I realized why the registrations have a trailing comma. Brilliant. Thanks !