unused varibles in manager.cpp - wxAUI

[Michael]

Hello,

I have remarked when compiling the wxAUI project that some variables in the manager.cpp are unused:

-------------- Build: wxAUI in Code::Blocks (wx2.6) ---------------
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DTIXML_USE_STL -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE -D__GNUWIN32__ -DWIN32 -DWXUSINGDLL  -IC:\Programme\DANAE\CodeBlocks\CodeBlocks\wx\include -IC:\Programme\DANAE\CodeBlocks\CodeBlocks\wx\lib\gcc_dll\mswu -IC:\Programme\DANAE\CodeBlocks\CodeBlocks\wx\lib\gcc_dll\mswu -IC:\Programme\DANAE\CodeBlocks\CodeBlocks\wx\contrib\include -Isdk\wxscintilla\include -Isdk\propgrid\include -Isrc\wxAUI -IC:\Programme\Resource\C++\CB_10jan2006_rev1707_win32\include  -c src\wxAUI\manager.cpp -o .objs\2.6\src\wxAUI\manager.o
src\wxAUI\manager.cpp: In member function `void wxFrameManager::LayoutAddDock(wxSizer*, wxDockInfo&, wxDockUIPartArray&, bool)':
src\wxAUI\manager.cpp:1784: warning: unused variable 'space_left'
src\wxAUI\manager.cpp: In member function `wxSizer* wxFrameManager::LayoutAll(wxPaneInfoArray&, wxDockInfoArray&, wxDockUIPartArray&, bool)':
src\wxAUI\manager.cpp:2146: warning: unused variable 'top'
src\wxAUI\manager.cpp:2148: warning: unused variable 'bottom'
src\wxAUI\manager.cpp: In member function `void wxFrameManager::OnFloatingPaneActivated(wxWindow*)':
src\wxAUI\manager.cpp:3314: warning: unused variable 'pane'
src\wxAUI\manager.cpp: In member function `void wxFrameManager::Render(wxDC*)':
src\wxAUI\manager.cpp:3338: warning: unused variable 'pane_state'
ar.exe -r src\wxAUI\libwxaui.a .objs\2.6\src\wxAUI\manager.o
ranlib src\wxAUI\libwxaui.a

Are these variables kept for a further use/re-use or could be deleted without consequences?

Michael

[killerbot]

I think they can all go, they drive me crazy. I don't like warnings. I think one is the result of an assignement from a function call.
Dunno if that function call can also go, maybe it alters some state and is needed, bu then don't assign it's return value, or check it to do something usefull with it.

devs .......

Cheers,
Lieven

[280Z28]

http://www.kirix.com/en/community/forums/viewtopic.php?t=39



Obviously I wouldn't expect you to have seen this, I'm just saying it's been taken care of at the source and we shouldn't run into that again.

[killerbot]

but the the devs need to update ;-)

[Michael]

Hmm. Strange. The patch just lists 4 variables, but I also get the variable pane as unused:

src\wxAUI\manager.cpp: In member function `void wxFrameManager::OnFloatingPaneActivated(wxWindow*)':
src\wxAUI\manager.cpp:3314: warning: unused variable 'pane'

Anyway, I am not sure that it is unused:

Code

void wxFrameManager::OnFloatingPaneActivated(wxWindow* wnd)
{
    if (GetFlags() & wxAUI_MGR_ALLOW_ACTIVE_PANE)
    {
        // try to find the pane
        wxPaneInfo& pane = GetPane(wnd);
        wxASSERT_MSG(pane.IsOk(), wxT("Pane window not found"));

        SetActivePane(m_panes, wnd);
        Repaint();
    }
}

Michael

[Der Meister]

This depends on the macro wxASSERT_MSG. According to the wxWidgets documentation wxASSERT (and all other wxASSERT_* macros) is replaced with nothing in release mode and thus the variable pane in this example is only used in Debug-Mode. Thus I would leave it even if it brings up a warning in release mode.

Just another thing: I don't know the code and this it might be even correct but to me it looks a bit strange that 'SetActivePane' uses 'm_panes' and not 'pane'. Is this really correct this way? And is the call to GetPane really necessary then?

[280Z28]

You could wrap it in #ifdef DEBUG

Code::Blocks really doesn't like having wxWidgets in debug mode

[killerbot]

I agree, ifdef around it (don't like those though).
There should be NO warnings, whatever build, debug or release o ..

[Michael]

Just another thing: I don't know the code and this it might be even correct but to me it looks a bit strange that 'SetActivePane' uses 'm_panes' and not 'pane'. Is this really correct this way? And is the call to GetPane really necessary then?

I am not sure about it. m_panes is defined in the manager.h file:

Code

private:

    wxFrame* m_frame;            // the frame being managed
    wxDockArt* m_art;            // dock art object which does all drawing
    unsigned int m_flags;        // manager flags wxAUI_MGR_*

    wxPaneInfoArray m_panes;     // array of panes structures

m_panes is also used in other functions (manager.cpp).

Michael
 

[280Z28]

I suggest you post this at the Kirix forums so the author can give feedback on this too.

[mandrav]

Code::Blocks really doesn't like having wxWidgets in debug mode

And what exactly does that mean Sam? What does C::B has to do with wxASSERT_MSG() and the fact that it expands to nothing when in release mode?

[280Z28]

Code::Blocks really doesn't like having wxWidgets in debug mode

And what exactly does that mean Sam? What does C::B has to do with wxASSERT_MSG() and the fact that it expands to nothing when in release mode?

It throws a TON of assertions, so many that you can't get very far into the program before it's just too much to write them down. I put a patch on SF that gets rid of some but not all of them.

https://sourceforge.net/tracker/index.php?func=detail&aid=1400615&group_id=126998&atid=707418

I'm talking about having the wxWidgets library itself in debug mode, so all the wxASSERT_MSG() calls in it start popping up. Not the ones in the C::B code.

[Game_Ender]

It throws a TON of assertions, so many that you can't get very far into the program before it's just too much to write them down. I put a patch on SF that gets rid of some but not all of them.

https://sourceforge.net/tracker/index.php?func=detail&aid=1400615&group_id=126998&atid=707418

I'm talking about having the wxWidgets library itself in debug mode, so all the wxASSERT_MSG() calls in it start popping up. Not the ones in the C::B code.

Isn't it standard development progress to always be running against the debug libraries?  Then when ready for final compile against the release builds?  Although I admit this can be hard because it looks like codeblocks project wasn't set up with this kind of development in mind.

As a wxWidges dev myself It can be hard.  I have been doing a developing a wxWidgets based projects for several months before I finally took the time to get the debug build compiled and installed.  Although with the intermittent stability issues Code::Blocks (at least on linux) has doing this more often sounds like a good idea.  On Monday I will compile the SVN version against wxGTK 2.6 dbg and see what I get.

EDIT: Make that the codeblocks project file, not the project itself.

[Michael]

I suggest you post this at the Kirix forums so the author can give feedback on this too.

I followed your advice and here is the answer from bwilliams:

Yeah, the code is correct. I suppose the check to make sure the pane exists is a bit padentic, so I'll take care of the problem by removing the unnecessary code.

Michael