Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Is it legal code?

Reply
Thread Tools

Is it legal code?

 
 
itaj sherman
Guest
Posts: n/a
 
      02-20-2011
On Feb 20, 11:13 pm, "Paul" <(E-Mail Removed)> wrote:

>
> Yes.
> I agree the word 'exists' is a bit dubious.
>
> To me a function exists if it has been declared and defined, but with
> nonstatic member functions it is not so simple because they are undefined
> unless called on an object.


I think you mean: "Without an objet the function invocation causes
undefined behaviour".

The "function definition" istelf has nothing to do with it.
The "function extistance" - depends how you define that.

However, this should be exactly the same as any reference parameter,
as in my example.
void foo( A& );
This function invocation without a valid object argument, will have
undefined behaviour.
Same as the nonstatic member function, and same as

> I think it is techincally possible to invoke a nonstatic and nonvirtual
> member function without an object, so therefore incorrect to say it does not
> exist, but I also think this would be invalid code according to the
> standard.
> The lifetime of a function could be considered as starting from when it is
> called until it returns, or it could be for as long as it is available for
> calling. The true definition of a functions existence is dependant on this.
> An object has a defined lifetime therefore I think it is correct to say an
> object only exists during its lifetime. It follows that the existence of a
> member function , called on said object, is dependant on the object existing
> in the first place. This is what I was trying to express.


Well then, maybe for these definitions, the names "function invocation
lifetime" and "function invocation exists" would be better than
"function lifetime" and "function exists"?
I think "function exists" could be confusing.

For example, IMO, even the names chosen for definitions in the
standard are not the best ones:
data member
static data member
function member
static function member

What the difinitions are, is very clear and precise in the standard,
but the names chosen for them IMO are quite confusing.
- The use of the word "static" as such, suggests that the difference
between "data member" and "static data member" is the same as the
difference between "function member" and "static function member".
This isn't so, it's not the same at all.
- Even the use of the same word "member", suggest that data, static
data, and functions are all members - belong to somthing in the same
way. Totaly not. The meaning of the word member is totaly different.

I think better names would be instead:

subobject variable //data member
because it defines a certain subobject of every instance of that
class.

related variable //static data member
because is just like a single global variable, except it's related to
the class by scope.

attached function //function member
the function's call syntax and lookup is attached to the special first
argument which is written before the function name and is equivalent
to a reference of the class.

related function //static function member
just like a global function, but related to the class by scope

I wouldn't use misleading words like "member" and "static".
But there's no chance to change them in the standard after been used
so long.

itaj
 
Reply With Quote
 
 
 
 
itaj sherman
Guest
Posts: n/a
 
      02-20-2011
On Feb 21, 12:32*am, Ian Collins <(E-Mail Removed)> wrote:
> On 02/21/11 11:11 AM, Paul wrote:
>


> > Can he actually show some standard compliant code that calls a nonstatic
> > member function
> > a) on a class type
> > b) without and object.

>
> a.h:
>
> struct A { void foo(); };
>
> void f( A* a );
>
> a.cc:
>
> #include "a.h"
>
> void A::foo() {}
>
> void f( A* a ) { a->foo(); }
>
> main.cc:
>
> #include "a.h"
>
> int main()
> {
> * *A a;
>
> * *f(&a); * // With object.
> * *f(NULL); // Without object.


I think this is undefined behaviour, even thought A::foo is empty.
inside f(),
a->foo()
is equivalent to:
(*a).foo()
which would be an indirection of NULL, undefined behaviour.
isn't it?

>
> }
>


itaj
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      02-20-2011
On 02/21/11 12:05 PM, itaj sherman wrote:
> On Feb 21, 12:32 am, Ian Collins<(E-Mail Removed)> wrote:
>> On 02/21/11 11:11 AM, Paul wrote:
>>

>
>>> Can he actually show some standard compliant code that calls a nonstatic
>>> member function
>>> a) on a class type
>>> b) without and object.

>>
>> a.h:
>>
>> struct A { void foo(); };
>>
>> void f( A* a );
>>
>> a.cc:
>>
>> #include "a.h"
>>
>> void A::foo() {}
>>
>> void f( A* a ) { a->foo(); }
>>
>> main.cc:
>>
>> #include "a.h"
>>
>> int main()
>> {
>> A a;
>>
>> f(&a); // With object.
>> f(NULL); // Without object.

>
> I think this is undefined behaviour, even thought A::foo is empty.
> inside f(),
> a->foo()
> is equivalent to:
> (*a).foo()
> which would be an indirection of NULL, undefined behaviour.
> isn't it?


It may result in undefined behaviour, but there's nothing non standard
in the code. I put the declaration and definition in separate
compilation units to force the point. There is no way the compiler can
know about the working of f() when compiling main.cc.

--
Ian Collins
 
Reply With Quote
 
itaj sherman
Guest
Posts: n/a
 
      02-20-2011
On Feb 21, 1:11 am, Ian Collins <(E-Mail Removed)> wrote:
> On 02/21/11 12:05 PM, itaj sherman wrote:


>
> > On Feb 21, 12:32 am, Ian Collins<(E-Mail Removed)> wrote:
> >> On 02/21/11 11:11 AM, Paul wrote:

>
> >>> Can he actually show some standard compliant code that calls a nonstatic
> >>> member function
> >>> a) on a class type
> >>> b) without and object.

>


>
> It may result in undefined behaviour, but there's nothing non standard
> in the code. I put the declaration and definition in separate
> compilation units to force the point. There is no way the compiler can
> know about the working of f() when compiling main.cc.
>


That's true.
I'd think Paul meant code "with defined behaviour", not just "well
formed".
But then again, he didn't specify that clearly.
And as you mention in your previous post, he doesn't seem strict about
the difference between "defined" and "defined behaviour".

And his response to that certainly didn't clear that up:

>
> >> To me a function exists if it has been declared and defined, but with
> >> nonstatic member functions it is not so simple because they are
> >> undefined unless called on an object.

>


Does Paul mean "undefined behaviour"?

> > How can something with a definition (the function body) be undefined?

>
> Sorry I meant unless called on an object it's undefined *by the standard* ,
> I should've been clearer.
>


Again, does Paul mean "undefined behaviour"?

itaj
 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      02-20-2011
James Kanze wrote:

> On Feb 20, 1:09 am, "Paul" <(E-Mail Removed)> wrote:
>> "gwowen" <(E-Mail Removed)> wrote in message

>
>> news:(E-Mail Removed)...
>> On Feb 19, 11:27 am, "Paul" <(E-Mail Removed)> wrote:

>
>> > Is it legal to invoke a (non static) member function without an object?

>
>> > I read something in the C++ standard that it may not be standard
>> > compliant code to invoke a (non static)member function directly from a
>> > pointer.

>
>> --If the pointer points to an object that still exists, its fine.
>> --Otherwise, no. Essentially the same as dereferencing the pointer.

>
>> So given that the following is true:

>
>> "If a nonstatic member function of a class X is called for an
>> object that is not of type X, or of a type derived from X, the
>> behavior is undefined."

>
>> It follows that if an object(or derived object) does not exist then it is
>> undefined behaviour to call its respective nonstatic member function?
>> Therefore it must be true that a member function does not exist without
>> an object.

>
> I don't quite follow you here. If I have a function:
> void f(int&);
> , it's undefined behavior for me to call f without a an object
> of type int. The function f(int&) still "exists". For some
> definition of "exists"---this is getting a bit too metaphysical
> for me. One could argue that in C++, only "objects" exist, and
> references and functions aren't objects, so can't "exist".
>


For me, only entities can "exist" and do exist (wiki: "An entity is
something that has a distinct, separate existence, although it need not be a
material existence."). In C++, functions and references are entities (in
C++03, a reference was not an entity yet, but has grown to be one in C++0x,
since the one definition rule also applies to references).

The identity of functions are their signature and I believe the identity of
objects is the tuple of (type, address) (address alone is not sufficient,
for example when you have an array, the first element has the same address
as its array).

I believe that everything that semantically "exists" in C++ needs to be
mentioned in the entity list, and usually needs to be mentioned in the one
definition rule (unless it can't apply to it, like "value"s and "parameter
pack"s). It's my own interpretation though. I'm not at all saying that your
model of "exists" is wrong or anything
 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      02-20-2011
Paul wrote:

>
> "James Kanze" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On Feb 20, 1:09 am, "Paul" <(E-Mail Removed)> wrote:
>>> "gwowen" <(E-Mail Removed)> wrote in message

>>
>>> news:d411186f-2faa-4429-

http://www.velocityreviews.com/forums/(E-Mail Removed)...
>>> On Feb 19, 11:27 am, "Paul" <(E-Mail Removed)> wrote:

>>
>>> > Is it legal to invoke a (non static) member function without an
>>> > object?

>>
>>> > I read something in the C++ standard that it may not be standard
>>> > compliant
>>> > code to invoke a (non static)member function directly from a pointer.

>>
>>> --If the pointer points to an object that still exists, its fine.
>>> --Otherwise, no. Essentially the same as dereferencing the pointer.

>>
>>> So given that the following is true:

>>
>>> "If a nonstatic member function of a class X is called for an
>>> object that is not of type X, or of a type derived from X, the
>>> behavior is undefined."

>>
>>> It follows that if an object(or derived object) does not exist then it
>>> is undefined behaviour to call its respective nonstatic member function?
>>> Therefore it must be true that a member function does not exist without
>>> an
>>> object.

>>
>>The function f(int&) still "exists". For some
>> definition of "exists"---this is getting a bit too metaphysical
>> for me. One could argue that in C++, only "objects" exist, and
>> references and functions aren't objects, so can't "exist".
>>

> An object(instance of a class type) has a lifetime, it exists for the
> duration of its lifetime.
> Because C++ disallows calling nonstatic member functions, without an
> object of , or derived from, the respective class type. A non static
> member function cannot exist unless an object exists.


For some objects, they exist not only during their lifetime, but also
afterwards and previously: The lifetime of class objects start as soon as
their constructor finishes execution, and their lifetime stops as soon as
the destructor finishes execution. But the object already exists at the
start of the constructor execution and still exists until the destructor
stops execution.

The Standard is not actually clear about the existence-question of objects,
I think. I think you can say that for non-class objects, their lifetime
defines their existence. But for class objects, the definition is more
complicated. An alternative model I can see can be interpreted from the
Standard is that an object starts existence independently from starting its
lifetime. But this alternative model has serious trouble, including the
question how objects that are created by mere writes to storage (malloc +
write) come to existence.


 
Reply With Quote
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      02-20-2011
Paul wrote:

>
> "James Kanze" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On Feb 20, 1:09 am, "Paul" <(E-Mail Removed)> wrote:
>>> "gwowen" <(E-Mail Removed)> wrote in message

>>
>>> news:d411186f-2faa-4429-

(E-Mail Removed)...
>>> On Feb 19, 11:27 am, "Paul" <(E-Mail Removed)> wrote:

>>
>>> > Is it legal to invoke a (non static) member function without an
>>> > object?

>>
>>> > I read something in the C++ standard that it may not be standard
>>> > compliant
>>> > code to invoke a (non static)member function directly from a pointer.

>>
>>> --If the pointer points to an object that still exists, its fine.
>>> --Otherwise, no. Essentially the same as dereferencing the pointer.

>>
>>> So given that the following is true:

>>
>>> "If a nonstatic member function of a class X is called for an
>>> object that is not of type X, or of a type derived from X, the
>>> behavior is undefined."

>>
>>> It follows that if an object(or derived object) does not exist then it
>>> is undefined behaviour to call its respective nonstatic member function?
>>> Therefore it must be true that a member function does not exist without
>>> an
>>> object.

>>
>>The function f(int&) still "exists". For some
>> definition of "exists"---this is getting a bit too metaphysical
>> for me. One could argue that in C++, only "objects" exist, and
>> references and functions aren't objects, so can't "exist".
>>

> An object(instance of a class type) has a lifetime, it exists for the
> duration of its lifetime.
> Because C++ disallows calling nonstatic member functions, without an
> object of , or derived from, the respective class type. A non static
> member function cannot exist unless an object exists.


For some objects, they exist not only during their lifetime, but also
afterwards and previously: The lifetime of class objects start as soon as
their constructor finishes execution, and their lifetime stop as soon as
the destructor begins execution. But the object already exists at the
start of the constructor execution and still exists until the destructor
stops execution.

The Standard is not actually clear about the existence-question of objects,
I think. I think you can say that for non-class objects, their lifetime
defines their existence. But for class objects, the definition is more
complicated. An alternative model I can see can be interpreted from the
Standard is that an object starts existence independently from starting its
lifetime. But this alternative model has serious trouble, including the
question how objects that are created by mere writes to storage (malloc +
write) come to existence.


 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      02-21-2011

"Ian Collins" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On 02/21/11 12:05 PM, itaj sherman wrote:
>> On Feb 21, 12:32 am, Ian Collins<(E-Mail Removed)> wrote:
>>> On 02/21/11 11:11 AM, Paul wrote:
>>>

>>
>>>> Can he actually show some standard compliant code that calls a
>>>> nonstatic
>>>> member function
>>>> a) on a class type
>>>> b) without and object.
>>>
>>> a.h:
>>>
>>> struct A { void foo(); };
>>>
>>> void f( A* a );
>>>
>>> a.cc:
>>>
>>> #include "a.h"
>>>
>>> void A::foo() {}
>>>
>>> void f( A* a ) { a->foo(); }
>>>
>>> main.cc:
>>>
>>> #include "a.h"
>>>
>>> int main()
>>> {
>>> A a;
>>>
>>> f(&a); // With object.
>>> f(NULL); // Without object.

>>
>> I think this is undefined behaviour, even thought A::foo is empty.
>> inside f(),
>> a->foo()
>> is equivalent to:
>> (*a).foo()
>> which would be an indirection of NULL, undefined behaviour.
>> isn't it?

>
> It may result in undefined behaviour, but there's nothing non standard in
> the code. I put the declaration and definition in separate compilation
> units to force the point. There is no way the compiler can know about the
> working of f() when compiling main.cc.
>
> --

No the code is invalid ref:
"5.2.5 Class member access [expr.ref]
1 A postfix expression followed by a dot . or an arrow >,
optionally followed by the keyword template
(14.8.1), and then followed by an idexpression,
is a postfix expression. The postfix expression before the
dot or arrow is evaluated;55) the result of that evaluation, together with
the idexpression,
determine the
result of the entire postfix expression.
2 For the first option (dot) the type of the first expression (the object
expression) shall be "class object" (of a
complete type). For the second option (arrow) the type of the first
expression (the pointer expression) shall
be "pointer to class object" (of a complete type). In these cases, the
idexpression
shall name a member of
the class or of one of its base classes. [Note: because the name of a class
is inserted in its class scope (9),
the name of a class is also considered a nested member of that class. ]
[Note: 3.4.5 describes how names
are looked up after the . and >
operators. ]"


The above quote from the C++ standard states "the first expression (the
pointer expression) shall
be "pointer to class object" (of a complete type). ".
Your expression a->foo() , with a =NULL, is not valid C++ code.

 
Reply With Quote
 
itaj sherman
Guest
Posts: n/a
 
      02-21-2011
On Feb 21, 3:14 am, "Paul" <(E-Mail Removed)> wrote:
> "Ian Collins" <(E-Mail Removed)> wrote in message
>
> news:(E-Mail Removed)...
>


>
>
> The above quote from the C++ standard states "the first expression (the
> pointer expression) shall
> be "pointer to class object" (of a complete type). ".
> Your expression a->foo() , with a =NULL, is not valid C++ code.- Hide quoted text -
>


You never mentioned validity before.
The code is well formed.
May produce undefined behaviour.

itaj
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      02-21-2011
On 02/21/11 02:14 PM, Paul wrote:
>
> "Ian Collins" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On 02/21/11 12:05 PM, itaj sherman wrote:
>>> On Feb 21, 12:32 am, Ian Collins<(E-Mail Removed)> wrote:
>>>> On 02/21/11 11:11 AM, Paul wrote:
>>>>
>>>
>>>>> Can he actually show some standard compliant code that calls a
>>>>> nonstatic
>>>>> member function
>>>>> a) on a class type
>>>>> b) without and object.
>>>>
>>>> a.h:
>>>>
>>>> struct A { void foo(); };
>>>>
>>>> void f( A* a );
>>>>
>>>> a.cc:
>>>>
>>>> #include "a.h"
>>>>
>>>> void A::foo() {}
>>>>
>>>> void f( A* a ) { a->foo(); }
>>>>
>>>> main.cc:
>>>>
>>>> #include "a.h"
>>>>
>>>> int main()
>>>> {
>>>> A a;
>>>>
>>>> f(&a); // With object.
>>>> f(NULL); // Without object.
>>>
>>> I think this is undefined behaviour, even thought A::foo is empty.
>>> inside f(),
>>> a->foo()
>>> is equivalent to:
>>> (*a).foo()
>>> which would be an indirection of NULL, undefined behaviour.
>>> isn't it?

>>
>> It may result in undefined behaviour, but there's nothing non standard
>> in the code. I put the declaration and definition in separate
>> compilation units to force the point. There is no way the compiler can
>> know about the working of f() when compiling main.cc.
>>


> No the code is invalid ref:
> "5.2.5 Class member access [expr.ref]


<snip>

> The above quote from the C++ standard states "the first expression (the
> pointer expression) shall
> be "pointer to class object" (of a complete type). ".
> Your expression a->foo() , with a =NULL, is not valid C++ code.


Where did I write a->foo() , with a =NULL?

I wrote a->foo() with a being an A* which is a pointer to a complete type.

Point out exactly where the standard is violated in either of those two
compilation units.

--
Ian Collins
 
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
Is it legal to write an logical equation for a FPGA LUT in claims of a patent? Weng Tianxiang VHDL 12 12-10-2005 03:49 PM
Research: File-sharers big legal download spenders. Silverstrand Front Page News 0 07-27-2005 03:00 PM
State machine transition on internal signals - is it legal? Divyang M VHDL 9 05-18-2005 03:58 PM
State machine transition on internal signals -- is it legal? Divyang M VHDL 1 05-15-2005 09:36 AM
Is this legal? Valentin Tihomirov VHDL 20 10-29-2003 10:31 AM



Advertisments