«

On 02/22/11 10:34 AM, itaj sherman wrote:
> On Feb 21, 10:09 pm, Ian Collins<ian-n...@hotmail.com> wrote:
>> On 02/22/11 03:54 AM, Stuart Redmann wrote:
>>
>>> On 21 Feb., "Paul" wrote:
>>>> What is your idea of the lifetime of a function?
>>>> a) from function calling code until return?
>>>> b) from start of program until end of a program?
>>>> c) something other?
>>
>>> 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.
>>
>
> Oh, and I forgot. How many minutes exactly are you referring to?

up 47 day(s), 18:28

--
Ian Collins

"Leigh Johnston" <> wrote in message
news: ...
> On 21/02/2011 19:32, Paul wrote:
>> <snip>
>>
>>>>> Functions only exist as machine code in the text segment; inlined
>>>>> functions exist as machine code in the calling function in the text
>>>>> segment.
>>>>>
>>>> "A function is not an object"
>>>
>>> Who said it was?
>>>
>>>> A function is a sub process, it exists on the Stack and CPU registers.
>>>
>>> Now your inexperience is showing; a function does not exist on the
>>> stack at all; all that exists on the stack is stack data such as
>>> function parameters; locals and return addresses. How can a function
>>> exist in a register? That is plain nonsense. You need to learn
>>> assembler and how compilers actually work.
>>
>> Please show the asm code for a function that does not use the stack or
>> any cpu registers.
>> I predict it won't happen!
>
> 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.

>>
>>>
>>> Functions only exist as machine code in the text segment; inlined
>>> functions exist as machine code in the calling function in the text
>>> segment.
>>>
>> The repetition of your incorrect statement won't make it correct.
>
> My statement is correct; your grasp of the fundamentals is not.

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

>
>>
>>>>
>>>> Please stop making noobish statements like: "Functions only exist as
>>>> machine code in the text segment".
>>>>
>>>
>>> It obvious to all who is the "n00b" here.
>>>
>> Yeah it is , you are.
>>
>
> 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.

"Leigh Johnston" <> wrote in message
news: ...
> On 21/02/2011 20:32, Ian Collins wrote:
>> On 02/22/11 09:26 AM, Leigh Johnston wrote:
>>> On 21/02/2011 20:05, Ian Collins wrote:
>>>> On 02/22/11 03:28 AM, Leigh Johnston wrote:
>>>>>
>>>>> Functions only exist as machine code in the text segment; inlined
>>>>> functions exist as machine code in the calling function in the text
>>>>> segment.
>>>>
>>>> If you stopped using such system specific terms as *the* text segment,
>>>> this argument would evaporate.
>>>>
>>>
>>> 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.

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.

On 02/22/11 12:16 PM, Paul wrote:
> "Leigh Johnston" <> wrote:
>> On 21/02/2011 20:32, Ian Collins wrote:
>>> On 02/22/11 09:26 AM, Leigh Johnston wrote:
>>>>
>>>> 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.
>
> 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.

--
Ian Collins

"itaj sherman" <> wrote in message
news:8e6f6de9-bcc1-42bf-a74b-...
> On Feb 21, 11:13 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "itaj sherman" <itajsher...@gmail.com> wrote in message
>>
>
>> > > When we converse about c++ here we stick to these definitions and any
>> > > others in the standard because we want to understand each other
>> > > easily.
>> > > If you want to talk about different things you have to choose another
>> > > name that is not used by already existing defintions (in the
>> > > standard), and explain very clearly what your definition is. For all
>> > > I
>> > > care you can call it x-member.
>> > > Also, you will be expected to show what your definitions are
>> > > beneficial for, if you want anyone to consider them seriously.
>>
>> > 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.
>
> 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.
>
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.

On Feb 21, 8:29*pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> <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-...ed_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".

"Ian Collins" <ian-> wrote in message
news:...
> On 02/22/11 10:13 AM, Paul wrote:
>>
>> 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?
>
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.

On Feb 21, 11:36*pm, Ian Collins <ian-n...@hotmail.com> wrote:
> On 02/22/11 10:34 AM, itaj sherman wrote:
>

>
> > On Feb 21, 10:09 pm, Ian Collins<ian-n...@hotmail.com> *wrote:
> >> On 02/22/11 03:54 AM, Stuart Redmann wrote:
>
> >>> On 21 Feb., "Paul" wrote:
> >>>> What is your idea of the lifetime of a function?
> >>>> a) from function calling code until return?
> >>>> b) from start of program until end of a program?
> >>>> c) something other?
>
> >>> 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.
>
> > Oh, and I forgot. How many minutes exactly are you referring to?
>
> 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

"Öö Tiib" <> wrote in message
news:523dc163-682e-43e2-9d1e-...
On Feb 21, 8:29 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> <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-...ed_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.

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

"Ian Collins" <ian-> wrote in message
news:...
> On 02/22/11 12:16 PM, Paul wrote:
>> "Leigh Johnston" <> wrote:
>>> On 21/02/2011 20:32, Ian Collins wrote:
>>>> On 02/22/11 09:26 AM, Leigh Johnston wrote:
>>>>>
>>>>> 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.
>>
>> 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.
>
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.