İşlev imzalarında neden std :: enable_if kullanmam gerekiyor?

Scott Meyers bir sonraki kitabı EC ++ 11'in içeriğini ve statüsünü yayınladı . Kitaptaki bir öğenin " std::enable_ifİşlev imzalarından kaçın" olabileceğini yazdı .

std::enable_if işlevleri veya sınıfları aşırı yük çözünürlüğünden koşullu olarak kaldırmak için işlev bağımsız değişkeni, dönüş türü veya sınıf şablonu veya işlev şablonu parametresi olarak kullanılabilir.

Gelen bu soruya her üç çözüm gösterilmiştir.

Fonksiyon parametresi olarak:

template<typename T>
struct Check1
{
   template<typename U = T>
   U read(typename std::enable_if<
          std::is_same<U, int>::value >::type* = 0) { return 42; }

   template<typename U = T>
   U read(typename std::enable_if<
          std::is_same<U, double>::value >::type* = 0) { return 3.14; }   
};

Şablon parametresi olarak:

template<typename T>
struct Check2
{
   template<typename U = T, typename std::enable_if<
            std::is_same<U, int>::value, int>::type = 0>
   U read() { return 42; }

   template<typename U = T, typename std::enable_if<
            std::is_same<U, double>::value, int>::type = 0>
   U read() { return 3.14; }   
};

Dönüş türü olarak:

template<typename T>
struct Check3
{
   template<typename U = T>
   typename std::enable_if<std::is_same<U, int>::value, U>::type read() {
      return 42;
   }

   template<typename U = T>
   typename std::enable_if<std::is_same<U, double>::value, U>::type read() {
      return 3.14;
   }   
};

• Hangi çözüm tercih edilmeli ve neden başkalarından kaçınmalıyım?
• Hangi durumlarda " std::enable_ifİşlev imzalarından kaçın " , dönüş türü olarak kullanımla ilgilidir (normal işlev imzasının bir parçası değil, şablon uzmanlıklarının bir parçasıdır)?
• Üye ve üye olmayan işlev şablonları için herhangi bir fark var mı?

Kesmeyi şablon parametrelerine koyun .

enable_ifŞablon parametresine yaklaşım diğerlerine en az iki avantajı vardır:

• okunabilirlik : enable_if kullanımı ve return / argüman türleri, bir dizi tipin disambiguator ve iç içe tip erişiminin karışık bir kümesiyle birleştirilmez; disambiguator ve iç içe tipin dağınıklığı takma ad şablonlarıyla azaltılabilse de, yine de ilgisiz iki şeyi bir araya getirecektir. Enable_if kullanımı, dönüş türleriyle değil şablon parametreleriyle ilgilidir. Bunların şablon parametrelerinde bulunması, önemli olana daha yakın oldukları anlamına gelir;

• evrensel uygulanabilirlik : kurucuların dönüş türleri yoktur ve bazı işleçlerin ek argümanları olamaz, bu nedenle diğer iki seçeneğin hiçbiri her yere uygulanamaz. Enable_if öğesini bir şablon parametresine koymak her yerde çalışır çünkü zaten SFINAE'yi şablonlarda kullanabilirsiniz.

Benim için okunabilirlik yönü bu seçimdeki en büyük motive edici faktör.

std::enable_ifşablon argümanı kesinti sırasında " Substition Failure Hata Değil " (SFINAE) prensibine dayanır . Bu çok kırılgan bir dil özelliğidir ve doğru olması için çok dikkatli olmanız gerekir.

1. içindeki durumunuz iç enable_ifiçe geçmiş bir şablon veya tür tanımı içeriyorsa (ipucu: ::jetonları arayın ), bu iç içe tempatles veya türlerin çözünürlüğü genellikle kesinti yapılmayan bir bağlamdır . Bu tür bir çıkarılmamış bağlamdaki herhangi bir ikame hatası bir hatadır .
2. birden fazla enable_ifaşırı yükteki çeşitli koşullar herhangi bir çakışma içeremez çünkü aşırı yük çözünürlüğü belirsiz olabilir. İyi bir derleyici uyarıları alsanız da, bu bir yazar olarak kendinizi kontrol etmeniz gereken bir şeydir.
3. enable_ifaşırı yük çözünürlüğü sırasında diğer kapsamlardan getirilen diğer işlevlerin varlığına bağlı olarak (örneğin ADL aracılığıyla) şaşırtıcı etkileşimlere sahip olabilen canlı işlevler kümesini manipüle eder. Bu onu çok sağlam değil.

Kısacası, işe yaradığında işe yarıyor, ama yapmadığı zaman hata ayıklamak çok zor olabilir. Çok iyi bir alternatif kullanmaktır etiket gönderilmesini (genellikle bir uygulama işlevine temsilci, yani detailiçinde kullandığınız aynı derleme zamanı durumuna göre bir kukla argüman alır ad veya bir yardımcı sınıf olarak) enable_if.

