Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Newbies don't learn C++

Reply
Thread Tools

Newbies don't learn C++

 
 
Paul
Guest
Posts: n/a
 
      01-12-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 12/01/2011 16:41, Paul wrote:
>>
>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> On 12/01/2011 01:05, Paul wrote:
>>>>
>>>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>>>> news:(E-Mail Removed)...
>>>>
>>>> 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?



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

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

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

>>
>> You seem to be applying pre-compile time jargon in the context of code
>> segments etc.
>>
>> Wouldn't be surprised if you try to say template parameters are defined
>> in obj files next.

>
> Perhaps it is time for you to "unsubscribe" again.
>
> /Leigh


 
Reply With Quote
 
 
 
 
Keith H Duggar
Guest
Posts: n/a
 
      01-12-2011
On Jan 11, 7:06*pm, Ian Collins <(E-Mail Removed)> wrote:
> On 01/12/11 01:04 PM, Leigh Johnston wrote:
>
> [nonsense snipped]
>
> > I thought you had unsubscribed from this newsgroup?

>
> Please don't feed the troll!
>
> Fully quoting its nonsense is a great way to bypass message filters...


Indeed. I keep hoping that as Paul says:

On Jan 11, 6:37*pm, "Paul" <(E-Mail Removed)> wrote:
> I have been totally shunned by the 'C++ community' and dismissed as complete
> nonsense by *supposed* experts. But its not complete nonsense it's a *dead
> sure fact.


Leigh, Joshua, Juha, and others will soon join the 'C++ community'
and 'totally shun' paul. Ie I hope they will start ignoring him soon.

KHD
 
Reply With Quote
 
 
 
 
Balog Pal
Guest
Posts: n/a
 
      01-12-2011
"Keith H Duggar" <(E-Mail Removed)>
>Leigh, Joshua, Juha, and others will soon join the 'C++ community'
>and 'totally shun' paul. Ie I hope they will start ignoring him soon.


Just plonked that trioa few minutes ago. Troll feeders are no better than
pimary trolls, the nonsense does not show an end, but at least can be
reached through extended killfiles on the client end.

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-12-2011

"Keith H Duggar" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
On Jan 11, 7:06 pm, Ian Collins <(E-Mail Removed)> wrote:
> On 01/12/11 01:04 PM, Leigh Johnston wrote:
>
> [nonsense snipped]
>
> > I thought you had unsubscribed from this newsgroup?

>
> Please don't feed the troll!
>
> Fully quoting its nonsense is a great way to bypass message filters...


Indeed. I keep hoping that as Paul says:

On Jan 11, 6:37 pm, "Paul" <(E-Mail Removed)> wrote:
> I have been totally shunned by the 'C++ community' and dismissed as
> complete
> nonsense by *supposed* experts. But its not complete nonsense it's a dead
> sure fact.


Leigh, Joshua, Juha, and others will soon join the 'C++ community'
and 'totally shun' paul. Ie I hope they will start ignoring him soon.

KHD

3 words for this moron:

BIG GAY FOLLOWING


 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-12-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 12/01/2011 18:47, Paul wrote:
>>
>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> On 12/01/2011 16:41, Paul wrote:
>>>>
>>>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>>>> news:(E-Mail Removed)...
>>>>> On 12/01/2011 01:05, Paul wrote:
>>>>>>
>>>>>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>>>>>> news:(E-Mail Removed)...
>>>>>>
>>>>>> 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 **** 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?

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-12-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
> On 12/01/2011 20:50, Paul wrote:
>>
>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>> news:(E-Mail Removed)...
>>> On 12/01/2011 18:47, Paul wrote:
>>>>
>>>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>>>> news:(E-Mail Removed)...
>>>>> On 12/01/2011 16:41, Paul wrote:
>>>>>>
>>>>>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>>>>>> news:(E-Mail Removed)...
>>>>>>> On 12/01/2011 01:05, Paul wrote:
>>>>>>>>
>>>>>>>> "Leigh Johnston" <(E-Mail Removed)> wrote in message
>>>>>>>> news:(E-Mail Removed)...
>>>>>>>>
>>>>>>>> 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. "

>
> Your appeal to authority is wrong on two counts:
>
> 1) Appealing to authority is usually invalid
> 2) Your actual appeal strengthens my position not yours.
>


