Keuntungan beralih pernyataan if-else

Apa praktik terbaik untuk menggunakan switchpernyataan vs menggunakan ifpernyataan untuk 30 unsignedpenghitungan di mana sekitar 10 memiliki tindakan yang diharapkan (yang saat ini adalah tindakan yang sama). Kinerja dan ruang perlu dipertimbangkan tetapi tidak kritis. Saya telah mengambil cuplikannya jadi jangan membenci saya karena konvensi penamaan.

switch pernyataan:

// numError is an error enumeration type, with 0 being the non-error case
// fire_special_event() is a stub method for the shared processing

switch (numError)
{  
  case ERROR_01 :  // intentional fall-through
  case ERROR_07 :  // intentional fall-through
  case ERROR_0A :  // intentional fall-through
  case ERROR_10 :  // intentional fall-through
  case ERROR_15 :  // intentional fall-through
  case ERROR_16 :  // intentional fall-through
  case ERROR_20 :
  {
     fire_special_event();
  }
  break;

  default:
  {
    // error codes that require no additional action
  }
  break;       
}

if pernyataan:

if ((ERROR_01 == numError)  ||
    (ERROR_07 == numError)  ||
    (ERROR_0A == numError)  || 
    (ERROR_10 == numError)  ||
    (ERROR_15 == numError)  ||
    (ERROR_16 == numError)  ||
    (ERROR_20 == numError))
{
  fire_special_event();
}

Gunakan sakelar.

Dalam kasus terburuk kompiler akan menghasilkan kode yang sama dengan rantai if-else, sehingga Anda tidak kehilangan apa pun. Jika ragu, masukkan kasus yang paling umum terlebih dahulu ke pernyataan switch.

Dalam kasus terbaik pengoptimal mungkin menemukan cara yang lebih baik untuk menghasilkan kode. Hal-hal umum yang dilakukan oleh kompiler adalah membangun pohon keputusan biner (menyimpan perbandingan dan melompat dalam kasus rata-rata) atau cukup membangun tabel melompat (berfungsi tanpa perbandingan sama sekali).

Untuk kasus khusus yang Anda berikan dalam contoh Anda, kode yang paling jelas mungkin:

if (RequiresSpecialEvent(numError))
    fire_special_event();

Jelas ini hanya memindahkan masalah ke area kode yang berbeda, tetapi sekarang Anda memiliki kesempatan untuk menggunakan kembali tes ini. Anda juga memiliki lebih banyak opsi untuk menyelesaikannya. Anda dapat menggunakan std :: set, misalnya:

bool RequiresSpecialEvent(int numError)
{
    return specialSet.find(numError) != specialSet.end();
}

Saya tidak menyarankan bahwa ini adalah implementasi terbaik dari MemerlukanSpecialEvent, hanya saja itu pilihan. Anda masih bisa menggunakan switch atau rantai if-else, atau tabel pencarian, atau manipulasi bit pada nilainya, apa pun. Semakin tidak jelas proses keputusan Anda, semakin banyak nilai yang akan Anda dapatkan dari memilikinya dalam fungsi yang terisolasi.

Switch adalah lebih cepat.

Coba saja jika ada 30 nilai berbeda di dalam satu loop, dan bandingkan dengan kode yang sama menggunakan sakelar untuk melihat seberapa cepat sakelar itu.

Sekarang, switch memiliki satu masalah nyata : Switch harus tahu pada waktu kompilasi nilai-nilai di dalam setiap case. Ini berarti kode berikut:

// WON'T COMPILE
extern const int MY_VALUE ;

void doSomething(const int p_iValue)
{
    switch(p_iValue)
    {
       case MY_VALUE : /* do something */ ; break ;
       default : /* do something else */ ; break ;
    }
}

tidak akan dikompilasi.

Kebanyakan orang kemudian akan menggunakan mendefinisikan (Aargh!), Dan yang lain akan mendeklarasikan dan mendefinisikan variabel konstan dalam unit kompilasi yang sama. Sebagai contoh:

// WILL COMPILE
const int MY_VALUE = 25 ;

