By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,978 Members | 1,831 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,978 IT Pros & Developers. It's quick & easy.

Fundamental question about visibility

P: n/a
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
Jul 19 '05 #1
Share this Question
Share on Google+
51 Replies


P: n/a
WW
Casper Bang wrote:
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.

--
WW aka Attila
Jul 19 '05 #2

P: n/a
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
Jul 19 '05 #3

P: n/a
WW
Casper Bang wrote:
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.


It is not relevant to the queston, but he way you have asked it. :-)
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.


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>

--
WW aka Attila
Jul 19 '05 #4

P: n/a
Casper Bang wrote:
[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();
}

Jul 19 '05 #5

P: n/a
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]
--
WW aka Attila
Jul 19 '05 #6

P: n/a
WW
red floyd wrote:
Casper Bang wrote:
[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".

--
WW aka Attila
Jul 19 '05 #7

P: n/a

"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
Casper Bang wrote:
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.


Oh brother. <warning>PedantPolice<warning>
Jul 19 '05 #8

P: n/a

"Casper Bang" <ca****@jbr.dk> wrote in message
news:3f***********************@dread14.news.tele.d k...
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.
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.
Jul 19 '05 #9

P: n/a
WW
jeffc wrote:
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
Casper Bang wrote:
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.


Oh brother. <warning>PedantPolice<warning>


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

--
WW aka Attila
Jul 19 '05 #10

P: n/a
WW
jeffc wrote:
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.


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.

--
WW aka Attila
Jul 19 '05 #11

P: n/a

"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
jeffc wrote:
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.


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?
Jul 19 '05 #12

P: n/a

"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...

There are no methods in C++. There are member functions.
Oh brother. <warning>PedantPolice<warning>


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.
Jul 19 '05 #13

P: n/a
WW
jeffc wrote:
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
jeffc wrote:
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.


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.

--
WW aka Attila
Jul 19 '05 #14

P: n/a
WW
jeffc wrote:
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...

There are no methods in C++. There are member functions.

Oh brother. <warning>PedantPolice<warning>


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.


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.

--
WW aka Attila
Jul 19 '05 #15

P: n/a
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" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
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]
--
WW aka Attila

Jul 19 '05 #16

P: n/a
WW
Casper Bang wrote:
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.

--
WW aka Attila
Jul 19 '05 #17

P: n/a

"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...

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.


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?
Jul 19 '05 #18

P: n/a
"WW" <wo***@freemail.hu> wrote in message news:<bk**********@phys-news1.kolumbus.fi>...
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
Jul 19 '05 #19

P: n/a
WW
jeffc wrote:
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...

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.


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.
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.


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.

--
WW aka Attila
Jul 19 '05 #20

P: n/a
WW
Shane Beasley wrote:
"WW" <wo***@freemail.hu> wrote in message
news:<bk**********@phys-news1.kolumbus.fi>...
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.


Method has no definition in a C++ discussion. It can only cause
imprecision, confusion and misunderstanding.

--
WW aka Attila
Jul 19 '05 #21

P: n/a
"jeffc" <no****@nowhere.com> wrote in message news:<3f********@news1.prserv.net>...
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
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?


How do you know how many other people also had an objection to the use
of 'method' but elected not to mention it after WW had already brought
it up?

And how does the exchange between the OP and WW which ended with the
OP's problem solved lead you to conclude that WW wasn't helping?
Jul 19 '05 #22

P: n/a
Gavin Deane wrote:
[SNIP]
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?


How do you know how many other people also had an objection to the use
of 'method' but elected not to mention it after WW had already brought
it up?

And how does the exchange between the OP and WW which ended with the
OP's problem solved lead you to conclude that WW wasn't helping?


He does not conclude. He prejudges.

--
Attila aka WW
Jul 19 '05 #23

P: n/a

"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...

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.


Because you're a pedant.
Jul 19 '05 #24

P: n/a

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d*************************@posting.google.co m...

How do you know how many other people also had an objection to the use
of 'method' but elected not to mention it after WW had already brought
it up?


I'd argue with all the pedants. Anyone who wastes a post telling someone
else that "method is not part of the C++ standard language! nyah nyah!" has
a stick way too far up their rear.
Jul 19 '05 #25

P: n/a

"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...

Method has no definition in a C++ discussion. It can only cause
imprecision, confusion and misunderstanding.


Yeah, right.
Jul 19 '05 #26

P: n/a

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d*************************@posting.google.co m...
And how does the exchange between the OP and WW which ended with the
OP's problem solved lead you to conclude that WW wasn't helping?


The part about the method was completely unhelpful. He was just saying it
to show off his book knowledge of detail unrelated to the question, so he
can appear authoritative, toe the party line, be part of the cool C++ geek
crowd, and waste space in the newsgroup. People like that are only
motivated partially by helping people. Terms like method are completely
valid when discussing C++ design and code, regardless of whether the word
appears in the C++ keyword list, or even the official standard. Just like
base class, parent class, and superclass can be used interchangably, even
though you won't find them in the language. Unlike some people, I'm not
sitting here with a steel rod up my butt waiting for the next time someone
uses the term superclass so I can pounce on them for using a word that
doesn't exist in the language.
Jul 19 '05 #27

P: n/a
WW wrote:
jeffc wrote:
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
Casper Bang wrote:

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.


Oh brother. <warning>PedantPolice<warning>

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


Methods are actions you may request that an object carry out. You
invoke 'methods' by passing 'messages'; methods are implementations of
messages. This is basic OO terminology that you learn in any
introductory text.

The problem with C++ is that when you pass a message to an object it is
not necissarily the one that carries out the action even if it has
overridden its parent's methods. This is only guaranteed if the method
is declaired virtual in *all* parents. I suppose this is why some
people would consider only virtual 'functions' to be methods and why
others would object to a "member function" being called a method at all.
This is also one of the reasons I find C++ does not quite apply the OO
paradigm (which can be a strength at times).

There is also the fact that all C++ "member functions" eventually get
altered to in fact be functions that accept class structs as arguments.
I myself don't believe this should have an impact on our terminology
as it is an implementation detail that the programmer never really sees.
In other OO languages the term method is used and they also get
altered by the compiler to have a more function like signature. For
example Objective-C works this way (many even just preprocess into C)
but we use OO terms not procedural terms.

In my opinion the *only* reason to call a method "member function" is
because it is what C++ programmer terminology uses; and of course
because there are some who will pretend not to know what you mean, go
off on some rant, and may never answer the question. The term
"function" is really not an OO concept and, in my opinion, it is a
mistake to use it as such.

NR

Jul 19 '05 #28

P: n/a

"Noah Roberts" <nr******@dontemailme.com> wrote in message
news:3F************@dontemailme.com...

Methods are actions you may request that an object carry out. You
invoke 'methods' by passing 'messages'; methods are implementations of
messages. This is basic OO terminology that you learn in any
introductory text.

The problem with C++ is that when you pass a message to an object it is
not necissarily the one that carries out the action even if it has
overridden its parent's methods. This is only guaranteed if the method
is declaired virtual in *all* parents. I suppose this is why some
people would consider only virtual 'functions' to be methods and why
others would object to a "member function" being called a method at all.
This is also one of the reasons I find C++ does not quite apply the OO
paradigm (which can be a strength at times).

There is also the fact that all C++ "member functions" eventually get
altered to in fact be functions that accept class structs as arguments.
I myself don't believe this should have an impact on our terminology
as it is an implementation detail that the programmer never really sees.
In other OO languages the term method is used and they also get
altered by the compiler to have a more function like signature. For
example Objective-C works this way (many even just preprocess into C)
but we use OO terms not procedural terms.

In my opinion the *only* reason to call a method "member function" is
because it is what C++ programmer terminology uses; and of course
because there are some who will pretend not to know what you mean, go
off on some rant, and may never answer the question.


