v.oddou
v.oddou

Reputation: 6775

Is there a way to detect portably that a standard header is included using macros?

I want to make an equivalent to boost::swap and in my environment, standard headers can, or cannot be included. Depending on project licencing and other stuff.
I'd like to make portions of the code protected by guard detectors:

Let's consider one compilation unit.
project specific, afore-written potential includes:

#include <algorithm> // (or <utility> for C++11 projects)

later in project code included from my swap utility header:

namespace MyCompany
{
  template<class T1, class T2>
  void swap(T1& left, T2& right)
  {
     #ifdef _ALGORITHM_   // you get the idea.
       std::swap(left, right);
     #else
       // fallback impl
     #endif
  }
}

I simplified because we are not talking about details of the ADL trick here, but it will get included.
here for the reference of what I am talking about, but this is irrelevant to this question:
http://www.boost.org/doc/libs/1_57_0/boost/core/swap.hpp

So this question is about, how can I detect standard header inclusion ? the _ALGORITHM_ guard is present in visual studio provided header, but I read nowhere on http://www.cplusplus.com/reference/algorithm/ that it should have any macro that I can check.

(final note: this question is a little bit XY biased. What I really want is to detect the presence of the std::swap function, not the header.)

Upvotes: 8

Views: 247

Answers (2)

v.oddou
v.oddou

Reputation: 6775

C++17 brought a new feature that now makes this possible is relevant.
https://en.cppreference.com/w/cpp/preprocessor/include

it's called __has_include
example here: #if __has_include(<algorithm>)

EDIT: it's different from the requirement of the question though, it just tells reachability.

Upvotes: 1

Richard Corden
Richard Corden

Reputation: 21721

One option you have it to make your overload a "worse match" than the alternatives. Then, only if they don't already exist will your version be selected:

#if 0
#include <algorithm>
using std::swap;
#endif

template <typename T>
struct ForceLessSpecialized {
  typedef T TYPE;
};

template <typename T>
void swap (T &, typename ForceLessSpecialized<T>::TYPE &) {
}

void bar () {
  int i;
  swap (i, i);
}  

What's happening:

When there are two candidate function template specializations, the compiler performs "Partial ordering of function templates"('03 14.5.5.2). This checks if the function template parameters of the one template can be used to specialize the other.

For each template we'll use dummy parameters T1 and T2 and we create dummy argument lists using these types:

// std::swap argument list
( T1 &  , T1 & )

// our swap argument list
( T2 &, typename ForceLessSpecialized<T2>::TYPE & )

Specializing our swap using the dummy arguments from std::swap gives:

Deduction from First parameter:  T == T1
Deduction from Second parameter:  Non Deduced Context

The deduced T is T1 and deduction has succeeded.

Specializing std::swap using the dummy arguments for our swap gives:

Deduction from First parameter:  T == T2
Deduction from Second parameter:  T == ForceLessSpecialized<T2>::TYPE

The deduced types for T are not the same, and so this is considered a deduction failure.

Therefore, the synthesized arguments of std::swap can be used to specialize our template, but the synthesized arguments of our template cannot be used to specialize std::swap. std::swap is seen as being more specialized and so wins the partial ordernig.

Upvotes: 5

Related Questions