A suggestion

P

Paul

The calling mechanics described in the above quote make it clear that a
member function is directly associated with an object.
What makes you think the opposite?
Or are you trying to twist the context of 'part of' to mean 'literally
contained within'?

Ok. Lets take OO then. Favorite object, me. I can (1) eat and i may
(2) be eaten. Eating is therefore behavior that can be associated with
me, yes. Does it mean eating is part of me? In what of given two
associations it is part of me?
.....................................................
The eating process belongs to the eater, not the eaten.
:)

Sry about the newsreaders lack of indentation.

I don't like to apply ownership to behaviour as behaviour can be induced or
produced.
....................................................

The only programming language i know a bit where the borders between
behavior and state are dim is Lisp and that language is rather far
from C++.
...................................................

I don't know these languages.
 
P

Paul

Leigh Johnston said:
Leigh Johnston said:
On 14/01/2011 18:13, Paul wrote:

On 14/01/2011 17:21, Paul wrote:

On 14/01/2011 15:33, Paul wrote:



[...]
You are ignoring the very reason a member function exists in
C++. That is to support the OOP concept of an object.

No. C++ (or maybe it was still C with Classes back then) had
member functions before it supported OOP (at least according to
the more frequent definitions of OOP). It's virtual functions
which were introduced to support OOP. According to Booch, C++
without virtual functions would support object based
programming, but not object oriented programming. Polymorphism
is essential for object oriented programming. And although just
about every one who uses the term "object oriented" seems to
have a slightly different definition, most seem to include some
form of polymorphic behavior as a requirement.

--
James Kanze

Ok well fair enough if thats how the progressive history of it all
actually was, I'll accept your word for it.

But with regard to the argument at hand , it doesn't change the
fact
that the member function, virtual or not, is bound to the object in
some
way or another. What other purpose does a member function have but
to be
part of an object? That is simply the purpose of a member function.
Am I missing some other purpose a member function has?


The only binding between an object and a member function is the
vtable
pointer present in an object of class type which includes at least
one
virtual function; an object of class type without any virtual
functions will not have a vtable pointer present; this only
applies to
implementations that use vtables which is likely to be all
implementations in current use.

I disagree. This is not the *only* binding.
The fact that the member function is declared within the objects
class
suggests to me that its bound to any object of that class type.
In a similar tone to the above. The fact that "a class is the
definition
of an object type" suggests that any function declared in said
class is
bound to an object instanciated from that class, by definition.
The fact that the calling syntax requires an object on which to
call the
member function also suggests its bound.

Obviously the above depends on your defintion of bound. And
naturally it
requires a certain level of intelligence to realise its not true for
static members.


Wrong yet again; again in C++ an object is simply a region of storage
(in the data segment or stack);
You really don't have a clue.
Funnily enough your misinterpretation of the standards reminds me of
someone else.
Normally objects are created on the heap, where do this totally
bollocks
idea of an implementation specific program format?

Again it is not a specific program format; "segment" is a computer
science term; "data segment" includes the "heap".
Absolute shite , an implementation is free to name memory segments as it
choses.
a member function after compilation/linking is just machine code in
the text segment no longer existing as a separate entity;

What is this bollocks all about? You could say any part of a program is
*just* machine code.
Dunno what you are on about seperate entities , seperate from what?

Functions (member or not) are compiled into machine code which lives
in the text segment. There is no difference between a member function
and a non-member function as far as the resultant executable is
concerned (it is all just machine code in the text segment).
Again absolute shite.
The invokation mechanism for a member function is different from that of
a non member function.

I never said that invocation of a member function is the same as that of a
non-member function (at least from a syntactical point of view); but you
refuse to accept the fact that a member function is effectively a normal
function with an extra parameter in which is passed an object's "this
pointer".
When discussing invokation of *member functions* at program code level you
need to get implementation specific. The way an implementation decides to
store a member functions opcode is not defined by any standard.
You seem to think that all types of program have the same format, which of
course is not the case.
Also you do not consider static and dynamic libs, how are member functions
stored in all the different formats of lib files?

