Re: A suggestion
On 16 jan, 01:19, "Paul" <pchris...@yahoo.co.uk> wrote:
"Michael Doubez" <michael.dou...@free.fr> wrote in message
news:50c41ffb-2953-43eb-a9f6-84f9bd00ca87@q18g2000vbk.googlegroups.com...
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.co=
m...
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 th=
at
caught my attention. One of the points in the discussion was whet=
her
a
member function is "part of" an object or not (the "member
functions"
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 consider=
ed
as
"part of" an object by everyone would be if it was possible to gi=
ve
each object a separate "copy" of the same member function, so tha=
t
each object can modify it (self-modifying code).
A copy of what ? In the c++ model, functions are not object and th=
us
cannot be contained within a object. You can store objects (ex:
function pointer or lambda) that achieves what you say but they ar=
e
member objects, not member functions.
An object is the concept of a data structure which consists of membe=
r
data
and member functions. This is as much a fact as the fact that the sk=
y
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 =
the
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 =
use
of a
member function, other than as an objects member function, is not it=
s
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=
as
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 =
the
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.
..........................................................
If you see it as blue thats possibly because it is blue.
What color do you suggest it is, if not blue?
To take an example, water is blue; it intrinsecally absorbs and
scatter white light into blue color. The gazes in the high atmosphere
are not blue but their interaction and the bias in human eye make it
seen blue.
If you look at a peace or pure water, it is blue while it is not the
same for a peace of the gazes that compose the sky.
In that, if the skype was blue, it would color the perception of the
sun (which would become blueish).
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
bollocks.
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
OOP,
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.
.........................................................................=
.....................
But C++ does not support the idea that an object is *simply* a region of
storage, if this were the case C++ would not support OOP.
It depends on what you put behind that /simply/.
If we limit to the phisical side, from the standard (as quoted) it is
a memory space and it has a type (and a lifetime). In some cases, RTTI
may require to put data in the object to retreive the type (ie. the
information at compile type is not sufficient for type resolution).
Thus, physically, an object is a piece of memory whatever you can
observe in term of (member) function you can apply on this piece of
memory.
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 engag=
e
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.
.............................................................
C++ does support my idea of OOP, the fact that C++ provides member
functions, inheretence , encapsulation and polymorphism is enough to sugg=
est
C++ supports OOP.
What is your idea of OOP? It's seems that your idea of OOP is that an obj=
ect
is a simple region of storage and nothing more.
In french, we have an epression which would translate as "Making the
donkey to have grain".
People can argue the sky is not blue and its only the refracted ligh=
t
that
enters our eyeballs that appears to be blue. But they are wrong, the
sky
*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.
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''=
'''''''''
So answer the question.
What is the color of the sky in your world? (during daytime)
You seem to be unable to determine which color the sky is.
Answered elsewhere.
People can argue that a member function is not part of an object
because
the
opcode of the function is not actually stored inside the object. But
they
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 pernicket=
y
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.
..........................................................
But the sky *is* blue , so how come you cannot see this?
You perceive blue light from the sky and deduce that the sky is blue.
Other people looked at flaty land and deduced eart was flat.
The fact that a small group of people cannot understand the obvious =
and
misinterpet the standards by quoting out of context does not make th=
em
correct.
Please do not be influenced by their idiotic and moronic way of
thinking.
:)
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?
.....................................................
It was you who made the statement I commented on re:
"Repeating something like a psittacidea doesn't make it true."
It was unclear what you were suggesting with this statement. Now it's
apparent you either didn't/don't know what you were talking about or you =
are
deliberately trying to introduce confusion.
Your main claim, repeated ad nauseum, without backing, that member
functions are part of objects.
Well that explains alot.
FYI the term you used ref "vulgarisation magazine" would generally be
considered to mean a pornography magazin
:)
In french it is a synonym of simplification/popularisation.
I don't know how you call such magazine in english.
--
Michael