Frasncis Glassboro wrote.

J

Joshua Maurice

You can't just make statements to define the C++ language as you interpret
it. You state them as a fact with nothing to support it.
If *everyone* else agrees with you it doesn't mean you are correct.

Yes, you can of can. In fact, that's the only way. The only way to
define terms is by consensus or by authority. If everyone agreed on
definition X, then that is the definition of the term.
 
I

Ian Collins

"If a stop sign is a sign, and red is a color, how can a stop sign be
red, because a sign is not a color. "

There. That makes about as much sense as what you just said.

You're assuming his intent is to make sense and not to keep this thread
going as long as possible!
 
J

Joshua Maurice

On 2011-01-07 15:15:36 -0500, Juha Nieminen said:




Yup so outside the context of the C++ standards , which is where we are
here.

But we're in comp.lang.c++, and the discussion has always been about
the C++ standard, and what object means in the C++ community. If you
want to persist in this argument: "what object should mean across
languages", I direct you to:
http://c2.com/cgi/wiki?DefinitionsForOo
http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs
They might care a little more for your trolling. (Well, they almost
certainly wouldn't, but I hope you see that there is a great deal of
confusion of what exactly OO means. I honestly don't care.)
A built-in type is NOT an object type as defined by its respective class.

I would be very surprised if the standards described a built-in type as an
object type anyway seems pretty stupid , confusing and unneccessarry when it
can easily be called a built-in type. But I guess all you guys seem to say
it does so I will accpet that is true.

That's because Java and what you would call "OO" languages are
different than C++. In C++, objects with polymorphic behavior, and
objects of user defined types, are not special compared to primitive
types as they are in Java.

For example, in Java, there are the primitive types and the object
types. (Java) object types exist only on the heap. All variables are
primitives, never objects. Such a primitive could be a reference to an
object. You can have a stack variable which is a reference to a (Java)
object, but never a stack variable which is a (Java) object.

In C++, we can talk about the parallels.

class foo {};
foo x;
This line has no parallel in Java. You cannot create a stack variable
which is a user defined type.

foo* y = new foo;
foo& z = y;
All you can do is the analogous of the above two lines. You 'new' the
object from the heap, and you have a stack variable which is a pointer
(aka Java 'reference') to the object.

In Java, there is a strict separation between user defined types and
primitive types. In Java, all variables are primitives, and all user
defined types are (Java) object types, which are allocated only from
the heap. In C++, there is no such dichotomy. All user defined types
are object types. All primitives are object types. All (named)
variables are objects, and all things allocated off the heap are
objects. There is no special magic that distinguishes between them,
unlike in Java. I can have a C++ polymorphic object or user defined
object on the stack, and on the heap. I can also have a primitive int
object on the stack, and a primitive int object on the heap.

Does this make C++ not OO? I would argue that C++ still natively
supports all of the important parts of OO, though I recognize that
others would disagree with me. Again, see:
http://c2.com/cgi/wiki?DefinitionsForOo
http://c2.com/cgi/wiki?NobodyAgreesOnWhatOoIs
Again, do I particularly care? No.
 
J

Juha Nieminen

Paul said:
A built-in type is NOT an object type as defined by its respective class.

Care to give some actual arguments why that is so, besides the fact
that built-in types cannot be inherited from (as already stated)?
 
J

Juha Nieminen

In comp.lang.c++ Paul said:
What part of "you lack such knowlege of the language" do you not understand
to be an insult?

If someone told me that I lack knowledge on quantum mechanics, which is
absolutely true, why would I feel insulted? I *do* lack a lot of knowledge
about quantum mechanics. Someone stating so, especially after I openly have
admitted so, would simply be telling the truth. Where exactly is the insult?

You clearly stated that you don't know about member function pointers.
Hence, rather obviously, you lack knowledge about them. Hence what I said
was a true statement.
Don't bother replying because I'll just tell ya to **** off anyway.

You are still trying to play the "you insulted me" card, probably so
that you don't have to discuss the actual arguments presented.
 
J

Juha Nieminen

In comp.lang.c++ Paul said:
I am not 'claiming' they don't work without objects , I am *telling* you
they don't.

The onus is on you to show us an example of using a virtual function without
an object, since you think it works.

Now you are changing your claim. You claimed in your earlier post that
"virtual function pointers cannot work", without mentioning anything about
objects. Now you are moving the goalposts and changing the claim to
"virtual function pointers cannot be called without an object", which is
a completely different statement.

If you actually *read* what I wrote earlier, I gave you the exact syntax
of how you can create a member function pointer and how you call it with
an object. Nobody claimed that you can *call* the function without an
object. What I said was that you can refer to a member function (in other
words, take its address and assign it to a pointer) without an object,
which would indicate that the function is not, in fact, tied to any
specific object, but a free function which is only tied to a specific
*class*. The function in question takes implicitly an object as
parameter, which is why you have to supply one when you call it (while
the syntax for this is special, it's in principle no different from
calling a regular function which takes an object as parameter in the
regular way).

In other words, there's little difference between this:

class A { public: void foo(); };

and this:

class A {};
void foo(A*);

(The major difference is the scope in which 'foo' is declared. In the
former case 'foo' is specifically tied to the scope of A.)
 
U

Ulrich Eckhardt

Paul said:
Do you want me to list all the C++ built-in types ?

Yep, please provide a list of those C++ types that are defined outside the
C++ standard.


Interesing is also ...
We *are* staying in the C++ context , you are the only one who is
suggesting otherwise.

...while just two postings earlier you suggest
Yup so outside the context of the C++ standards , which is where
we are here.
Remarkable.


What *claims* have I made that the C++ object model conflicts with?

You have claimed that objects contain memberfunctions.

The standards are written in a context that is to define the C++
language. I am certainly not here to try and define the C++ language,
therefore I will not be attempting to write in the context of the
standards.

If there is no well-agreed base where you draw your terminology from,
there is no guarantee either that what you say will be understood in the
way you meant it. Isn't that kind of stupid?

Alot of people around here seem to think:
a) there is some rule that states we can only speak in the context of
the standards

