Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > member functions

Reply
Thread Tools

member functions

 
 
James Kanze
Guest
Posts: n/a
 
      01-07-2011
On Jan 7, 2:17 pm, (E-Mail Removed) (Drew Lawson) wrote:
> In article <(E-Mail Removed)>
> James Kanze <(E-Mail Removed)> 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.

--
James Kanze
 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      01-07-2011

"James Kanze" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Jan 7, 3:59 pm, "Paul" <(E-Mail Removed)> wrote:
>> "Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)-berlin.de...

>
> [...]
>> >>> 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.
>
> --
> James Kanze


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.

 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      01-07-2011

"James Kanze" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Jan 7, 2:17 pm, (E-Mail Removed) (Drew Lawson) wrote:
>> In article
>> <(E-Mail Removed)>
>> James Kanze <(E-Mail Removed)> 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.
>
> --
> James Kanze
>

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.

 
Reply With Quote
 
antred antred is offline
Junior Member
Join Date: Jan 2011
Posts: 6
 
      01-08-2011
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.
 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      01-08-2011
Paul wrote:
> 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.

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-08-2011

"Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)-berlin.de...
> Paul wrote:
>> 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.

 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      01-08-2011
Paul <(E-Mail Removed)> wrote:
> 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.
 
Reply With Quote
 
Ebenezer
Guest
Posts: n/a
 
      01-08-2011
On Jan 7, 9:48*pm, Ulrich Eckhardt <(E-Mail Removed)> wrote:
> Paul wrote:
> > 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
 
Reply With Quote
 
Ulrich Eckhardt
Guest
Posts: n/a
 
      01-08-2011
Paul wrote:
> "Ulrich Eckhardt" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)-berlin.de...
>> Paul wrote:
>>> 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?

 
Reply With Quote
 
Drew Lawson
Guest
Posts: n/a
 
      01-11-2011
In article <pTLVo.18536$(E-Mail Removed)2>
"Paul" <(E-Mail Removed)> writes:
>
>"James Kanze" <(E-Mail Removed)> wrote in message
>news:(E-Mail Removed)...
>> On Jan 7, 2:17 pm, (E-Mail Removed) (Drew Lawson) wrote:
>>> In article
>>> <(E-Mail Removed)>
>>> James Kanze <(E-Mail Removed)> 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.
>>
>> --
>> James Kanze
>>

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


--
Drew Lawson | "But the senator, while insisting he was not
| intoxicated, could not explain his nudity."
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
overloading non-template member functions with template member functions Hicham Mouline C++ 1 04-24-2009 07:47 AM
overloading non-template member functions with template member functions Hicham Mouline C++ 0 04-23-2009 11:42 AM
Defining Non-Member Functions for Template Member Types flounder C++ 4 04-01-2009 11:59 PM
Member function pointers to member functions with default arguments Hamish C++ 3 01-25-2008 06:46 AM
How would I use qsort to sort a struct with a char* member and a long member - I want to sort in order of the long member Angus Comber C Programming 7 02-05-2004 06:41 PM



Advertisments