Is it legal code?

[Ian Collins]

On 21 Feb., "Paul" wrote:

I'd opt for b).

Considering this is purely a metaphysical discussion, c) is an equally
plausible description. On this box, a standard library function like
puts() has existed for the 47 days, 17 hours and a few minutes, since
the system booted and loaded libC into memory.

 

[itaj sherman]

Paul, why don't you be the man and reply on this one?

Don't forget to reply on this one Paul. Don't be afraid, it won't bite
you (maybe).

 

[Ian Collins]

My terminology is correct:

"In computing, a code segment, also known as a text segment or simply as
text, is a phrase used to refer to a portion of memory or of an object
file that contains executable instructions."

It is true that a system can have more than one such segment but this is
a minor point which doesn't really detract from my main point that after
compilation functions only exist as machine code in the executable file
or memory; they are certainly never part of an object (in C++ at least).

Maybe, but the bickering is over the details. If you want to keep the
focus on the main issue, don't provide seeds for distractions.

 

[Paul]

Hang on, you quote a section of the standard then blame me snipping it for
your misunderstanding? When you are in a hole, the time comes to stop
digging.


What is the definition of valid?


So which constraint does the code violate?

You're attempt to invoke a member function on a null pointer causes
undefined behaviour.
Your program may invoke the member function but then again it might make
your screen go blue. On my system I get a big fat.."the program has stopped
responding" msg.

So your programs produces an error no matter what terminology you use.
If the standard says your code causes undefined behaviour then you cannot
put that code forward as standard compliant code.

 

[Paul]

Paul, why don't you be the man and reply on this one?

I think you are incorrect to suggest that we must always speak in
standardesque.
I don't disagree with the standard by saying an NSMF is a member of an
object(instance of class type).
The standard defines a class as the definition of an object type ,this
supports my argument that non static members declared in a class are also
members of an object of that class type.

 

[itaj sherman]

Considering this is purely a metaphysical discussion, c) is an equally
plausible description. On this box, a standard library function like
puts() has existed for the 47 days, 17 hours and a few minutes, since
the system booted and loaded libC into memory.

I don't see the source of the confusion here. This is very simple.

A member function's lifetime spans from the completion of its
constructor to the beginning of its destructor.
A static member function doesn't ever have a lifetime because it
doesn't have any constructors - with the exception of virtual static
member fucntions who can't have a constructor themselves, but can
inherit one from their superfunction.

* BTW my definition of "virtual static member function" is a static
member function that only has a virtual lifetime because it's inherits
it superfunction in virtual inheritance.

As has been mentioned by the creators of the language. See relevant
quotes I have given in some of my posts on this newsgroup and some
others, and in some email I sent to my ex-girlfriend Shira.

Also you should probably check this:

itaj

 

[itaj sherman]

I think you are incorrect to suggest that we must always speak in
standardesque.

Not what I said. I said you have to choose unused names for your new
definitions.

I don't disagree with the standard by saying an NSMF is a member of an
object(instance of class type).

How could you?

The standard defines a class as the definition of an object type ,this
supports my argument that non static members declared in a class are also
members of an object of that class type.- Hide quoted text -

This is not an argument. It could be a definition. If you change its
name to something unused, it might even be a useful one. Instead of
the used "member" say "instance member" or "x-member" for all I care.

BTW have you ever studied theoretical math like ring theory, topology
or model-thoery?

itaj

 

[Ian Collins]

I think you are incorrect to suggest that we must always speak in
standardesque.

Programmers don't speak in standardese, but they use the definitions
from the standard to establish a common metaphor.

I don't disagree with the standard by saying an NSMF is a member of an
object(instance of class type).
The standard defines a class as the definition of an object type ,this
supports my argument that non static members declared in a class are
also members of an object of that class type.

Given instances of a class have unique address, how do you explain
member functions having a shared address?

 

[Paul]

That's a lengthy FAQ. I assume you were referring to
http://www2.research.att.com/~bs/bs_faq2.html#null?

If that's the case, it makes no mention of a null pointer not having an
address.

How can a pointer be a pointer if it doesn't have an address? Does
assigning the value NULL to a pointer make it disappear?

Explain