Not only, but discussions about the finer details of a standard should
rather be based on that standard's definitions. When talking about
precisely the C++ object model, general OOP lingo is a bad choice, see
above why it's stupid.

b) any words used in the standard , will also be used be used in same
context here.

The standard defines C++. This newsgroup is about C++. Can you make the
connection? See also my response to your claim a) above.

c) they are capable of defining the C++ language, when they're not.

Interpreting != defining

People do make mistakes and can find the standards confusing, which is a
good reason why we don't speak in that context when having general C++
programming discussions

That may be so, but making claims about the content of the standard should
be made with a greater "technical correctness" than general programming
discussions, exactly because implications of precise definitions are not
easy to understand and change their meaning if you slightly change their
wording.

For example with:
int x;
Its too easy for people to say x is not an integer type because the
standard says an integer type is an object, or whatever argument they
put across.....

x is an instance of an integer type, it is not a type. That distinction
exists in pretty much any language that has a type concept even. You have
been given several explanations of this fact, but you fail to listen.

Obviously x *is* an integer type.

If it was, I could create an alias for that type:

typedef x integer_type;

Try it, explanations are already given above.

To suggest the standards would state otherwise is completely
ridiculous but this does actually happen.

Sorry, pal, but the C++ standard does state otherwise.

Are you suggesting the standards describe a built-in type as an object
type? or just implying it might do in some round about way?

Yes. You have been told that the C++ object model considers even non-class
types as objects. Get over it, it isn't going to change, no matter how
much you bitch and complain that it doesn't make sense [to you, that is].
If you are trying to raise some sort of argument here about built-in
types please make it clear what you are trying to say.