How can an object and its member function be used from a linked lib? You
think the lib contains a C++ class file?
I said *after* linking; try reading what I said.
I know you said after linking , you need to link the dll in the first place
to get a lib file.
Am I though?
Obviously.

Am I? Again you are forgetting the ultimate proof that *you* are the one
who is spouting bullshit: an inlined member function.

If a member function invocation is inlined then the member function only
exists as machine code in the calling function's definition so how can it
possibly be part of an object? You have failed and continue to fail by
not admitting that you are wrong.
How can you possibly call it part of a class?
Do you now suggest a member function is so called because it is a member of
a program?

You seem totally confused.
 
Ö

Öö Tiib

Ok. Lets take OO then. Favorite object, me. I can (1) eat and i may
(2) be eaten. Eating is therefore behavior that can be associated with
me, yes. Does it mean eating is part of me? In what of given two
associations it is part of me?
....................................................
The eating process belongs to the eater, not the eaten.
:)

Yes ... but i have to behave edible in that process to be eaten ... i
guess.
Sry about the newsreaders lack of indentation.

I don't like to apply ownership to behaviour as behaviour can be induced or
produced.

Most don't like. That's why the primary carrier of behavior in C++ - a
member function is not exactly a part owned by object. It is
associated to that object as its possible behavior. Associated by a
class. Class is also associated to object but not as an owned part of
object. Class is associated as rigid meta-information about object ...
a classification, a type.

C++ is meant to tie a type to each object at moment of birth and never
let to change it. C++ is "strongly typed language". For same reason
member functions are strongly defined by class. When some object has
been tried to be used in some context then language engine checks if
and how the object does classify and if its type fits into that
context. Thanks to run-time polymorphism it is fortunately not too
rigid.

Of course ... C++ developers are sort of anarchists. Most of template
wizardry was invented to break the rules using templates (that rather
clearly weren't meant to be used like they often are). Types are
further softened by using even softer types like boost::variant or
boost::any. Similarly the rigid relations with member functions are
softened by replacing their usage with usage of function objects and
lambdas as carriers of behavior. So ... the objects really can
actively change their type and own or carry behavior in C++ like you
say, but it is not achieved using plain classes and member functions.
 
P

Paul

Ok. Lets take OO then. Favorite object, me. I can (1) eat and i may
(2) be eaten. Eating is therefore behavior that can be associated with
me, yes. Does it mean eating is part of me? In what of given two
associations it is part of me?
....................................................
The eating process belongs to the eater, not the eaten.
:)

Yes ... but i have to behave edible in that process to be eaten ... i
guess.
Sry about the newsreaders lack of indentation.

I don't like to apply ownership to behaviour as behaviour can be induced
or
produced.

Most don't like. That's why the primary carrier of behavior in C++ - a
member function is not exactly a part owned by object. It is
associated to that object as its possible behavior. Associated by a
class. Class is also associated to object but not as an owned part of
object. Class is associated as rigid meta-information about object ...
a classification, a type.

C++ is meant to tie a type to each object at moment of birth and never
let to change it. C++ is "strongly typed language". For same reason
member functions are strongly defined by class. When some object has
been tried to be used in some context then language engine checks if
and how the object does classify and if its type fits into that
context. Thanks to run-time polymorphism it is fortunately not too
rigid.

Of course ... C++ developers are sort of anarchists. Most of template
wizardry was invented to break the rules using templates (that rather
clearly weren't meant to be used like they often are). Types are
further softened by using even softer types like boost::variant or
boost::any. Similarly the rigid relations with member functions are
softened by replacing their usage with usage of function objects and
lambdas as carriers of behavior. So ... the objects really can
actively change their type and own or carry behavior in C++ like you
say, but it is not achieved using plain classes and member functions.
.......................................................................

This seems like a pretty fair assessment of the C++ language. Not so sure I
agree about edible though.
One could appear edible but not sure one could behave edibly :)

It seems C++ is expanding without any clear direction, as you say it used to
be strongly typed and a pretty well defined language. It seems like a
stramash of confusion to me now. It must take a year to develop a compiler
for any new computer system..
 
P

Paul

