Fundamental question about visibility

C

Casper Bang

My question is fundamental I beleive but it has been teasing me for a while:

I have two classes in my app. The first class is instantiated as a member of
my second class. Within this first class, a method (event) needs to be able
to invoke methods of the second class. With static classes its possible but
this is not desirable. There's obviouly some visibility problem I am not
familiar with. It is not a parent-child relationship since there's no
enheritance is it? (If so, something like GetParent().WantToBeCalled() would
be the right way I guess...)


class FirstClass{
public:
void TriggeringEvent(); // When this is called, invoke
WantToBeCalled of CS
};

class SecondClass{
public:
FirstClass FS;
void WantToBeCalled(); //
};

SecondClass CS;
....

What fundamental "visibility issue" haven't I understood correct? I've
looked at "export" directives and also suspect namespaces could have
something to do with it but I am getting tired or trial-and-error without
success.

Thanks in Advance,
Casper
 
W

WW

Casper said:
My question is fundamental I beleive but it has been teasing me for a
while:

I have two classes in my app. The first class is instantiated as a
member of my second class. Within this first class, a method (event)
needs to be able to invoke methods of the second class.

There are no methods in C++. There are member functions. Some people call
cirtual member functions methods, but since this meaning is not all well
known, it is not recommended to refer to C++ member functions as methods in
a C++ language discussion. Simply it can happen that people will
misunderstand. For example your example code did not contain any method for
those, who only call virtual member functions methods.
With static
classes its possible but this is not desirable. There's obviouly some
visibility problem I am not familiar with. It is not a parent-child
relationship since there's no enheritance is it? (If so, something
like GetParent().WantToBeCalled() would be the right way I guess...) [SNIP]
What fundamental "visibility issue" haven't I understood correct?
[SNIP]

No. I must say that it seems that you have not understood object oriented
design. What you wanted to do above can be done with some "tricks", but I
am not exactly sure that it has to be. Could you please describe what you
really want to do? In your code I see no concepts - not that you have no
concept, but the names of the example classes are too vague to have any idea
about what they are.
 
C

Casper Bang

There are no methods in C++. There are member functions
Yeah I remember hearing that before, however I assume when such a prototype
is illustrated within a C++ class{}construct, calling it method, function or
procedure is semantically the same and hardly relevant to my original
question.
No. I must say that it seems that you have not understood object oriented
design.
That may be partly true practically, due to a mix of programming real OO
Java and fake OO Visual Basic for 3-4 years. The hybrid paradigm C++ is thus
a completely new matter.
What you wanted to do above can be done with some "tricks", but I
am not exactly sure that it has to be. Could you please describe what you
really want to do? In your code I see no concepts - not that you have no
concept, but the names of the example classes are too vague to have any idea
about what they are.

Had I been more specfic in my example, people would criticize that this is a
ANSI C++ group not dealing with MSVC++ or the MFC library but here goes
nothing:

// Overide CWndApp, defining our main application object
// This is our "Point of entry", in that the overidden InitInstance
// method is responsible for creating window(s) etc.
class CMyApp : public CWinApp
{
public:
virtual BOOL InitInstance();
};


// Overide the CEdit class so we can capture CTRL + ENTER events
class CModifiedEdit : public CEdit
{
public:
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};


// Overide CWnd, defining our main window the application will create
class CMainWindow : public CWnd
{
public:
CMainWindow();
void OnParseMe();
CModifiedEdit m_wndEdit;
};


Within CMyApp the CMainWindow is instantiated. CMainWindow has member
function ::OnKeyDown() which will be fired (event callback) sooner or later.
When this happens, I am interested in calling the member funtion
CMainWindow::OnParseMe()

Hope this helps,
Casper
 
W

WW

Casper said:
Yeah I remember hearing that before, however I assume when such a
prototype is illustrated within a C++ class{}construct, calling it
method, function or procedure is semantically the same and hardly
relevant to my original question.

It is not relevant to the queston, but he way you have asked it. :)
That may be partly true practically, due to a mix of programming real
OO Java and fake OO Visual Basic for 3-4 years. The hybrid paradigm
C++ is thus a completely new matter.