I just intended to remind you of the fact that your expectation ("I would
be very surprised if..") above has been shattered multiple times in this
thread already and that you missed that. I did explicitly not want to
explain it to you again.
 
R

Rui Maciel

Paul said:
I am not 'claiming' they don't work without objects , I am *telling* you
they don't.

The onus is on you to show us an example of using a virtual function
without an object, since you think it works.

You got it backwards. If you claim that they don't work then you are
responsible to provide a concrete case where they don't work, so that
those interested in helping you can analyse your example and, from there,
provide an answer.


Rui Maciel
 
J

James Kanze

[...]
A functions lifetime begins when it's invoked and ends when it
returns,

From where did you get this? In the C++ standard, functions
don't have lifetime. They just are. Only objects have
lifetime, and a function isn't an object.

[...]
The term 'member function' implies it's a member of something.

Yes. The class.
You cannot seriously say it is a member of the code segment.
You cannot say it's a member of a class yet not a member of an
object because this would imply its a static function.

Why?

You continually make assertions with no justification, which are
contrary to the actual text in the C++ standard.

[...]
If a member function is declared in a class, then surely it's
a reasonable interpretation to say that the object type is
defined to 'contain' a member function or the member function
is deifned to be a member of that object type.

Certainly. Given that in this case, object type and class are
synonyms.
Or something along these lines that imply ownership of that
member function.

One doesn't usually use the term ownership for membership, but
the function is certainly a member of the class.
It is more correct to say it is a member of the object. And
this seems like the ONLY fitting explanation.

Once again, you're confusing object and type. The two are quite
distinct: types exist within the compiler (in C++, at
least---other languages do evaluate types at runtime), where as
objects are purely runtime.
 
J

James Kanze

"Pete Becker" <[email protected]> wrote in message
On
2011-01-07 15:15:36 -0500, Juha Nieminen said:
Yup so outside the context of the C++ standards , which is
where we are here. A built-in type is NOT an object type as
defined by its respective class.

An object type is not necessarily a class type. int is an
object type, but not a class type.
I would be very surprised if the standards described a
built-in type as an object type

Why don't you read it and see. An object type is a type which
defines an object: i.e. something other than a function type or
a reference type.
anyway seems pretty stupid ,
confusing and unneccessarry when it can easily be called a
built-in type.

The standard needs a term for the collection of types which are
objects, as opposed to types which are functions or references.
The expression "object type" seems very natural for that.
But I guess all you guys seem to say it does so
I will accpet that is true.

It's vocabulary. Established by consensus or authority. In the
case of the standard, by authority: within the standard, words
mean what the standard defines them to mean. Some common sense
is expected, but given the standard's definition of object
(which, as Pete says, is that of a compiler writer), its use of
"object type" is emminently coherent.
 
J

James Kanze

[...]
Dog is a class
More fully:
Dog is a class,that is the definition of an object type.
If fido is an object, and Dog is a class
How can fido be a Dog , because an object is not a class?

fido has type Dog.
You can juggle these terms around till the cows come home.
But you cannot state that "fido is *not* an object type" because fido is an
object type in the same sense it's a Dog type'

You cannot reasonably state that fido is an object type, because
fido is not a type, it is an object. This is just plain basic
logic.
Consider someone asking the question , what type is fido?
You could reply ... fido is an object type.

No. The type of fido is an object type. fido is an object, not
a type.

Do you understand the difference between types (compiler
entities) and objects (runtime entities)?
 
J

James Kanze

"James Kanze" <[email protected]> wrote in message
[...]
I can understand the concept you express but
a) how do you get the address of a member function?
&ClassName::functionName
Concretely:
struct C { void f(); };
void (C::*pf)() = &C::f;
b) what happens if this member function is virtual?
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.
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 point was to show that a member function can be called
*without * an object.

Whose point, where and when? You're just making things up as
you go along, trying to bluff your way out, rather than just
admitting that you really don't know C++.
 
J

James Kanze

On 01/07/2011 11:35 PM, Paul wrote:

[...]
Ok, there are two functions, C1::f and C2::f, and the pointer really
points to an offset into a vtable (the vtable being part of the object),
which contains the address of the function actually called (not part of
the object).

Maybe. That's one implementation technique. In other
implementations, the pointer actually points to some other
function entirely, which then makes the virtual function call.

The important thing, I think, is that these functions (however
many) live independently of any objects.
 
P

Paul

Garrett Hartshaw said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Garrett Hartshaw said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2011 08:55 PM, Paul wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2011 02:06 PM, Paul wrote:




[...]
I can understand the concept you express but
a) how do you get the address of a member function?

&ClassName::functionName

Concretely:

struct C { void f(); };
void (C::*pf)() = &C::f;

b) what happens if this member function is virtual?

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?

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.