Leigh Johnston said:
Leigh Johnston said:
On 14/01/2011 21:35, Paul wrote:

On 14/01/2011 18:13, Paul wrote:

On 14/01/2011 17:21, Paul wrote:

On 14/01/2011 15:33, Paul wrote:




[...]
You are ignoring the very reason a member function exists in
C++. That is to support the OOP concept of an object.

No. C++ (or maybe it was still C with Classes back then) had
member functions before it supported OOP (at least according to
the more frequent definitions of OOP). It's virtual functions
which were introduced to support OOP. According to Booch, C++
without virtual functions would support object based
programming, but not object oriented programming. Polymorphism
is essential for object oriented programming. And although just
about every one who uses the term "object oriented" seems to
have a slightly different definition, most seem to include some
form of polymorphic behavior as a requirement.

--
James Kanze

Ok well fair enough if thats how the progressive history of it
all
actually was, I'll accept your word for it.

But with regard to the argument at hand , it doesn't change the
fact
that the member function, virtual or not, is bound to the
object in
some
way or another. What other purpose does a member function have
but
to be
part of an object? That is simply the purpose of a member
function.
Am I missing some other purpose a member function has?


The only binding between an object and a member function is the
vtable
pointer present in an object of class type which includes at least
one
virtual function; an object of class type without any virtual
functions will not have a vtable pointer present; this only
applies to
implementations that use vtables which is likely to be all
implementations in current use.

I disagree. This is not the *only* binding.
The fact that the member function is declared within the objects
class
suggests to me that its bound to any object of that class type.
In a similar tone to the above. The fact that "a class is the
definition
of an object type" suggests that any function declared in said
class is
bound to an object instanciated from that class, by definition.
The fact that the calling syntax requires an object on which to
call the
member function also suggests its bound.

Obviously the above depends on your defintion of bound. And
naturally it
requires a certain level of intelligence to realise its not true
for
static members.


Wrong yet again; again in C++ an object is simply a region of
storage
(in the data segment or stack);
You really don't have a clue.
Funnily enough your misinterpretation of the standards reminds me of
someone else.
Normally objects are created on the heap, where do this totally
bollocks
idea of an implementation specific program format?

Again it is not a specific program format; "segment" is a computer
science term; "data segment" includes the "heap".

Absolute shite , an implementation is free to name memory segments as
it
choses.


a member function after compilation/linking is just machine code in
the text segment no longer existing as a separate entity;

What is this bollocks all about? You could say any part of a
program is
*just* machine code.
Dunno what you are on about seperate entities , seperate from what?

Functions (member or not) are compiled into machine code which lives
in the text segment. There is no difference between a member function
and a non-member function as far as the resultant executable is
concerned (it is all just machine code in the text segment).

Again absolute shite.
The invokation mechanism for a member function is different from that
of
a non member function.

I never said that invocation of a member function is the same as that
of a non-member function (at least from a syntactical point of view);
but you refuse to accept the fact that a member function is
effectively a normal function with an extra parameter in which is
passed an object's "this pointer".
When discussing invokation of *member functions* at program code level
you need to get implementation specific. The way an implementation
decides to store a member functions opcode is not defined by any
standard.
You seem to think that all types of program have the same format, which
of course is not the case.
Also you do not consider static and dynamic libs, how are member
functions stored in all the different formats of lib files?

How can an object and its member function be used from a linked lib? You
think the lib contains a C++ class file?
in C++ a member function is part of a class not part of an object;
in
C++ an object type does not have to be a class type ergo in C++ an
object does not have to be an instance of a class. Member functions
are invoked *on* objects; they are not *part* of objects.

A member function is *declared* in a class, how can the function
itself
be part of a class when the class is simply source code and discarded
after compilation?
I can compile and link an object from a precompiled library, hence
create an object(with member functions) when the class file has been
deleted.

Your narrowmindedness cannot see that a member function can be
considered part of both a class and an object. This is apparent as
you
obviously think it must be one or the other.

You are wrong; member functions are part of classes not of objects;
after compilation/linking member functions and classes cease to exist,
all that is left is machine code in the text segment which includes
the addresses of the start of what were functions during compilation.

