To prevent access to null pointer method

[Wu zhen hai]

#include <exception>
#include <iostream>
class A
{
public:
  void show() {
    if (this == nullptr) throw std::exception();//current_line
  }
};

int main()
{
  A* ptra = nullptr;
  try
  {
    ptra->show();
  }
  catch (std::exception& e)
  {
    std::cout << "error" << std::endl;
  }
  std::cin.get();
}

if pointer is nullptr, 'this' will be nullptr.
Is it suitable to use 'current_line' to avoid 'access to null pointer' crash?

[JLBorges]

If the this pointer in is null or invalid, it is a clear programming error, not a run-time error.
This error should be detected and corrected during development, and should not be present in production code.

[Wu zhen hai]

I care more about the 'feasibility', not the 'reasonability'.

[mbozzi]

What is it supposed to mean if this is null? It's nonsense, clearly.
((A*) nullptr)->show();

Edit: I'll be more explicit: the behavior is undefined. Make A::show static, or a non-member, and pass the pointer as an argument.

[Enoizat]

According to this post
https://www.reddit.com/r/cpp_questions/comments/3roy3e/this_nullptr_can_this_ever_be_true/
"this" cannot be "nullptr" (the behaviour is undefined, as mbozzi said).

[jonnin]

'this' aside, there are smart pointer classes (most are a little clunky and bloated) or you can try to roll your own. I had one way back before the STL and all it did was 3 things... free the memory when the dtor was invoked, for auto-cleanup, assign to null on creation (initialize, that is) and allocate memory (ctor or afterwards, user choice). Still bloat, but saved a lot of hands-on tracking (at some minor risk, if you didn't understand what would happen in some scenarios you could destroy things accidentally). Its trivial to write something like that if you find it useful -- the temptation is to make it a big feature rich mess that makes every pointer you use a a performance hit.

Use of pointers is fading, so the value in this is dubious at best, now.

[Wu zhen hai]

@Enizat

ok! it is an undefined behaviour!


Thanks for all!

[JLBorges]

> I care more about the 'feasibility', not the 'reasonability'.

The check for this being a null pointer is not even (portably) feasible. In a well-formed C++ program, the this pointer can never be null; a compiler may completely eliminate the redundant check and the associated code.

class A
{
public:
  void show() {
    /*
    // may be optimised away as dead code 
    if (this == nullptr) throw std::exception();//current_line
    */
  }
};

Of the three mainstream compilers, it is only the GNU compiler that actually performs this optimisation.

#include <iostream>

struct A
{
    const char* foo() const
    {
        // clang++: warning: 'this' pointer cannot be null in well-defined C++ code;
        //          pointer may be assumed to always convert to true
        //
        //     g++: warning: nonnull argument 'this' compared to NULL
        if( this == nullptr ) return "this == nullptr" ;

        return "not nullptr (in C++ the this pointer can't be null)" ;
    }
};

int main()
{
   const A* pa = nullptr ;
   std::cout << pa->foo() << '\n' ; // g++: not nullptr (in C++ the this pointer can't be null)
                                    // clang++, microsoft: this == nullptr
}

http://coliru.stacked-crooked.com/a/42533d8a73cc6126
https://godbolt.org/g/sqPsuX

[Wu zhen hai]

ok, 'optimized as dead code' is an important reason!