Now that is the voice of reason. Having said all that, it's pretty clear
why we don't have to post a whole page like this just because someone in
this newsgroup uses the term "method".
Jul 19 '05 #29

P: n/a
WW
jeffc wrote:
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...

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.


Because you're a pedant.


Stop trolling.

--
WW aka Attila
Jul 19 '05 #30

P: n/a
WW
jeffc wrote:
"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d*************************@posting.google.co m...

How do you know how many other people also had an objection to the
use
of 'method' but elected not to mention it after WW had already
brought
it up?


I'd argue with all the pedants. Anyone who wastes a post telling
someone else that "method is not part of the C++ standard language!
nyah nyah!" has a stick way too far up their rear.


Stop trolling!

--
WW aka Attila
Jul 19 '05 #31

P: n/a
WW
jeffc wrote:
"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d*************************@posting.google.co m...
And how does the exchange between the OP and WW which ended with the
OP's problem solved lead you to conclude that WW wasn't helping?


The part about the method was completely unhelpful. He was just
saying it to show off his book knowledge of detail unrelated to the


Stop trolling!

--
WW aka Attila
Jul 19 '05 #32

P: n/a
WW
jeffc wrote:
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...

Method has no definition in a C++ discussion. It can only cause
imprecision, confusion and misunderstanding.


Yeah, right.


Stop trolling!

--
WW aka Attila
Jul 19 '05 #33

P: n/a
WW
Noah Roberts wrote:
[SNIP]
Please, if you *know* what method means in the realm of the C++
language... by all means, post it here!

Methods are actions you may request that an object carry out. You
invoke 'methods' by passing 'messages'; methods are implementations of
messages. This is basic OO terminology that you learn in any
introductory text.


That is the meaning of method in OO. What is the meaning of method in C++?
The problem with C++ is that when you pass a message to an object it
is not necissarily the one that carries out the action even if it
has overridden its parent's methods. This is only guaranteed if
the method is declaired virtual in *all* parents.
That is one interesting issue. The other is that in C++ freestanding
functions (due to ADL and operator overloading) may very well be considered
part of a class types interface.
I suppose this is why some people would consider only
virtual 'functions' to be methods and why
others would object to a "member function" being called a method at
all.
And this is already a source for confusion.
This is also one of the reasons I find C++ does not quite
apply the OO paradigm (which can be a strength at times).
C++ is multiparadigm.
There is also the fact that all C++ "member functions" eventually get
altered to in fact be functions that accept class structs as
arguments. I myself don't believe this should have an impact on our
terminology as it is an implementation detail that the programmer
never really sees.
Unless he starts to do tricks, like calling a member directly from C or
assembly. I saw that being done in an allegedly portable system. :-) "Why?
The this pointer is the first argument, everybody knows!" Nice parallel to
stating that method has a well defined meaning in C++.

In other OO languages the term method is used and they also get
altered by the compiler to have a more function like signature.
That is OK. They did include the term method into their vocabulary and
defined its meaning. It is not done for C++.
For example Objective-C works this way (many even just preprocess
into C) but we use OO terms not procedural terms.
Does nto have much to do with why it is wrong in C++. For example in
English fast is an OK word. The same word in Hungarian means "the private
parts of a man". So does that mean we should bad the word from English?
Nope. Does that mean we should not use it in Hungarian? Only if you don't
want to get into trouble. But unfortunately (and not talking about yuou
here Noah) some people problems with the sizeof(privates) and so they spend
their time by trolling here and show up contiguous series of knee-jerk
reactions.
In my opinion the *only* reason to call a method "member function" is
because it is what C++ programmer terminology uses;
Method is an operation supported by a classes interface. Therefore method
and member function are not interchangeable. In C++ (using the OO
terminology) freestanding operator functions found by the argument dependent
name lookup are part of the interface provided by the object. And they are
not member functions. For one.
and of course because there are some who will pretend
not to know what you mean, go off on some rant,
and may never answer the question.
Really? How about they *don't* know what do you mean? Or they do, and give
you the answer which is *wrong* for you, because they do NOT understand the
word the same way as you do? Remember the thread where the greenhorn asked
"what methods does the C++ compiler automatically generate for us". Picking
up the *only* closest-thing-toi official-but-still-far-from-it note as a
defintion - where Bjarne Stroustrup that some peoplecall *virtual* member
functions methods - the answer is *NONE*. Not one method is generated.
The term "function" is really not an OO concept and,
in my opinion, it is a mistake to use it as such.