I'm not APPEALING to anyone , I am posting a quote from Bjarne Stroustrup ,
the man who invented C++, and what he says is evidence to support my
argument. And it's also proof that what you are saying is complete nonsnese.

You seem to have collapsed and I feel sorry for you now. Please don't get me
wrong I am not trying to put you down I am simply sticking up for technical
correctness. it was after all you who first claimed I was wrong.

You obviously seem to be right into your standards and all that and I
respect you for that and for trying to be correct. But you have to sometimes
accept you are wrong.


 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-12-2011

>>>> 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. "
>>>
>>> Your appeal to authority is wrong on two counts:
>>>
>>> 1) Appealing to authority is usually invalid
>>> 2) Your actual appeal strengthens my position not yours.
>>>

>>
>> I'm not APPEALING to anyone , I am posting a quote from Bjarne
>> Stroustrup , the man who invented C++, and what he says is evidence to
>> support my argument. And it's also proof that what you are saying is
>> complete nonsnese.
>>
>> You seem to have collapsed and I feel sorry for you now. Please don't
>> get me wrong I am not trying to put you down I am simply sticking up for
>> technical correctness. it was after all you who first claimed I was
>> wrong.
>>
>> You obviously seem to be right into your standards and all that and I
>> respect you for that and for trying to be correct. But you have to
>> sometimes accept you are wrong.
>>

>
> Accepting that you are wrong is something *you* are unable to do; that
> much is obvious.
>

If you allow people to bully you into being wrong then you are weak.
If you have no brain of your own and simply go with the flow then you are
weak.
I'd rather be strong and correct, than weak and wrong.
<shrug>

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      01-12-2011

>>>> 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. "
>>>
>>> Your appeal to authority is wrong on two counts:
>>>
>>> 1) Appealing to authority is usually invalid
>>> 2) Your actual appeal strengthens my position not yours.
>>>

>>
>> I'm not APPEALING to anyone , I am posting a quote from Bjarne
>> Stroustrup , the man who invented C++, and what he says is evidence to
>> support my argument. And it's also proof that what you are saying is
>> complete nonsnese.
>>
>> You seem to have collapsed and I feel sorry for you now. Please don't
>> get me wrong I am not trying to put you down I am simply sticking up for
>> technical correctness. it was after all you who first claimed I was
>> wrong.
>>
>> You obviously seem to be right into your standards and all that and I
>> respect you for that and for trying to be correct. But you have to
>> sometimes accept you are wrong.
>>

>
> Accepting that you are wrong is something *you* are unable to do; that
> much is obvious.
>

If you allow people to bully you into being wrong then you are weak.
If you have no brain of your own and simply go with the flow then you are
weak.
I'd rather be strong and correct, than weak and wrong.
<shrug>

 
Reply With Quote
 
Joshua Maurice
Guest
Posts: n/a
 
      01-12-2011
On Jan 12, 9:42*am, "Paul" <(E-Mail Removed)> wrote:
> The only reference i made to Java was to suggest it is much more portable
> across ALL of the new devices that are the current fashion.
> *i.e: mobile phones, since you obviously need an example to explain this.


Depends on your technical definition of portable. While there might be
less porting work when taking java from implementation A to
implementation B, I'm pretty sure that C is supported on much more
hardware than Java.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-12-2011
Leigh Johnston <(E-Mail Removed)> writes:
[...]
> Accepting that you are wrong is something *you* are unable to do; that
> much is obvious.


The rest of us figured that out days ago.

If you can't resist the tempation to respond, at least don't re-quote
everything he writes.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail 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"
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Some information for the one who decided to learn C++, and now wantsto learn at least a bit of C? Alexander C Programming 20 09-11-2010 01:04 AM
How we recognize newbies as newbies Alf P. Steinbach C++ 31 08-21-2007 05:12 PM
Learn the language before you learn the GUI. CoreyWhite C++ 1 03-31-2007 08:56 PM
Re: Newbies? - Usenet don't need no steenking newbies! =?iso-8859-1?Q?=B1?= Digital Photography 2 07-17-2004 02:26 PM
newbie question: should I learn TKinter or skip it and learn more advanced toolkit? Porky Pig Jr Python 3 05-12-2004 08:58 AM



Advertisments