Re: A suggestion
On 14 jan, 15:56, "Paul" <pchris...@yahoo.co.uk> wrote:
"Michael Doubez" <michael.dou...@free.fr> wrote in message
news:bff38087-f8ce-4fe2-aa2a-d8d2c5a70134@d7g2000vbv.googlegroups.com...
On 13 jan, 20:28, "Paul" <pchris...@yahoo.co.uk> wrote:
"Michael Doubez" <michael.dou...@free.fr> wrote in message
news:8063b8f2-2170-40d2-a790-7271d6b10f7d@k30g2000vbn.googlegroups.com.=
...
On 13 jan, 13:12, Stuart Redmann <DerTop...@web.de> wrote:
I just read some of the follow-ups in one of your recent threads
("Newbies don't learn C++ Optionen"), and I glimpsed something that
caught my attention. One of the points in the discussion was whethe=
r a
member function is "part of" an object or not (the "member function=
s"
thread), where "part of" could be interpreted quite differently
depending on the personal point of view of the reader.
A scenario where a member function will most probably be considered=
as
"part of" an object by everyone would be if it was possible to give
each object a separate "copy" of the same member function, so that
each object can modify it (self-modifying code).
A copy of what ? In the c++ model, functions are not object and thus
cannot be contained within a object. You can store objects (ex:
function pointer or lambda) that achieves what you say but they are
member objects, not member functions.
An object is the concept of a data structure which consists of memb=
er
data
and member functions. This is as much a fact as the fact that the sky =
is
blue.
No it is not, except in vulgarisation magazines. A more precise
definition is "an object is an instance of the data structure and
behaviour defined by the object's class". You cannot make abstraction
of the class concept, otherwise, you don't have the model for the
object's state, methods and interaction; even if the class is not
expressed by the language (in some languages where functions are in
fact data members, like in javascript).
I don't abstract the class I have stated many times that an object is
defined by the class.
Whether you call it objects behaviour , method , or member function you
cannot deny that the member function is the objects behaviour.
C++ was designed to be, or support, object orientated programing in th=
e
context of my above definition. This is the main reason why member
functions
exist and this is primarily what a member function is used for. Any us=
e
of a
member function, other than as an objects member function, is not i=
ts
primary intended use.
And I cannot call a function if I don't have an instance of the
parameters. That doesn't make the function part of the parameters.
For this reason alone a member function is part of an object as much a=
s
the
sky is blue.
Actually, it is not but I won't talk about dipole physics here :)
The sky is blue, obviously in daytime( for those who choose to observe th=
e
sky at night)
I don't know what color the sky is in your world, if not blue.
I see it blue all right but I know it is composed of layers of gases
that are not blue.
C++ did *not* set out to support the idea that an object was simply a
region
of stroage and did not contain member functions. This is simply bolloc=
ks.
The first name of C++ (1979) was C With class
Seehttp://www2.research.att.com/~bs/hopl2.pdf
<quote>
Even though support of concurrency and Simula-s tyle simulations was a
primary aim of C with
Classes, the language contained no primitives for expressing
concurrency; rather, a combination
of inheritance (class hierarchies) and the ability to define class
member functions with special
meanings recognized by the pre-p rocessor was used to write the
library that supported the desired
styles of concurrency.
</quote>
Are you trying to suggest that C++ does not support OOP?
I can provide a hell of alot of quotations that prove C++ does support OO=
P,
if you really want to raise an argument about this.
That is not what I said, I answer that indeed C++ *did* set out to
support the idea that an object was simply a region of storage, from
the very begining.
And commenting code from 1980
<quote>
Clearly, the most important aspect of C with Classes - and later of C+
+ - was the class concept.
Many aspects of the C with Classes class concept can be observed by
examining a simple example
from [Stroustrup,1980a]:
class stack {
char s[SIZE]; /* array of characters */
char * min; /* pointer to bottom of stack */
char * top; /* pointer to top of stack */
char * max; /* pointer to top of allocated space */
void new(); /* initialization function (constructor) */
public:
void push(char);
char pop();
};
A class is a user-d efined data type. A class specifies the type of
the class members that define the
representation of a variable of the type (an object of the class),
specifies the set of operations
(functions) that manipulate such objects, and specifies the access
users have to these members.
Member functions are typically defined ''elsewhere:''
</quote>
That's pretty explicit. I won't quote the wholde document and I engage
you to read it.
What are you supposed to be proving with this quote?
Again , are you suggesting C++ does not support OOP?
It does not support *your* definition of OOP.
People can argue the sky is not blue and its only the refracted light
that
enters our eyeballs that appears to be blue. But they are wrong, the s=
ky
*IS* blue.
Actually the dipoles of the high atmosphere vibrate and emit all
colour but inversoerse proportionnal to the power of 4 of the wave
length. Thus blus is predominates.
So the sky is blue? or blus? Make your mind up earlier you said the sky
wasn't blue.
What actually is the colour of the sky in your world?
The color of difracted light.
There is also the factor that our human eyes perceives some coulours
better than other.
People can argue that a member function is not part of an object becau=
se
the
opcode of the function is not actually stored inside the object. But t=
hey
are wrong because an object *does* contain functions.
In the conext of C++, functions are member in the same sense as
someone is the member of a club. Being a member of a clud does't me
the club contains you. They are the privileged function that can
access all members and even can use the this keyword in their
definition.
If you are a member of something you belong to it , or are part of it,
associated with it . Whatever term you use it just seems like pernickety
pedantic babbling to argue against this general meaning.
You see a blue sky. I see difracted light. From my point of view, blue
is not an intrinsec attribute of the sky.
The fact that a small group of people cannot understand the obvious an=
d
misinterpet the standards by quoting out of context does not make them
correct.
Please do not be influenced by their idiotic and moronic way of thinki=
ng.
:)
Repeating something like a psittacidea doesn't make it true.
Are you suggesting something is untrue? If so what?
Are you suggesting something is true? If so what?
This would mean that the compiler had to use some form of dispatch
mechanism for non-virtual member functions, too. I know that no C++
compiler provides such a mechanism, but the C++ standard doesn't
forbid it to do so.
AFAIS this would be some kind of dynamic/multiple instance linkage
which is not covered by the C++ standard. This is no longer C++.
Because something is not covered by the C++ standards does not mean it=
is
not C++. To state this suggests you do not understand what a standard =
is,
or
it's intended purpose.
Something not in the standard of the C++ language is by definition no
longer standard C++ and since it is the only authoritative document on
a language called c++, it is no longer C++.
Because sometihng is UB or IS does not mean it is no longer C++, thats pu=
re
bollocks.
If something is UB, it is noted as such in the standard.
You are another person who doesnt seem to understand what a standard is o=
r
its purpose.
Note: I apologise if I offend anyone with use of the vulgar word bollocks=
..
I'm sure Michael will not be offended if he reads those sort of magazines=
..
:)
I am not a native english speaker. Those words have no emotional
weight for me even if I understand them.
--
Michael