How is Null a Possible Value for "this" in C++?

Question

I am puzzled by a NULL value for "this" in one of my native C++ classes.

I declare the class in stdafx.h like so:

extern Filing* Files;

Then implement it in stdafx.cpp like so:

Filing* Files = new Filing();

The debugger chokes on this method, and throws a "Write access violation": Message also says: "this was nullptr".

void Filing::Startup()
{
this->ExePath = this->GetPathToExe(); //Throws right here
this->LogDirectoryPath = this->GetLogDirectoryPath();
CreateDirectory(LogDirectoryPath->c_str(), NULL);
}

How is this possible? How do I fix this? Full "Filing" header and definition below.

Filing.h:

#pragma once

#include <Windows.h>
#include <sstream>

using namespace std;

class Filing
{
  public:
     Filing();
     ~Filing();

/// <summary>
/// The path to this exe.
/// </summary>
     wstring* ExePath;

/// <summary>
/// The path to the log folder that exists or will be created.
/// </summary>
    wstring* LogDirectoryPath;

/// <summary>
/// Kicks off some startup logic.
/// </summary>
    void Startup();

/// <summary>
/// Determines if the specified directory exists.
/// </summary>
/// <param name="Path"></param>
/// <returns></returns>
    bool DoesDirectoryExist(string* Path);

  private:

/// <summary>
/// Returns the directory from which this executable is running from.
/// </summary>
    wstring* GetPathToExe();

/// <summary>
/// Gets the path to the log directory.
/// </summary>
/// <returns></returns>
    wstring* GetLogDirectoryPath();
};

Filing.cpp:

#include "stdafx.h"
#include "Filing.h"

Filing::Filing()
{
   this->Startup();
}

Filing::~Filing()
{
   delete this->ExePath;
   delete this->LogDirectoryPath;
}

void Filing::Startup()
{
   this->ExePath = this->GetPathToExe();
   this->LogDirectoryPath = this->GetLogDirectoryPath();
   CreateDirectory(LogDirectoryPath->c_str(), NULL);
}

bool Filing::DoesDirectoryExist(string* Path)
{
   DWORD ftyp = GetFileAttributesA(Path->c_str());

   if (ftyp == INVALID_FILE_ATTRIBUTES)
   {
     Console->WriteLine("Invalid path!");
     return false;  //something is wrong with your path!
   }

   if (ftyp & FILE_ATTRIBUTE_DIRECTORY)
   {
      return true;   // this is a directory!
   }

   return false;    // this is not a directory!
}

wstring* Filing::GetPathToExe()
{
   #ifdef UNICODE
   TCHAR ownPth[260];
   #else
   char ownPth[MAX_Path];
   #endif // UNICODE

   // Will contain exe path
   HMODULE hModule = GetModuleHandle(NULL);
   if (hModule != NULL)
   {
      // When passing NULL to GetModuleHandle, it returns handle of exe itself
      GetModuleFileName(hModule, ownPth, (sizeof(ownPth)));
      return new wstring(ownPth);
   }
   else
   {
      throw new exception("Error! NullPointerException!");
   }
}

wstring* Filing::GetLogDirectoryPath()
{
   //if (this == nullptr)
   //{
   //   int i = 0;
   //}

   wstring *directory;
   const size_t last_slash_idx = ExePath->rfind('\\');
   if (string::npos != last_slash_idx)
   {
      directory = new wstring(ExePath->substr(0, last_slash_idx));
      directory->append(L"\\Logs");
   }
   else
   {
      throw new exception("Error! Directory not found from path!");
   }
   return directory;
}

Things I have tried so far:

Clean and Rebuild.

Initializing Filing.

EDIT:

I have seen some comments about not using stdafx.h and stdafx.cpp for what I am using it for. I am using them for global variables/classes right now. How could I define them elsewhere and still be global?

EDIT2:

Traced the error all the way back to a little GetTime() function.

const char* Writer::GetTime()
{
    string* Formatted = new string("[");
    time_t rawtime;
    tm* timeinfo;
    char buffer[80];
    time(&rawtime);
    timeinfo = std::localtime(&rawtime);

    strftime(buffer, 80, "%Y-%m-%d-%H-%M-%S", timeinfo);
    Formatted->append(buffer);
    Formatted->append("]: ");

    const char* Ret = Formatted->c_str();

    delete Formatted;
    delete timeinfo;//Errors here SOMETIMES. Any ideas?
    return Ret;
}