So how can its be possible to invoke a member function?
How come I can link and lib that contains member functions?

I said *after* linking; try reading what I said.
I know you said after linking , you need to link the dll in the first
place to get a lib file.

DLLs and DLL import libraries are orthogonal to this discussion; DLLs and
DLL import libraries treat exported member and non-member functions
identically (on all implementations I have used at least); i.e. DLLs are
usually C++ agnostic. The start address of what was a member or
non-member function during compilation/linking of the DLL will be included
in the built DLL/ DLL import library. Also DLLs can be used without an
import library on some platforms at least; there will be a mechanism to
convert an exported function name/ordinal to a callable address.
No a DLL call to a member function is still invoked on an object:
pDLLObject.->mfunc();
You are the one who is confused; a member function is so called because it
is a member of a class and this has been stated to you many times and is
becoming tiresome. After compilation/linking member functions cease to
exist as separate entities as they become just machine code in the text
segment alongside non-member functions.

Crap. Because a class also ceases to exist after compilation/linking.
Therefore you're argument collapses.
However the calling mechanics in the program code still bind the member
function to the object.
The fact that member functions can be inlined totally invalidates your
claim that member function are part of objects for any sane definition of
the term "part of". Again we are talking about C++ objects not general
OOP objects.
Nonsense, if a function is inlined then it's simply no longer a function.
..
 
G

Garrett Hartshaw

Garrett Hartshaw said:
.
On 13 Jan., "Paul" wrote:
An object is the concept of a data structure which consists of
member data and member functions. [snip]
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.

As far as I remember, C++ was also designed to be an extension
of
the
C programming language. From this point of view it seems as if the
exisiting features of C have been expanded in such a way that
we
get
object-orientation: The "class"-feature can be considered just
as
the
expansion of the "struct"-feature with access modifiers, and member
functions can be considered as special functions with an hidden
argument.

From the point of view of a programmer who uses the objects, the
member functions are most often considered as part of the
object.
If I
type the member access operator in my IDE, it will pop up a
list
of
member variables and member functions. The IDE would not do
this
if it
didn't consider the methods also as "part" of the object. But this is
just another view-point.

Hally...loo...yah.. One person has actually acknowledged this.

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.
I'm not so sure. Maybe we should ask Bjarne.

I don't think Bjarne would impose such a restriction on the language.
In fact here is one quote from Bjarne. Many quotes can be found
on
the
internet explaining this exact same description of how a member function
works in C++:

"An object of a C++ class is represented by a contiguous region
of
memory. A
pointer to an object of a class points to the first byte of that region of
memory. The compiler turns a call of a member function into an ''ordinary''
function call with an ''extra'' argument; that ''extra'' argument is a
pointer to the object for which the member function is called."

It's clear that Bjarne does not dis-associate member functions
and
objects.
The opposite seems to be the consensus for the majority of this
group.

It's clear Bjarne also believes that an object is a region of memory
(storage) and that the compiler treats member function as regular
functions with different syntax. E.g. it changes this:

Yes he does believe an object is a region of memory because an object *is* a
region of memory.
But what you have said about a compiler treating a member function as a
regular function is not true.

What he says clarifies a member function is *not* the same as a regular
function. When talks of changing the function call to an ordinary function
call he is describing the calling mechanics and the very fact that he says
the function call is converted to an ordinary call implies the function is
not ordinary.
class C {
void fun();
};

into something like this:

class C;
void fun( C * );

And then changes this:

C obj;
obj.fun();

into this:

C obj;
fun( &obj );

I don't think it's possible to explain the calling mechanisms using C++
code.

He's saying that it is simply syntatic sugar, but that they are the
same thing otherwise.
 
P

Paul

He's saying that it is simply syntatic sugar, but that they are the same
thing otherwise.

If you are suggesting this is what Bjarne Stroustrup is saying in the
following then I disagree.

"An object of a C++ class is represented by a contiguous region of memory. A
pointer to an object of a class points to the first byte of that region of
memory. The compiler turns a call of a member function into an ''ordinary''
function call with an ''extra'' argument; that ''extra'' argument is a
pointer to the object for which the member function is called."