int* p(NULL);
int** pp(&p);

if p doesn't have an address.

--

We were talking about the value of the pointer. Not the address of the
pointer. I think it's obvious from the context.

 

[itaj sherman]

Considering this is purely a metaphysical discussion, c) is an equally
plausible description.  On this box, a standard library function like
puts() has existed for the 47 days, 17 hours and a few minutes, since
the system booted and loaded libC into memory.

Oh, and I forgot. How many minutes exactly are you referring to?

 

[Ian Collins]

Oh, and I forgot. How many minutes exactly are you referring to?

up 47 day(s), 18:28

 

[Paul]

What you are failing to grasp is that a "function invocation" is not the
same as a "function". Your ambiguous terminology and inability to express
yourself properly to your peers seems to be the nub of the problem.

You stated that a function *only* exists as machine code in the text
segment.
Apparently you were spouting bullshit again.

My statement is correct; your grasp of the fundamentals is not.

No it's not correct
http://en.wikipedia.org/wiki/Flat_memory_model

Again, it obvious to all who is the "n00b" here.

You speak about segments yet you have no clue.
The old dos tiny model had only 1 segment for everything ( COM files)
A segmented memory model is not the *only* place a function exists. And even
with a segmented memory model code can be executed from segments other than
_text or _code segs, on some systems.
You claimed to have written a z80 emulator in asm but you don't know the z80
has no segment registers?
The ZX spectrum pc had old Tap files with no segments, my Ti calculator has
a z80 chip and I program it in asm, there are no segments in these programs.

 

[Paul]

Ian is as bad as Leigh, what does he mean maybe?
There is no maybe its utter bullshit to state that a function *only* exists
in the text seg/ a text seg/ any text seg.

The main issue is Paul The Troll's misunderstanding of what a C++ member
function is; I am simply defining what a C++ function is post-compilation.

C++ is not restricted to any particular executable file format, your
definition of a C++ function is incorrect IMO.

Also you fail to recognise the discrepancy in the definiton of function
lifetime/existance. Other such as James at least recognises this fact, you
however are plain ignorant to this fact and refuse to accept anyone else
POV. So don't you call him a troll when you are worse.

 

[Ian Collins]

Ian is as bad as Leigh, what does he mean maybe?

That functions only exist as machine code in the executable file is a
possible scenario.

 

[Paul]

Not what I said. I said you have to choose unused names for your new
definitions.


How could you?


This is not an argument. It could be a definition. If you change its
name to something unused, it might even be a useful one. Instead of
the used "member" say "instance member" or "x-member" for all I care.

The word object has a well defined meaning in the context of OOP. I think it
is a ridiculous decision for the standard to use this word in a different
context. The standard should use the term object to mean what it *really*
means( an instance of a class type), or at least capitalise it or something.
So any programmer coming from the realm of another language must endure the
ludicrous confusion imposed by the C++ standards use of the word 'object'?

BTW have you ever studied theoretical math like ring theory, topology
or model-thoery?

Done a litle modelling but nothing as heavy as model theory.

 

[Öö Tiib]

<quote ref =http://java.sun.com/docs/glossary.html#O>
"object
The principal building blocks of object-oriented programs. Each object isa
programming unit consisting of data (instance variables) and functionality
(instance methods). See also class."
</quote>

It talks about methods not member functions.

[...]

One above and here's another, there are hundreds if not thousands:

http://en.wikipedia.org/wiki/Object-oriented_programming

Now that is a good article of how contradicting and dim the views
about OOP are. I try to pick a quote there:

<quote>
By contrast, the object-oriented approach encourages the programmer to
place data where it is not directly accessible by the rest of the
program. Instead the data is accessed by calling specially written
'functions', commonly called methods, which are either bundled in with
the data or inherited from "class objects" and act as the
intermediaries for retrieving or modifying that data.
</quote>

Yes, so in C++ we have member functions inherited from class instead
of methods bundled in with the data. Class is type. There are no
reflection in C++ and no "class objects" in C++. Instead one can get
some sort of typeid that is a dim implementation-specific thing or
mess with templates to attach traits to types. Still that "member
function" of C++ is close enough to "method" of OOP to call it "OOP
support".

 