May I suggest you getting hold of (once you have mastered C++ fundmentals)
the book with the title Multi-Paradigm DESING for C++ from Coplien?
Had I been more specfic in my example, people would criticize that
this is a ANSI C++ group not dealing with MSVC++ or the MFC library
but here goes nothing:
;-)

// Overide CWndApp, defining our main application object
// This is our "Point of entry", in that the overidden InitInstance
// method is responsible for creating window(s) etc.
class CMyApp : public CWinApp
{
public:
virtual BOOL InitInstance();
};


// Overide the CEdit class so we can capture CTRL + ENTER events
class CModifiedEdit : public CEdit
{
public:
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};


// Overide CWnd, defining our main window the application will create
class CMainWindow : public CWnd
{
public:
CMainWindow();
void OnParseMe();
CModifiedEdit m_wndEdit;
};


Within CMyApp the CMainWindow is instantiated. CMainWindow has member
function ::OnKeyDown() which will be fired (event callback) sooner or
later. When this happens, I am interested in calling the member
funtion CMainWindow::OnParseMe()

Hmmm. That seems to be a flow in the MFC design. The edit control does
knwow it very well what Window owns it (parent) but it seems it has no way
to get the C++ object belonging to that Window. Is that true? Are you sure
you are unable to ask MFC to give you the parent C++ object? If this is so
the only easy C++ thing I can imagine is to add a non-default constructor to
CModifiedEdit taking a pointer to its parent C++ object and initialize it on
the initializer list of the CMainWindow constructor:

class CMainWindow;

// Overide the CEdit class so we can capture CTRL + ENTER events
class CModifiedEdit : public CEdit
{
CMainWindow *parent;
public:
CModifiedEdit(CMainWindow *mamma) : parent(mamma) { ; }
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};


// Somewhere in a CModifiedEdit.cpp, far far away
// or int the CModifiedEdit.h after the class declaration and
// including CMainWindow.h to enable inlining
// (don't forget header guards!):
afx_msg void CModifiedEdit::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
// Do whatever
parent->OnParseMe();
}



// Overide CWnd, defining our main window the application will create
class CMainWindow : public CWnd
{
public:
CMainWindow();
void OnParseMe();
CModifiedEdit m_wndEdit;
};

CMainWindow::CMainWindow():m_wndEdit(this) {
// The rest
}

===

<OT>
And of course there is a Windows Way[TM]. Bind the execution of OnParseMe()
to a user defined Windows Message. In that way anyone knowing the main
window handle will be able to ask it to reparse using a SendMessage
(synchronous) or Postmessage (asynchronous).
</OT>
 
R

red floyd

Casper said:
[redacted]
Within CMyApp the CMainWindow is instantiated. CMainWindow has member
function ::OnKeyDown() which will be fired (event callback) sooner or later.
When this happens, I am interested in calling the member funtion
CMainWindow::OnParseMe()

void CMainWindow::OnKeyDown(/* params */)
{
OnParseMe();
}
 
W

WW

WW wrote:
[SNIP]
Update
// Overide the CEdit class so we can capture CTRL + ENTER events
class CModifiedEdit : public CEdit
{
CMainWindow *parent;

Here I hope a *lot* that CEdit does have a virtual destructor. In our case
it does not really matter (there is no descruction for a pointer and Windows
will release the memory properly) but according to Standard C++ it is better
be there. (Also in your code CMainWindow will always destroy CModifiedEdit
as CModifiedEdit, but later if you go dynamic about the GUI it might not be
the case.)
public:
CModifiedEdit(CMainWindow *mamma) : parent(mamma) { ; }
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};
[SNIP]
 
W

WW

red said:
Casper said:
[redacted]
Within CMyApp the CMainWindow is instantiated. CMainWindow has member
function ::OnKeyDown() which will be fired (event callback) sooner
or later. When this happens, I am interested in calling the member
funtion CMainWindow::OnParseMe()

void CMainWindow::OnKeyDown(/* params */)
{
OnParseMe();
}

Please indent your source code when posted here.