Sure. So don't use it in OO. Here we discuss the C++ language, not OO.

--
WW aka Attila
Jul 19 '05 #34

P: n/a
WW
jeffc wrote:
[SNIP]
Now that is the voice of reason. Having said all that, it's pretty
clear why we don't have to post a whole page like this just because
someone in this newsgroup uses the term "method".


On the contrary. The above snipped post is filled with technical
inaccuracies, tries to mix OO and C++ terminology (while C++ is
multiparadigm) and absolutely fails the task to define the term method in
the realm of the C++ language.

jeffc, stop trolling!

--
WW aka Attila
Jul 19 '05 #35

P: n/a

"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
Noah Roberts wrote:
[SNIP]
Please, if you *know* what method means in the realm of the C++
language... by all means, post it here!

Methods are actions you may request that an object carry out. You
invoke 'methods' by passing 'messages'; methods are implementations of
messages. This is basic OO terminology that you learn in any
introductory text.


That is the meaning of method in OO.


We discuss OO here. C++ is an OO language.
That is OK. They did include the term method into their vocabulary and
defined its meaning.


One can only imagine you hiding your dictionaries under your mattress, and
reading them late at night with a flashlight.
Jul 19 '05 #36

P: n/a
WW
jeffc wrote:
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
Noah Roberts wrote:
[SNIP]
Please, if you *know* what method means in the realm of the C++
language... by all means, post it here!
Methods are actions you may request that an object carry out. You
invoke 'methods' by passing 'messages'; methods are implementations
of messages. This is basic OO terminology that you learn in any
introductory text.


That is the meaning of method in OO.


We discuss OO here. C++ is an OO language.


C++ is a multiparadigm language, not an OO one.
That is OK. They did include the term method into their vocabulary
and defined its meaning.


One can only imagine you hiding your dictionaries under your
mattress, and reading them late at night with a flashlight.


Stop trolling! Last warning.

--
WW aka Attila
Jul 19 '05 #37

P: n/a

"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
We discuss OO here. C++ is an OO language.
C++ is a multiparadigm language, not an OO one.


So, just for the record, you are saying C++ is not an OO language?
Stop trolling! Last warning.


<snicker> Now, back to your mattress, flashlight, and dog-eared copy of
Proceedings of the C++ Conference, 1994.
Jul 19 '05 #38

P: n/a
WW
jeffc wrote:
"WW" <wo***@freemail.hu> wrote in message
news:bk**********@phys-news1.kolumbus.fi...
We discuss OO here. C++ is an OO language.


C++ is a multiparadigm language, not an OO one.


So, just for the record, you are saying C++ is not an OO language?


C++ is a multiparadigm language.
Stop trolling! Last warning.


<snicker> Now, back to your mattress, flashlight, and dog-eared copy
of Proceedings of the C++ Conference, 1994.


Stop trolling!

--
WW aka Attila
Jul 19 '05 #39

P: n/a
jeffc wrote:
[SNIP]
That is the meaning of method in OO.
We discuss OO here.


We discuss the C++ language here, as defined by its standard. Not OO. That
is comp.object. I start to get the feeling you are also posting there.
With the name TopMind.
C++ is an OO language.
C++ is a multiparadigm langauge.
One can only imagine you hiding your dictionaries under your
mattress, and reading them late at night with a flashlight.


Get a life.

