与重载的ostream运算符<<的directory_entry的输出冲突，对于具有变体的类

如何解决与重载的ostream运算符<<的directory_entry的输出冲突，对于具有变体的类

我有一个项目，我从directory_iterator打印std::filesystem::directory_entry。另一方面，我有一个完全独立的类，具有重载std::ostream& operator<<，该类具有模板化构造函数，该构造函数初始化了std::variant成员。

#include <variant>
#include <iostream>
#include <filesystem>

typedef std::variant<long,std::string> VarType;

class Var {
  VarType _value;
public:
  template<typename T>
  Var(T value) : _value{value} {
  }
};    

std::ostream& operator<< (std::ostream& stream,const Var&) {
  return stream;
}

int main() {
  std::cout << std::filesystem::directory_entry() << "\n";//tigger compling error
  return 0;
}

编译失败：

main.cpp: In instantiation of ‘Var::Var(T) [with T =
std::filesystem::__cxx11::directory_entry]’: main.cpp:25:49:  
required from here main.cpp:11:30: error: no matching function for
call to ‘std::variant<long int,double,std::__cxx11::basic_string<char,std::char_traits<char>,std::allocator<char> > >::variant(<brace-enclosed initializer list>)’ 
Var(T value) : _value{value} {
... several pages of output ... 

在将directory_entry发送到Var之前，它似乎尝试将cout包装到variant中，但是我不确定。

能否请您解释实际发生的情况以及代码为什么出错？

我在周围测试。对于这个问题，无论我输入什么#include <variant> #include <iostream> #include <filesystem> typedef std::variant<long,const VarType&) { return stream; } int main() { std::cout << std::filesystem::directory_entry() << "\n"; return 0; } ，似乎都没有关系，即使只有一个变体也很糟糕。这个

_value

工作正常。如果将operator=移到c-tor主体中，则初始化会因相同的逻辑错误而失败，但对于ostream& operator<<，至少是一致的。显然，它适用于非模板c-tor。

如果我将Var的实现移到一个单独的单元中并将其定义为operator<<的朋友，则编译会通过（这是一种适当的解决方法，但不应认为{{1 }}可以访问私有课程。但是，如果我只是分开而不交朋友，它就会失败。

main.cpp：

#include "var.hpp"
#include <iostream>
#include <filesystem>

int main() {
  std::cout << std::filesystem::directory_entry() << "\n";
  std::cout << Var(1l) << "\n";
  return 0;
}

var.hpp：

#include <variant>
#include <ostream>

typedef std::variant<long,std::string> VarType;

class Var {
  VarType _value;
public:
  template<typename T>
  Var(T value) : _value{value} {
  }   
  friend std::ostream& operator<< (std::ostream& stream,const Var&);    //works
};    
//std::ostream& operator<< (std::ostream& stream,const Var&);    //instead above does not works

var.cpp：

#include "var.hpp"

std::ostream& operator<< (std::ostream& stream,const Var&) {
  return stream;
}

那使我完全迷路了。假设它尝试在Var上调用<< c-tor，应该没有什么区别。 为什么这样的变化很重要？

我使用g ++ 8.4（g++ -std=c++17 main.cpp var.cpp -lstdc++fs进行构建，也尝试了clang7.0并获得类似结果）。

解决方法

在曼苏尔的提示下，我想我发现了。

C-tor

此代码很危险。

class Var {
public:
  template<typename T>
  Var(T value)  {
  }  
};

避免这种情况。 编译器将尝试在Var是可见的并且可能合适的任何隐式转换中替换此类c-tor。 将c-tor标记为explicit是限制这种野蛮替换的最直接方法。 SFINAE和enable_if可以是限制替换的其他方式。

在我的案例中，不良替代正是打破复杂性的原因，因为在旧版本中，directory_entry没有ostream<<的直接定义。编译器寻找转换器，并找到合适的Var。可以实例化但不能遵从。后者很好，因为如果可以的话，错误是无法追踪的。

有一个有关{2018的补丁程序https://gcc.gnu.org/legacy-ml/gcc-patches/2018-06/msg01084.html（或者可能很快就修复了），引入了明确的ostream << directory_entry。

在此之前，directory_entry可以通过隐式c-tor转换为path

template<typename _Source,typename _Require = _Path<_Source>>
  path(_Source const& __source,format = auto_format)

这就是如果未明确定义ostream << directory_entry的情况下ostream<<起作用的原因。

朋友

Friend实际上限制了转换器的可见性。那也可以

class Var {
  VarType _value;
public:
  template<typename T>
  Var(T value) : _value{value} {
  }
  friend std::ostream& operator<< (std::ostream& stream,const Var&) {
    return stream;
  }
};    

但是如果将std::ostream&声明为好朋友，并且ostream << directory_entry的定义（或其他声明）是可见的，则_value{value}会再次破坏复杂性，因为其他声明对于野生替代可见。这就解释了为什么将其分成几个单元并使用朋友创建一个解决方法。

SFINAE

SFINAE不检查功能主体。它仅适用于声明。 template< class T,typename = std::enable_if_t<std::disjunction_v<std::is_same<T,long>,std::is_same<T,std::string>>>> Var(T value) : _value{value} { } 是身体。调用SFINAE c-tor应该像

std::variant

如何处理import cv2 image = cv2.imread("squirrel.jpg") cv2.imshow("squirrel",image) cv2.waitKey(0) cv2.destroyAllWindows()``` 依赖的c-tor的绝妙想法可以在这里找到： How do I check if an std::variant can hold a certain type。