Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Frasncis Glassboro wrote.

Reply
Thread Tools

Frasncis Glassboro wrote.

 
 
David Hutto
Guest
Posts: n/a
 
      01-09-2011
Why do the alleged intellectuals keep lecturing on why not to respond
to the 'trolls' keep saying not to egg them on, tehn egg them on by
calling them trolls.

They further keep saying how not to respond, but further respond
themselves, and demonstrate their own ignorance.
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      01-09-2011
On Jan 9, 9:32 pm, Leigh Johnston <(E-Mail Removed)> wrote:
> On 09/01/2011 21:24, David Hutto wrote:


> > Why do the alleged intellectuals keep lecturing on why not
> > to respond to the 'trolls' keep saying not to egg them on,
> > tehn egg them on by calling them trolls.


> > They further keep saying how not to respond, but further
> > respond themselves, and demonstrate their own ignorance.


> A troll gets a "win" if it gets the last word. Replying to a
> troll is probably a bit childish but if the troll post
> potentially confuses newbies then a reply is possibly
> justified.


I'm curious: what is the currently accepted meaning for troll?
Back when I started in newsgroups, the definition of a troll was
someone who posted a contentious statement to a newsgroup, in
order to provoke an incredible amount of traffic, but who didn't
participate in the discussions after that. By that definition,
Paul isn't a troll. (Which doesn't mean that he isn't a childish
idiot, or any other pejorative terms which might apply.) But
that was some time ago, and such definitions tend to evolve.
(Wikipedia, for example, doesn't mention the fact that a troll
doesn't participate in the "discussion", once he's triggered
it.)

--
James Kanze
 
Reply With Quote
 
 
 
 
James Kanze
Guest
Posts: n/a
 
      01-09-2011
On Jan 8, 4:16 pm, Leigh Johnston <(E-Mail Removed)> wrote:
> On 08/01/2011 16:07, Paul wrote:


[...]
> > No, you cannot use a virtual function without an object.
> > A virtual function is basically a pointer that exists within an object,
> > a virtual function never actually exists as a function hence *virtual*
> > function.
> > It is impossible to invoke a virtual function without the existence of
> > an object. The object contains the pointer (that is the virtual function).


> You are wrong yet again; you obviously do not know C++.


Actually, he's right in the above (except for the last sentence,
which is completely irrelevant). You cannot invoke a virtual
function (or any non-static member function, for that matter)
without an object. You also cannot invoke a function which has
reference parameters without an object (or objects, if there is
more than one reference parameter). I don't see how that's
relevant to the discussion, but as you've surely notices, Paul
likes to throw out a lot of irrelevant junk, to try to confuse
the issues.

> The address of
> a virtual function is contained within a vtable;


That's one implementation technique. By far the most prevelant,
and I suspect, the only one actually used in practice. But at
least theoretically, others are possible. But vtables and vptr
are all behind the scenes issues, which only concern the
compiler writer, and not the language as it is defined.

I'll repeat my position (you can agree or not): objects do not
have members (function members or data members); classes have
members. It is, however, a convenient shortcut to speak of
non-static data members as members of the object, since they
have the same lifetime (more or less) as the object which
contains them. The key here is lifetime: functions don't have
lifetime, so it makes no sense to speak of them as members of an
object.

[...]
> > Hope this makes sense to you.
> > Some peope are obviously confused between a precompile time
> > entity(class) and an object.
> > A function is not contained within a class anymore than it is contained
> > within an object, with:
> > wanda.blowBubbles();
> > This statement contains an object and a member function,
> > there is no class here. This member function does not exist
> > until it's invoked on an


> Wrong yet again; member functions exist within the code
> segment before any objects are created at runtime.


In practice. The C++ standard doesn't say anything about the
lifetime of functions. Functions just "are", independently of
any objects.

[...]
> I suggest you read a C++ book or two


Maybe "You Can Program in C++", by Francis Glassboro. Rated
"highly recommended" by the ACCU.

--
James Kanze
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      01-09-2011
On Jan 8, 5:39 pm, "Paul" <(E-Mail Removed)> wrote:
> "Leigh Johnston" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed) ...


[...]
> > It is important to note however that the use of vtables is
> > an implementaiton specific way of doing things (vtables are
> > not mentioned by the standard AFAIK). I do not know of any
> > implementations that do not use vtables however; this is
> > down to the fact that the vtable solution to the problem of
> > dynamic dispatch is efficient and not memory intensive
> > (requiring only a single pointer in an object when using
> > single inheritance).


> The function calling mechanisms for any given implementation
> is *obviously* not defined in the standards.


> The point here is that you seen to have eaten a book that
> contains the word 'vtable' and now you are an expert on the
> function calling mechanism for all implemenmtations. Most of
> your babblings about your idea of how things work on some
> implementation of yours, is pretty irrellevant.


> But there is one important point, that the object contains a
> pointer to the function, whether it be a direct or indirect.


Bullshit.