--
Attila aka WW
Jul 19 '05 #40

P: n/a
WW wrote:
jeffc wrote:
[SNIP]
Now that is the voice of reason. Having said all that, it's pretty
clear why we don't have to post a whole page like this just because
someone in this newsgroup uses the term "method".

On the contrary. The above snipped post is filled with technical
inaccuracies,


By all means point them out. At a very basic level I believe everything
was more or less correct.

tries to mix OO and C++ terminology (while C++ is multiparadigm)
You yourself, in a disagreement with me, claimed C++ supports the OO
paradigm. If this is true it must also support the terminology. If
indeed C++ is multiparadigm (and it of course is) then this is not a
problem.

and absolutely fails the task to define the term method in the realm of the C++ language.


If you want to use differing terminology to avoid confusion between C++
classes and OO Objects then I won't argue, it might even be a good idea.
In my opinion it is acceptable to use the OO terminology in C++ if you
are using the OO paradigm.

And to spell it out for you:

If you consider C++ classes to equate with OO objects then your "member
functions" are indeed "methods", your calls to "member functions" are
messages, your "member variables" are "instance variables" except when
they are of course "static member variables" in which case they are now
"class variables" (and yes, there is also "class methods"). The only
other altered terminology that I can think of off hand is that "Base
classes" are "Super classes" and "Derived" classes are "Sub" classes.

When you design the architecture you use these terms, why not also use
them as you write the code?

Blah, Blah, and Blah

NR

Jul 19 '05 #41

P: n/a
WW wrote:
Noah Roberts wrote:
[SNIP]
Please, if you *know* what method means in the realm of the C++
language... by all means, post it here!

Methods are actions you may request that an object carry out. You
invoke 'methods' by passing 'messages'; methods are implementations of
messages. This is basic OO terminology that you learn in any
introductory text.

That is the meaning of method in OO. What is the meaning of method in C++?


If you are using the OO paradigm while writing C++ code then they mean
the same thing. You could say that you implement methods in C++ with
functions.
The problem with C++ is that when you pass a message to an object it
is not necissarily the one that carries out the action even if it
has overridden its parent's methods. This is only guaranteed if
the method is declaired virtual in *all* parents.

That is one interesting issue. The other is that in C++ freestanding
functions (due to ADL and operator overloading) may very well be considered
part of a class types interface.


A very interesting point. They may very well be considered methods as
well then. It would have to be thought about more than I am prepaired
to right now :P

I suppose this is why some people would consider only
virtual 'functions' to be methods and why
others would object to a "member function" being called a method at
all.

And this is already a source for confusion.


Of course. You must understand the limitations of the language you are
working with. This is always a source of confusion.

This is also one of the reasons I find C++ does not quite
apply the OO paradigm (which can be a strength at times).

C++ is multiparadigm.


Few aren't, though with OO languages many are not. IMHO it is a bad
idea for a language to enforce a particular paradigm on all of its
types. One of many reasons why I hate Java.
There is also the fact that all C++ "member functions" eventually get
altered to in fact be functions that accept class structs as
arguments. I myself don't believe this should have an impact on our
terminology as it is an implementation detail that the programmer
never really sees.

Unless he starts to do tricks, like calling a member directly from C or
assembly. I saw that being done in an allegedly portable system. :-) "Why?
The this pointer is the first argument, everybody knows!"


You can always break the paradigm. In Objective-C it is also possible,
in fact the language supports it (IMP == a pointer to the actual
function version of a method). With an unpatched gdb you in fact have
to use the function names (complete with underscores:
"__i_ClasName_method()") of the methods you wish to debug; I myself
recommend using the patch :P
Does nto have much to do with why it is wrong in C++. For example in
English fast is an OK word. The same word in Hungarian means "the private
parts of a man". So does that mean we should bad the word from English?
Nope. Does that mean we should not use it in Hungarian?
I would equate the situation more like the following: fast is an ok
english word. In hungarian it is not. Does this mean that if we are in
Hungary we should not say the word fast? I would say that depends on
whether you are talking in English or Hungarian. C++ is Hungary,
Hungarian is the terms C++ uses, English is OO terminology - many who
live in hungary also speak english and it works well for them.

