Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| For the streams in <ostreams>, we now in DebugStream.h which ones are
| needed. So I guess it is all or nothing.
s/now/know ?
Yes I think you are right.
| Lars> And to whom would the "definitions [be] much cleaner" ?
|
| I mean that if everytime we use <ostreams> we need 15 lines of
| error prone preprocessor stuff, the fun factor will tend to go low. At
| first I thought that we would use these << operators only on a
| DebugStream, so just including "debug.h" would setup everything nicely
| for us. If you really plan to send them to real streams, then I agree
| we should think of something else.
That is the nice thing of useing
ostream & operator<<(ostream &, <foo>);
We don't need to know what types of ostreams we are writing to, this
will fit nicely into _any_ ostream. Even if we only use this for
DebugStream now, we might use it for the .lyx file later.
| Now that I think of it, after "debug.h" is included, we are guaranteed
| that ostream can be accessed directly, right?
Yes, in close to all cases. I think you can assume so.
| Lars> | (BTW, why does DebugStream.C include | debug.h and not
| Lars> DebugStream.h?)
|
| Lars> Because of the struct Debug, which is not LyX specific. Every
| Lars> application that uses DebugStream needs to have Debug::types
| Lars> defined.
|
| This is not very clean, IMO. Isn't this a case where we should define
| DebugStream as a template?
No, I don't think so... A template could be used, but then you require
Debug to be a struct and do not allow it to be a namespace.
I am also not very satisfied by the current solution, but I don't see
any other nice solution. The nice thing about the current solution is
that DebugStream does not need to know anything abut Debug::type, it
only need to exist at be a binary(?) enum. What I originally wanted
was something like:
namespace Debug {
enum type {
no_err = 0,
err1 = 1,
err2 = 2,
err3 = 4,
...
}
}
class DebugStream {
DebugStream(Debug::type a);
};
The DebugStream does require a Debug::type to be existant, but does not
need to know anything about it. The Debug::type is application
specific the DebugStream is not. This means to me that DebugStream.h
should not put any demands on where the Debug::type is defined. So
currently this is the layout:
debug.h: contains the Debug::type and includes the DebugStream.h
DebugStream.C: includes debug.h (and this is what I think is dirty
but I don't have a good solution.)
Of course we could have a requirement on applications using
DebugStream that the must have a header "debug.h" that defines the
Debug::type. That would clean up the '#include "debug.h"' in the
DebugStream.C file, but then all files now including "debug.h" must
include "DebugStream.h" instead which also is not very clean...and you
get into a problem on where do declare lyxerr.
| Lars> This is depricated in the C++ standard and has also nothing to
| Lars> do with Cinlcudes. The old header for iostreams was <iostream.h>
| Lars> and the new one is <iostream> They are not equivalent in the
| Lars> same way as <type.h> and <ctype> is.
|
| Yes, I understand that... So, your point is that we do not even try to
| support istreams.hxx (which seems to be old-style Dec, I do not see
| whether others used that too), right?
the iostreams in <iostream.h> are quite similar to the one in
<iostream> so in a lot of cases they can be used interchangable. F.ex.
Gcc 2.95 has now a <iostream> header that just uses the old
<iostream.h> implementation, but they are workign hard on making a
real std::iostream.
Lgb