Bjarne says that the 'function call' is turned into an ordinary 'function
call'.
He is talking about calling mechanics not syntax.
 
Ö

Öö Tiib

Yes ... but i have to behave edible in that process to be eaten ... i
guess.





Most don't like. That's why the primary carrier of behavior in C++ - a
member function is not exactly a part owned by object. It is
associated to that object as its possible behavior. Associated by a
class. Class is also associated to object but not as an owned part of
object. Class is associated as rigid meta-information about object ...
a classification, a type.

C++ is meant to tie a type to each object at moment of birth and never
let to change it. C++ is "strongly typed language". For same reason
member functions are strongly defined by class. When some object has
been tried to be used in some context then language engine checks if
and how the object does classify and if its type fits into that
context. Thanks to run-time polymorphism it is fortunately not too
rigid.

Of course ... C++ developers are sort of anarchists. Most of template
wizardry was invented to break the rules using templates (that rather
clearly weren't meant to be used like they often are). Types are
further softened by using even softer types like boost::variant or
boost::any. Similarly the rigid relations with member functions are
softened by replacing their usage with usage of function objects and
lambdas as carriers of behavior. So ... the objects really can
actively change their type and own or carry behavior in C++ like you
say, but it is not achieved using plain classes and member functions.
......................................................................

This seems like a pretty fair assessment of the C++ language. Not so sure I
agree about edible though.
One could appear edible but not sure one could behave edibly :)

This is carnivore talking in you. ;) Actually food, eater and
immediate surroundings participate in eating process. Food gets
destroyed and its details become exposed; some are consumed by eater
some will be left lying around in surroundings. Of course the eater is
actively orchestrating it so eating is its "method" to gain nutrition,
but during doing it he needs other participants to behave as well.
It seems C++ is expanding without any clear direction, as you say it used to
be strongly typed and a pretty well defined language. It seems like a
stramash of confusion to me now. It must take a year to develop a compiler
for any new computer system..

C++ is expanding in several directions at once to better support
different programming paradigms. For developers it is good, since
developers can pick what they use and what they don't from the pile of
features.

For compiler maker it is rather huge work to support everything.
Still ... several of popular C++ compilers are open source and written
mostly in C (g++ and CLang). That makes it possible to reuse their
code in big part when making a new C++ compiler compiling for a new
system. It is rather unlikely for C++ to disappear. Interpreted
languages are inefficient, JIT-compiling languages assume that
platform has spare power to JIT-compile.
 
G

Garrett Hartshaw

If you are suggesting this is what Bjarne Stroustrup is saying in the
following then I disagree.

"An object of a C++ class is represented by a contiguous region of memory. A
pointer to an object of a class points to the first byte of that region of
memory. The compiler turns a call of a member function into an ''ordinary''
function call with an ''extra'' argument; that ''extra'' argument is a
pointer to the object for which the member function is called."

Bjarne says that the 'function call' is turned into an ordinary 'function
call'.
He is talking about calling mechanics not syntax.

He is saying that the calling mechanics are the same, and that when
the compiler sees a member function call, it translates it to an
ordinary function and then emits machine code. If a member function
was anything more than syntactic sugar, the compiler would be unable
to change it to a nomal function call.
 
P

Paul

Garrett Hartshaw said:
He is saying that the calling mechanics are the same, and that when the
compiler sees a member function call, it translates it to an ordinary
function and then emits machine code. If a member function was anything
more than syntactic sugar, the compiler would be unable to change it to a
nomal function call.

Erm no, I think you are misnterpreting this completely.
The function is a member function and Bjarne doesn't suggest it's an
ordinary function. What he says is that the 'function call' is converted to
and ordinary 'function-call', that is he explaining the mechanics of a non
virtual member function invokation.
He certainly doen'tt say the calling mechanics are the same, as you have
stated.
I don't know what this term 'syntax sugar' is supposed to mean, I suggest
you stop using it in technical forums as TBH it's simply a gay term.
 
P

Paul

Leigh Johnston said:
Thanks for confirming that you are either an obnoxious troll or a hormonal
teenager (or possibly both); you are certainly ignorant and bigoted as
your illustrated by your repeated homophobic rants and lack of technical
understanding.