Really? How about they *don't* know what do you mean? Or they do, and give
you the answer which is *wrong* for you, because they do NOT understand the
word the same way as you do? Remember the thread where the greenhorn asked
"what methods does the C++ compiler automatically generate for us".


At some point that could have been myself. I started with OO languages
like Java and Objective-C (deinately the better of the two)x and later
moved to C++. It took me a long time to supress the hate and begin to
like C++ for its differences.

There are several. In fact you could say that all C++ objects actually
subclass a non-existant super class which provides such things as
destructors, constructors, copy operators, etc... In some OO languages
the answer is *none* and so you subclass a super that provides these
interfaces or go through the pain of implementing "alloc".
NR

Jul 19 '05 #42

P: n/a
Noah Roberts wrote:
WW wrote: [SNIP]
On the contrary. The above snipped post is filled with technical
inaccuracies,


By all means point them out. At a very basic level I believe
everything was more or less correct.


You use OO *theoretical* terms (message, method) which have no equivalent
concepts in C++. For example in the system I make there are messages. They
involve several design patterns and they do work as in OO. But not because
C++ has messages.

"the only reason to call a method "member function" is
because it is what C++ programmer terminology uses"

No. The *only* reason because it is called member fucntion, because it is a
member function. The reason why it is nto called method is because there is
no one to one mapping between that OO theory term and the C++ language
features.
tries to mix OO and C++ terminology (while C++ is
multiparadigm)


You yourself, in a disagreement with me,
claimed C++ supports the OO paradigm.


Where? I have said C++ is multiparadigm. You can cut with a Swiss army
knife like a normal knife. But talking about "the blade" is nonsense, since
it has more than one blade. It support the notion of knife but it is *not*
a knife. It is *more* than a knife. C++ supports the OO methodology, but
it is *not* an OO language. It is *more* than an OO language. That is why
some OO terms (and thanx to some other wonders like C heritage, ADL,
namespaces) does not one-to-one apply to it.
If this is true it must also support the terminology.
I have just proven it is not so.
If indeed C++ is multiparadigm (and it of course is)
then this is not a problem.
It would only be a bigger problem if C++ had no OO support whatsoever.
and absolutely fails the task to define the term method in
the realm of the C++ language.
If you want to use differing terminology to avoid confusion between
C++ classes and OO Objects then I won't argue, it might even be a
good idea. In my opinion it is acceptable to use the OO terminology
in C++ if you are using the OO paradigm.


We are not using the OO paradigm here. We are using C++. As defined by the
standard. And the standard has no definition of such term as method. If
you whish to discuss OO methodology then go to comp.objects and start with
killfiling TopMind.
And to spell it out for you:

If you consider C++ classes to equate with OO objects
I don't.
then your "member functions" are indeed "methods",
Unfortunately yes and no. There is no one to one mapping for the
theoretical OO term "method" and C++ language terms.
your calls to "member functions" are messages,
They corellate to them.
your "member variables" are "instance variables"
except when they are of course "static member variables"
in which case they are now "class variables"
This is the only thing which I can accept as one-to-one, non-confusing
mapping.
(and yes, there is also "class methods").
Not in C++. In C++ there are static member functions. In C++ classes are
not first class objects.
The only other altered terminology that I can
think of off hand is that "Base classes"
are "Super classes" and "Derived"
classes are "Sub" classes.
And member functions. There is no term "methods", which has an unambiguous
definition, known by all. It is only good to create confusion and
misunderstanding. Just in this newsgroup I have seen already 3 different
people to sware on 3 different meanings for method in C++.
When you design the architecture you use these terms,
why not also use them as you write the code?
Simple. For the same reason you do not use the same terms in designing the
architecture of a house, and designing its bricks.
Blah, Blah, and Blah


