Re: [Audacity-devel] Possible erroneous ASSERT in TrackPanel.cpp

[Bruce E. <Bruce@EckelObjects.com>]

Thanks for the nice plug.

I too have begun forgetting some of the arcane (but necessary)
details of the language. The spectrum from C++ to Java to Python is
dramatic, and educational!

Most current information can be found at:
http://www.mindview.net/Etc/notes.html
===================
Bruce Eckel    http://www.BruceEckel.com
Contains free electronic books: "Thinking in Java 2e" & "Thinking
in C++ 2e"
Please subscribe to my free newsletter -- just send any email to:
joi...@ea...
My schedule can be found at:
http://www.mindview.net/Calendar
===================

*********** REPLY SEPARATOR ***********

On 5/8/2002 at 1:26 PM bf...@ew... wrote:
At 5:41 pm -0400 7/5/02, Shane Mueller wrote:
On Tue, 2002-05-07 at 14:43, ewitness - Ben Fowler wrote:
> Tell me also if this is an appropriate post to this list.
It would be marginally easier if the patch was an attachment

Will do. Actually I would have sent the patch only to the
maintainer
of that file/module, had I known whom


> This file also has 7 warnings that a virtual function is hidden.
>
> Should these functions be either re-named or properly made
> virtual to eliminate these warnings, and the possiblility of
> programming mishaps occurring through their existence?

For my personal education, could you (or someone) please give me
the
2-minute "Intro to C++" lesson on a) What this means, b) Why it is
bad,
and c) How to avoid it? Thanks.


If you are asking for something concise, id est brief as well as
accurate, you would do well to study The Mozilla Guidelines at
<URL: http://www.mozilla.org/hacking/portable-cpp.html >, though
some of these are stricter than usually needed, and there some
things that I would still regard as optional. This page is also
mentioned in the wxWindows Programming Standards document
<URL: http://www.wxwindows.org/standard.htm  >. The standard medium
level Introduction to C++ is 'Thinking in C++' by Bruce Eckel
<URL: http://www.ibiblio.org/pub/docs/books/eckel/ > and
<URL: http://www.mindview.net/Books/TICPP/ThinkingInCPP2e.html >
and
<URL: http://www.maththinking.com/boat/languageBooks.html >.
This book is very strongly recommended. There is a list of style
guides at <URL: http://www.literateprogramming.com/pstyle.html >
THE FAQ is at <URL: http://www.parashift.com/c++-faq-lite/ >


The note about the current issue is at
<URL:
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-2
3.5 >


If you have never seen an accurate account of this problem, it
is no fault of your own, and possibly not even your teachers. This
issue is far from well publicised. (Try to find an alternative,
authoritative mention of it anywhere else on the net, if you
find that hard to accept).


(Arguably, this is the kind of thing that gives C++ a bad name:
it has too many warts and misfeatures for all but the brainest
people to rememember...).


See also Stroustrup 'The Design & Evolution of C++' 3.5.3
<URL: http://www.research.att.com/~bs/dne.html >


At best your code is harder to read/understand than it need
be (though the compiler will get it right).


The problem is that in class TrackPanel,
   virtual bool DoPopupMenu( wxMenu *menu, int x, int y )
is now not visible, so you could not call it without a scope
resolution operator. In the general case, this may mean that
a base class function is called when you expected a derived class
one, or to put it concisely, the run-time dispatching of the
correct
member function based on type of object is not available.


I don't think that it is any more bad than that, but the C++ author
seems to think that it is. After all, it is a warning rather than
error...


Assuming that you actaully are happy for the the Base
wxWindow::DoPopupMenu( )
to be called if your class were ever called (through a wxWindow
pointer) on to carry out a
    virtual bool DoPopupMenu( wxMenu *menu, int x, int y )
method, then you can repair your code by adding these lines
to the private part of class definition:


    // unhide wxWindow::DoPopupMenu( )
    bool DoPopupMenu( wxMenu *menu, int x, int y ) { return
wxWindow::DoPopupMenu( menu, x, y ); };

Alternatively, if the PopUp operation in TrackPanel is different
in kind rather than quality than the same named operation in a
basic wxWindow (& it is curious as to where it gets its extra
input data from), why not give it a different name, videlicet:


    bool DoTrackPopupMenu( wxMouseEvent & event, wxRect &
titleRect, VTrack * t, wxRect & r, int num )


Arguably, this warning is pointing you to check your design and/or
documentation and/or comments, rather than the code.


This feature of C++ is a little controversial,


If you really do mean to hide the function, I don't know of a C++
idiom
to notify the compiler that you don't need this warning, that you
intentionally
hid the name. The simplest way round the the problem is (with
modern compilers)
to use the using declaration, which unhides the name, and I would
guess
would enable the compiler to warn you if anything else went wrong,
I
appreciate that in such a case I am recommending you in the
interests of simplicity
and brevity to do the opposite of what you might have wished, but
simplicity
and brevity whilsy not necessarily members of the famous three
virtues
of programmers are pretty handy in the C++ world.


Ben.