|
Boost : |
From: Felipe Magno de Almeida (felipe.m.almeida_at_[hidden])
Date: 2005-04-26 00:30:44
I mean something like:
#ifndef NDEBUG
inline
#endif
log_stream &operator <<(log_stream &stream, int i)
{
#ifdef NDEBUG
code that puts the int in the stream
#endif
return stream;
}
I dont see why a compiler would be passing the stream around, mainly
with the operator being inline.
That way we dont need to use macros in the client code, that makes the
code a little ugly in my opinion...
The only problem that I see is for:
stream << "testing";
where at least in my compiler (VC7.1) these strings are shipped even
when not used... for embedded systems these strings really get the
code much bigger... As I've tried it with BREW...
On 4/26/05, Patrick Bennett <patrick.bennett_at_[hidden]> wrote:
> Felipe Magno de Almeida wrote:
>
> >couldn't a macro disable code like:
> >stream << a << b << c
> >making operator << a "do nothing" function? I dont think it will have
> >any overhead in the release code... maybe just for strings "of this
> >type" that normally isnt optimized away...
> >
> >
> Could it completely 'remove' the code? Not that I know of.
> Although, there's no reason a decent compiler wouldn't detect something
> like this (which the macro could be changed into with a 'don't compile'
> compilation option) and not emit code for it.
> if (1) ; else someStream() << a << b << c;
>
> Patrick Bennett
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
-- Felipe Magno de Almeida UIN: 2113442 email: felipe.almeida at ic unicamp br, felipe.m.almeida at gmail com, felipe at synergy com I am a C, modern C++, MFC, ODBC, Windows Services, MAPI developer from synergy, and Computer Science student from State University of Campinas(UNICAMP). To know more about: Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br current work: http://www.mintercept.com "There is no dark side of the moon really. Matter of fact it's all dark."
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk