«

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.

--
Ian Collins

On Feb 21, 9:52*pm, itaj sherman <itajsher...@gmail.com> wrote:
> On Feb 21, 8:31*pm, itaj sherman <itajsher...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 21, 7:46*pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > > Object Orientated Programming.
>
> > > I guess you are looking for a more detailed answer but I don't know what to
> > > say TBH. I think there are differing opinions about some OOP concepts.. But
> > > there are some concepts that are generally agreed on, member functions as
> > > members of an object is one of the generally agreed upon concepts IMHO.
>
> > Whatever your definitions mean.
> > The following section of the standard is very clear about the
> > definitions of all members in c++ (and whether they are members of the
> > class or something else):
>
> > 9.2/1 The member-specification in a class definition declares the full
> > set of members of the class; no member can be added elsewhere. Members
> > of a class are data members, member functions (9.3), nested types, and
> > enumerators. Data members and member functions are static or non-
> > static; see 9.4. Nested types are classes (9.1, 9.7) and enumerations
> > (7.2) defined in the class, and arbitrary types declared as members by
> > use of a typedef declaration (7.1.3). The enumerators of an unscoped
> > enumeration (7.2) defined in the class are members of the class.
> > Except when used to declare friends (11.4) or to introduce the name of
> > a member of a base class into a derived class (7.3.3, 11.3), member-
> > declarations declare members of the class, and each such member-
> > declaration shall declare at least one member name of the class. A
> > member shall not be declared twice in the member-specification, except
> > that a nested class or member class template can be declared and then
> > later defined, and except that an enumeration can be introduced with
> > an opaque-enum-declaration and later redeclared with an enum-
> > specifier.
>
> > 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?
>

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

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 Collins

"Ian Collins" <ian-> wrote in message
news:...
> On 02/22/11 12:01 AM, Paul wrote:
>>
>> <big snip>
>>
>>>>> No, it states the *type* (emphasis mine) of pointer expression shall
>>>>> be “pointer to class object”. Not the value shall be “pointer to an
>>>>> instance of a class object”.
>>>
>>>> Don't be silly , how can a type point to anything.
>>>
>>> I'm not being silly, I was pointing out an error in your
>>> interpretation of 5.2.5 (with the actual text).
>>>
>>>> Your being unreasonable here , the standards simply do not state that
>>>> at
>>>> all, I'm not even gonna bother requoting to prove it , its further up
>>>> the page, I quoted it plenty already.
>>
>> I have to admit it does say type , but this misunderstanding is due to
>> your innapporiopriate snipping of my original quote.
>
> 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.
>
>> However this does not make your program valid, that was only one of many
>> arguments I have against your program.
>
> What is the definition of valid?
>
>> <snip snip>
>>>
>>> You asked for "standard compliant code" and you have yet to show how
>>> the code violates any constraints.
>>
>> You produce UB prior to invokation of the member function, to suggest
>> that the results of UB is standard compliant code is nonsense.
>
> 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.

"itaj sherman" <> wrote in message
news:0be04cfe-0ea8-4893-bf21-...
On Feb 21, 9:52 pm, itaj sherman <itajsher...@gmail.com> wrote:
> On Feb 21, 8:31 pm, itaj sherman <itajsher...@gmail.com> wrote:
>
>
>
>
>
> > On Feb 21, 7:46 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
> > > Object Orientated Programming.
>
> > > I guess you are looking for a more detailed answer but I don't know
> > > what to
> > > say TBH. I think there are differing opinions about some OOP concepts.
> > > But
> > > there are some concepts that are generally agreed on, member functions
> > > as
> > > members of an object is one of the generally agreed upon concepts
> > > IMHO.
>
> > Whatever your definitions mean.
> > The following section of the standard is very clear about the
> > definitions of all members in c++ (and whether they are members of the
> > class or something else):
>
> > 9.2/1 The member-specification in a class definition declares the full
> > set of members of the class; no member can be added elsewhere. Members
> > of a class are data members, member functions (9.3), nested types, and
> > enumerators. Data members and member functions are static or non-
> > static; see 9.4. Nested types are classes (9.1, 9.7) and enumerations
> > (7.2) defined in the class, and arbitrary types declared as members by
> > use of a typedef declaration (7.1.3). The enumerators of an unscoped
> > enumeration (7.2) defined in the class are members of the class.
> > Except when used to declare friends (11.4) or to introduce the name of
> > a member of a base class into a derived class (7.3.3, 11.3), member-
> > declarations declare members of the class, and each such member-
> > declaration shall declare at least one member name of the class. A
> > member shall not be declared twice in the member-specification, except
> > that a nested class or member class template can be declared and then
> > later defined, and except that an enumeration can be introduced with
> > an opaque-enum-declaration and later redeclared with an enum-
> > specifier.
>
> > 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.
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.

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

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:
http://www.youtube.com/watch?v=sc3nIoiOUEk

itaj

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.

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

itaj

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?

--
Ian Collins

"Ian Collins" <ian-> wrote in message
news:...
> On 02/22/11 08:41 AM, Paul wrote:
>>
>> "Ian Collins" <ian-> wrote in message
>> news:...
>>> On 02/22/11 03:37 AM, Paul wrote:
>>>>
>>>> "Leigh Johnston" <> wrote:
>>>>>
>>>>> A null pointer value does not have to be zero; a null pointer value is
>>>>> an address.
>>>>>
>>>> The above seems incorrect:
>>>> A null pointer is a pointer that *doesn't* have an address.
>>>
>>> So by your logic expressed in this thread, a null doesn't exist?
>>>
>> I agree with this description:
>> http://www2.research.att.com/~bs/bs_faq2.html
>
> 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.

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?