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@inin.com> 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."