Re: [boost] Re: Regexp++ 3.03: where is the type.hpp header file?

From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2001-02-04 17:44:42

Paul Selormey wrote:
> I understand the whole boost effort is about standard library.
> However, I am working currently on an MFC component, and the users
> require level 4 compilation.

I'm confused.  What's "level 4 compilation"? 

> To achieve this without extensive use of #prama(...) in the VC++6.0,
> I try to avoid the standard stuff. The regexp++ headers are included
> in my precompiled header enclosed in #prama(...).

So it seems that your particular environment requires #pragma's
around the regexp++ headers to compile. So be it; far worse workarounds
have been effected for MSVC.

> The last time I compiled the Regexp++ with the level 4 (before the
> boost effort and have reported this to you), I had over 5000 warnings!

Ah, "level 4" refers to some mode enabling lots of warnings.  Are most of
these warnings being provoked by the standard library or by the regular
expression library?

If it's from the former, complain to your vendor.   As a side note, I've
just compiled the regression test for the latter with gcc's "-Wall -W"
flags, which enables pretty much all warnings gcc knows about.  However,
that resulted in only very few warnings (mostly signed/unsigned compare).

> My humble request was for us to work with the old method of callback,
> instead of the new standard stuff.

Your desire to avoid the C++ standard library seems to indicate that the
standard headers are provoking a sizeable proportion of the warnings
you give the impression not to like.  Note, however, that boost libraries
are designed to work well with the C++ standard library and not to avoid
it at all cost.

As with all well-designed components, it is your freedom to choose
whatever interfacing strategy suits your needs best.

In the spirit of separating components with clear interfaces in between,
may I suggest you consider duplicating the standard library "std::mem_fun"
and "std::bind1st" functionality in your code so that your desire to avoid
standard headers can be honored.  STLport 4.0 (www.stlport.org) may give
hints how to implement this functionality.  Note that I personally
disapprove of this approach, because it avoids re-use.

I'm strongly opposed to specializing the current regexp++ callback
interface for the specific case of a single callback pointer.
regexp++ is large enough as-is.

(Executive summary:  Write a wrapper yourself, don't burden regexp++ with
it.)

Jens Maurer