template<typename T>
T fun(T arg) 
{ 
    return detail::fun(arg, typename some_template_trait<T>::type() ); 
}

namespace detail {
    template<typename T>
    fun(T arg, std::false_type /* dummy */) { }

    template<typename T>
    fun(T arg, std::true_type /* dummy */) {}
}

Etiket gönderme, aşırı yük kümesini değiştirmez, ancak derleme zamanı ifadesiyle (örneğin bir tür özelliğinde) uygun bağımsız değişkenleri sağlayarak tam olarak istediğiniz işlevi seçmenize yardımcı olur. Deneyimlerime göre, bu hata ayıklamak ve doğru almak çok daha kolay. Eğer sofistike tip özelliklerin arzulanan bir kütüphane yazarı iseniz, bir enable_ifşekilde ihtiyacınız olabilir , ancak derleme zamanı koşullarının en düzenli kullanımı için önerilmez.

Hangi çözüm tercih edilmeli ve neden başkalarından kaçınmalıyım?

• Template parametresi

  • Yapıcılarda kullanılabilir.
  • Kullanıcı tanımlı dönüşüm operatöründe kullanılabilir.
  • C ++ 11 veya üstünü gerektirir.
  • IMO, daha okunabilir.

  • Kolayca yanlış kullanılabilir ve aşırı yüklerle ilgili hatalar üretir:

    template<typename T, typename = std::enable_if_t<std::is_same<T, int>::value>>
    void f() {/*...*/}
    
    template<typename T, typename = std::enable_if_t<std::is_same<T, float>::value>>
    void f() {/*...*/} // Redefinition: both are just template<typename, typename> f()

  Bildirimi typename = std::enable_if_t<cond>yerine doğru birstd::enable_if_t<cond, int>::type = 0

• dönüş türü:

  • Yapıcıda kullanılamaz. (dönüş türü yok)
  • Kullanıcı tanımlı dönüşüm işlecinde kullanılamaz. (çıkartılamaz)
  • C ++ 11 öncesi kullanmak olabilir.
  • Daha okunabilir ikinci IMO.

• Son olarak, fonksiyon parametresinde:

  • C ++ 11 öncesi kullanmak olabilir.
  • Yapıcılarda kullanılabilir.
  • Kullanıcı tanımlı dönüşüm işlecinde kullanılamaz. (parametre yok)
  • Bu argümanların sabit sayıda yöntemlerde kullanılamaz (birli / ikili operatörler +, -, *, ...)
  • Kalıtımda güvenle kullanılabilir (aşağıya bakınız).
  • İşlev imzasını değiştirme (temel olarak son bağımsız değişken olarak fazladan bir seçeneğiniz vardır void* = nullptr) (böylece işlev işaretçisi farklı olur, vb.)

Üye ve üye olmayan işlev şablonları için herhangi bir fark var mı?

Miras ile ince farklılıklar vardır ve using:

Göre using-declarator(vurgu maden):

namespace.udecl

Using-declarator tarafından tanıtılan bildirim kümesi, tanımlayıcıdaki ad için tanımlanmış olarak gizli işlevler hariç olmak üzere nitelikli ad araması ([basic.lookup.qual], [class.member.lookup]) yaparak bulunur. altında.

...

Using-declarator, bir temel sınıftan bildirimleri türetilmiş bir sınıfa getirdiğinde, türetilmiş sınıftaki üye işlevleri ve üye işlev şablonları , aynı işlev , parametre türü-listesi, cv- ile üye işlevlerini ve üye işlev şablonlarını geçersiz kılar ve gizler. yeterlilik ve bir temel sınıftaki ( varsa) ref-niteleyicisi . Bu tür gizli veya geçersiz kılınan bildirimler, kullanım bildiricisi tarafından sunulan bildiriler kümesinin dışında tutulur.

Bu nedenle, hem şablon bağımsız değişkeni hem de dönüş türü için, yöntemler aşağıdaki senaryo gizlidir:

struct Base
{
    template <std::size_t I, std::enable_if_t<I == 0>* = nullptr>
    void f() {}

    template <std::size_t I>
    std::enable_if_t<I == 0> g() {}
};

struct S : Base
{
    using Base::f; // Useless, f<0> is still hidden
    using Base::g; // Useless, g<0> is still hidden

    template <std::size_t I, std::enable_if_t<I == 1>* = nullptr>
    void f() {}

    template <std::size_t I>
    std::enable_if_t<I == 1> g() {}
};

Demo (gcc yanlış temel işlevi bulur).

Tartışma ile benzer senaryo çalışır:

struct Base
{
    template <std::size_t I>
    void h(std::enable_if_t<I == 0>* = nullptr) {}
};

struct S : Base
{
    using Base::h; // Base::h<0> is visible

    template <std::size_t I>
    void h(std::enable_if_t<I == 1>* = nullptr) {}
};

gösteri