Back to General and Gameplay Programming

C++ "this" pointer?

pdugan · 2002-05-08T04:17:35

In the process of writing a Texture manager class, I came across a peculiar bug: a this pointer that is NULL. I was wondering if anyone else has come across this, and knows under what circumstances a this pointer can be null. Also, as a bonus question to any more experienced programmers: When dealing with pointers/references passed between functions, where does the responsibility of testing the pointers for validity lie? Should the calling function test a pointer it is going to pass for NULL? Should the recieving function perform this chore? Or should this test (and/or assert()) be done in both? Thanks in advance, Patrick "a riddle wrapped in a mystery inside an enigma" - Churchill

General and Gameplay Programming Programming

Started by pdugan May 02, 2002 03:41 PM

35 comments, last by pdugan 21 years, 11 months ago

davepermen

1,047

May 07, 2002 07:24 AM

quote:It buys me the knowledge that I am not allowing insidious and dormant bugs to lie in my code.

well.. if i know how my compiler i use works, i know much bether why an error occurs and why not..
if i follow the standart but the compiler doesn''t, then i a) have bugs i can''t find where they are b) write faults i don''t find..

if i follow my compiler then all errors and crashes that exists are faults by ME and they i can find with no bigger problem (sometimes with hours of browsing my code, but oh well..

)

in my compiler

object->Function();

is ObjectType::Function(object);

and

object.Function();

is ObjectType::Function(&object);

and because i know its that way i know what happens _IF_ there could be a 0->Function()..

then its not undefined behavior but simply no problem if this will never be dereferenced in the function ObjectType::Function or a crash if it will..

helps me more than knowing well.. it will behave undefined..

now the behaving _IS DEFINED_

that means i _CAN USE_ this as a feature, not as a bug..

one feature could be this:

bool Object::Valid() {
return this!=0;
}

this works assuming you create and release your objects correctly..

and the whole talk is just bullshit anyways..

you don''t care about the c++ standart
you don''t care about the abi standart

you care about WORKING code..

who needs c++?

ever worked on some console? you think their compilers are perfect? so you learn their standart.

stop beeing some stupid schoolboy crieing for standarts.. use what you have, and learn how it works.. don''t cry if it works stupid, be happy _THAT_ it works..

for pdugan

i think its some designfault in your code that resulted to call a 0-pointer-member function..

but without posting code we can''t help you much..

"take a look around" - limp bizkit
www.google.com

If that's not the help you're after then you're going to have to explain the problem better than what you have. - joanusdmentia

My Page davepermen.net | My Music on Bandcamp and on Soundcloud

SabreMan

504

May 07, 2002 08:31 AM

quote:Original post by davepermen
i think its some designfault in your code that resulted to call a 0-pointer-member function..

So, in that case, you agree with the generalism that he probably doesn''t want this to happen? If so, then you agree with the basic point I am making.

[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

SabreMan

504

May 07, 2002 05:09 PM

I've just had time to read this properly, and thought I would respond...

quote:Original post by davepermen
well.. if i know how my compiler i use works, i know much bether why an error occurs and why not..
if i follow the standart but the compiler doesn't, then i a) have bugs i can't find where they are b) write faults i don't find..

c) are going to have difficulties when you move to another compiler which matches a different subset of the Standard's requirements. That's not a desirable situation.

quote:
then its not undefined behavior but simply no problem if this will never be dereferenced in the function ObjectType::Function or a crash if it will..

helps me more than knowing well.. it will behave undefined..

No. Undefined behaviour implies that you probably didn't want to do it unless you have a specific reason to do so. It's often sufficient to know that something invokes undefined behaviour - if you didn't know that, then you probably shouldn't be doing it. Therefore, it can be useful to point out something leads to undefined behaviour.

quote:
bool Object::Valid() {
return this!=0;
}

this works assuming you create and release your objects correctly..

Under that assumption, the Object::Valid() method is free from value. If you are saying that assumption implies the technique will work, then it is also free from value when the assumption doesn't hold, as then it doesn't "work".

quote:
and the whole talk is just bullshit anyways..

Really? I actually thought it was a reasonable discussion until you joined in.

quote:
you don't care about the c++ standart
you don't care about the abi standart

you care about WORKING code..

The latter does not imply the first two statements. In fact, my standpoint is that the first two enable the latter, as they contribute towards defining the correctness of the code. Obviously, suitable unit tests would also contribute.

quote:
who needs c++?

What do you mean? If you are not interested in C++, then nobody is forcing you to discuss it here.

quote:
stop beeing some stupid schoolboy crieing for standarts..

What is this supposed to contribute to the discussion?

[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

[edited by - SabreMan on May 7, 2002 6:10:47 PM]

DrPizza

160

May 07, 2002 07:03 PM

quote:Results in undefined behaviour. Perhaps there is a good reason to do this, but I can''t think of one.

One might not do it on purpose; the pointer might point to memory allocated by non-throwing new (testing against NULL is typically cheaper than exception handling), or the member function might be called from another language.

Slightly different, but related; how does one implement an offsetof macro (which is both promised to exist and promised to be a macro) without dereferencing a NULL pointer?

char a[99999],*p=a;int main(int c,char**V){char*v=c>0?1[V]:(char*)V;if(c>=0)for(;*v&&93!=*v;){62==*v&&++p||60==*v&&--p||43==*v&&++*p||45==*v&&--*p||44==*v&&(*p=getchar())||46==*v&&putchar(*p)||91==*v&&(*p&&main(0,(char**)(--v+2))||(v=(char*)main(-1,(char**)++v)-1));++v;}else for(c=1;c;c+=(91==*v)-(93==*v),++v);return(int)v;}  /*** drpizza@battleaxe.net ***/

SabreMan

504

May 08, 2002 03:29 AM

quote:Original post by DrPizza
Slightly different, but related; how does one implement an offsetof macro (which is both promised to exist and promised to be a macro) without dereferencing a NULL pointer?

Why should I care unless I was writing a C++ compiler? All I''m interested in, where it''s relevant, is how offsetof is useful to me in writing C++ programs. I''ve just checked the C++ Standard, which refers out to the C Standard on this issue. The C99 Standard tells me this (I know I should be looking in the C89 Standard, but I don''t have it in front of me):

quote:
offsetof(type, member-designator)
which expands to an integer constant expression that has type size_t, the value of which is the offset in bytes, to the structure member (designated by member-designator), from the beginning of its structure (designated by type). The type and member designator shall be such that given

static type t;

then the expression &(t.member-designator) evaluates to an address constant. (If the specified member is a bit-field, the behaviour is undefined.)

I actually think that description is quite useful, and certainly not "irrelevant" should I be looking for such a solution.

[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

DrPizza

160

May 08, 2002 03:56 AM

quote:Original post by SabreMan
Why should I care unless I was writing a C++ compiler?

Because macros aren''t special, and it seems that the only way to get the desired semantics is for the language to permit dereferencing NULL pointers in certain manners.

quote:All I''m interested in, where it''s relevant, is how offsetof is useful to me in writing C++ programs. I''ve just checked the C++ Standard, which refers out to the C Standard on this issue. The C99 Standard tells me this (I know I should be looking in the C89 Standard, but I don''t have it in front of me):

I actually think that description is quite useful, and certainly not "irrelevant" should I be looking for such a solution.

It doesn''t strike me as particularly useful, as it''s not what I asked; I know what the macro is supposed to do. I''m wondering if one can implement it without dereferencing a NULL pointer. If one cannot then it forces dereferencing NULL pointers to be a well-defined thing to do.

char a[99999],*p=a;int main(int c,char**V){char*v=c>0?1[V]:(char*)V;if(c>=0)for(;*v&&93!=*v;){62==*v&&++p||60==*v&&--p||43==*v&&++*p||45==*v&&--*p||44==*v&&(*p=getchar())||46==*v&&putchar(*p)||91==*v&&(*p&&main(0,(char**)(--v+2))||(v=(char*)main(-1,(char**)++v)-1));++v;}else for(c=1;c;c+=(91==*v)-(93==*v),++v);return(int)v;}  /*** drpizza@battleaxe.net ***/

SabreMan

504

May 08, 2002 04:17 AM

quote:Original post by DrPizza
Because macros aren''t special, and it seems that the only way to get the desired semantics is for the language to permit dereferencing NULL pointers in certain manners.

The language does permit dereferencing NULL pointers in certain manners. What it doesn''t do is define the results, since it can''t extend that definition in a portable manner. It is completely necessary to rely on non-portable behaviour to implement a compiler and libraries. That doesn''t make non-portable behaviour any more palatable when it is not necessary.

quote:
It doesn''t strike me as particularly useful, as it''s not what I asked;

That doesn''t mean it''s not useful.

quote:
I know what the macro is supposed to do.

I know what it''s supposed to do aswell. I know that because the Standard tells me what it''s supposed to do. The Standard is not "irrelevant" as you seem to think.

quote:
I''m wondering if one can implement it without dereferencing a NULL pointer. If one cannot then it forces dereferencing NULL pointers to be a well-defined thing to do.

By some other standard. Which does not mean that the C++ Standard is irrelevant.

[ C++ FAQ Lite | ACCU | Boost | Python | Agile Manifesto! ]

C++ "this" pointer?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

C++ "this" pointer?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines