technical correctness

[Paul]

I would guess that the spelling error is the result of being caught
between community and committee. Such errors are not that unusual even for
native English speakers. In James' case he is writing in his third
language. How good is your French and German? You did not know? Well that
speaks volumes for James.

James is probably much better qualified to express an opinion as to the
positions of the majority of other C++ experts than are you. He knows and
is known by a great number of them and his opinions are generally treated
with respect even by those who disagree with him on some issue.

You are deviating from the point, the point is that you and your friend
Francesco raised an argument about the relevant meaning of input. Your made
an attempt to misrepresent the standards, whether this was deliberate or if
you actually think you are correct, I don't know but these
misinterpretations were 100% incorrect. You fail to accept this fact yet
you seem to consider yourself a respected programmer.
You and a few others here like to put yourselves across as respected
programmers and label yourselves with some kind of expert status, however
the quality of technical accuracy you display is very poor quality.


As an example I will quote some of the nonsense I have to deal with:
<snippet ref=
http://groups.google.com/group/alt....sg/e43aa1f655aa7bc9?&q=clear+idea+about+input >

Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard, where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [Note: A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same concept
of this extremely wrong sentence of yours: "function is an integral part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
</ snippet>

It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of an object.

This is a complete misinterpretation of the standards as is your
interpretation of input.
It is completely unbelievable that any person who agrees with these
interpretations can consider themselves a programmer , never mind an expert.

Blab on all you want about respecability in YOUR C++ community but who cares
about respectability in a community that excels only in poor quality. There
is nothing proffessional about misinterpreting the standards and making
technically incorrect statements on internet forums.

 

[Paul]

On 03/01/2011 01:31, Paul wrote:


On 12/31/2010 11:08 AM, Paul wrote:

When he is wrong but will not, and cannot, admit he is wrong, he
can be
nothing more than a wanking idiot.

This is a strong one, himself will come into play I suppose.

I doubt he'll waste his time. If this is the discussion I think
it is, Francis (and others) were simple expressing the consensus
of the C++ communitee (and most other experts).

--
James Kanze

You, who has made a petty attempt to appear intellectual, have failed
miserably by displaying the spelling skills of a 5 year old and I doubt
you are in any position to speak on behalf of 'most experts'.

I would guess that the spelling error is the result of being caught
between community and committee. Such errors are not that unusual even
for native English speakers. In James' case he is writing in his third
language. How good is your French and German? You did not know? Well
that speaks volumes for James.

James is probably much better qualified to express an opinion as to
the positions of the majority of other C++ experts than are you. He
knows and is known by a great number of them and his opinions are
generally treated with respect even by those who disagree with him on
some issue.

You are deviating from the point, the point is that you and your friend
Francesco raised an argument about the relevant meaning of input. Your
made an attempt to misrepresent the standards, whether this was
deliberate or if you actually think you are correct, I don't know but
these misinterpretations were 100% incorrect. You fail to accept this
fact yet you seem to consider yourself a respected programmer.
You and a few others here like to put yourselves across as respected
programmers and label yourselves with some kind of expert status,
however the quality of technical accuracy you display is very poor
quality.


As an example I will quote some of the nonsense I have to deal with:
<snippet ref=
http://groups.google.com/group/alt....sg/e43aa1f655aa7bc9?&q=clear+idea+about+input
Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard, where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [Note: A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same concept
of this extremely wrong sentence of yours: "function is an integral part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
</ snippet>

It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of an
object.

This is a complete misinterpretation of the standards as is your
interpretation of input.
It is completely unbelievable that any person who agrees with these
interpretations can consider themselves a programmer , never mind an
expert.

A function is not part of an *object*; a function can be part of a *class*
though. A *class* is not an *object*.

/Leigh

This guy actually thinks this is correct?

What good is any object without methods or functions? give yourself a shake
please.

 

[Michael Doubez]

On 03/01/2011 01:31, Paul wrote:

I would guess that the spelling error is the result of being caught
between community and committee. Such errors are not that unusual even for
native English speakers. In James' case he is writing in his third
language. How good is your French and German? You did not know? Well that
speaks volumes for James.

James is probably much better qualified to express an opinion as to the
positions of the majority of other C++ experts than are you. He knows and
is known by a great number of them and his opinions are generally treated
with respect even by those who disagree with him on some issue.

You are deviating from the point, the point is that you and your friend
Francesco raised an argument about the relevant meaning of input. Your made
an attempt to misrepresent the standards, whether this was deliberate or if
you actually think you are correct, I don't know but these
misinterpretations were 100% incorrect. You fail to accept this fact  yet
you seem to consider yourself a respected programmer.
You and a few others here like to put yourselves across as respected
programmers and label yourselves with some kind of expert status, however
the quality of technical accuracy you display is very poor quality.

As an example I will quote some of the nonsense I have to deal with:
<snippet ref=http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/e43aa1f6...>

Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard, where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [Note: A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same concept
of this extremely wrong sentence of yours: "function is an integral part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
</ snippet>

It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of an object.

For a given definition of integral part.

- If you mean integral part as "a necessary part of an object" -

If members functions were integral part of an object, you could not
instantiate an object if a member function was not defined. In C++,
the compiler can be designed such that you can declare a member
function without defining it and the program would compile provided
the function definition is not needed.

- If you mean as "the function cannot be called outside an object"

Typically, static member functions are used as any other function and
have the same type as a free functions (ses [basic.compound]/note 45).
They are member functions (albeit static) and are not an integral part
of an object.

On some compilers, you can event call a member function on a NULL
pointer and it works provided you don't use any member. Well, it is UB
so you could argue that the result could have been anything but even
then, it shows something.

This is a complete misinterpretation of the standards as is your
interpretation of input.

You have not included this part and I am not sure about your argument
(and your quoting system makes it hard to read you). In the standard,
there are 2 concepts:
- std::streambuf which provides provides read/write functionalities
from character sequence in a physical devices (disk file, pipe ...).
- std::istream which provides reading and interpreting input from
sequences of characters (provided by a stream - see rdbuf() )

An input succeeds if the input sequence seen by std::istream could
generate an object of the wanted type. The std::streambuf is the one
to handle the eof() and physical input errors.

Typically, the last input before EOF in a file may succeed although
the streambuf encountered EOF to terminate the input. And it is only
the next input which will mark the stream input as failed.

 It is completely unbelievable that any person who agrees with these
interpretations can consider themselves a programmer , never mind an expert.

Well, you cannot believe it. Which is a good thing: either you are
right and all will learn from you or you are wrong and as such on the
brink of discovering something.

Blab on all you want about respecability in YOUR C++ community but who cares
about respectability in a community that excels only in poor quality. There
is nothing proffessional about misinterpreting the standards and making
technically incorrect statements on internet forums.

I have not seen anybody trying to make you accept their authority but
going against a large group of professionals without strong arguments
should be a hint.

 

[Paul]

On 03/01/2011 13:20, Paul wrote:

message On 03/01/2011 01:31, Paul wrote:




On 12/31/2010 11:08 AM, Paul wrote:

When he is wrong but will not, and cannot, admit he is wrong, he
can be
nothing more than a wanking idiot.

This is a strong one, himself will come into play I suppose.

I doubt he'll waste his time. If this is the discussion I think
it is, Francis (and others) were simple expressing the consensus
of the C++ communitee (and most other experts).

--
James Kanze

You, who has made a petty attempt to appear intellectual, have
failed
miserably by displaying the spelling skills of a 5 year old and I
doubt
you are in any position to speak on behalf of 'most experts'.

I would guess that the spelling error is the result of being caught
between community and committee. Such errors are not that unusual
even
for native English speakers. In James' case he is writing in his
third
language. How good is your French and German? You did not know? Well
that speaks volumes for James.

James is probably much better qualified to express an opinion as to
the positions of the majority of other C++ experts than are you. He
knows and is known by a great number of them and his opinions are
generally treated with respect even by those who disagree with him on
some issue.



--
Note that robinton.demon.co.uk addresses are no longer valid.


You are deviating from the point, the point is that you and your
friend
Francesco raised an argument about the relevant meaning of input. Your
made an attempt to misrepresent the standards, whether this was
deliberate or if you actually think you are correct, I don't know but
these misinterpretations were 100% incorrect. You fail to accept this
fact yet you seem to consider yourself a respected programmer.
You and a few others here like to put yourselves across as respected
programmers and label yourselves with some kind of expert status,
however the quality of technical accuracy you display is very poor
quality.


As an example I will quote some of the nonsense I have to deal with:
<snippet ref=
http://groups.google.com/group/alt....sg/e43aa1f655aa7bc9?&q=clear+idea+about+input




Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard,
where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access,
and
manipulate objects. An object is a region of storage. [Note: A
function
is not an object, regardless of whether or not it occupies storage in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same
concept
of this extremely wrong sentence of yours: "function is an integral
part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
</ snippet>

It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of an
object.

This is a complete misinterpretation of the standards as is your
interpretation of input.
It is completely unbelievable that any person who agrees with these
interpretations can consider themselves a programmer , never mind an
expert.


A function is not part of an *object*; a function can be part of a
*class* though. A *class* is not an *object*.

/Leigh

This guy actually thinks this is correct?

What good is any object without methods or functions? give yourself a
shake please.

Of course I am correct. An object is an *instance* of a class; an object
is not a class. A class is a compile time artefact; an object is a
runtime artefact.

More formally (in C++) an object is a region of storage, slightly less
formally an object is an instance of a *type* (which includes classes),
for example instances of built-in types are also objects:

int integerObject;

/Leigh

An object can and usually does contain functions or methods.
End of story mate there is no argument here.

 

[Paul]

On 03/01/2011 01:31, Paul wrote:

I would guess that the spelling error is the result of being caught
between community and committee. Such errors are not that unusual even
for
native English speakers. In James' case he is writing in his third
language. How good is your French and German? You did not know? Well
that
speaks volumes for James.

James is probably much better qualified to express an opinion as to the
positions of the majority of other C++ experts than are you. He knows
and
is known by a great number of them and his opinions are generally
treated
with respect even by those who disagree with him on some issue.

You are deviating from the point, the point is that you and your friend
Francesco raised an argument about the relevant meaning of input. Your
made
an attempt to misrepresent the standards, whether this was deliberate or
if
you actually think you are correct, I don't know but these
misinterpretations were 100% incorrect. You fail to accept this fact yet
you seem to consider yourself a respected programmer.
You and a few others here like to put yourselves across as respected
programmers and label yourselves with some kind of expert status, however
the quality of technical accuracy you display is very poor quality.

As an example I will quote some of the nonsense I have to deal with:
<snippet
ref=http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/e43aa1f6...>

Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard, where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [Note: A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same concept
of this extremely wrong sentence of yours: "function is an integral part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
</ snippet>

It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of an
object.

For a given definition of integral part.

test


- If you mean integral part as "a necessary part of an object" -


If members functions were integral part of an object, you could not
instantiate an object if a member function was not defined. In C++,
the compiler can be designed such that you can declare a member
function without defining it and the program would compile provided
the function definition is not needed.

- If you mean as "the function cannot be called outside an object"

Typically, static member functions are used as any other function and
have the same type as a free functions (ses [basic.compound]/note 45).
They are member functions (albeit static) and are not an integral part
of an object.

On some compilers, you can event call a member function on a NULL
pointer and it works provided you don't use any member. Well, it is UB
so you could argue that the result could have been anything but even
then, it shows something.

This is a complete misinterpretation of the standards as is your
interpretation of input.

You have not included this part and I am not sure about your argument
(and your quoting system makes it hard to read you). In the standard,
there are 2 concepts:
- std::streambuf which provides provides read/write functionalities
from character sequence in a physical devices (disk file, pipe ...).
- std::istream which provides reading and interpreting input from
sequences of characters (provided by a stream - see rdbuf() )

An input succeeds if the input sequence seen by std::istream could
generate an object of the wanted type. The std::streambuf is the one
to handle the eof() and physical input errors.

Typically, the last input before EOF in a file may succeed although
the streambuf encountered EOF to terminate the input. And it is only
the next input which will mark the stream input as failed.

It is completely unbelievable that any person who agrees with these
interpretations can consider themselves a programmer , never mind an
expert.

Well, you cannot believe it. Which is a good thing: either you are
right and all will learn from you or you are wrong and as such on the
brink of discovering something.

Blab on all you want about respecability in YOUR C++ community but who
cares
about respectability in a community that excels only in poor quality.
There
is nothing proffessional about misinterpreting the standards and making
technically incorrect statements on internet forums.

I have not seen anybody trying to make you accept their authority but
going against a large group of professionals without strong arguments
should be a hint.

 

[Paul]

On 03/01/2011 14:01, Leigh Johnston wrote:
On 03/01/2011 13:58, Paul wrote:

On 03/01/2011 13:20, Paul wrote:

message On 03/01/2011 01:31, Paul wrote:





On 12/31/2010 11:08 AM, Paul wrote:

When he is wrong but will not, and cannot, admit he is
wrong, he
can be
nothing more than a wanking idiot.

This is a strong one, himself will come into play I suppose.

I doubt he'll waste his time. If this is the discussion I think
it is, Francis (and others) were simple expressing the consensus
of the C++ communitee (and most other experts).

--
James Kanze

You, who has made a petty attempt to appear intellectual, have
failed
miserably by displaying the spelling skills of a 5 year old and I
doubt
you are in any position to speak on behalf of 'most experts'.

I would guess that the spelling error is the result of being caught
between community and committee. Such errors are not that unusual
even
for native English speakers. In James' case he is writing in his
third
language. How good is your French and German? You did not know?
Well
that speaks volumes for James.

James is probably much better qualified to express an opinion as to
the positions of the majority of other C++ experts than are you. He
knows and is known by a great number of them and his opinions are
generally treated with respect even by those who disagree with
him on
some issue.



--
Note that robinton.demon.co.uk addresses are no longer valid.


You are deviating from the point, the point is that you and your
friend
Francesco raised an argument about the relevant meaning of input.
Your
made an attempt to misrepresent the standards, whether this was
deliberate or if you actually think you are correct, I don't know
but
these misinterpretations were 100% incorrect. You fail to accept
this
fact yet you seem to consider yourself a respected programmer.
You and a few others here like to put yourselves across as respected
programmers and label yourselves with some kind of expert status,
however the quality of technical accuracy you display is very poor
quality.


As an example I will quote some of the nonsense I have to deal with:
<snippet ref=
http://groups.google.com/group/alt....sg/e43aa1f655aa7bc9?&q=clear+idea+about+input





Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard,
where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access,
and
manipulate objects. An object is a region of storage. [Note: A
function
is not an object, regardless of whether or not it occupies storage
in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same
concept
of this extremely wrong sentence of yours: "function is an integral
part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
</ snippet>

It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of an
object.

This is a complete misinterpretation of the standards as is your
interpretation of input.
It is completely unbelievable that any person who agrees with these
interpretations can consider themselves a programmer , never mind an
expert.


A function is not part of an *object*; a function can be part of a
*class* though. A *class* is not an *object*.

/Leigh

This guy actually thinks this is correct?

What good is any object without methods or functions? give yourself a
shake please.


Of course I am correct. An object is an *instance* of a class; an
object
is not a class. A class is a compile time artefact; an object is a
runtime artefact.


More formally (in C++) an object is a region of storage, slightly less
formally an object is an instance of a *type* (which includes
classes), for example instances of built-in types are also objects:

int integerObject;

/Leigh

An object can and usually does contain functions or methods.
End of story mate there is no argument here.

Wrong. An object does not "contain functions"; as far as C++ is concerned
an object is simply a region of storage. Perhaps this will help your
understanding:

A *function pointer* is an object.
A *function* is not an object.

I repeat: a *class* can contain functions, an *object* does not. An
object can be an *instance* of a class.

/Leigh

You seem to be going around in cirlces and confusing yourself with classes
and instances of classes. Nobody mentioned classes or function definitions
or function pointers. or pointers to functions or pointers to function
pionters

The internal workings of a systems memory,CPU and how the function is stored
within an object is irrellevant. The point is that somehow that object
contains some kind of reference to the function and that function is an
integral part of the object.
As I said before an object can and usually does contain functions or
methods. This is not wrong and you have not given any evidence to support
that. The fact that you think an object cannot contain functions is wrong
however and if you want me to start posting links to prove that, I can do.
But I think it is best that you realise your error and waken up to the
facts.


And why do you feel the need to decorate your text with asterix?

 

[Paul]

On 03/01/2011 01:31, Paul wrote:

I would guess that the spelling error is the result of being caught
between community and committee. Such errors are not that unusual even
for
native English speakers. In James' case he is writing in his third
language. How good is your French and German? You did not know? Well
that
speaks volumes for James.

James is probably much better qualified to express an opinion as to the
positions of the majority of other C++ experts than are you. He knows
and
is known by a great number of them and his opinions are generally
treated
with respect even by those who disagree with him on some issue.

You are deviating from the point, the point is that you and your friend
Francesco raised an argument about the relevant meaning of input. Your
made
an attempt to misrepresent the standards, whether this was deliberate or
if
you actually think you are correct, I don't know but these
misinterpretations were 100% incorrect. You fail to accept this fact yet
you seem to consider yourself a respected programmer.
You and a few others here like to put yourselves across as respected
programmers and label yourselves with some kind of expert status, however
the quality of technical accuracy you display is very poor quality.

As an example I will quote some of the nonsense I have to deal with:
<snippet
ref=http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/e43aa1f6...>

Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard, where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [Note: A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same concept
of this extremely wrong sentence of yours: "function is an integral part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
</ snippet>

It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of an
object.

For a given definition of integral part.

- If you mean integral part as "a necessary part of an object" -


Its quite simple and clear what I mean, I will explain:
Objects can and, more often than not, do contain member functions. To
suggest that objects do not contain functions is complete nonsense.
My newsreader doesnt like to indent your text so sorry about that.






If members functions were integral part of an object, you could not
instantiate an object if a member function was not defined. In C++,
the compiler can be designed such that you can declare a member
function without defining it and the program would compile provided
the function definition is not needed.

- If you mean as "the function cannot be called outside an object"

Typically, static member functions are used as any other function and
have the same type as a free functions (ses [basic.compound]/note 45).
They are member functions (albeit static) and are not an integral part
of an object.

On some compilers, you can event call a member function on a NULL
pointer and it works provided you don't use any member. Well, it is UB
so you could argue that the result could have been anything but even
then, it shows something.


I don't know what you are blabbing on about here but you seem to be
generally trying to argue that objects do not contain functions. As I have
made clear I disagree with this and would go as far as to say its complete
and utter nonsense.

This is a complete misinterpretation of the standards as is your
interpretation of input.

You have not included this part and I am not sure about your argument
(and your quoting system makes it hard to read you). In the standard,
there are 2 concepts:
- std::streambuf which provides provides read/write functionalities
from character sequence in a physical devices (disk file, pipe ...).
- std::istream which provides reading and interpreting input from
sequences of characters (provided by a stream - see rdbuf() )

An input succeeds if the input sequence seen by std::istream could
generate an object of the wanted type. The std::streambuf is the one
to handle the eof() and physical input errors.

Typically, the last input before EOF in a file may succeed although
the streambuf encountered EOF to terminate the input. And it is only
the next input which will mark the stream input as failed.



I was referring to the general discussion where Francis and others argued
that, in the context of the standards, input meant to extract data from the
stream to a variable, I posted a link to this message earlier in this
discussion:
http://groups.google.com/group/alt.comp.lang.learn.c-c++/msg/a70e0c43be410f2e.
This goes against logic and they are misinterpretting the standards.

It is completely unbelievable that any person who agrees with these
interpretations can consider themselves a programmer , never mind an
expert.

Well, you cannot believe it. Which is a good thing: either you are
right and all will learn from you or you are wrong and as such on the
brink of discovering something.


If I am wrong then so must the overwhelming majority of texts on the
internet be wrong.

Blab on all you want about respecability in YOUR C++ community but who
cares
about respectability in a community that excels only in poor quality.
There
is nothing proffessional about misinterpreting the standards and making
technically incorrect statements on internet forums.

I have not seen anybody trying to make you accept their authority but
going against a large group of professionals without strong arguments
should be a hint.

--
Michael

So far all I've seen is a few people who state that objects don't have
functions. I have an overwhelming amount of internet links (all written by
proffessionals) that disagree with YOUR group of proffessionals.

 

[Keith Thompson]

Its quite simple and clear what I mean, I will explain:
Objects can and, more often than not, do contain member functions. To
suggest that objects do not contain functions is complete nonsense.
My newsreader doesnt like to indent your text so sorry about that.

[...]

Your newsreader's failure to quote properly makes it difficult to
figure out who wrote what, so I'll just respond to this one paragraph.
You might want to investigate why your newsreader is malfunctioning,
and perhaps consider using a different one. You might also consider
trimming excessive quoted material.

Yes, what you mean is quite simple and clear. It's also quite wrong, at
least if you use the word "object" as it's defined by the C++ standard.

Quoting the 2003 version of the ISO C++ standard, section 1.8:

An object is a region of storage. [Note: A function is not an
object, regardless of whether or not it occupies storage in the way
that objects do.]

(The word "object" is in italics, indicating that this is the standard's
definition of the word. The second sentence does not directly refute
your claim; I include it for completeness.)

Member functions do not exist within objects. Member functions can
certainly be associated with objects, but they are not contained within
them.

It's possible, I suppose, to construct a consistent model of the C++
language in which member functions are contained within objects. But
doing so would probably require a non-standard meaning for "contained
within", or perhaps for "member function".

The syntax of C++ does tend to imply that member functions are
contained within objects the way member data is ("obj.func()"
vs. "obj.data"), but that's an abstraction, not a reflection of
what's actually going on.

Leigh Johnston also makes a good point. Suppose a class "C" defines a
member function "func", and suppose you have 10 objects of type C:

C arr[10];

If member functions are contained within objects, doesn't that imply
that there are 10 distinct member functions, one for each object C[0]
through C[9]?

If a member function is contained within an object, does the existence
of a member function contribute to the size of that object as reported
by sizeof? Why or why not?

 

[Ulrich Eckhardt]

As an example I will quote some of the nonsense I have to deal with:
<snippet ref=...>

Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard, where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [Note: A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same concept
of this extremely wrong sentence of yours: "function is an integral part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
</ snippet>

It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of an
object.

Why? The precise definition (if such a precise definition exists!) of an
object differs between languages, e.g. in some a type itself is an object,
in others it isn't. The C++ standard defines what "object" means in its
context, hence the title "The C++ object model". The C++ standard is
independent, it doesn't make any claims concerning the meaning of the term
"object" in different contexts and it isn't affected by the meaning of the
term "object" in different contexts either. The C++ standard is not
affected by other standards as it is unaffected by other OOP docs. To put
it differently, the C++ standard doesn't define what an object is, it only
defines what the term "object" means in the context of the C++ standard
itself.

BTW: C++ doesn't claim to be an OOP language, hence for example it doesn't
have methods but memberfunctions. So common OOP jargon can't be applied
unconditionally either.

This is a complete misinterpretation of the standards as is your
interpretation of input.

This may be a questionable use of the term object if you are an OOP
purist/zealot. Nonetheless, it is internally consistent and to me it makes
sense. I believe you could make sense of it if you wanted to, too.

It is completely unbelievable that any person who agrees with these
interpretations can consider themselves a programmer , never mind an
expert.

Blab on all you want about respecability in YOUR C++ community but who
cares about respectability in a community that excels only in poor
quality. There is nothing proffessional about misinterpreting the
standards and making technically incorrect statements on internet
forums.

Insulting people and calling names is professional and respectable
behaviour for an expert? Changing subject whenever an inconvenient
question would have to be answered? I'm not even talking about your
stylistic choices while structuring your postings, because that is
just my taste.


You leave me wondering what prompts your behaviour...

Uli

 

[Paul]

On 03/01/2011 14:34, Paul wrote:

On 03/01/2011 14:01, Leigh Johnston wrote:
On 03/01/2011 13:58, Paul wrote:

On 03/01/2011 13:20, Paul wrote:

message On 03/01/2011 01:31, Paul wrote:






On Dec 31 2010, 1:01 pm, Umut Tabak <[email protected]>
wrote:
On 12/31/2010 11:08 AM, Paul wrote:

When he is wrong but will not, and cannot, admit he is
wrong, he
can be
nothing more than a wanking idiot.

This is a strong one, himself will come into play I suppose.

I doubt he'll waste his time. If this is the discussion I think
it is, Francis (and others) were simple expressing the
consensus
of the C++ communitee (and most other experts).

--
James Kanze

You, who has made a petty attempt to appear intellectual, have
failed
miserably by displaying the spelling skills of a 5 year old and
I
doubt
you are in any position to speak on behalf of 'most experts'.

I would guess that the spelling error is the result of being
caught
between community and committee. Such errors are not that unusual
even
for native English speakers. In James' case he is writing in his
third
language. How good is your French and German? You did not know?
Well
that speaks volumes for James.

James is probably much better qualified to express an opinion
as to
the positions of the majority of other C++ experts than are
you. He
knows and is known by a great number of them and his opinions are
generally treated with respect even by those who disagree with
him on
some issue.



--
Note that robinton.demon.co.uk addresses are no longer valid.


You are deviating from the point, the point is that you and your
friend
Francesco raised an argument about the relevant meaning of input.
Your
made an attempt to misrepresent the standards, whether this was
deliberate or if you actually think you are correct, I don't
know but
these misinterpretations were 100% incorrect. You fail to accept
this
fact yet you seem to consider yourself a respected programmer.
You and a few others here like to put yourselves across as
respected
programmers and label yourselves with some kind of expert status,
however the quality of technical accuracy you display is very poor
quality.


As an example I will quote some of the nonsense I have to deal
with:
<snippet ref=
http://groups.google.com/group/alt....sg/e43aa1f655aa7bc9?&q=clear+idea+about+input






Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard,
where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to,
access,
and
manipulate objects. An object is a region of storage. [Note: A
function
is not an object, regardless of whether or not it occupies
storage in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same
concept
of this extremely wrong sentence of yours: "function is an
integral
part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
</ snippet>

It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of
an
object.

This is a complete misinterpretation of the standards as is your
interpretation of input.
It is completely unbelievable that any person who agrees with
these
interpretations can consider themselves a programmer , never
mind an
expert.


A function is not part of an *object*; a function can be part of a
*class* though. A *class* is not an *object*.

/Leigh

This guy actually thinks this is correct?

What good is any object without methods or functions? give yourself
a
shake please.


Of course I am correct. An object is an *instance* of a class; an
object
is not a class. A class is a compile time artefact; an object is a
runtime artefact.


More formally (in C++) an object is a region of storage, slightly less
formally an object is an instance of a *type* (which includes
classes), for example instances of built-in types are also objects:

int integerObject;

/Leigh

An object can and usually does contain functions or methods.
End of story mate there is no argument here.

Wrong. An object does not "contain functions"; as far as C++ is
concerned an object is simply a region of storage. Perhaps this will
help your understanding:

A *function pointer* is an object.
A *function* is not an object.

I repeat: a *class* can contain functions, an *object* does not. An
object can be an *instance* of a class.

/Leigh

You seem to be going around in cirlces and confusing yourself with
classes and instances of classes. Nobody mentioned classes or function
definitions or function pointers. or pointers to functions or pointers
to function pionters

You are the one who is confused.

The internal workings of a systems memory,CPU and how the function is
stored within an object is irrellevant. The point is that somehow that
object contains some kind of reference to the function and that function
is an integral part of the object.
As I said before an object can and usually does contain functions or
methods. This is not wrong and you have not given any evidence to
support that. The fact that you think an object cannot contain functions
is wrong however and if you want me to start posting links to prove
that, I can do. But I think it is best that you realise your error and
waken up to the facts.

Your wrongness gets worse. Functions live in the text segment; objects
live in the data segment. If you instantiate 100 identical objects do you
think you will create 100 function "references" for each class member
function? Wrong. What about inlined inline member functions? What about
member functions which only have a declaration and no definition? Try
thinking.

By your own words objects are created at runtime so how can it live in any
segment?
You try thinking about that and please dont suggest what I think and mark it
as wrong as if I had said it.

The closest an object gets to storing function "references" is the storage
of a vtable pointer. You can have function pointer member variables but
this is not the same as "an object containing functions".

Who said an object STORES a function? It's only you who is saying that.
I said a member function is an integral part of an object. This is a
completely different concept from what you are saying.

As you seem to think that a function cannot be part of an object(or
instance) do you think all member functions are static?. Obviously they are
not, so wakey wakey.

 

[Paul]

Its quite simple and clear what I mean, I will explain:
Objects can and, more often than not, do contain member functions. To
suggest that objects do not contain functions is complete nonsense.
My newsreader doesnt like to indent your text so sorry about that.

[...]

Your newsreader's failure to quote properly makes it difficult to
figure out who wrote what, so I'll just respond to this one paragraph.
You might want to investigate why your newsreader is malfunctioning,
and perhaps consider using a different one. You might also consider
trimming excessive quoted material.

Yes, what you mean is quite simple and clear. It's also quite wrong, at
least if you use the word "object" as it's defined by the C++ standard.

Quoting the 2003 version of the ISO C++ standard, section 1.8:

An object is a region of storage. [Note: A function is not an
object, regardless of whether or not it occupies storage in the way
that objects do.]

(The word "object" is in italics, indicating that this is the standard's
definition of the word. The second sentence does not directly refute
your claim; I include it for completeness.)

And what part of this do you interpret to mean ... objects cannot contain
member functions?
All this says is that an object is a region of storage.
I can't understand why you think this says something other than that.

Member functions do not exist within objects. Member functions can
certainly be associated with objects, but they are not contained within
them.

An object can contain a method function , yet the two entities can be stored
at different memory locations.
If you would prefer to say a member function was associated with an object
then thats fine , but I think it's more generally considered to be part of
the object.

It's possible, I suppose, to construct a consistent model of the C++
language in which member functions are contained within objects. But
doing so would probably require a non-standard meaning for "contained
within", or perhaps for "member function".

The syntax of C++ does tend to imply that member functions are
contained within objects the way member data is ("obj.func()"
vs. "obj.data"), but that's an abstraction, not a reflection of
what's actually going on.

Why do you think this is not a reflection of what is going on?
Member functions are a part of the object, they are in the objects scope and
have access to that objects members, the way these things are stored in
memory does not change this. You probably dont know where in memory that
object will be stored anyway and you will not be accessing its members using
pointer arithmetic or anything silly like that.

Leigh Johnston also makes a good point. Suppose a class "C" defines a
member function "func", and suppose you have 10 objects of type C:

C arr[10];

If member functions are contained within objects, doesn't that imply
that there are 10 distinct member functions, one for each object C[0]
through C[9]?

If you delve into the calling mechanics of specific systems you will
probably find that calls to a member function are passed and additional
argument which is a reference to their object. virtual functions and derived
classes and overriding functions get more complicated and have lookup tables
and stuff.

If a member function is contained within an object, does the existence
of a member function contribute to the size of that object as reported
by sizeof? Why or why not?

--
Keith Thompson (The_Other_Keith) (e-mail address removed)
<http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Please do not confuse a member function being part of an object as meaning
the functions code is stored within the object in memory.

 

[Paul]

As an example I will quote some of the nonsense I have to deal with:
<snippet ref=...>

Extremely wrong. Functions are NOT part of an object.
Remember that we are speaking in the context of the C++ Standard, where
an "object" is defined as a region of storage:
<citation>
1.8 The C+ + object model [intro.object]
1 The constructs in a C++ program create, destroy, refer to, access, and
manipulate objects. An object is a region of storage. [Note: A function
is not an object, regardless of whether or not it occupies storage in
the way that objects do. ]
</citation>
Please find me a quote from the standard that expresses the same concept
of this extremely wrong sentence of yours: "function is an integral part
of an object".
You wanted to get technical, didn't you? Chapter and verse please.
</ snippet>

It is complete nonsense to assume the standards or any other OOP
documentation implies that functions are not an integral part of an
object.

Why? The precise definition (if such a precise definition exists!) of an
object differs between languages, e.g. in some a type itself is an object,
in others it isn't. The C++ standard defines what "object" means in its
context, hence the title "The C++ object model". The C++ standard is
independent, it doesn't make any claims concerning the meaning of the term
"object" in different contexts and it isn't affected by the meaning of the
term "object" in different contexts either. The C++ standard is not
affected by other standards as it is unaffected by other OOP docs. To put
it differently, the C++ standard doesn't define what an object is, it only
defines what the term "object" means in the context of the C++ standard
itself.

You make out its all very confusing and difficult and undefined but I don't
see it like that at all.
It's a pretty simple concept and there are many texts on OOP if you find it
difficult to understand.

BTW: C++ doesn't claim to be an OOP language, hence for example it doesn't
have methods but memberfunctions. So common OOP jargon can't be applied
unconditionally either.

According to Bjarne Stroustrup:
<quote>
"The reason for this is partly to introduce C++ and partly because C++ is
one of the few languages that supports both data abstraction and
objectoriented
programming in addition to
traditional programming techniques."
</quote>

<snip content="idiotic nonsense">

 

[Paul]

Well static and heap objects live in the data segment, stack based objects
don't, however all of them are created at runtime.

a data segment is created at compile time or link time, so surely anything
that lives there is also created then.

You are wrong though.


struct a { char c; };
struct b { char c; void f() {} };

You will find that sizeof(a) == sizeof(b); i.e. the function "f" (or any
reference to it) is not stored in any b objects, ergo a member function is
*not* an integral part of an object.


I already said that an object can store a vtable pointer which is what is
used for dynamic dispatch; also this is a pointer to a table; there are
not multiple function references stored in an object which is what you are
asserting. Try reading what I wrote; you are the one who is asleep.

I am not saying that objects store multiple function references.
I didn't go into any details of calling mechanics because it only becomes an
issue if you are trying to argue about what is STORED within objects.
Is it impossible to understand that a member function can be part of an
object, yet that function is stored in a different area of memory?

 

[Paul]

If you disagree with what I said you asserted here is a reminder of what
you actually said:

"The point is that somehow that object contains some kind of reference to
the function and that function is an integral part of the object."

I wasn't implying this is the only way it worked, and it certainly isn't an
attempt to go into details about the calling mechanics.
You are trying to argue that functions are not stored inside objects and I
was trying to get away from that scenario by introducing the concept that
functions and object can exist together yet in seperate areas of memory.

The only function references that are *indirectly* contained by objects
are the entries in a vtable a pointer to which will be contained by the
object if the class of which the object is an instance contains any
virtual functions. Any non-virtual class member functions will not have
an entry in any vtable; i.e. NO REFERENCE TO SUCH MEMBER FUNCTIONS EXIST
WITHIN AN OBJECT.

BTW you were not arguing about "virtual member functions"; you were
arguing about "member functions"; don't try and now pretend that you were.

I'm talking about all non static member functions I guess but Im not trying
to argue that they are actually stored within the objects memory as you try
to imply.

How difficult is it to understand the concept that the member function is
part of the object although they live in different places. There will be
some connection between function and object and the exact calling mechanics
are pretty irrellevant.

 

[Keith Thompson]

Its quite simple and clear what I mean, I will explain:
Objects can and, more often than not, do contain member functions. To
suggest that objects do not contain functions is complete nonsense.
My newsreader doesnt like to indent your text so sorry about that.

[...]

Your newsreader's failure to quote properly makes it difficult to
figure out who wrote what, so I'll just respond to this one paragraph.
You might want to investigate why your newsreader is malfunctioning,
and perhaps consider using a different one. You might also consider
trimming excessive quoted material.

Yes, what you mean is quite simple and clear. It's also quite wrong, at
least if you use the word "object" as it's defined by the C++ standard.

Quoting the 2003 version of the ISO C++ standard, section 1.8:

An object is a region of storage. [Note: A function is not an
object, regardless of whether or not it occupies storage in the way
that objects do.]

(The word "object" is in italics, indicating that this is the standard's
definition of the word. The second sentence does not directly refute
your claim; I include it for completeness.)

And what part of this do you interpret to mean ... objects cannot
contain member functions?
All this says is that an object is a region of storage.
I can't understand why you think this says something other than that.

Yes, all it says is that an object is a region of storage. What makes
you think I think it says anything else?

It also says that functions to not necessarily occupy storage in the way
that objects do.

An object can contain a method function , yet the two entities can be
stored at different memory locations.
If you would prefer to say a member function was associated with an
object then thats fine , but I think it's more generally considered to
be part of the object.

Ok, I think I see the source of the confusion. You're using the word
"contain" and the phrase "part of" in a different sense than the rest of
us are.

Let me explain to you again how I (and I think, most other people)
understand the use of those terms.

An object is a region of storage. That's all it is. For something to
be *part of* an object (or, equivalently to be contained within an
object), it has to be somewhere within that region of storage.
Something outside the region of storage may well be associated with the
object, but it's not *part of* the object.

For example, a data member really is *part of* an object.

Can you at least understand that the sense in which a data member
is part of an object does not entirely apply to a member function?

[...]

Please do not confuse a member function being part of an object as
meaning the functions code is stored within the object in memory.

That's exactly what most of us thought you were trying to say, which is
why we've been telling you you're wrong.

 

[Paul]

Segments are defined at compile/link time and created at runtime.


For the last time: a member function is part of a *class* not part of an
*object*.

A function definition is a member of a class or a static member function.
When the member function is used by an object it is integral to that object
only.

This is a C++ newsgroup so the C++ Standard's definitions of "object" and
"member function" are de rigueur here in this newsgroup. An "object" is a
region of storage; not a region of storage plus a collection of member
functions.

/Leigh

Correct the standards do not say that, an object is a region of storage plus
a collection of member functions, and neither did I.
Its pretty simple the member function lives in a diff place but it's still a
part of the object. It's a part of the object because it is within the
objects scope and it has accesss to the objects properties. The member
function also has access to the "this" keyword which is a pointer to the
object which that member function belongs.

 

[Keith Thompson]

How difficult is it to understand the concept that the member function is
part of the object although they live in different places. There will be
some connection between function and object and the exact calling mechanics
are pretty irrellevant.

It's not difficult at all to understand that concept, once you get
around to explaining that that's what you meant.

For most of this discussion, you've been asserting that member
functions are "part of" objects, *not* explaining what you meant,
and asserting that anyone who doesn't agree with your particular
use of terminology must be stupid.

 

[Paul]

Stop repeatedly saying that others are confused when it is you who is
confused. Member functions (references or otherwise) are not "part of an
object"; vtables only apply to virtual member functions and are only used
for dynamic dispatch not static dispatch.

Maybe the problem is that you are unable to express yourself properly on
this medium.

/Leigh

The problem is you can't accept that the member function called on an object
is specific to that object. The physical memory layout is irrellevant as are
the calling mechanics.
Another object of the same class may use the same function but in the second
instance the function does not have priveleges to the first object.

 

[Paul]

It's not difficult at all to understand that concept, once you get
around to explaining that that's what you meant.

For most of this discussion, you've been asserting that member
functions are "part of" objects, *not* explaining what you meant,
and asserting that anyone who doesn't agree with your particular
use of terminology must be stupid.

I'm glad you understand and I have not intended to assert you as stupid , I
am sorry if I did.

 

[Keith Thompson]

I'm glad you understand and I have not intended to assert you as stupid , I
am sorry if I did.

That's a good start. Apology accepted.

Now I suggest you apologize to everyone else you've insulted in
this thread. Admitting the possibility that their point of view
might be as valid as yours would also be a nice gesture.

Please understand that, although I think I understand what you're
saying, I still disagree with you. I think your use of the terms
"contained in" and "part of" are inappropriate in the context of C++.