On Tue, Mar 24, 2009 at 4:11 PM, Caleb <caleb.epst...@gmail.com> wrote: > > On Mar 23, 7:16 pm, Kenton Varda <ken...@google.com> wrote: > >> BTW, you should always compile with -DNDEBUG unless you are building a debug >> build. It strips out several debug checks which makes things faster. > > Note that 'NDEBUG' isnt' a Google-ism, its a Standard C-ism. It > disables the assert() macro, removing all assertions from your code. > This is generally good practice for production code, but just be > careful that you're not doing anything with assert() that has side > effects you depend on, like > > assert (++i < 100); > > or something silly like that. Never been bit by this myself, but I've > seen it bite others...
Going off topic a little, but it is debatable whether assertions should be disabled in production code. Disabling them doesn't make incorrect code suddenly become correct. It just disguises the failure by making the application behave in potentially *very* wonky ways (which can include everything up to losing/destroying/corrupting data). On the other hand, if assertions remain enabled, you will get a clean, clinical crash when something unexpected happens. Much easier to debug than a tiny subtle data corruption that happened two weeks ago and snowballed up to the point where someone noticed. At Google, 99% of assertions remain enabled at all times. There are some nuances (as always, mindless dogma gets you nowhere), but in general, if it should crash during testing, it should also crash in production. The alternative is entering the forbidden realm of undefined/unpredictable behavior. We really much prefer to debug a clean crash with a traceback at the error site, rather than sieving through weirdness after the fact. Of course, this policy is supplemented by a heavy focus on automated testing at all granularities, a focus on designing fault tolerant software to reduce the impact of a single server crashing, and a lot of caution (ie. canaries) when upgrading production systems. Such a policy can't work sanely if your release procedure is "It compiles? Update the production servers!" So, the question you need to ask yourself: why is it acceptable, when something unexpected happens, to silently corrupt data and state in production and not in testing? In most cases, I find that the answer is "it is not. Keep the checks." My 2¢ :-) - Dave > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---