Include Order and Hidden Dependencies - c++

Question

While looking for best pratices regarding include order, I was stumbling over this thread:
C/C++ include file order/best practices [closed]
#squelart was stating, that it is better pratice to include from local to global, as this reduces the chance of hidden dependencies. I just tested this in a VS2015 project with the following code:
StrTest.h
#pragma once
class CStrTest
{
public:
CStrTest();
~CStrTest();
std::string test;
};
StrTest.cpp
#include <string>
#include "StrTest.h"
CStrTest::CStrTest()
{
}
CStrTest::~CStrTest()
{
}
I couldn't reproduce the stated behaviour (hidden dependencie duo including string first in StrTest.cpp). The compiler gives me mulitple errors. So is this something out of the past or did I overlook something?
EDIT: VS2015 Compiler errors:
Error C4430 missing type specifier - int assumed. Note: C++ does not support default-int
Error C2039 'string': is not a member of 'std'
Error C3646 'test': unknown override specifier

Answer 1

So is this something out of the past
No, the hidden dependencies are the standard behaviour and do happen in modern compilers. I don't know of VS, but GCC and Clang do compile your shown program without any errors. Demo: https://wandbox.org/permlink/ATJndwrOwirpDgDd
The compiler gives me mulitple errors.
Although an "implicit" include is poor style, it is still technically well formed as far as the standard is concerned as long as the implicitly included file is guaranteed to be included by you or whoever wrote the header that includes it - standard headers have no such guarantees.
Therefore I would be against such compiler feature that considers implicit includes as errors. An explicitly enable-able warning would be much more suitable.

Answer 2

I think the point of hidden dependence problem discussed there is that typically each file includes several other files and if header is not self-contained then including it may work in cases when it's implicit dependences are included by some other header and break everything when those other headers change and / or get moved / removed. In short: use of headers with hidden dependencies lead to extremely fragile code.
// foo.hpp
#pragma once
#include <string> // if we remove this unrelated `StrTest.h` header will be broken
...
.
// main.cpp
#include "foo.hpp" // if we move this one line lower `StrTest.h` header will be broken
#include "StrTest.h" // accidentally works fine
...