On Wed, Nov 28, 2007 at 06:34:20AM +0200, Martin Vermeer wrote:
> On Tue, Nov 27, 2007 at 10:25:36PM +0100, Andre Poenitz wrote:
> > On Tue, Nov 27, 2007 at 08:54:07PM +0100, Andre Poenitz wrote:
> > >
> > > > bash ../development/tools/count_lines_of_included_code.sh debug.h
> > > debug.h : 30091
> > >
> > > ;-(
> >
> > Using something "handcrafted" along the lines of
> >
> > struct LyXErr {
> > bool debugging(Debug::type t = Debug::ANY) const;
> > void endl();
> > };
> >
> > LyXErr & operator<<(LyXErr &, const char *);
> > LyXErr & operator<<(LyXErr &, char);
> > LyXErr & operator<<(LyXErr &, int);
> > LyXErr & operator<<(LyXErr &, double);
> > LyXErr & operator<<(LyXErr &, std::string const &);
> > LyXErr & operator<<(LyXErr &, docstring const &);
> > LyXErr & operator<<(LyXErr &, support::FileName const &);
> > LyXErr & operator<<(LyXErr &, std::ostream &(*)(std::ostream &));
> > [... possibly a few more added, no #include, though]
> >
> > extern LyXErr lyxerr;
> >
> > #define LYXERR(type, msg) \
> > do { \
> > if (!lyx::lyxerr.debugging(type)) {} \
> > else { lyx::lyxerr << msg; lyxerr.endl(); } \
> > } while (0)
> >
> >
> > instead of the current std::ostream/boost::nullstream based solution
> > would cut down total compiled lines from currently 17.9 Mio to 17.0
> > Mio, i.e. reduce compilation effort by almost exactly 5%.
> >
> > Note that this would also allow us to "magically" pipe "unmodified"
> > std::strings and docstrings into the same "stream" and therefore
> > simplify the calling code by removing the need for 170 (rough
> > guesstimate by grep -R -i -A2 lyxerr | grep to_utf8 | grep -v svn | wc)
> > 'to_utf8' calls in the code.
> >
> > Sounds interesting?
> >
> > Andre'
>
> What's the catch?
It's not a 'proper std::ostream' but a thin wrapper around one. Purist
will hate it as this means that third party classes implementing a
ostream & operator<<(ostream &, ThirdPartyStuff const &)
would not magically work (at least not after the second '<<' in
a statement. [For the first occurence in an expression it does
if we have a LyXErr::operator ostream&() which already exists
in my tree...]
Of course one might argue that LyXErr is not exactly in widespread use
among third party developers so this would not be a real restriction...
Andre'