/Leigh

You're the only one doing any ranting here. :)
 
M

Michael Doubez

 "A class" (like in class-based OO languages) makes no sense in
Javascript.

IIRC, in javascrpit OO works on the pattern

function MyClasse(parameter1, parameter2) {
this.attribute1 = parameter1;
this.attribute2 = parameter2;

this.method = function() {
alert("Attributs: " + this.attribute1 + ", " +
this.attribute2);
}
}

var obj = new MyClasse("value1", "value2");
obj.method();

The class does exists although, like in mainy dynamic typing language,
it is not formalized at the language level.

When working on the DOM of a page, you still have to lookup the
members and the methods available at the nodes (in fact you do look up
the type of the node); that is the class.
Class is other (less flexible) concept than that language
supports. Javascript's prototypes are not classes. Objects have full
freedom to change their data model and behavior during their lifetime
(and may do same to other objects that they know of).

In theory, but in practice, if it they change their interface, they
become useless because you don't know what method you can call. I
won't start the dynamic typing vs static typing all over again, my
only point is that this feature is mainly useful at the development
stage, not at runtime (where a static typing language can then achieve
the same).
The objects of
Javascript are not forced to stay in prototype where they started in
and so they simply have no class.

They don't have to but, as I said, in practice you do.
As an example, in prototype.js you define classes (among other
things).

In fact, I don't see how you can speak about inheritance without class
and inheritance is (arguably) a base concept of OOP.

Actually, in the implementation, you can work with objects (like in
smalltalk where you can change base of an object, and I suspect
prototype.js does the same) but IMHO metaobjects are just an
implementation of classes.
 
M

Michael Doubez

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.








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.
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.
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.
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.
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.
Are you suggesting something is untrue? If so what?

Are you suggesting something is true? If so what?
Because sometihng is UB or IS does not mean it is no longer C++, thats pure
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 or
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.
 
P

Paul

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.








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?


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

C++ does support my idea of OOP, the fact that C++ provides member
functions, inheretence , encapsulation and polymorphism is enough to suggest
C++ supports OOP.

What is your idea of OOP? It's seems that your idea of OOP is that an object
is a simple region of storage and nothing more.

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.

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

But the sky *is* blue , so how come you cannot see this?

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.
Because sometihng is UB or IS does not mean it is no longer C++, thats
pure
bollocks.

If something is UB, it is noted as such in the standard.
......................................................................
If something is undefined behaviour the it is *undefined*. This does not
mean it is not valid C++, as is the case with implementation specific C++
You are another person who doesnt seem to understand what a standard is or
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.

.......................................

Well that explains alot.
FYI the term you used ref "vulgarisation magazine" would generally be
considered to mean a pornography magazine.
 
P

Paul

"A class" (like in class-based OO languages) makes no sense in
Javascript.

IIRC, in javascrpit OO works on the pattern

function MyClasse(parameter1, parameter2) {
this.attribute1 = parameter1;
this.attribute2 = parameter2;

this.method = function() {
alert("Attributs: " + this.attribute1 + ", " +
this.attribute2);
}
}

var obj = new MyClasse("value1", "value2");
obj.method();

The class does exists although, like in mainy dynamic typing language,
it is not formalized at the language level.
..................................................................
I see where you are coming from in associating this with a C++ class but
this is not the case in Javascript.
In Javascript all objects are created from a simple built-in Object.
...............................................................


When working on the DOM of a page, you still have to lookup the
members and the methods available at the nodes (in fact you do look up
the type of the node); that is the class.
.................................................................
IIRC a DOM node, or node type, is defined in an XML namespace. This is not a
good example to describe the mechanics of JS objects.
.................................................................
Class is other (less flexible) concept than that language
supports. Javascript's prototypes are not classes. Objects have full
freedom to change their data model and behavior during their lifetime
(and may do same to other objects that they know of).

In theory, but in practice, if it they change their interface, they
become useless because you don't know what method you can call. I
won't start the dynamic typing vs static typing all over again, my
only point is that this feature is mainly useful at the development
stage, not at runtime (where a static typing language can then achieve
the same).
.......................................................................

