Error 'this_thread': the symbol to the left of a '::' must be a type?

Question

My headers:

#include <chrono>
#include <thread>
#include <iostream>
#include <string>
#include <fstream>
#include "include\curses.h"

My code problem:

        std::this_thread::sleep_for(std::chrono::milliseconds(500));

My error:

error C3083: 'this_thread': the symbol to the left of a '::' must be a type

It just makes no sense to me!? Every header needed is added. Intellisense (I'm on VS2012) detects the references and parameters. It just won't compile.

Other related errors

*error C2039: 'sleep_for' : is not a member of 'std'*

*error C3861: 'sleep_for': identifier not found*

Answer 1

I just experienced a similar issue - VS Intellisense had no problems with my code, but I was getting the same error you had when building, not just in VS but in GCC as well. (not a VS bug)

One big issue I had is that 2 headers were including each other. Essentially, because one file includes the other but the other is dependent on the first, you can get some strange behavior.

As you are no doubt aware, headers normally have #ifndef's at the top which encompass the entire contents of the header, so it can never be included more than once. This at least saves us from getting caught in an endless include loop, though we still have a problem.

When the second is included, it is referencing the first, but the first is already defined, so the first does not get included into the second, then the code from the second header is copied into the first where it was included. Because the second header is included above the functions it needs, you will get errors about things not being defined, and even namespaces not existing (because these are not defined until after the second is inserted at the top of the first.)

Here are 2 solutions:

1. In my case, because I was only dependent on the first file with a single small function, I chose to simply remove one of the dependencies by manually inlining the code in the second.

2. You should also be able to add prototypes to the functions you want to use, so if one gets included below the other you at least have a prototype which tells the compiler that "this will be defined later, just trust me it exists."

The way I found out what was going on was by moving the problem header above all the others in the include list, which revealed more errors many of which were similar but now plaguing the other include.

I'm not totally sure why the using namespace worked for you, but all I can figure is that this using statement at least tells the compiler to treat the name as a namespace rather than some undefined thing, hence the error about your namespace not being a type.