And no, not really. Doing this will distort OOD, where it is said: every
class is responsible for itself. In your case you would put all the
knowledge of the required operations into the Window, which then would need
to "work externally" on the edit control object. Unless of course you are
intended to use the Chain of Responsibility pattern, and you have meant that
the edit control class will do whatever it needs to and then signal to MFC
that it has to still pass the message up to the onwer as well. While this
approach may be sufficient in many case it has the drawback of possibly
using heavier machinery for the task delegation and also that whatever the
main window does *must* be done *after* what the edit control does.

<OT>
Unless of course MFC supports delegating to the owner (and returning) at any
point in the message handler - but that is off-topic here. BTW I don't know
if I did (I guess I did) mention this in my reply to the OP, but IMHO since
it is MFC the best would be to find an "MFC way" and check MSDN or whatever
to see if the edit control can "know" about its parent.
</OT>

As far as I understood the OPs intention was that it is the edit control who
knows when to parsem so that the main window does not need to know a change
in which control should trigger a parse and which is not. So IMO this means
that it is not enough to delegate message handling. Since in this case the
main window would always need to look at the message and ask itself: why the
heck did I get this, what should I do? It seems to be a cleaner desing if
the edit control (via Windows messages or C++ member function calls) would
ask definitely what it wants. And that is not "I had a key pressed", but "I
want you to parse".
 
J

jeffc

Casper Bang said:
Yeah I remember hearing that before, however I assume when such a prototype
is illustrated within a C++ class{}construct, calling it method, function or
procedure is semantically the same and hardly relevant to my original
question.

C'mon Casper, don't expect reason and common sense to hold back the wall of
flames....
Had I been more specfic in my example, people would criticize that this is a
ANSI C++ group not dealing with MSVC++ or the MFC library...

Of course - then you would have gotten no answer at all.
 
W

WW

jeffc said:
Of course - then you would have gotten no answer at all.

I start to recall why did I killfile you once already. If you did care to
look at the thread you would see that it is old news. Not only he has got
an answer but it seems he was happy with it.
 
J

jeffc

WW said:
I start to recall why did I killfile you once already. If you did care to
look at the thread you would see that it is old news. Not only he has got
an answer but it seems he was happy with it.

Oh, you mean like when the guy asked "My question is where is the correct
(and best way) to initialize [static class member] variables?" and you
replied "Your question is Windows (DLL) specific." simply because he
mentioned he was writing a Windows DLL?
 
J

jeffc

WW said:
Please, if you *know* what method means in the realm of the C++ language...
by all means, post it here!

I'll let you read about it "The C++ Programming Language" by Bjarne
Stroustrup. In the meantime, if you can possibly be any more pedantic,
please do. It would amaze me.
 
W

WW

jeffc said:
WW said:
I start to recall why did I killfile you once already. If you did
care to look at the thread you would see that it is old news. Not
only he has got an answer but it seems he was happy with it.

Oh, you mean like when the guy asked "My question is where is the
correct (and best way) to initialize [static class member]
variables?" and you replied "Your question is Windows (DLL)
specific." simply because he mentioned he was writing a Windows DLL?

Quit trolling. Look at the original post there. He uses the standard way
to initialize the members but it does not happen. At least that what he
says.
 
C

Casper Bang

Adding custom constructors for passing of desired objects works but is not
exactly an elegant solution.
I solved it with the suspected GetParent call:

((<DerivedClass>)GetParent()).<MemberName>
^
Returns base class!

....but I had to cast to the overidden class and NOT rely on C++ to know
this! I would've thought GetParent pointed to the new class and not the old
but maybe this is simply a MFC specific twist. One more lesson learned!

Thanks for the feedback,
Casper

----------

WW said:
WW wrote:
[SNIP]
Update
// Overide the CEdit class so we can capture CTRL + ENTER events
class CModifiedEdit : public CEdit
{
CMainWindow *parent;

Here I hope a *lot* that CEdit does have a virtual destructor. In our case
it does not really matter (there is no descruction for a pointer and Windows
will release the memory properly) but according to Standard C++ it is better
be there. (Also in your code CMainWindow will always destroy CModifiedEdit
as CModifiedEdit, but later if you go dynamic about the GUI it might not be
the case.)
public:
CModifiedEdit(CMainWindow *mamma) : parent(mamma) { ; }
afx_msg void OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags);
};
[SNIP]
 