Yeah, it was.

--
Attila aka WW
Jul 19 '05 #43

P: n/a
Noah Roberts wrote:
[SNIP]
That is the meaning of method in OO. What is the meaning of method
in C++?
If you are using the OO paradigm while writing C++ code then they mean
the same thing. You could say that you implement methods in C++ with
functions.


Yes. And you can also implement them by freestanding operator functions.
And who know in how many ways (actual syntax aside). Any ways ADL will find
them.
That is one interesting issue. The other is that in C++ freestanding
functions (due to ADL and operator overloading) may very well be
considered part of a class types interface.


A very interesting point. They may very well be considered methods as
well then. It would have to be thought about more than I am prepaired
to right now :P


Yes. That is why the term method has no meaning in the realm of C++.
Method is an OO term. A theoretical term. Some languages took it in as it
is, some not. C++ is one of those, which did not.
I suppose this is why some people would consider only
virtual 'functions' to be methods and why
others would object to a "member function" being called a method at
all.


And this is already a source for confusion.


Of course. You must understand the limitations of the language you
are working with. This is always a source of confusion.


Limitations??? You mean a multiparadigm language supporting more than OO is
a *limitation*????
This is also one of the reasons I find C++ does not quite
apply the OO paradigm (which can be a strength at times).


C++ is multiparadigm.


Few aren't, though with OO languages many are not. IMHO it is a bad
idea for a language to enforce a particular paradigm on all of its
types. One of many reasons why I hate Java.


C3PO also hates Jawas. He said: disquasting creatures. ;-) I love C3PO.
:-)
Unless he starts to do tricks, like calling a member directly from C
or assembly. I saw that being done in an allegedly portable system.
:-) "Why? The this pointer is the first argument, everybody knows!"


You can always break the paradigm. In Objective-C it is also
possible, in fact the language supports it (IMP == a pointer to the
actual function version of a method). With an unpatched gdb you in
fact have to use the function names (complete with underscores:
"__i_ClasName_method()") of the methods you wish to debug; I myself
recommend using the patch :P


:-)
Does nto have much to do with why it is wrong in C++. For example in
English fast is an OK word. The same word in Hungarian means "the
private parts of a man". So does that mean we should bad the word
from English? Nope. Does that mean we should not use it in
Hungarian?


I would equate the situation more like the following: fast is an ok
english word. In hungarian it is not. Does this mean that if we are
in Hungary we should not say the word fast?


Yes. Unless you want to get your face repartitioned and reformatted. The
rough transalation of what fast will be received (perceived) in Hungary is:
a big c*ock into your mouth you S-Whole.
I would say that depends on whether you
are talking in English or Hungarian.
It depends.
C++ is Hungary, Hungarian is the terms C++ uses,
English is OO terminology - many who live in hungary
also speak english and it works well for them.
Nope. That parallel was only good up to the point I used it: while a word
can hold one meaning in one language it may not hold the same (or any
definable - agreed) meaning in another. The rest (what you wrote) is B/S.
Why? Because English and Hungarian people talk about the *same thing*.
While OO (theory) and C++ (implementation) is *not*.
Really? How about they *don't* know what do you mean? Or they do,
and give you the answer which is *wrong* for you, because they do
NOT understand the word the same way as you do? Remember the thread
where the greenhorn asked "what methods does the C++ compiler
automatically generate for us".

[SNIP] There are several. In fact you could say that all C++ objects
actually subclass a non-existant super class which provides such
things as destructors, constructors, copy operators, etc...
No, you cannot. Because in this case they could be converted to that common
base class.
In some
OO languages the answer is *none* and so you subclass a super that
provides these interfaces or go through the pain of implementing
"alloc".


Yep. So let's not mix OO theory with C++ practice. They have a very strong
relationship but there are just things there with no one-to-one mapping.

--
Attila aka WW
Jul 19 '05 #44

