Re: [lmi] __WXDEBUG__ [Was: synchronizing wx and lmi for production]

[Greg Chicares]

On 2005-11-17 23:43 UTC, Vadim Zeitlin wrote:
> On Thu, 17 Nov 2005 06:58:06 +0000 Greg Chicares <address@hidden> wrote:
>
> GC> Vadim--Would you help me figure out whether we want '-D__WXDEBUG__'
> GC> for lmi?
[...]
> GC> I never use facilities like wxASSERT, wxLogDebug, or wxDebugContext.
> 
>  I never use wxDebugContext myself. I do use wxASSERT (or its equivalent in
> my own code -- but not standard assert which is too feature-poor compared
> to wxASSERT) extensively and to be honest can't imagine living without it.
> I guess you must have your reasons for not using it but I admit that I
> can't really fathom them.

I ran 'grep ASSERT' and 'wc -l * |grep total' in each of these directories:

  /wxWidgets-2.5.4/src/common
  /lmi/src/lmi

Here are the results:

  364 in 104177 lines
  400 in 100737 lines

They're almost indistinguishable. I guess our philosophies are similar
(unless the part of wx you've written has more than the average number
of assertions). Of course, wx has other, similar macros and functions;
so does lmi.

You're using wxASSERT and wxASSERT_MSG; why do I use LMI_ASSERT instead?
Mine was originally written in 1998; yours is copyright 1998 too. But I
wasn't using wx then, so I had to write my own. I could change to wx
assertions now, but I don't think there's enough benefit to justify the
cost, and I'd like to keep lmi's non-GUI versions from depending on
another library.

> GC> Some of those seem to be errors I could produce by using wx incorrectly.
> 
>  Yes, most of them are.
> 
> GC> Now I'm thinking that it would always be unwise to release a system with
> GC> those diagnostics suppressed.
> 
>  Normally you shouldn't use __WXDEBUG__ for production build because users
> usually can't use the assertions in any meaningful way. In your case it
> might be different because I presume that users have easier access to the
> developers than usual so it might make sense.

Yes, our case is different. Most of our users are in the same building.
If they see a diagnostic, they probably walk over and share it with us
right away, especially if it they don't understand it.

Moreover, conditional macros introduce some possibility that the
production and development systems behave differently. No matter how
slight that worry might be, it's better to remove it completely. And I
don't think our users would care that a GUI built without __WXDEBUG__
is a little more responsive, because financial calculations account for
most of the run time.

Thanks for the discussion. We'll continue to define __WXDEBUG__ without
exception for lmi.