Re: [boost] Boost.Preprocessor - Naming Help

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-10-20 00:01:53

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>

> > As some of you know, I recently added a new preprocessor data type to
the
> > preprocessor library.  I called it a "set" because it is more or less a
set

[...]

> What are the performance characteristics?
>
> Does it have an O(1) or O(log N) membership test? If not, I don't like
> "SET". Is there any reason to use LIST instead of these beasts? If
> not, maybe we should replace LIST. How many different sequence types
> do we need? I get the sense that the zoo is getting a little
> over-crowded.

What do you mean by "membership test"?  It doesn't have any analogy to a
mathematical set if that's what you're getting at.  As far as performance
goes, it is superior to lists and virtually as fast as tuples.  It is kind
of a cross between the two with some traits of each, but it does not fully
support *all* the traits of both.

As far as a comparison against lists goes, a "set" (or whatever) doesn't
directly support a nil state, so lists are still viable until C++ gets the
C99 macro rules (You can pass nothing as a macro parameter in C99.).

We don't need any more sequence types.  I made them initially to be a solid
replacement for tuples--one that doesn't need a size.  It just happens that
they are very "algorithmic" in nature, so I just gave them the same support
as lists as well.  Altogether, there are only four data types:  array, list,
tuple, and "set."  Each of them has different properties with various
overlaps.

I've been tooling around with an "includer" that uses both (for example):

#define HEADERS (..., (iostream)(iomanip)(vector)(map)(fstream))
#include ANGLED_INCLUDE()

Which basically includes all the headers in the "set."  The ... specifies
"no directory."  So you effectively get:

#include <iostream>
#include <iomanip>
#include <vector>
#include <fstream>

So, for instance:

#define HEADERS \
   ((boost/preprocessor),
(cat.hpp)(stringize.hpp)(tuple/elem.hpp)(control/if.hpp))
#include ANGLED_INCLUDE()

...effectively does this:

#include <boost/preprocessor/cat.hpp>
#include <boost/preprocessor/stringize.hpp>
#include <boost/preprocessor/tuple/elem.hpp>
#include <boost/preprocessor/control/if.hpp>

If I didn't have more than one type of structure, I'd have to put the
directory into the group of files--which I find unacceptable.  The structure
difference represents clarity as well as options.

Paul Mensonides