Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| 1) add the proper 'using std::ostream' for all the objects like this
| that we use. The particular problem with ostream is that it is or
| is not in std:: depending on the header we use to declare it...
One other problem with ostream (and string for that matter) is that a
conformant implementations uses templates for these and thus you are
not allowed to use a forward declaration in your code. (e.g. class
ostream; ) Luckily this problem is easy to solve just add the correct
inlcude file instead of using the forward declaration.
| 2) define a macro STD (or maybe _std_) which is set to NULL when we do
| not want to have namespaces. A problem with this is constructs
| like
| debugbuf(streambuf * b)
| : std::streambuf(), sb(b) {}
| where the compiler (gcc 2.8.1 here) does not understand correctly
| ": ::". This means that we will have to reorder initializations or
| other non-fun (TM) stuff.
|
| Concerning using explicit namespaces and fun factor: I do not think
| that using std::string or std::ostream all over the code is much fun,
| and it seems to me that specifying 'using' in strategic places
| still provides us with namespace protection for other classes defined
| in headers. However, if Lars prefers option 2), that's OK with me.
std::string and std::ostream is not what I am talking about when
saying "fun factor", is it more that using iostream is more fun than C
i/o. Using "using" at appropriate places is of course ok.
My realy problem with "using std::ostream" in this specfic context
(debugstream) is that it pollutes the global namespace...but perhaps
that is of little concern... anyway this would not have been a problem
if we were allowed to put debugstream inside a namespace.
plain ostream is not an option (except for very short term), it must be:
using std::ostream;
ostream a;
or
std::ostream a;
Lgb