I don't program in Winders but are you supposed to edit stdafx.h? I thought this was compiler generated precompiled header? But then, what do I know about Winders? — systemcpro, Aug 01 '17 at 19:11
@systemcpro: It's generated by the IDE. But you are free to edit it. — Benjamin Lindley, Aug 01 '17 at 19:12
Why is this == nullptr not allowed? It wasn't in my original code with the bug, it was just debugging code to prove the error wasn't being misdiagnosed by the debugger. Anyways, If you remove it you will still have the issue. — SneakyTactician2, Aug 01 '17 at 19:12
@Justin - Really? I can't find a reference to that (comparing to nullptr I mean). — StoryTeller - Unslander Monica, Aug 01 '17 at 19:12
Don't implement things in `stdafx.cpp`; it should be empty except for `#include "stdafx.h"` — Justin, Aug 01 '17 at 19:12
To use a non-static member method you are required to use a valid instance. If `this` would be `nullptr`, you have undefined behavior. You can therefor disregard any comparison between `this` and `nullptr` as either they are different or you have undefined behavior and may act as though they were different. — François Andrieux, Aug 01 '17 at 19:13
Thanks Benjamin - maybe you'll make a Windows man out of me yet :) — systemcpro, Aug 01 '17 at 19:15
Possible duplicate of [In which case the C++ this pointer can be NULL](https://stackoverflow.com/q/31336294/11683) — GSerg, Aug 01 '17 at 19:15
@StoryTeller what Justin likely means is that you can't pass `nullptr` `this` and then expect the test within the function to work. — yuri kilochek, Aug 01 '17 at 19:15
If `this` is `nullptr` your program has Undefined Behaviour. In a correct program, `this` is never `nullptr`. — Jesper Juhl, Aug 01 '17 at 19:16
...and a reproducible code would be nice to find the error for you. — deviantfan, Aug 01 '17 at 19:17
@yurikilochek - No, that's not what Justin said. "Not being allowed" is not the same as being removed because the compiler knows the language better than you. Simply having the check there is not UB or a constraint violation, it's just silly. — StoryTeller - Unslander Monica, Aug 01 '17 at 19:17
I have seen visual studio show nonesense for the this pointer when the breakpoint is set at the start of a function scope (it didnt fill in the this value yet). — Andreas Loanjoe, Aug 01 '17 at 19:17
@StoryTeller I don't always remember everything correctly. You are allowed to do `this == nullptr`, but since `this` can never be null, the compiler can ignore the comparison — Justin, Aug 01 '17 at 19:18
@Andreas Loanjoe The commented out check if (this == nullptr) proved it wasn't just nonsense. — SneakyTactician2, Aug 01 '17 at 19:19
@SneakyTactician2 commented out code *proves* absolutely *nothing*. — Jesper Juhl, Aug 01 '17 at 19:23
@Jesper Juhl Is there any way to prove anything here? Somehow it seems there is some undefined behavior going on. Can we track that to the source? — SneakyTactician2, Aug 01 '17 at 19:25
@manni66 Totally right there. That should just be a console message. — SneakyTactician2, Aug 01 '17 at 19:25
@SneakyTactician2, @manni66's comment was in regards to using `new` to construct an exception, not about throwing an exception. It should just be `throw exception("Message")` In general, you're using `new` in lots of places you don't need it. — Miles Budnek, Aug 01 '17 at 19:27
Why does `Startup()` exist? And as a *public* member even. Why not just inline that code in the constructor where it belongs? — Jesper Juhl, Aug 01 '17 at 19:28
@Miles Budnek You guys are right again. I'm originally a C# developer, so I am very "new" happy. — SneakyTactician2, Aug 01 '17 at 19:28
@SneakyTactician2 what are you looking to prove? Code containing UB can do *anything* it's fairly pointless trying to reason about it.. — Jesper Juhl, Aug 01 '17 at 19:30
@Jesper Juhl I just want to know what is causing it, so I can fix it. Kinda like every other developer when they get a bug? — SneakyTactician2, Aug 01 '17 at 19:32
Hard to say what the problem is, other than it probably isn't in the provided code. — user4581301, Aug 01 '17 at 19:33
What's causing it is a dangling reference somewhere. Or a null pointer being passed. — StoryTeller - Unslander Monica, Aug 01 '17 at 19:34
Minimal, Complete and Verifiable example, please. Otherwise we can talk about the irrelevant snippet until cows come home — SergeyA, Aug 01 '17 at 19:34
@StoryTeller or corrupted stack. Or double-freed pointer. Or any other of 100 reasons. — SergeyA, Aug 01 '17 at 19:35
@SergeyA - You forgot out of bounds access and heap corruption. Or is that in the other 100 reasons? — StoryTeller - Unslander Monica, Aug 01 '17 at 19:36
"*How could I define them elsewhere and still be global?*" - Uh, you just do it? What exactly is the problem? — melpomene, Aug 01 '17 at 19:43
The issue is probably due to this memory not set to zeroes: TCHAR ownPth[260]; And than when you create string from it, there is no \0 termination at the right place and you get access violation. Try TCHAR ownPth[260] = {0}; — David Constantine, Aug 01 '17 at 19:44
@David Constantine Ehh - his problem is *explicitly* a null value - the exact opposite of what you are saying. — Jesper Juhl, Aug 01 '17 at 19:49

score 3 · Accepted Answer · answered Aug 01 '17 at 20:02

Here's an example of a program that may result in you seeing this set to be a NULL pointer. (I say may because per the C++ language specification, this program invokes undefined behavior, so technically the compiler is free to crash or output an executable for PacMan or whatever else it wants to do in response to this source code... but in many compiler implementations, a commonly-observed behavior is a NULL this-pointer. Ahem):

#include <stdio.h>

class Foo
{
public:
   Foo() {/* empty*/}

   void bar() {printf("this=%p\n", this);}
};

int main(int, char **)
{
   Foo * f = NULL;
   f->bar();  // undefined behavior here: calling a method on a NULL object!
   return 0;
}

When I run this program, I get this output:

$ ./a.out 
this=0x0

Needless to say, you shouldn't do this in any real program.

As for your own code, the most likely explanation is that you are calling the Startup() method on a NULL pointer. The solution would be to track down all the locations where you call Startup(), and make sure that the pointer they call Startup() on is non-NULL (and pointing to a valid object) before calling any methods on it.

How is Null a Possible Value for "this" in C++?

1 Answers1