[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Greg Chicares
Subject: [lmi] __WXDEBUG__ [Was: synchronizing wx and lmi for production]
Date: Thu, 17 Nov 2005 06:58:06 +0000
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

Way back on 2005-8-17 9:10 UTC, Vadim Zeitlin wrote:
> On Tue, 16 Aug 2005 21:45:34 -0500 Wendy Boutin <address@hidden> wrote:
> WB> Is there a real benefit to using the "debug" version versus the "release"
> WB> version. It seems as though the debug file is 625% bigger than the release
> WB> one:
> WB> 47957kb  wxmsw26d_gcc_custom.dll
> WB>  7675kb  wxmsw26_gcc_custom.dll

Vadim--Would you help me figure out whether we want '-D__WXDEBUG__'
for lmi? I think Wendy's earlier question concerned 'gcc -g', which
is different from the question I'd like to ask here.

>  Yes, gcc produces huge executables with debug.

I believe it's '-g' that makes binaries huge.

> But using it still makes
> sense because in debug build you get many checks (asserts) which help you
> to detect the situations when you use the library in an invalid way.

Here I think you're speaking of __WXDEBUG__.

>  In principle, it's possible to compile with __WXDEBUG__ defined (so that
> you get asserts) but without -g and with -O but you'd need to manually set
> up C[XX]FLAGS for this and IMHO it's not worth it.

I never use facilities like wxASSERT, wxLogDebug, or wxDebugContext.
I very rarely get memory-allocation errors. I rarely use a debugger.
The documentation seems to suggest that I might not want __WXDEBUG__.

But I have sometimes seen messages from wx when I try to do something
that doesn't make sense. Unfortunately, I can't remember anything
about the messages I have seen, except that I was very glad to get
them and they saved me a lot of time. So I grepped the wx source and
found things like this:

    wxASSERT_MSG( m_frozenness > 0, _T("Thaw() without matching Freeze()") );

    // this function should not be called for wxCB_READONLY controls, it is
    // the callers responsability to check this
    wxASSERT_MSG( !(GetWindowStyle() & wxCB_READONLY),
                  _T("read-only combobox doesn't have any edit control") );

    wxASSERT_MSG( !IsModal(), _T("wxDialog::ShowModal() reentered?") );
    wxASSERT_MSG( IsModal(), _T("EndModal() called for non modal dialog") );

    wxASSERT_MSG( (0 < month) && (month <= 12), _T("invalid month") );

Some of those seem to be errors I could produce by using wx incorrectly.
Now I'm thinking that it would always be unwise to release a system with
those diagnostics suppressed. Why would anyone not define __WXDEBUG__
all the time? Or, alternatively, why do these safety features not use
wxCHECK_MSG? I feel like I'm missing something.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]