#include <iostream>

class C1 {
public:
virtual void f() {
std::cout << "C1::f" << std::endl;
}
};

class C2 : public C1 {
public:
virtual void f() {
std::cout << "C2::f" << std::endl;
}
};

int main () {
void (C1::*p)() = &C1::f; //create a pointer to a member function

C1 a; //create a object of type C1
C1 * b; //create a object of type pointer to C1

The challenge put forward was to invoke a virtual function without
creating an object. Here you have created an object.
I applaud your abilities nonetheless, assuming the code is correct.


b = new C2(); //allocate a object of type C2

(a.*p)(); //call the member function pointed to
//by p, with &a as this
(b->*p)(); //call the member function pointed to
//by p (virtually), with b as this

return 0;
}

This code prints the following.

C1::f
C2::f

The very nature of virtual functions require objects and perhaps you
have demostrated this.
This was what i was referring when I initially stated 'it won't work
with virtual functions':

"You can take the address of a member function (and assign it to a
function pointer of the proper type), and it will *not* be tied to any
specific object."


The (virtual) member function was *not* tied to a specific object, as it
(the same function) was used by two different objects. If it was *a part
of* the object, you would not be able to have a pointer to it.

With:
(a.*p)(); //call the member function pointed to by p, with &a as this
(b->*p)(); //call the member function pointed to by p (virtually),
with b as this

There are two functions here.
As I understand it you seem to think there is only one function . ????

Ok, there are two functions, C1::f and C2::f, and the pointer really
points to an offset into a vtable (the vtable being part of the object),
which contains the address of the function actually called (not part of
the object). However, if we had another object of (dynamic) type C2
(e.g. C1 * c = new C2(); ), and call the function ( (c->*p)(); ), then
we have 3 objects ( a, b, c ), and only 2 functions ( C1::f, and C2::f
). This would not be possible if the function itself was part of the
object.

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

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 object.
The function is exclusively tied to the object, (*not the class*), the class
is stored on some file on an old dusty computer on the other side of the
world.
After the code is compiled a class no longer exists , a class is a
precompile time entity in C++, a class in C++ is not the same as Java class.

I don't know what is wrong these people who cannot understand this , they
are obviously very very ignorant and confused, please don't be one of them
 
P

Paul

Leigh Johnston said:
Garrett Hartshaw said:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2011 11:35 PM, Paul wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2011 08:55 PM, Paul wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2011 02:06 PM, Paul wrote:





[...]
I can understand the concept you express but
a) how do you get the address of a member function?

&ClassName::functionName

Concretely:

struct C { void f(); };
void (C::*pf)() = &C::f;

b) what happens if this member function is virtual?

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?

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.


#include <iostream>

class C1 {
public:
virtual void f() {
std::cout << "C1::f" << std::endl;
}
};

class C2 : public C1 {
public:
virtual void f() {
std::cout << "C2::f" << std::endl;
}
};

int main () {
void (C1::*p)() = &C1::f; //create a pointer to a member function

C1 a; //create a object of type C1
C1 * b; //create a object of type pointer to C1

The challenge put forward was to invoke a virtual function without
creating an object. Here you have created an object.
I applaud your abilities nonetheless, assuming the code is correct.


b = new C2(); //allocate a object of type C2

(a.*p)(); //call the member function pointed to
//by p, with &a as this
(b->*p)(); //call the member function pointed to
//by p (virtually), with b as this

return 0;
}

This code prints the following.

C1::f
C2::f

The very nature of virtual functions require objects and perhaps you
have demostrated this.
This was what i was referring when I initially stated 'it won't work
with virtual functions':

"You can take the address of a member function (and assign it to a
function pointer of the proper type), and it will *not* be tied to
any
specific object."


The (virtual) member function was *not* tied to a specific object,
as it
(the same function) was used by two different objects. If it was *a
part
of* the object, you would not be able to have a pointer to it.

With:
(a.*p)(); //call the member function pointed to by p, with &a as this
(b->*p)(); //call the member function pointed to by p (virtually),
with b as this

There are two functions here.
As I understand it you seem to think there is only one function . ????