P: n/a
"jeffc" <no****@nowhere.com> wrote in message news:<3f********@news1.prserv.net>...
"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d*************************@posting.google.co m...
And how does the exchange between the OP and WW which ended with the
OP's problem solved lead you to conclude that WW wasn't helping?


The part about the method was completely unhelpful. He was just saying it
to show off his book knowledge of detail unrelated to the question, so he
can appear authoritative, toe the party line, be part of the cool C++ geek
crowd, and waste space in the newsgroup. People like that are only
motivated partially by helping people. Terms like method are completely
valid when discussing C++ design and code, regardless of whether the word
appears in the C++ keyword list, or even the official standard. Just like
base class, parent class, and superclass can be used interchangably, even
though you won't find them in the language. Unlike some people, I'm not
sitting here with a steel rod up my butt waiting for the next time someone
uses the term superclass so I can pounce on them for using a word that
doesn't exist in the language.


Base class, superclass and parent class AFAIK all mean exactly the
same thing so could be interchanged. Whether this is still true in the
case of non-public, virtual or multiple inheritance I don't know. If
there were a princilpe of OO design that said that 'superclass' was
not the appropriate term in multiple inheritance, then that OO
superclass concept would not be interchangeable with C++'s base class
concept.

C++ has member functions, static member functions, virtual and pure
virtual ones, friend functions and non-member non-friend functions
that can make up a class's interface. I may have forgotten others.
'Method' is not technically defined in C++. When someone asks a C++
design question and talks about methods, it is important to ascertain
which of the above list of types of class interface function they
regard as methods. Otherwise how can you understand the question or
propose a solution?

It is also valuable to point out that 'method' is not a C++ term.
Someone who has learnt the term in the context of another language or
general OO design principles may well not be aware of exactly how C++
implements the concepts.

I don't know why you have a problem with attention to detail. It is an
extremely important quality in a computer programmer, since the
computer has to follow precisely what you told it to do, even if you
meant something slightly different.

GJD
Jul 19 '05 #45

P: n/a

"Gavin Deane" <de*********@hotmail.com> wrote in message
news:6d**************************@posting.google.c om...

I don't know why you have a problem with attention to detail. It is an
extremely important quality in a computer programmer, since the
computer has to follow precisely what you told it to do, even if you
meant something slightly different.


Oh. I didn't realize that Gavin. Maybe that's why none of my programs have
ever compiled. In the future I will try to remember to be more detail
oriented if I expect success in computers. Thank you.
Jul 19 '05 #46

P: n/a

"Noah Roberts" <nr******@dontemailme.com> wrote in message
news:3F**************@dontemailme.com...

You yourself, in a disagreement with me, claimed C++ supports the OO
paradigm. If this is true it must also support the terminology. If
indeed C++ is multiparadigm (and it of course is) then this is not a
problem.


His robotic responses change depending from which side of the fence he's
currently arguing.
Jul 19 '05 #47

P: n/a

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...
One can only imagine you hiding your dictionaries under your
mattress, and reading them late at night with a flashlight.


Get a life.


In case you couldn't translate that sentence, that's what it meant.
Jul 19 '05 #48

P: n/a
WW
jeffc wrote:
"Noah Roberts" <nr******@dontemailme.com> wrote in message
news:3F**************@dontemailme.com...

You yourself, in a disagreement with me, claimed C++ supports the OO
paradigm. If this is true it must also support the terminology. If
indeed C++ is multiparadigm (and it of course is) then this is not a
problem.


His robotic responses change depending from which side of the fence
he's currently arguing.


Stop trolling!

--
WW aka Attila
Jul 19 '05 #49

P: n/a
WW
jeffc wrote:
"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...
One can only imagine you hiding your dictionaries under your
mattress, and reading them late at night with a flashlight.


Get a life.


In case you couldn't translate that sentence, that's what it meant.


Stop trolling!

--
WW aka Attila
Jul 19 '05 #50

51 Replies

This discussion thread is closed

Replies have been disabled for this discussion.