void doSomething(const int p_iValue)
{
    switch(p_iValue)
    {
       case MY_VALUE : /* do something */ ; break ;
       default : /* do something else */ ; break ;
    }
}

Jadi, pada akhirnya, pengembang harus memilih antara "speed + clarity" vs. "code coupling".

(Bukan berarti sakelar tidak bisa ditulis untuk membingungkan sekali ... Kebanyakan sakelar yang saya lihat saat ini termasuk kategori "membingungkan" "... Tapi ini adalah cerita lain ...)

Edit 2008-09-21:

bk1e menambahkan komentar berikut: " Mendefinisikan konstanta sebagai enum dalam file header adalah cara lain untuk menangani ini".

Tentu saja.

Titik tipe extern adalah untuk memisahkan nilai dari sumber. Mendefinisikan nilai ini sebagai makro, sebagai deklarasi konst int sederhana, atau bahkan sebagai enum memiliki efek samping dari inlining nilai. Jadi, seandainya mendefinisikan, nilai enum, atau nilai konstanta berubah, sebuah kompilasi akan diperlukan. Deklarasi eksternal berarti tidak perlu mengkompilasi ulang jika terjadi perubahan nilai, tetapi di sisi lain, membuatnya tidak mungkin untuk menggunakan sakelar. Kesimpulannya adalah Menggunakan sakelar akan meningkatkan sambungan antara kode sakelar dan variabel yang digunakan sebagai kasing . Ketika OK, maka gunakan sakelar. Kalau tidak, maka tidak mengejutkan.

.

Edit 2013-01-15:

Vlad Lazarenko mengomentari jawaban saya, memberikan tautan ke studi mendalam tentang kode perakitan yang dihasilkan oleh sebuah saklar. Sangat mencerahkan: http://lazarenko.me/switch/

Kompiler akan tetap mengoptimalkannya - gunakan sakelar karena itu yang paling mudah dibaca.

Switch, jika hanya untuk keterbacaan. Raksasa jika pernyataan lebih sulit dipertahankan dan sulit dibaca menurut saya.

ERROR_01 : // fall-through yang disengaja

atau

(ERROR_01 == numError) ||

Yang belakangan lebih rentan kesalahan dan membutuhkan lebih banyak pengetikan dan pemformatan daripada yang pertama.

Kode untuk keterbacaan. Jika Anda ingin tahu apa yang berkinerja lebih baik, gunakan profiler, karena pengoptimalan dan penyusun berbeda-beda, dan masalah kinerja jarang terjadi di mana orang berpikir seperti itu.

Gunakan switch, ini untuk apa dan apa yang diharapkan oleh programmer.

Saya akan memasukkan label case yang berlebihan - hanya untuk membuat orang merasa nyaman, saya mencoba mengingat kapan / apa aturannya untuk tidak menggunakannya.
Anda tidak ingin programmer berikutnya yang mengerjakannya harus melakukan pemikiran yang tidak perlu tentang perincian bahasa (mungkin Anda dalam waktu beberapa bulan!)

Compiler sangat bagus dalam mengoptimalkan switch. Gcc terbaru juga baik dalam mengoptimalkan banyak kondisi dalam if.

Saya membuat beberapa test case di godbolt .

Ketika case nilai dikelompokkan berdekatan, gcc, clang, dan icc semuanya cukup pintar untuk menggunakan bitmap untuk memeriksa apakah suatu nilai adalah salah satu yang istimewa.

misalnya gcc 5.2 -O3 mengkompilasi switchto (dan ifsesuatu yang sangat mirip):

errhandler_switch(errtype):  # gcc 5.2 -O3
    cmpl    $32, %edi
    ja  .L5
    movabsq $4301325442, %rax   # highest set bit is bit 32 (the 33rd bit)
    btq %rdi, %rax
    jc  .L10
.L5:
    rep ret
.L10:
    jmp fire_special_event()

Perhatikan bahwa bitmap adalah data langsung, jadi tidak ada potensi data-cache ketinggalan mengaksesnya, atau tabel lompatan.

gcc 4.9.2 -O3 mengkompilasi switchke bitmap, tetapi melakukan 1U<<errNumberdengan mov / shift. Ini mengkompilasi ifversi ke serangkaian cabang.

errhandler_switch(errtype):  # gcc 4.9.2 -O3
    leal    -1(%rdi), %ecx
    cmpl    $31, %ecx    # cmpl $32, %edi  wouldn't have to wait an extra cycle for lea's output.
              # However, register read ports are limited on pre-SnB Intel
    ja  .L5
    movl    $1, %eax
    salq    %cl, %rax   # with -march=haswell, it will use BMI's shlx to avoid moving the shift count into ecx
    testl   $2150662721, %eax
    jne .L10
.L5:
    rep ret
.L10:
    jmp fire_special_event()

Perhatikan cara mengurangi 1 dari errNumber(dengan leamenggabungkan operasi itu dengan gerakan). Itu memungkinkannya menyesuaikan bitmap menjadi 32bit segera, menghindari 64bit-langsungmovabsq yang membutuhkan lebih banyak byte instruksi.

Urutan yang lebih pendek (dalam kode mesin) adalah:

    cmpl    $32, %edi
    ja  .L5
    mov     $2150662721, %eax
    dec     %edi   # movabsq and btq is fewer instructions / fewer Intel uops, but this saves several bytes
    bt     %edi, %eax
    jc  fire_special_event
.L5:
    ret

(Kegagalan untuk menggunakan jc fire_special_eventada di mana-mana, dan merupakan bug penyusun .)

rep retdigunakan dalam target cabang, dan mengikuti cabang bersyarat, untuk kepentingan AMD K8 dan K10 lama (pra-Bulldozer): Apa arti `rep ret`? . Tanpanya, prediksi cabang tidak akan bekerja dengan baik pada CPU yang usang.

bt(uji bit) dengan register arg cepat. Ini menggabungkan pekerjaan menggeser kiri 1 demi errNumberbit dan melakukan atest , tetapi masih 1 siklus latensi dan hanya satu Intel uop. Ini lambat dengan memori arg karena caranya terlalu-semantik CISC: dengan operan memori untuk "bit string", alamat byte yang akan diuji dihitung berdasarkan argumen lain (dibagi dengan 8), dan tidak terbatas pada potongan 1, 2, 4, atau 8 byte yang ditunjukkan oleh operan memori.

Dari tabel instruksi Agner Fog, instruksi shift penghitungan variabel lebih lambat dari btpada Intel terbaru (2 uops, bukan 1, dan shift tidak melakukan semua hal lain yang diperlukan).

Keuntungan dari sakelar () dibandingkan jika kasing lain adalah: - 1. Sakelar jauh lebih efisien dibandingkan jika kasing karena setiap kasing tidak tergantung pada kasing sebelumnya tidak seperti jika kasing terpisah harus diperiksa untuk kondisi benar atau salah.

2. Ketika ada no. dari nilai-nilai untuk ekspresi tunggal, sakelar kasus lebih fleksibel daripada jika lain karena dalam jika lain penilaian kasus didasarkan pada hanya dua nilai yaitu benar atau salah.

3. Nilai-nilai di saklar ditentukan oleh pengguna sedangkan nilai-nilai di dalam kasus lain didasarkan pada kendala.

4. Jika terjadi kesalahan, pernyataan dalam sakelar dapat dengan mudah diperiksa dan dikoreksi yang relatif sulit untuk diperiksa jika ada pernyataan if else.

5. Switch case jauh lebih kompak dan mudah dibaca dan dimengerti.

IMO ini adalah contoh sempurna dari apa saklar jatuh dibuat untuk.

Jika kasus Anda cenderung tetap dikelompokkan di masa mendatang - jika lebih dari satu kasus sesuai dengan satu hasil - peralihan mungkin terbukti lebih mudah dibaca dan dirawat.

Mereka bekerja sama baiknya. Performanya hampir sama diberikan kompiler modern.

Saya lebih suka jika pernyataan daripada pernyataan kasus karena lebih mudah dibaca, dan lebih fleksibel - Anda dapat menambahkan kondisi lain yang tidak didasarkan pada kesetaraan numerik, seperti "|| max <min". Tetapi untuk kasus sederhana yang Anda posting di sini, itu tidak masalah, lakukan saja apa yang paling mudah dibaca oleh Anda.

saklar pasti disukai. Lebih mudah untuk melihat daftar kasus switch & tahu pasti apa yang dilakukannya daripada membaca kondisi jika panjang.

Duplikasi dalam ifkondisi sulit di mata. Misalkan salah satu ==ditulis !=; apakah kamu memperhatikan? Atau jika satu contoh 'numError' ditulis 'nmuError', yang kebetulan dikompilasi?

Saya biasanya lebih suka menggunakan polimorfisme alih-alih beralih, tetapi tanpa lebih detail konteksnya, sulit dikatakan.

Adapun kinerja, taruhan terbaik Anda adalah menggunakan profiler untuk mengukur kinerja aplikasi Anda dalam kondisi yang mirip dengan apa yang Anda harapkan di alam liar. Kalau tidak, Anda mungkin mengoptimalkan di tempat yang salah dan dengan cara yang salah.

Saya setuju dengan kemampuan solusi beralih tetapi IMO Anda membajak sakelar di sini.
Tujuan sakelar adalah memiliki penanganan yang berbeda tergantung pada nilainya.
Jika Anda harus menjelaskan algo Anda dalam pseudo-code, Anda akan menggunakan if karena, secara semantik, begitulah: jika whatever_error melakukan ini ...
Jadi kecuali jika suatu hari Anda bermaksud mengubah kode Anda untuk memiliki kode spesifik untuk setiap kesalahan , Saya akan gunakan jika .

Saya akan memilih pernyataan if demi kejelasan dan konvensi, meskipun saya yakin beberapa akan tidak setuju. Lagi pula, Anda ingin melakukan sesuatu ifsuatu kondisi yang benar! Berganti dengan satu tindakan sepertinya sedikit ... tidak perlu.

Saya akan mengatakan menggunakan SWITCH. Dengan cara ini Anda hanya perlu menerapkan hasil yang berbeda. Sepuluh kasing identik Anda dapat menggunakan default. Jika satu perubahan yang Anda perlukan adalah menerapkan perubahan secara eksplisit, tidak perlu mengedit default. Jauh lebih mudah untuk menambah atau menghapus kasus dari SWITCH daripada mengedit IF dan ELSEIF.

switch(numerror){
    ERROR_20 : { fire_special_event(); } break;
    default : { null; } break;
}

Mungkin bahkan menguji kondisi Anda (dalam hal ini numerror) terhadap daftar kemungkinan, sebuah array mungkin jadi SWITCH Anda bahkan tidak digunakan kecuali pasti akan ada hasilnya.

Karena Anda hanya memiliki 30 kode kesalahan, buat sendiri tabel lompatan Anda sendiri, lalu buat sendiri semua pilihan pengoptimalan (lompatan akan selalu tercepat), daripada berharap kompiler akan melakukan hal yang benar. Itu juga membuat kode sangat kecil (terlepas dari deklarasi statis dari tabel lompat). Ini juga memiliki keuntungan sampingan bahwa dengan debugger Anda dapat memodifikasi perilaku saat runtime harus Anda butuhkan, hanya dengan menyodok data tabel secara langsung.

Saya tidak yakin tentang praktik terbaik, tapi saya akan menggunakan sakelar - dan kemudian menjebak secara sengaja melalui 'default'

Secara estetika saya cenderung menyukai pendekatan ini.

unsigned int special_events[] = {
    ERROR_01,
    ERROR_07,
    ERROR_0A,
    ERROR_10,
    ERROR_15,
    ERROR_16,
    ERROR_20
 };
 int special_events_length = sizeof (special_events) / sizeof (unsigned int);

 void process_event(unsigned int numError) {
     for (int i = 0; i < special_events_length; i++) {
         if (numError == special_events[i]) {
             fire_special_event();
             break;
          }
     }
  }

Jadikan data sedikit lebih pintar sehingga kita bisa membuat logikanya sedikit bodoh.

Saya menyadari itu terlihat aneh. Inilah inspirasinya (dari bagaimana saya melakukannya dengan Python):

special_events = [
    ERROR_01,
    ERROR_07,
    ERROR_0A,
    ERROR_10,
    ERROR_15,
    ERROR_16,
    ERROR_20,
    ]
def process_event(numError):
    if numError in special_events:
         fire_special_event()

while (true) != while (loop)

Mungkin yang pertama dioptimalkan oleh kompiler, yang akan menjelaskan mengapa loop kedua lebih lambat saat meningkatkan jumlah loop.

Ketika datang untuk mengkompilasi program, saya tidak tahu apakah ada perbedaan. Tetapi untuk program itu sendiri dan menjaga kode sesederhana mungkin, saya pribadi pikir itu tergantung pada apa yang ingin Anda lakukan. jika tidak, jika tidak, pernyataan memiliki kelebihan, yang menurut saya adalah:

memungkinkan Anda untuk menguji variabel terhadap rentang tertentu Anda dapat menggunakan fungsi (Perpustakaan Standar atau Pribadi) sebagai persyaratan.

(contoh:

`int a;
 cout<<"enter value:\n";
 cin>>a;

 if( a > 0 && a < 5)
   {
     cout<<"a is between 0, 5\n";

   }else if(a > 5 && a < 10)

     cout<<"a is between 5,10\n";

   }else{

       "a is not an integer, or is not in range 0,10\n";

Namun, jika tidak, jika lain pernyataan bisa menjadi rumit dan berantakan (meskipun upaya terbaik Anda) terburu-buru. Pergantian pernyataan cenderung lebih jelas, lebih bersih, dan lebih mudah dibaca; tetapi hanya dapat digunakan untuk menguji terhadap nilai-nilai spesifik (contoh:

`int a;
 cout<<"enter value:\n";
 cin>>a;

 switch(a)
 {
    case 0:
    case 1:
    case 2: 
    case 3:
    case 4:
    case 5:
        cout<<"a is between 0,5 and equals: "<<a<<"\n";
        break;
    //other case statements
    default:
        cout<<"a is not between the range or is not a good value\n"
        break;

Saya lebih suka pernyataan if - else if - else, tapi itu terserah Anda. Jika Anda ingin menggunakan fungsi sebagai kondisi, atau Anda ingin menguji sesuatu terhadap rentang, array, atau vektor dan / atau Anda tidak keberatan berurusan dengan sarang yang rumit, saya akan merekomendasikan menggunakan If else if else blok. Jika Anda ingin menguji terhadap nilai tunggal atau Anda ingin blok yang bersih dan mudah dibaca, saya akan merekomendasikan Anda menggunakan switch () blok kasus.

Saya bukan orang yang memberitahu Anda tentang kecepatan dan penggunaan memori, tetapi melihat statment switch adalah jauh lebih mudah untuk dipahami daripada pernyataan if besar (terutama 2-3 bulan kemudian)

Saya tahu yang lama tapi

public class SwitchTest {
static final int max = 100000;

public static void main(String[] args) {

int counter1 = 0;
long start1 = 0l;
long total1 = 0l;

int counter2 = 0;
long start2 = 0l;
long total2 = 0l;
boolean loop = true;

start1 = System.currentTimeMillis();
while (true) {
  if (counter1 == max) {
    break;
  } else {
    counter1++;
  }
}
total1 = System.currentTimeMillis() - start1;

start2 = System.currentTimeMillis();
while (loop) {
  switch (counter2) {
    case max:
      loop = false;
      break;
    default:
      counter2++;
  }
}
total2 = System.currentTimeMillis() - start2;

System.out.println("While if/else: " + total1 + "ms");
System.out.println("Switch: " + total2 + "ms");
System.out.println("Max Loops: " + max);

System.exit(0);
}
}

Memvariasikan jumlah loop berubah banyak:

Sementara jika / selain itu: 5ms Switch: 1ms Max Loops: 100000

Sedangkan jika / selain itu: 5ms Switch: 3ms Max Loops: 1000000

Sementara jika / selain itu: 5ms Switch: 14ms Max Loops: 10000000

Sedangkan jika / selain itu: 5ms Switch: 149ms Max Loops: 100000000

(tambahkan lebih banyak pernyataan jika Anda mau)