[Paul]

Programmers don't speak in standardese, but they use the definitions from
the standard to establish a common metaphor.


Given instances of a class have unique address, how do you explain member
functions having a shared address?

How to you come to this conclusion?
I agree this is the normally case because of the way OOP is normally
implemetated in C++. But this case is not always guaranteed because it
outside the realm of the standard to define the way an implementation
implements member functions.

You have to accept that the standard does not define every aspect of C++,
and be reasonable about discussions on these subjects. I think its
unreasonable to resort to the standard for every given debate and quote
things out of context.

The C++ standard hits a blank wall post compile, this does not mean C++ does
not exist post compile. But if we are discussing this we need to be
reasonable and accept the documents presented by Bjarne Stroustrup and
people of his standard as authorative papers.

Objects(as an instance of an class type as I need to keep repeating) are
runtime entities and the C++ standard draws a blank line at runtime , almost
everything it states about program execution is undefined.

 

[itaj sherman]

On 02/22/11 10:34 AM, itaj sherman wrote:



up 47 day(s), 18:28

Yeah, that seems right.

And another thing I forgot,
I think should we be ready for a troll yes/no vote.

I did my best to avoid this and give the benefit or the doubt. But
this is quite enough.

I'm for yes.
Any thoughts?

itaj

 

[Paul]

<quote ref =http://java.sun.com/docs/glossary.html#O>
"object
The principal building blocks of object-oriented programs. Each object is
a
programming unit consisting of data (instance variables) and functionality
(instance methods). See also class."
</quote>

It talks about methods not member functions.

[...]
/////////////////////////////////////////////////////////////////////////////////////////
dam indenting again
//////////////////////////////////////////////////////////////////////////////////////////

That to me is an ignorant reply. A method is generally accepted to mean the
same thing as a member function(nonstatic respectively implied)

One above and here's another, there are hundreds if not thousands:

http://en.wikipedia.org/wiki/Object-oriented_programming

Now that is a good article of how contradicting and dim the views
about OOP are. I try to pick a quote there:

<quote>
By contrast, the object-oriented approach encourages the programmer to
place data where it is not directly accessible by the rest of the
program. Instead the data is accessed by calling specially written
'functions', commonly called methods, which are either bundled in with
the data or inherited from "class objects" and act as the
intermediaries for retrieving or modifying that data.
</quote>

Yes, so in C++ we have member functions inherited from class instead
of methods bundled in with the data. Class is type. There are no
reflection in C++ and no "class objects" in C++. Instead one can get
some sort of typeid that is a dim implementation-specific thing or
mess with templates to attach traits to types. Still that "member
function" of C++ is close enough to "method" of OOP to call it "OOP
support".

///////////////////////////////////////////////////////////////////////////////////////////////////////
I don't see what you are trying to state here. I understand that text on OOP
perfectly; It describes the concept of data protection and accessor
functions.
Why is it contradicting and dim?

When you speak of methods "bundled" with objects , this is an OOP concept.
If the programming language supports OOP then it has mechanisms which
support this concept, it doesn't really matter what the underlying technical
implementations are.
The C++ language is defined in such a way that if a class declares a
nonstatic method then this method will be available as a member of an
object(instance of the class).
Note: deliberate use of method here to emphasise the association with OOP.

The C++ standard cannot fully define the mechanisms because it chooses to
leave this up to the implementation, for a good reason. If the C++ standard
was to try and define this for every possible and future computer system ,
it would need to be rewritten before it was drafted for comments.

////////////////////////////////////////////////////////////////////////////////////////////////////////////////

 

[Paul]

That functions only exist as machine code in the executable file is a
possible scenario.

Even this is debateable , consider a SOAP application or something like that
that invokes a function across a network. That function could come from
anyplace, technically speaking it could be dynamically created dependant on
the parameters or something silly like that.
This debate could only be resolved for a given scenario but it would be
incorrect to suggest a function can *only* exist in a particular form, for a
given scenario. Because in a different scenraio the function could exist in
a different form.
Yes I am being slightly unreasonable with excentric examples but I think the
continued repetition that a function can *only* exist blah blah is even more
unreasonable and it is not taking into consideration the other POV.