NFD

Does this apply to ndn-cxx as well or just NFD?

Answer to note-5:

ndn-cxx is a platform project so it conforms to the same policy.

These checks don't hurt and I don't see the advantage in dropping them. Remember that there are other platforms beyond the supported ones, such as Android or uclibc/musl-based embedded systems, that we should care about. Also, compiler version != standard library capabilities, there are platforms that ship with a recent gcc version but a different standard library that is lagging behind libstdc++.

I partially disagree with this.

• FRIEND_TYPENAME is a compiler feature, not standard library capability.
• NFD-Android uses gnustl_shared which is libstdc++-v3.

The harm of keeping those is: there's no effective way to prevent a developer from using std::is_default_constructible, etc directly without wrapping with a #ifdef, because every platform on Jenkins will successfully build the code.

Junxiao Shi wrote:

• FRIEND_TYPENAME is a compiler features, not standard library capability.

I'd be ok with removing this check. (assuming it's supported by MSVC)

• NFD-Android uses gnustl_shared which is libstdc++-v3.

Yeah but some features depend on the C library used, e.g. glibc vs musl vs bionic etc...

Let me remind you that one of the goals of v0.5 is expanding the actively supported platforms to mobile and embedded devices. I'm not against removing unnecessary cruft, but first make sure you're not making it harder to support those platforms down the road.

The harm of keeping those is: there's no effective way to prevent a developer from using std::is_default_constructible, etc directly without wrapping with a #ifdef, because every platform on Jenkins will successfully build the code.

Of course it would be better to have more extensive CI coverage, but keeping the checks doesn't make the situation any worse. Removing them, on the other hand, creates more work in case we need to re-introduce them later when we extend the support to more platforms.