Its not uselss to add new properties to an object at runtime.
It is possible to examine a JS object and determine what properties exist,
and this technique is often used in DOM programming.
.......................................................................
The objects of
Javascript are not forced to stay in prototype where they started in
and so they simply have no class.

They don't have to but, as I said, in practice you do.
As an example, in prototype.js you define classes (among other
things).

In fact, I don't see how you can speak about inheritance without class
and inheritance is (arguably) a base concept of OOP.

Actually, in the implementation, you can work with objects (like in
smalltalk where you can change base of an object, and I suspect
prototype.js does the same) but IMHO metaobjects are just an
implementation of classes.

--
Michael
.....................................................................

I don't know what this file 'prototype.js' is, AFAIK a JS prototpye object
is built into the languge and is not available as a JS file.
But in JS all objects are built upon the built-in basic Object type, not
classes.
 
U

Ulrich Eckhardt

Paul said:
If you think something is of no relevance to the standards , why do you
persist in talking about the standard.

What is it that I consider of no importance to the standards? Seriously,
it is far from clear here since you don't get your plural/singular right
again.

Here you twist things around to suggest that C++ has the freedom to not
require any implementation.

Read again, I never said that. Something seems to have been lost between
the monitor and your mind....
Don't speak rubbish, the implementation
comes first in any program design.

There are design models that disagree with this, what's the point anyway?
The C++ standard does not go into any details about implementation
specific C++, this does not mean that implementation specific C++ is,
illegal or unworthy of any discussion.

What is this "implementation specific C++"?

You are restricting the the discussion to the scope of the C++
standards.

No, I'm not restricting the discussion to that scope. I'm only pointing
out that if someone restricts a statement to a certain scope, you can not
argue against that outside the scope. Do you understand why?

C++ is not *free* as you wrongly imply.

Read again, and this time try not to interpret any implications into it.
If you don't understand this, as it is rather philosophical, just ask, but
don't read things into it that are just not there.

No you are wrong. The C++ standard does not go into any details about
the mechanics of calling member functions. Therefore the C++ standard
does not fully define the implementation of a C++ program on any given
implementation.

Talking about the C++ object model, it defines what can be members of an
object. Are member functions listed as allowed members there?

Can you quote where it does ?
Yes.


Of course it follows. It's obvious C++ *must* support mechanics that
support OOP. Otherwise C++ does not support OOP.

You still don't understand the fact that the word "object" can have
different meanings in different contexts. Let me try once again, by asking
a question: The jar of honey on my desk, is it an object? What would the
implications be for the word "object"?

I don't finally admit anything, I have never disputed the fact that the
standards used the term object in a different context.

I didn't claim that you disputed the fact that the C++ standard uses the
term object in a different context. But, and that is what I say above and
which is different from what you deny below, you fail to fully grasp that
different contexts can imply different meaning to the same term, because
you repeatedly present arguments that only apply to one context as
"proofs" for another.

No you don't *need* to leave out OOP. The problem is that you define
everything in the context of the standards, as if C++ wouldn't exist
without the standards. Typically changing around the chiken and egg
scenario. The standards only exist because of the language, not
vice-versa.

The C++ standard is written in a way that makes it self-consistent. No
implementations are necessary for it.

Im not changing any context , I am talking about objects(onbjects that
contain member functions) in C++. THat is obviously an object in the
OOP context, you are attempting to change to the context
of an object in the context of the standard.

Scroll back up in this thread. If someone starts a sentence with "In the
C++ object model..", you can not come up with an argument in the general
OOP context to refute that. Let alone can you do so without explicitly
saying that you use a different context. But you did, so your argument
itself is faulty.
 
M

Michael Doubez

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

C++ does support my idea of OOP, the fact that C++ provides member
functions, inheretence , encapsulation and polymorphism is enough to suggest
C++ supports OOP.

What is your idea of OOP? It's seems that your idea of OOP is that an object
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".
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.
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.
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.
 
P

Paul

