member functions

[James Kanze]

James Kanze <[email protected]> writes:

[...]

The flow and which bits he keeps re-quoting has me wondering whether
he is attaching extra meaning to the "member" in "A subobject can
be a member subobject." I don't have a copy of the standard, so I
can't clarify the meaning of "member subobject."

It's just one of the types of subobjects. There are three
(assuming I've not forgotten any): members, bases and array
elements. A subobject can be a member subobject or a base
subobject of an object with class type, or an element of an
object with array type.

 

[Paul]

[...]

Base b;
Derived d;
b = d;
b.some_function();
Will the last function call invoke Base::some_function()
or Derived::some_function()? If the member functions are
part of the object, copying the object will also copy the
functions. However, it doesn't, so this is something your
distorted view doesn't explain. I'm not settling for your
sub-par explanations, and you shouldn't either.
I'm not sure what this is supposed to demonstrate. Other
than the already well known fact that the actual function
code is not stored within an objects region of storage.
It demonstrates that no reference to a function is stored in
the object, otherwise the call would change targets with the
assignment, too.

Actually, it doesn't demonstrate anything except maybe that
objects never change type.

You are in disagreement with this paper written by Bjarne Stroustrup:

"A virtual function call: The function to be called depends on
the type of the object for which it is called. This type
cannot in general be determined until run time. Typically, the
pointerp will be of some base classB and the object will be an
object of some derived classD (as was the case with the base
classshape and the derived classcircle above). *The call
mechanism must look into the object and find some information*
placed there by the compiler to determine which functionf is
to be called. "

I think the general public would be in agreement with what
Bjarne has written here.

Yes, but it doesn't seem relevant to anything we've been
discussing. (Strictly speaking, of course, it's also not
correct; other mechanisms of handling virtual functions are
possible. But it does correspond to usual practice.) No one is
denying that any specific object has a type. And that virtual
function call resolution depends on that type. The fact that an
object has a type, however, doesn't make it a type.

Now you are saying Bjarne Stroustrup is incorrect, LOL.
I'm not saying that Bjarne is perfect but its a pretty bold statement to say
he is incorrect about a language he invented.
I think most people will agree that is is almost ceretainly you that is
incorrect.

 

[Paul]

<[email protected]>
[...]
The flow and which bits he keeps re-quoting has me wondering whether
he is attaching extra meaning to the "member" in "A subobject can
be a member subobject." I don't have a copy of the standard, so I
can't clarify the meaning of "member subobject."

It's just one of the types of subobjects. There are three
(assuming I've not forgotten any): members, bases and array
elements. A subobject can be a member subobject or a base
subobject of an object with class type, or an element of an
object with array type.

Why don't you simply give the guy the correct quote from standard, instead
of a vague recollection from your memory that may or may not be correct and
has a strong possibiility of being innaccurate.

It seems as though you are trying to hide the correct standards quotation,
since you always snip it out.

 

[antred]

Having read through both of these threads now, I can't help but feel you guys are arguing over nothing.
Whether you consider a member function a member of the class or a member of an instance of that class is pretty much a purely academic distinction.

 

[Ulrich Eckhardt]

You are in disagreement with this paper written by Bjarne Stroustrup:

"A virtual function call blahblah blah [adopting Paul Reid's quoting
style]"

There is no virtual function call involved in the code in question. You
are assuming things that are just not there.

I think its quite apparent that *your* interpretation of the C++
programming language is nothin more than a sloppy misunderstanding.

I'm wondering, is there any code you can show that demonstrates your
coding skills? As it stands, I would also accept non C++. BTW, I'd say
that reality proves you wrong with that assumption about my skills.

This, and your insults towards my mother, suggest you are a person of
very low intelligence.

Actually, properly insulting people requires a fair amount of
intelligence. It also takes intelligence to notice, similar to irony.

 

[Paul]

You are in disagreement with this paper written by Bjarne Stroustrup:

"A virtual function call blahblah blah [adopting Paul Reid's quoting
style]"

There is no virtual function call involved in the code in question. You
are assuming things that are just not there.

I think its quite apparent that *your* interpretation of the C++
programming language is nothin more than a sloppy misunderstanding.

I'm wondering, is there any code you can show that demonstrates your
coding skills? As it stands, I would also accept non C++. BTW, I'd say
that reality proves you wrong with that assumption about my skills.

If that code demonstrates your coding skills then it follows that you do not
have the intellectual capacity to understand the complexity of my code.
If you cannot even understand the simple statement:
fido.Bark();

then how can you understand a full program.
If you think fido.Bark() is a class function then you should jump over to a
java group.

You simply state yourself as correct and think this must be so because
you're in the majority.

 

[Juha Nieminen]