Leigh speaks about what is certainly the most common
implementation technique; I don't know of a C++ compiler which
uses anything else (and I've actually spoken with most of the
people who've actually written C++ compilers). Within the
standards committee, however, the possibility of other
implementations was discussed, and the typical alterative to a
vptr was to use a map, mapping object address to function
address.

All of which is completely irrelevant. Classes have members,
and objects have subobjects. At least according to the
standard.

> The important point here is that an OBJECT contains the
> pointer, not a CLASS.


Obviously, an object doesn't contain a class, since classes are
a compile time concept, and objects a runtime concept.

--
James Kanze
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      01-09-2011
On Jan 8, 5:59 pm, "Paul" <(E-Mail Removed)> wrote:
> "James Kanze" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...


[...]
> >> >> > It works correctly. That's why pointer to member
> >> >> > functions are often larger than any other pointer
> >> >> > types (but there are other ways of solving the
> >> >> > problem).


> >> >> What would your pointer point to ?


> >> > That's the compiler writers problem, not mine.


> >> It certainly is a problem for the compiler, and perhaps the
> >> program too. Especially if you didn't initialised the
> >> empty pointer. Let me put it another way, where would you
> >> get the address for the virtual function?


> > From the object you call the pointer on.


> Then you are calling the function on an object.


Obviously. If a function takes parameters, you have to provide
those parameters. That's true for any function, member or not.
The only real particularity concerning member functions is the
call syntax.

> You can't have a virtual function without an object ,end of
> story.


You can't call a non-static member function (virtual or not)
without an object. You can't call a function which has a
reference parameter without an object either. So?

> >> >> You cannot do this with virtual functions and you are
> >> >> wrong to suggest it works correctly.


> >> > It does work, and I've done it. More than once.


> >> It simply can't be done as the concept of virtual functions
> >> only lives in the world of objects. Please show some basic
> >> code. I guarantee you cannot.


> > Your guarantees aren't worth much, since you obviously aren't
> > familiar with C++. It does work, and I've done it. Several
> > types, with different compilers (Sun CC, g++ and VC++, at
> > least---although you need special compiler options with VC++ if
> > everything isn't in the same translation unit).


> The fact that you cannot provide code to suggest what you
> claimed proves the opposite.


I didn't bother providing code, because someone else had already
done so. It's standard C++.

> And it suggests that your claims are pretty weak and
> innaccurate.


The fact that you doubt it rather proves that you don't know
C++.

--
James Kanze
 
Reply With Quote
 
LR
Guest
Posts: n/a
 
      01-10-2011
James Kanze wrote:

> You cannot invoke a virtual
> function (or any non-static member function, for that matter)
> without an object.


I don't understand this.

I've tried this code with two compilers and gotten "X::f()" as output.

#include <iostream>
struct X {
void f() {
std::cout << "X::f()" << std::endl;
}
};

int main() {
X *p = 0;
p->f();
}

Perhaps, since you say "an object" and not an object of the type that
has the invoked function as a member, you mean that p is the object that
is used to call the function?

Or perhaps I didn't understand the qualifiers you suggest for the kinds
of functions that can be called?

Or is this code just plain wrong per the standard?

LR

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      01-10-2011
On 01/10/11 02:38 PM, LR wrote:
> James Kanze wrote:
>
>> You cannot invoke a virtual
>> function (or any non-static member function, for that matter)
>> without an object.

>
> I don't understand this.
>
> I've tried this code with two compilers and gotten "X::f()" as output.
>
> #include<iostream>
> struct X {
> void f() {
> std::cout<< "X::f()"<< std::endl;
> }
> };
>
> int main() {
> X *p = 0;
> p->f();
> }
>
> Perhaps, since you say "an object" and not an object of the type that
> has the invoked function as a member, you mean that p is the object that
> is used to call the function?


p is a pointer to an X. The undefined behaviour is using a NULL value.

In this case you aren't accessing any member variables in f, so nothing
bad happens. If f was a virtual function, or you attempted to access a
member variable, your toilet could explode.

--
Ian Collins
 
Reply With Quote
 
stan
Guest
Posts: n/a
 
      01-10-2011
James Kanze wrote:
<snip>
> I'm curious: what is the currently accepted meaning for troll?
> Back when I started in newsgroups, the definition of a troll was
> someone who posted a contentious statement to a newsgroup, in
> order to provoke an incredible amount of traffic, but who didn't
> participate in the discussions after that. By that definition,
> Paul isn't a troll. (Which doesn't mean that he isn't a childish
> idiot, or any other pejorative terms which might apply.) But
> that was some time ago, and such definitions tend to evolve.
> (Wikipedia, for example, doesn't mention the fact that a troll
> doesn't participate in the "discussion", once he's triggered
> it.)


In the early times that was generally true, but there were
exceptions. A significant difference between then and now is that back
then most trolls actually had intent and many were intelligent and
even clever and funny once in awhile; even while stirring the pot. I
won't claim to understand others motives but they seemed to do it for
sport.

Today I think most people accused of being a troll are giving them a
bad name. Most dont have a clue or a plan, and they dont seem to have
the mental capacity to form intent to mischief. Mostly they seem
troubled, confused, and desperate, and childish. Basically today's
crop is a very poor imitation of the troll that once roamed usenet. I
don't know if the definition evolved but the behavior has clearly
devolved.
 
Reply With Quote
 
LR
Guest
Posts: n/a
 
      01-10-2011
Ian Collins wrote:
> On 01/10/11 02:38 PM, LR wrote:
>> James Kanze wrote:
>>
>>> You cannot invoke a virtual
>>> function (or any non-static member function, for that matter)
>>> without an object.

>>
>> I don't understand this.
>>
>> I've tried this code with two compilers and gotten "X::f()" as output.
>>
>> #include<iostream>
>> struct X {
>> void f() {
>> std::cout<< "X::f()"<< std::endl;
>> }
>> };
>>
>> int main() {
>> X *p = 0;
>> p->f();
>> }
>>
>> Perhaps, since you say "an object" and not an object of the type that
>> has the invoked function as a member, you mean that p is the object that
>> is used to call the function?

>
> p is a pointer to an X. The undefined behaviour is using a NULL value.


I don't know why I keep forgetting that for this case.

Thank you.


> In this case you aren't accessing any member variables in f, so nothing
> bad happens. If f was a virtual function, or you attempted to access a
> member variable, your toilet could explode.


LR

 
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
looking for scott from Glassboro State Fran Duffy Python 0 06-23-2007 10:12 AM



Advertisments