Ok, there are two functions, C1::f and C2::f, and the pointer really
points to an offset into a vtable (the vtable being part of the object),
which contains the address of the function actually called (not part of
the object). However, if we had another object of (dynamic) type C2
(e.g. C1 * c = new C2(); ), and call the function ( (c->*p)(); ), then
we have 3 objects ( a, b, c ), and only 2 functions ( C1::f, and C2::f
). This would not be possible if the function itself was part of the
object.

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++. The address of a
virtual function is contained within a vtable; it doesn't exist within an
object; all that exists within an object is a pointer to the vtable if the
object is of class type and the class contains at least one virtual
function. Objects do not contain member functions (virtual or not);
classes contain member functions (virtual or not).
I don't know what type of implementation you are trying to define here, but
on my implementaion a function is a process that begins when an instruction
is loaded into a cpu register,
A function is normally invoked on the stack and uses stack pointers and/or
offsets to reference any objects within its scope.
A virtual function is a psuedonym for the function that is represented by
the pointer inside the object.
A virtual function does not have an address, a function is not a region of
memory as you seem to think.

A class is a precompile time entity, a function is a runtime entity.
To suggest that a function belongs to a class is complete nonsense, becuase
the class does not even exist when the function is invoked.

You seem to be talking about a function definition , not a function.

This is C++, not Java!.

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

Utter bullshit.
Functions exist in a cpu not in a region of memory.
An object is a region of memory, a function is not a region of memory.
And remeber an object is definately not a function :)

Please don't state I am wrong *again* as if I have previously been proven
wrong about something .
It is apparent you have strange ideas about functions living in memory and
it is indeed more likely to be you that is wrong.

I suggest you read a C++ book or two and stop trolling your ignorance in
this newsgroup wasting people's time.

/Leigh

The level of intelligence displayed by your insult is your problem.
 
G

Garrett Hartshaw

I didn't say 'fido is a type' , I said *fido is an object type*.
I could also say fido is a Dog type.

In the phrase object type, object is a adjective that modifies the
noun type. Therefore, when you said that 'fido is an object type', it
was read the same as 'fido is a type. That type describes an object',
not, as I think you meant, 'fido is an object'.
 
P

Paul

Leigh Johnston said:
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).

/Leigh

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.
The important point here is that an OBJECT contains the pointer, not a
CLASS.
 
P

Paul

James Kanze said:
On 01/07/2011 11:35 PM, Paul wrote:
[...]
With:
(a.*p)(); //call the member function pointed to by p, with &a as this
(b->*p)(); //call the member function pointed to by p (virtually),
with b as this
There are two functions here.
As I understand it you seem to think there is only one function . ????
Ok, there are two functions, C1::f and C2::f, and the pointer really
points to an offset into a vtable (the vtable being part of the object),
which contains the address of the function actually called (not part of
the object).

Maybe. That's one implementation technique. In other
implementations, the pointer actually points to some other
function entirely, which then makes the virtual function call.

The important thing, I think, is that these functions (however
many) live independently of any objects.

The functions are not independant of the objects as James incorrectly
states. The important point is that the object contains a pointer to the
function, whether direct or indirect.
When a function is invoked it exists within a CPU. I don't know what James
is confused about but he seems to think a function is a region of memory or
something. Maybe he thinks C++ has classes in the same context as a java
class because he seems to think the function is part of a class.
In C+ a class is not a runnable entity, a class is basically a set of
declarations grouped together in precompiled code.
The object is the entity on which the member function is invoked, not the
class.
 
G

Garrett Hartshaw

For example with:
int x;
Its too easy for people to say x is not an integer type because the standard
says an integer type is an object, or whatever argument they put across.....
. They think because they are speaking in the context of the standards they
must be correct.
Obviously x *is* an integer type. To suggest the standards would state
otherwise is completely ridiculous but this does actually happen. These
people usually quote some text out of context, which is an indirect
misinterpreatation of the standards. There are quite a few direct
misinterpretations too.

Actually, 'x' is both an integer and an object. 'int' is both an
integer type (type that describes an integer) and object type (type
that describes an object).
 

Ask a Question

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

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

Ask a Question

Members online

No members online now.

Forum statistics

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

Latest Threads

Top