If that code demonstrates your coding skills then it follows that you do not
have the intellectual capacity to understand the complexity of my code.

Says the person who didn't even know what a member function pointer is.

 

[Ebenezer]

You are in disagreement with this paper written by Bjarne Stroustrup:

"A virtual function call blahblah blah [adopting Paul Reid's quoting
style]"

There is no virtual function call involved in the code in question. You
are assuming things that are just not there.

I think its quite apparent that *your* interpretation of the C++
programming language is nothin more than a sloppy misunderstanding.

I'm wondering, is there any code you can show that demonstrates your
coding skills? As it stands, I would also accept non C++. BTW, I'd say
that reality proves you wrong with that assumption about my skills.

Sometimes it's the unruly child who demands and gets all the
attention at the expense of his siblings. I have some C++ code
that I would like to have reviewed. There's an archive here --
http://webEbenezer.net/build_integration.html .

Brian Wood
Ebenezer Enterprises
http://webEbenezer.net
(651) 251-9384

 

[Ulrich Eckhardt]

You are in disagreement with this paper written by Bjarne Stroustrup:

"A virtual function call blahblah blah [adopting Paul Reid's quoting
style]"

There is no virtual function call involved in the code in question. You
are assuming things that are just not there.

I think its quite apparent that *your* interpretation of the C++
programming language is nothin more than a sloppy misunderstanding.

I'm wondering, is there any code you can show that demonstrates your
coding skills? As it stands, I would also accept non C++. BTW, I'd say
that reality proves you wrong with that assumption about my skills.

If that code demonstrates your coding skills then it follows that you do
not have the intellectual capacity to understand the complexity of my
code.

What code of mine are you talking about? There wasn't any mentioned yet.
Or are you saying that that code of yours in question would demonstrate my
coding skills? No, you can't seriously mean that, that would be even more
twisted than what you deliver here otherwise. Or are you perhaps talking
about the snippet of example code I gave? In that case, it is quite
presumptuous to assume that this small example allows you such a broad
claim on my skills, wouldn't it?

If you cannot even understand the simple statement:
fido.Bark();

then how can you understand a full program.

I can and I can. I have actually written programs, and I still do this
professionally, using C++ and a bunch of other languages. AFAIK, you have
managed to lose all respect that people here typically pay to newcomers,
other than that, nothing.

If you think fido.Bark() is a class function then you should jump over
to a java group.

Not even in Java (note the capital J, it's a name) that would be a "class
function", so what's your point? BTW: It doesn't even have to be a call to
a memberfunction in C++ if Bark is a function pointer. Did you consider
that when asking the question? That and the third alternative what it
could mean?

You simply state yourself as correct and think this must be so because
you're in the majority.

How would you know what I think? Anyhow, I earned my understanding by
repeatedly putting my views to test in peer reviews and constructive
discussions here and elsewhere. You on the other hand show blank areas in
even the basics of C++ programming, let alone the finer details of the
language, and insult people that point out that your statements are
incorrect. So tell me, even assuming the above paragraph is just /my/
perception of reality, why should I accept your ignorant ramblings
combined with your childish behaviour?

 

[Drew Lawson]

<[email protected]>
[...]
The flow and which bits he keeps re-quoting has me wondering whether
he is attaching extra meaning to the "member" in "A subobject can
be a member subobject." I don't have a copy of the standard, so I
can't clarify the meaning of "member subobject."

It's just one of the types of subobjects. There are three
(assuming I've not forgotten any): members, bases and array
elements. A subobject can be a member subobject or a base
subobject of an object with class type, or an element of an
object with array type.

Why don't you simply give the guy the correct quote from standard, instead
of a vague recollection from your memory that may or may not be correct and
has a strong possibiility of being innaccurate.

Shut up troll.

He provided just the detail that I was lacking -- that array objects
have subobjects. I was thinking only of class/struct types of
aggregations.

 

[Paul]

On Jan 7, 2:17 pm, (e-mail address removed) (Drew Lawson) wrote:
<[email protected]>

[...]
The flow and which bits he keeps re-quoting has me wondering whether
he is attaching extra meaning to the "member" in "A subobject can
be a member subobject." I don't have a copy of the standard, so I
can't clarify the meaning of "member subobject."

It's just one of the types of subobjects. There are three
(assuming I've not forgotten any): members, bases and array
elements. A subobject can be a member subobject or a base
subobject of an object with class type, or an element of an
object with array type.

Why don't you simply give the guy the correct quote from standard, instead
of a vague recollection from your memory that may or may not be correct
and
has a strong possibiility of being innaccurate.

Shut up troll.

He provided just the detail that I was lacking -- that array objects
have subobjects. I was thinking only of class/struct types of
aggregations.

Who cares what you were lacking , or what you were thinking?