strict variant下載 - strict variant源代碼下載

strict variant

其他源碼

1.0.0

下載

嚴格的變體

您是使用boost::variant還是C ++項目中“標記的Union”或變體類型的許多開源C ++的實現之一？

boost::variant是一個很棒的圖書館。我創建了strict_variant以解決我不喜歡的boost::variant的一些事情。

TL; dr版本是與boost::variant或std::variant不同， strict_variant永遠不會拋出異常或在支持具有投擲動作的類型的努力中進行動態分配。如果發生這種情況，默認版本將使靜態斷言失敗。 strict_variant::easy_variant將在這種情況下進行分配，因此，如果需要，您可以選擇加入，這兩個版本的變體“很好地”一起播放。這種事情通常是具有實時需求或嵌入式設備的項目中的主要問題，或者可能不允許使用這些C ++功能。如果您正在製作可能在“常規”項目中使用的庫，這些庫希望來自boost::variant易用性，但也可以用於具有限制性要求的項目中，並且您想使用variant類型作為API的一部分， strict_variant可能會提供一種使每個人都開心的方法。

除此之外，在變體的界面中還有一些問題，這些問題使使用日常的恕我直言更加愉快。（這些實際上是該項目的最初動機。）

我不喜歡這樣的代碼可能會編譯而沒有任何警告或錯誤消息：
```
boost::variant<std::string, int > v;  

v = true ;  
```
我通常寧願我的variant對可能發生的隱性轉換更加限制。
我希望這樣的事情應該編譯並做有意義的事情，即使解決方案是模棱兩可的。
```
variant< bool , long , double , std::string> v;  

v = true ;  // selects bool
v = 10 ;    // selects long 
v = 20 . 5f ; // selects double
v = " foo " ; // selects string
```
我還希望這種行為（在這種情況下選擇）是便攜式的。
（對於這樣的代碼示例， boost::variant具有不幸的行為，請參見文檔中的“抽象和動機”。）
在strict_variant中，我們通過刪除某些候選人來修改這些情況下的過載分辨率。
例如：
- 我們消除了許多有問題的轉化類別，包括縮小和指針轉換。
- 我們禁止bool ，積分，浮點，指針，角色和其他一些類之間的標準轉換。
- 我們強加了“基於等級的優先級”。如果允許兩個整數促銷，但其中一個比另一個更大，那麼較大的促銷活動將被丟棄，
  例如，如果int -> long and int -> long long是候選人，則消除了long long 。
有關詳細信息，請參見文檔。
我不喜歡那個boost::variant默默地製作我的物體的備份副本。例如，考慮這個簡單的程序，其中已定義了A和B來記錄所有CTOR和DTOR調用。
```
 int main () {
  using var_t = boost::variant<A, B>;

  var_t v{ A ()};
  std::cout << " 1 " << std::endl;
  v = B ();
  std::cout << " 2 " << std::endl;
  v = A ();
  std::cout << " 3 " << std::endl;
}
```
boost::variant產生以下輸出：
```
 A ()
A(A&&)
~A()
1
B()
B(B&&)
A( const A &)
~A()
B( const B &)
~A()
~B()
~B()
2
A()
A(A&&)
B( const B &)
~B()
A( const A &)
~B()
~A()
~A()
3
~A()
```
對於某些程序員來說，這可能會令人驚訝。
相比之下，如果您使用C ++ 17 std::variant或具有“有時偏置”語義的變體，則會得到類似的東西（此std::experimental::variant的輸出）
```
 A ()
A(A&&)
~A()
1
B()
~A()
B(B&&)
~B()
2
A()
~B()
A(A&&)
~A()
3
~A()
```
這更接近天真的程序員期望的人不了解boost::variant內部細節，這是他在源代碼中看到的唯一存在對象的副本。
這種事情通常無關緊要，但是有時，如果例如，如果您要調試一個討厭的內存損壞問題（也許在變體中包含的對象之一中存在不良代碼），那麼這些額外的對象，移動和復制，可能使事情變得更加複雜。
這是您使用strict_variant所獲得的：
```
 A ()
A(A&&)
~A()
1
B()
B(B&&)
~A()
~B()
2
A()
A(A&&)
~B()
~A()
3
~A()
```
但是， strict_variant沒有空的狀態，並且是完全例外的！
（這些示例來自gcc 5.4 ，請參見example文件夾中的代碼。）
總結差異：
- std::variant很少發行，總是基於堆棧。實際上，當拋出異常時，這是空的。稍後，如果您在空白時嘗試訪問，它會引發不同的異常。
- boost::variant永遠是不空的，通常是基於堆棧的。只要能夠拋出異常，它就必須進行動態分配和備份副本，但是如果實際上並未拋出異常，則會立即被釋放。
- strict_variant永遠是不空的，噹噹前值類型不可移動時，請完全基於堆棧。它永遠不會進行備份移動或複制，也從未引發過例外。
每種方法都有其優點。我選擇了strict_variant方法，因為我發現它更簡單，並且避免了我認為是boost::variant and std::variant的缺點。而且，如果您設法使所有類型都無法構造，我經常發現我可以構造，那麼strict_variant可以為您提供最佳性能，與std::variant相同，而沒有空狀態。