Isolating dependencies in header files

From: Paul Hollingsworth (boost_at_[hidden])
Date: 2000-10-05 10:47:06

How do people deal with the following problem:

I might have some class that uses std::vector:

fast_string.h:

#include <vector>

class fast_string
{
        std::vector<char> chars_;
        public:
        // None of the arguments to the public
        // methods depend on vector
};

This has the effect that when somebody #includes "fast_string.h", they end
up also importing the definition of  std::vector. The problem being, it
becomes very easy for them to then write code like this:

#include "fast_string.h"

std::vector g_vector; // Compiles, but ideally it wouldn't unless they've
also included <vector>

The problem with this of course is that you can no longer change
fast_string.h at a later date to use something else besides std::vector. Or
at least, you can, but you couldn't remove the #include <vector> even after
it becomes unrelated.

Ideally, it would be nice if there was some way of writing fast_string.h so
that the above code fragment failed to compile.

One solution I thought might work would be:

namespace impl {
#include <vector>
}

class fast_string
{
        impl::std::vector<char> chars_;
        public:
        // rest of methods
};

But unfortunately this fails to compile on VC++ STL because it has code like
the following:

class exception {
};

namespace std {
        // assumption that exception is defined in the global namespace
        using ::exception
}

I'm know that <vector> shouldn't be adding <exception> to the global
namespace anyway (it's probably some backwards compatibility solution), but
I wonder whether the above "trick" _should_ work with a fully compliant STL?

That is, according to the ANSI/ISO standard, should you be able to use this
trick?

I'm aware of handle classes and/or using abstract base classes - but these
solutions carry a performance penalty and do not work for templates anyway.

Ideally, it would be possible to distribute code for template libraries
solely as header files, while at the same time not revealing any
implementation details of said template library... Oh, and of course, VC++
does not support the 'export' keyword, so that is not a solution either in
this case.

So, are there any other cool tricks that can be brought to bear on this
problem?

Paul Hollingsworth
http://PaulHollingsworth.com