Re: Newbies don't learn C++
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:fP-dnT8PgoTdnbPQnZ2dnUVZ8uednZ2d@giganews.com...
On 12/01/2011 18:47, Paul wrote:
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:cJCdnV-GIYq2fbDQnZ2dnUVZ8v-dnZ2d@giganews.com...
On 12/01/2011 16:41, Paul wrote:
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:YsCdnQP-qutGILDQnZ2dnUVZ8rOdnZ2d@giganews.com...
On 12/01/2011 01:05, Paul wrote:
"Leigh Johnston" <leigh@i42.co.uk> wrote in message
news:t--dnfrSVMF9crHQnZ2dnUVZ8hOdnZ2d@giganews.com...
You have not given one single argument to suggest a member function
belongs to a class. The only argument you have is to switch the
context
from runtime to a precompile time class. And even with this very weak
argument it only proves the function is 'declared' in a class.
The very fact that a function is declared in a class suggests a
member
function does belong to an object. As a class is the definition of an
object(or an objects type if you want to get pedantic).
Member functions only exist as separate entities during compilation
where they are part of classes.
Leigh the very first line of your post makes no sense and that is not
having a go at you.
MF's only exists as seperatae entites to what?......or are you saying
members and functions are the two entities to be seperated ?
As it stands I need to guess at what you are trying to say, perhaps
english is not your first language(seriously) so I will not be cheeky
about it.
English is my first language; I have doubts that it is yours due to
your inability to understand simple logic expressed with it.
No I read it 10 times and i simply cannot work out what that sentence
above is suppose to mean, please rephrase it
During compilation a member function is a separate entity even though
it is part of something else (a class); this is no different to saying
that a window is a separate entity even though it is part of a house.
Perhaps I should have used the word "distinct" instead of "separate".
How can it be seperate although part of something?
And what to you mean during compilation, You cant make a definiton of
its state in the middle of the compilation process , lets be clear do
you mean before or after compilation?
A member function is treated by the compiler as a separate entity during
compilation even though it is part of a class; why do you find this so
hard to grasp? The fact that a compiler can inline a member function
should be sufficient evidence to illustrate what I am saying is fact. The
compiler converts a non-inlined member function into machine code the
beginning of which is the function's unique start address which is used
during linking. After linking all that exists is a binary executable
which contains among other things a text segment which contains all the
machine code for all the function definitions; member functions cease to
exist as entities which means they can not be part of objects in the C++
sense.
So you now refuse to accept that a member function even exists after compile
time?
You are in complete disagreement with Bjare Stroustrup re:
"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. "
Ole Bjarne here seems to think different to you. So who is right and who is
wrong?
After compilation/linking member functions live in the code segment
alongside non-member functions and like classes cease to exist as
separate entities.
C++ is not restricted to the IBM PC program format, but I accept it if
you choose to use this program format as an example to explain.
I have made no reference to the IBM PC program format; "code (text)
segment" is a computer science term; not an IBM PC program format term.
Does the computer in my car have this format of program?
I disagree that this is a general computer program format. I think it is
a specific program format you speak of. The only knowledge I have of
this type of format is from dabbling in asm many years ago.
I said that text segment is a computer science term not specific to any
particular platform program format.
Functions don't *live* in the code section, you are thinking of the set
of instruction that are the "function definition". The function proper
doesn't live until it's been invoked.
But I also accept that this function definition can be, and usually is,
referred to as simply 'the function'.
The terms "function" and "function invocation" are distinct; in other
words a "function invocation" is not a "function". Functions live in
the text segment.
A function invocation begins execution of a function , that is the start
of its lifespan. Don't state a function is not a function -invocation as
if I have said it was.
If any definiton of a function "living" it is not its storage in memory.
It is time from its invocation till return.
No; a function lives in the text segment; the text segment exists in
memory (or paged into memory on demand) whilst the program exist in memory
for some definition of "memory".
Its not necessarily the case that a function exists in a text segment.
The point here is that you are saying it 'lives' there and that isn't really
a proper technical term in computer programming so I will not argue , it can
'live' wherever you want it to 'live', its your term.
I do not understand the last part of your above para re: "and like
classes cease to exist as separate entities.".
If something is seperate is must be seperate from something else, it
can't just be defined to be a 'seperate entity' on its own.
Member functions (and non-member functions) only exist as separate
entities during compilation; after compilation/linking they all live
side by side in the text segment.
They all live side by side does not mean they exists as the same entity.
Here you seem to imply that after compilation they all live side by side
but somehow as the same entity.
They all live side by side in the text segment. There is no difference
between a member function and a non-member function as far as the text
segment is concerned
There is a difference in the calling mechanism. As Bjarne clearly states.
Please clarify what you are trying to say here.
>The compiler/linker will emit the
start addresses of functions into calling code and vtables but a start
address is not enough to fully delineate functions within the text
segment definition of an executable.
This looks a sure copy and paste paragraph Im not sure what you are
trying to say here.
You haven't even considered inlined functions which plainly
contradicts your claim that a function can be part of an object during
invocation; if the function is inlined then it only exists in the
calling function (assuming that the calling function is not also
inlined).
Don't try to confuse things by introducing inline functions.
Confuse things? More like I have given you a shining example of why what
you are claiming is bullshit.
What you say is in complete disagreement with Bjarne Stroustrup , is this
not enough to suggest it's probably *your* claims that are complete
bullshit?
How can something that no longer exists as a separate entity be part
of an object?
What no longer exists and as a seperate entity and from what other
entity has it been seperated?
Objects only exist at runtime; member functions only exist at compile
time; how can something that only exists at compile time but part of
something that only exists at runtime? Text segments.
member functions only exist at compile time? What kind of nonsense is
that to state?.
Yes; member functions only exist at compile time. After compiling/linking
all that remains of them is machine code in the text segment.
See above quote from Bjarne Stroustrup.
If you need anyomore I have hundreds of quotes lined up waiting to prove you
are wrong about this.
The compiler provided passing of an object's "this" pointer to what
was a member function during compilation is no different to the
passing of any other function argument modulo the possible use of a
register rather than the stack.
What does the compiler have to do with the invokation of a member
function?
The compiler doesn't pass any pointers , this is all processed by the
CPU. It's an instruction pointer, and CPU stack and registers blah
blah,
I don't even want to go there for any given implementation.
I never said the compiler passes pointers; I said the "compiler
*provided* passing" which to anyone with half a brain would understand
that I was referring to the code the compiler emits which passes the
argument.
So you admit that the code that calls a member function passes a pointer
to an object?
The compiler emits code that allows an object's "this" pointer to be used
by the machine code representing what used to be a member function. Again
this is all just machine code in the text segment. Nothing is "passed to
an object" as an object is just a region of storage in C++; how can you
pass something to a region of storage? You can't as that makes no sense.
Please dont confuse the term..passing a pointer-to-an-object with passing a
pointer into an object.
An object is not a function remember, you cannot pass arguments to a region
of storage. Your misinterpretation does not make sense.
Anyway it is not neccessary for you to confirm this point as Bjarne
Stroustrup has confirmed it above.
If you disagree with me try looking at the assembler generated during
compilation. I suspect you don't know how to program in assembler
because if you did you wouldn't have started any of these bullshit
threads of yours (assuming you are not a troll).
I don't claim to be any expert on x86 assembly , but you seem to think
you are. Classes with inheretance in ASM is very advanced stuff and if
you can understand exactly how that works on a modern IBM PC by simply
reading the ASM code from a linker output then you possess a talent
most
human beings do not have.
Apart from yourself who mentioned x86 assembly or IBM PCs?
Of course one can talk about a theoretical C++ implementation (e.g. an
interpreter) which contradicts what I have said above but most of us
live in the real world using traditional C++ implementations.
But we're not talking aobut a theoretical implementation , we're
talking
about real implementations.
On a typical windows system for example, when you create a C++ program
the class is compiled/linked to a typedef in program code. The class is
then discarded and no longer exists.
You suggest you know assembly so surely you know how you create a class
type in ASM. You simply typedef the construct in whatever segment you
choose.
What the f**k are you talking about?
You are the one who raised theoretical implementations. I could say the
same to you.
Oh you also gave the argument that 'we' all think so therefore 'we'
must
be correct.
"we" are correct yes; "you" are wrong.
You have given no reasonable argument to prove this. Additionally the
onus is on you to provide evidence, as you are the one claiming me to
be
wrong.
Proof that "we" are correct and "you" are wrong? One only has to look
at all the replies in the threads started by you.
What like this reply? Is this your proof?
What happens if you create a singleton object then overwrite its
typdef?
Where does this class of yours exist, other than some source file.?
I have no idea what you are trying to say here.
/Leigh
Ok create a program with an object typedeffed at text seg offsett 0xFF.
1)The program creates an object on the heap
2) The program loads EAX with the address of the member function ( say
code seg offset 0xFE)
3) The program invokes the objects member function by calling JMP EAX
4) The code that resides at code seg offset 0xFE( the functions
instructions) executes the following MOV [CS reg]+0xFF, 00000000
This is a very basic example of how an object can overwrite its own
typdef, there is no connection to the class AT ALL at this point.
This is an extreme example that would very rarely be done unless the
memory availabe was very limited.
It is intended to disprove your suggestion that a function is stored
inside a *class* at pogram code level. A class is a compile time entity
unless you are referring to class members(statics).
Utter guff; one word: "clueless".
Um ok I bolloxed that up with my segments as I say Im no expert .
See if you can understand now:
Ok create a program with an object typedeffed at data seg offsett 0xFF.
1)The program creates an object on the heap of the tpye typedeffed at
DS+0xFF
2) The program loads EAX with the address of the member function ( say
code seg offset 0xFE)
3) The program invokes the objects member function by calling JMP EAX
4) The code that resides at code seg offset 0xFE( the functions
instructions) executes the following MOV [DS]+0xFF, 00000000
As I am trying to explain a concept that you have not understood ,
perhaps I am not explaining clearly enough. And I attempt to explain it
in a manner you seem to be knowledgable in. Please state what you do not
understand or what you believe to be incorrect.
Again this is just clueless guff; how is anybody supposed to *understand*
clueless guff.
This is very basic asm psuedo code.
What part of it don't you understand exactly?
In C++
Create a program and typedef a class:
typedef struct{unsigned x; unsigned y;}myType;
1) myType x = new(myType);
2) overwrite();
3)//incorporated in 2
4)//function executes code
void overwrite(){do some shit that overwrites the typedef in the data seg;}
object x is still there, but the typedef is erased. No more object s of
myType can be made.
Pretty simple, what don't you understand about this?