Re: [boost] Boost.Preprocessor - Naming Help

From: David Abrahams (dave_at_[hidden])
Date: 2002-10-29 00:50:47

"Paul Mensonides" <pmenso57_at_[hidden]> writes:

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

It is.

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

"VECTOR"?

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

Ah, then by analogy to C++ types it should be called "ARRAY" ;-)
And ARRAY should be called "VECTOR".

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

Yikes! How does ... turn into nothing here?

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

That's too cool!

-- 
                    David Abrahams
dave_at_[hidden] * http://www.boost-consulting.com