What is it that I consider of no importance to the standards? Seriously,
it is far from clear here since you don't get your plural/singular right
again.
If you weren't so stupid you would realise I was obviously commenting on
your statement above re:
"This may be of historic relevance to the standard, but it is irrelevant
inside the standard itself"

My use of standards in plural is correct. Your use of the singular standard
makes it far from clear which standard you are speaking about, and you seem
to think there is only one.

Obviously you can't , since no quote was provided,.


Scroll back up in this thread. If someone starts a sentence with "In the
C++ object model..", you can not come up with an argument in the general
OOP context to refute that. Let alone can you do so without explicitly
saying that you use a different context. But you did, so your argument
itself is faulty.
It's *you* that's rasing the argument here not me.
 
P

Paul

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).
********************************************
Why is this complete rubbish? I will explain:
If you take a molecule out of the sky and examine it in a different context
then you are no longer examining the sky.

You still haven't said what color the sky is in your world. All you do is
avoid giving any direct answer.
..



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.
****************************************************
This is not quoted from the standards this is a complete misinterpretation
by you.
The standards state 'an object is a region of storage'. There is no /simply/
in there at all, this has been introduced by you.

An objects member function has calling mechanisms that associate the member
function with the object. The C++ standards do not detail these calling
mechanisms because the language would then be tied to hardware that
supported these calling mechanisms. So it doesn't take a great deal of
intelligence to realise that C++ standard is the wrong doc to ref in the
first place.
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.
.............................................................

C++ does support my idea of OOP, the fact that C++ provides member
functions, inheretence , encapsulation and polymorphism is enough to
suggest
C++ supports OOP.

What is your idea of OOP? It's seems that your idea of OOP is that an
object
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".
**************************************
Well we're not talking French here.
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.
***********************************
You haven't answered it correctly, if so please remind us which colour you
said it was.
You seem unable to answer this simple question.

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 sky *is* blue.
You don't know what color it is.

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.
*************************************
I do have lots of backing, Bjarne Stroutsrup has written many papars that
describe calling member function on Objects.
There is thousands of papers online that support me.

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.

*********************************

Dunno maybe its one of those french things that cannot be translated
 
Ö

Öö Tiib

IIRC, in javascrpit OO works on the pattern

function MyClasse(parameter1, parameter2) {
    this.attribute1 = parameter1;
    this.attribute2 = parameter2;

    this.method = function() {
        alert("Attributs: " + this.attribute1 + ", " +
this.attribute2);
    }

}

var obj = new MyClasse("value1", "value2");
obj.method();

The class does exists although, like in mainy dynamic typing language,
it is not formalized at the language level.

There is prototype, you clone that prototype with new, not create
instances of class. You can add methods to prototype outside of that
"contructor" like "MyClasse.prototype.otherMethod = function()
{ return 42; }" and from there on the clones have it too.
When working on the DOM of a page, you still have to lookup the
members and the methods available at the nodes (in fact you do look up
the type of the node); that is the class.

No there are no classes in prototype based languages like Javascript,
Actionscript or Lua. Static classes are good for compiled languages
and allow simpler optimizations.
In theory, but in practice, if it they change their interface, they
become useless because you don't know what method you can call. I
won't start the dynamic typing vs static typing all over again, my
only point is that this feature is mainly useful at the development
stage, not at runtime (where a static typing language can then achieve
the same).

I did not want to imply that more flexible is always superior or that C
++ is not flexible enough. However ... like you see, some template
wizardry of C++ is used to achieve more dynamic types like
boost::variant or more dynamic functions like with boost::bind. So
there is a market for more run-time flexibility in C++ community.
They don't have to but, as I said, in practice you do.
As an example, in prototype.js you define classes (among other
things).

In fact, I don't see how you can speak about inheritance without class
and inheritance is (arguably) a base concept of OOP.

I don't think that it is mandatory concept. In Javascript there are
cloning of prototypes and delegation and reflection. Quite powerful
features if to think of it. Usually when someone talks of inheritance
as OOP concept these days then he mentions delegation as alternative.
 

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,755
Messages
2,569,536
Members
45,012
Latest member
RoxanneDzm

Latest Threads

Top