Newbies don't learn C++

[Paul]

I was programming Windows COM Objects 10 years ago , and I'm not interested
in that anymore.Its old tech.
It appears to me that "the C++ community" has become very confused, since I
last visisted the world of C++.

10 years ago C++ was usefull because of the rapid growth of microsoft
windows, but thats old tech and its all been done. Who cares about MS
windows as long as they can watch you-tube and blog with their mates.
XBOX and IPOD is the current fashion, the latest thing being IPOD APPS. Java
is much more portable across the constantly changing hardware fashions that
is the world we live in today.


WHy should anyone try to learn a programming language that is unneccessarily
overly complicated by unclear confused and undefined standards. C++ seems
caught up in a chiken-egg scenario with the C++ standard/s and they are
still arguing about the same shit they were 10 years ago.
Some people refuse to accept the term object as it is widely used in
computer programming today.

In C++ a member function belongs to an object, end of story, there is no
argument about this its a FACT.
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.

In 10 years time C++ will be useless knowledge, as fortran or basic is
today. It seems like even the people who are writing the standards now think
a member function belongs to a class. And it seems nowadays that the
standards are defining the implementation of the language, and not a
definiton of the language(as they should be).

My second-hand book shop now has two C++ books for sale at 30p each, thanks
to my donation. I will not be replacing them.

If after 10 years the current standard is such confused bollocks then it's
certainly not going to be any better in C++ 0x . There is a high probably it
will introduce more confusion into the minds of these people who are doing
nothing more than killing what used to be a very well defined and respected
programming language.

C++.............................Your fired!

Stuart also thought he was a professional and expert.

 

[Ian Collins]

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

 

[Paul]

I thought you had unsubscribed from this newsgroup?

In C++ a member function is a part of a class not part of an object.

When a member function is invoked for an object, the class is of no
relevance. A class is only necessary to create an object, after an object
has been created the class does not even need to exist. Only the function
definiton is required.

An object is bound to a member function dependant on the calling mechanism.
Whether it be a pointer within the object or an pointer in a register, or
whatever calling mechanism is used. The same cannot be said for a class.

A member function cannot be invoked if there is no object present, therefore
it follows that a member function cannot exist unless an object exists.The
same cannot be said for a class.
I know a non virtual member function can be invoked directly with a pointer
but this is probably not legal as it break scope rules.

The general concept of objects, in an OOP context, is that a member function
is encapsualted within an object. And C++ is a language that supports OOP,
therefore C++ supports this concept.

All of the above are perfectly good arguments to suggest that a member
function belongs to an object, unless you can prove otherwise.


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

Oh you also gave the argument that 'we' all think so therefore 'we' must be
correct.

What happens if you create a singleton object then overwrite its typdef?
Where does this class of yours exist, other than some source file.?

 

[Paul]

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

I would like to remind Ian that he was very recently proved wrong in
learn.c-c++ .
re: Ian Collins wrote..

 

[Joshua Maurice]

Oh you also gave the argument that 'we' all think so therefore 'we' must be
correct.

Over matters of definition and terminology, yes.

 

[Rui Maciel]

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 believe that by now there is any doubt that this Paul is a troll.
All the personal attacks, the name calling and the insistence to reiterate
nonsense no matter how many times people point out his misconceptions and
mistakes are a clear indication that this character's purpose is to troll
a hand full of newsgroups.


Rui Maciel

 

[Paul]

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.
No I read it 10 times and i simply cannot work out what that sentence above
is suppose to mean, please rephrase it

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

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.

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?

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.

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.

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.

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

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


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.

 

[Juha Nieminen]

10 years ago C++ was usefull because of the rapid growth of microsoft
windows, but thats old tech and its all been done. Who cares about MS
windows as long as they can watch you-tube and blog with their mates.
XBOX and IPOD is the current fashion, the latest thing being IPOD APPS. Java
is much more portable across the constantly changing hardware fashions that
is the world we live in today.

You once again brilliantly demonstrate your complete ignorance.

Neither the "XBOX" (by which I assume you mean the Xbox 360) nor the
"IPOD" (by which I assume you mean the iPhone family of devices, including
the iPhone, the iPod Touch and the iPad) are programmed in Java.

iPhone apps are made in either Objective-C or Objective-C++ (which is
a mix between Objective-C and C++).

Xbox 360 games are written principally in whatever language the game
houses want to use, but it's often C++ (because the major game engines
are usually written in C++), and whatever scripting language the particular
game engine supports. Users can write so-called "arcade games" in C#.

 

[ptyxs]

The content of this thread as well as the content of other threads by
the same author Paul, shows clearly that this guy just opens pure
trolls : please, don't feed the troll and let him discuss with
himself.
All that is a mere waste of time and energy.

 

[Paul]

You once again brilliantly demonstrate your complete ignorance.

You are the ignorant one.

Neither the "XBOX" (by which I assume you mean the Xbox 360) nor the
"IPOD" (by which I assume you mean the iPhone family of devices, including
the iPhone, the iPod Touch and the iPad) are programmed in Java.

I never said an xbox game or OS was programmed in java, and I nevers said
what language any apple i-turds were programmed in either.

iPhone apps are made in either Objective-C or Objective-C++ (which is
a mix between Objective-C and C++).

Xbox 360 games are written principally in whatever language the game
houses want to use, but it's often C++ (because the major game engines
are usually written in C++), and whatever scripting language the
particular
game engine supports. Users can write so-called "arcade games" in C#.

I doubt you will be coding any XBOX titles in your lifetime.


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.

 

[Paul]

English is my first language; I have doubts that it is yours due to your
inability to understand simple logic expressed with 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?

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.

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.

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.

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

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?

Apart from yourself who mentioned x86 assembly or IBM PCs?


What the f**k are you talking about?

You are the one who raised theoretical implementations. I could say the same
to you.

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.

 

[Keith H Duggar]

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:

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

 

[Balog Pal]

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.

 

[Paul]

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:

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

 

[Paul]

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?

I said that text segment is a computer science term not specific to any
particular platform program format.


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.

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.

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?

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

 

[Paul]

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.

 

[Paul]

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>

 

[Paul]

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>

 

[Joshua Maurice]

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.

 

[Keith Thompson]

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.