W

WW

jeffc said:
I'll let you read about it "The C++ Programming Language" by Bjarne
Stroustrup. In the meantime, if you can possibly be any more
pedantic, please do. It would amaze me.

You mean the quote that some people, sometimes may call virtual member
functions methods? A very widely accepted definition. See the original
post of this thread.

If you choose to use a vague and confusing term (with no exact definition)
by all means do it. But then do not wonder if people think you are not here
to help. BTW as it happens it is not only me who thinks that it is not the
luckiest thing to use the non-existing C++ term method in C++ discussion.
Steve Dewhurts's (not so) new book just says the same. Conincidence that a
co-worker of Bjarne Stroutrup, the lead designer and implementer of the
first non-cfront C++ compiler, former principal on the ANSI/ISO C++
standardization committee happens to have the same opinion? Maybe. Maybe
he just happened to eat somewhere the same poisoned food I did. But I beg
to think otherwise.
 
W

WW

Casper said:
Adding custom constructors for passing of desired objects works but
is not exactly an elegant solution.
I solved it with the suspected GetParent call:

((<DerivedClass>)GetParent()).<MemberName>
^
Returns base class!

...but I had to cast to the overidden class and NOT rely on C++ to
know this! I would've thought GetParent pointed to the new class and
not the old but maybe this is simply a MFC specific twist. One more
lesson learned!

Don't top post! I will not suggest using templates to someone possibly
using VC++ 6.0.
 
J

jeffc

WW said:
You mean the quote that some people, sometimes may call virtual member
functions methods? A very widely accepted definition. See the original
post of this thread.

I don't need to look past the post that said "There are no methods in C++."
If you choose to use a vague and confusing term (with no exact definition)
by all means do it. But then do not wonder if people think you are not here
to help.

Riiiiiiight, Mr. Pedant. No one had a problem with the OP's question except
you. Now, who wasn't here to help, but to display his dictionary knowledge
of the C++ language?
 
S

Shane Beasley

WW said:
Please, if you *know* what method means in the realm of the C++ language...
by all means, post it here!

<http://www.nightflight.com/foldoc-bin/foldoc.cgi?method>

"The name given in Smalltalk and other object-oriented languages to a
procedure or routine associated with one or more classes. An object of
a certain class knows how to perform actions, e.g. printing itself or
creating a new instance of itself, rather than the function (e.g.
printing) knowing how to handle different types of object."

Sounds like a virtual function to me. Actually, FOLDOC also mentions
the concept of a "class method" -- that's a static member function, of
course.

Given this, one might say that it is incorrect to use "method" to
describe a non-virtual member function, although I have yet to find
any such use to be confusing or misleading, so I don't even bother
bringing that up. I might almost mention it if a non-member function
were called a method, though.

- Shane
 
W

WW

jeffc said:
I don't need to look past the post that said "There are no methods in
C++."

Again: you refer to TC++PL for what method means. That says: *some* call
virtual member functions methods. My proof: look at what the OPs original
post and realise that he was *not* using method in the sense Mr. Stroustrup
says *some* (apparently other) people do.

Stop trolling.
Riiiiiiight, Mr. Pedant.

Please read my name Mr. Infantile. It is not Mr. Pedant. Stop trolling.
No one had a problem with the OP's question
except you.

I had no problem with the question. I have answered it. Stop trolling.
Now, who wasn't here to help, but to display his
dictionary knowledge of the C++ language?

And what are you here for? To get into every thread and try to attack me
because you think it is cool? Stop trolling. You help none, on the
contrary.

BTW NICE SNIPPING! How come you have snipped out that Steve Dewhurst's book
(C++ Gothcas) exactly my advice: do not use the word method in C++
discussions? Ah. Because that was showing that all you do is troll to
practice your ego.

The OP had no problem with my advice. The OP was (instead of you) showing
no attitude and has got answer to his questions. So why don't you get lost
for ever? It is clear you do not have the mental capacity to help, so you
troll. No need for that. Find another place where you can scream and
wallow on the ground to get into the center of attention. Stop trolling.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top