Mengapa saya harus menghindari std :: enable_if dalam tanda tangan fungsi

Scott Meyers memposting konten dan status buku berikutnya EC ++ 11. Dia menulis bahwa satu item dalam buku itu bisa menjadi "Hindari std::enable_ifdalam tanda tangan fungsi" .

std::enable_if dapat digunakan sebagai argumen fungsi, sebagai tipe kembali atau sebagai templat kelas atau parameter templat fungsi untuk menghapus fungsi atau kelas secara kondisional dari resolusi kelebihan beban.

Dalam pertanyaan ini ketiga solusi ditampilkan.

Sebagai parameter fungsi:

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; }   
};

Sebagai parameter template:

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; }   
};

Sebagai jenis pengembalian:

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;
   }   
};

• Solusi mana yang lebih disukai dan mengapa saya harus menghindari yang lain?
• Dalam kasus mana "Hindari std::enable_ifdalam tanda tangan fungsi" menyangkut penggunaan sebagai tipe pengembalian (yang bukan bagian dari tanda tangan fungsi normal tetapi spesialisasi templat)?
• Apakah ada perbedaan untuk templat fungsi anggota dan non-anggota?

Letakkan retasan di parameter template .

Pendekatan enable_ifpada template parameter memiliki setidaknya dua keunggulan dibandingkan yang lain:

• keterbacaan : penggunaan enable_if dan tipe pengembalian / argumen tidak digabung bersama menjadi satu potongan berantakan disambiguator nama ketik dan akses tipe bersarang; meskipun kekacauan disambiguator dan tipe bersarang dapat dikurangi dengan templat alias, itu masih akan menggabungkan dua hal yang tidak terkait bersama. Penggunaan enable_if terkait dengan parameter template, bukan tipe yang dikembalikan. Memiliki mereka di parameter template berarti mereka lebih dekat dengan apa yang penting;

• penerapan universal : konstruktor tidak memiliki tipe pengembalian, dan beberapa operator tidak dapat memiliki argumen tambahan, sehingga tidak satu pun dari dua opsi lainnya dapat diterapkan di mana-mana. Menempatkan enable_if dalam parameter template berfungsi di mana saja karena Anda hanya dapat menggunakan SFINAE pada templat.

Bagi saya, aspek keterbacaan adalah faktor pendorong besar dalam pilihan ini.

std::enable_ifbergantung pada " Kegagalan Substisi Bukan Kesalahan " (alias SFINAE) selama pengurangan argumen templat . Ini adalah fitur bahasa yang sangat rapuh dan Anda harus sangat berhati-hati untuk memperbaikinya.

1. jika kondisi Anda di dalam enable_ifberisi templat bersarang atau definisi tipe (petunjuk: cari ::token), maka resolusi tempatles atau tipe bersarang ini biasanya merupakan konteks yang tidak dideduksi . Kegagalan substitusi apa pun pada konteks yang tidak dideduksi adalah kesalahan .
2. berbagai kondisi secara berganda enable_if kelebihan tidak dapat memiliki tumpang tindih karena resolusi kelebihan akan ambigu. Ini adalah sesuatu yang Anda sebagai penulis perlu periksa sendiri, meskipun Anda akan mendapatkan peringatan kompiler yang baik.
3. enable_ifmemanipulasi sekumpulan fungsi yang layak selama resolusi kelebihan beban yang dapat memiliki interaksi yang mengejutkan tergantung pada keberadaan fungsi lain yang dibawa dari lingkup lain (misalnya melalui ADL). Ini membuatnya tidak terlalu kuat.

Singkatnya, ketika berhasil, ia bekerja, tetapi jika tidak, bisa sangat sulit untuk di-debug. Alternatif yang sangat baik adalah dengan menggunakan pengiriman tag , yaitu untuk mendelegasikan ke fungsi implementasi (biasanya dalam detailnamespace atau dalam kelas pembantu) yang menerima argumen dummy berdasarkan kondisi waktu kompilasi yang sama yang Anda gunakan di 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 */) {}
}

Pengiriman tag tidak memanipulasi set overload, tetapi membantu Anda memilih fungsi yang Anda inginkan dengan memberikan argumen yang tepat melalui ekspresi waktu kompilasi (misalnya dalam sifat tipe). Dalam pengalaman saya, ini jauh lebih mudah untuk di-debug dan diperbaiki. Jika Anda adalah seorang penulis perpustakaan yang bercita-cita untuk ciri-ciri tipe canggih, Anda mungkin perlu enable_ifentah bagaimana, tetapi untuk sebagian besar penggunaan kondisi kompilasi waktu yang teratur itu tidak dianjurkan.

Solusi mana yang lebih disukai dan mengapa saya harus menghindari yang lain?

• Parameter template

  • Ini dapat digunakan dalam Konstruktor.
  • Ini dapat digunakan di operator konversi yang ditentukan pengguna.
  • Ini membutuhkan C ++ 11 atau lebih baru.
  • Ini adalah IMO, semakin mudah dibaca.

  • Mungkin dengan mudah digunakan salah dan menghasilkan kesalahan dengan kelebihan:

    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()

  Perhatikan typename = std::enable_if_t<cond>bukan yang benarstd::enable_if_t<cond, int>::type = 0

• jenis kembali:

  • Itu tidak dapat digunakan dalam konstruktor. (tidak ada tipe pengembalian)
  • Itu tidak dapat digunakan di operator konversi yang ditentukan pengguna. (tidak dapat dikurangkan)
  • Itu bisa menggunakan pre-C ++ 11.
  • Kedua IMO lebih mudah dibaca.

• Terakhir, dalam parameter fungsi:

  • Itu bisa menggunakan pre-C ++ 11.
  • Ini dapat digunakan dalam Konstruktor.
  • Itu tidak dapat digunakan di operator konversi yang ditentukan pengguna. (tidak ada parameter)
  • Hal ini tidak dapat digunakan dalam metode dengan jumlah tetap argumen (unary / operator biner +, -,* , ...)
  • Itu dapat dengan aman digunakan dalam warisan (lihat di bawah).
  • Ubah tanda tangan fungsi (pada dasarnya Anda memiliki tambahan sebagai argumen terakhir void* = nullptr) (jadi penunjuk fungsi akan berbeda, dan sebagainya)

Apakah ada perbedaan untuk templat fungsi anggota dan non-anggota?

Ada perbedaan halus dengan warisan dan using :

Menurut using-declarator(penekanan milikku):

namespace.udecl

Himpunan deklarasi yang diperkenalkan oleh using-declarator ditemukan dengan melakukan pencarian nama yang memenuhi syarat ([basic.lookup.qual], [class.member.lookup]) untuk nama dalam using-declarator, tidak termasuk fungsi yang disembunyikan seperti yang dijelaskan di bawah.

...

Ketika menggunakan-deklarator membawa deklarasi dari kelas dasar ke kelas turunan, fungsi anggota dan templat fungsi anggota dalam kelas turunan menimpa dan / atau menyembunyikan fungsi anggota dan templat fungsi anggota dengan nama yang sama, daftar tipe-tipe, daftar cv- kualifikasi, dan ref-kualifikasi (jika ada) di kelas dasar (bukan yang saling bertentangan). Deklarasi tersembunyi atau yang dikesampingkan tersebut dikecualikan dari set deklarasi yang diperkenalkan oleh using-declarator.

Jadi untuk argumen templat dan jenis pengembalian, metode yang disembunyikan adalah skenario berikut:

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 salah menemukan fungsi dasar).

Sedangkan dengan argumen, skenario serupa berfungsi:

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) {}
};

Demo