Versi tertulis dari operator logika

94

Ini adalah satu-satunya tempat yang pernah saya lihat and, ordan notterdaftar sebagai operator sebenarnya di C ++. Ketika saya menulis program pengujian di NetBeans, saya mendapat garis bawah merah seolah-olah ada kesalahan sintaks dan menemukan situs web salah, tetapi NetBeans yang salah karena dikompilasi dan berjalan seperti yang diharapkan.

Saya bisa melihat !lebih disukai nottetapi keterbacaan and&& ortampaknya lebih besar daripada saudara gramatikal mereka. Mengapa versi operator logika ini ada dan mengapa tampaknya tidak ada yang menggunakannya? Apakah ini benar-benar C ++ valid atau semacam kompatibilitas dengan C yang disertakan dengan bahasa?

cacat
sumber
4
\ me Menulis ulang semua kodenya
Penebusan Terbatas
2
dalam semangat "kode bersih" saya pribadi merekomendasikan untuk menghilangkan kebiasaan menulis ||dan &&, mungkin bahkan !pada waktu tertentu. Kata-kata selalu lebih baik daripada "derau garis", belum lagi kemungkinan kebingungan dengan operator manipulasi bit.
Ichthyo
2
@Iyo Itu tidak selalu benar. Jauh lebih cepat membaca banyak simbol dan mengetahui artinya, daripada membaca banyak kata.
vallentin
apa yang lebih jelas bagi pembaca manusia bergantung pada "Gestalt". Terkadang sebuah simbol bisa lebih jelas daripada beberapa istilah yang kacau, tetapi dalam kasus ini tidak. Dan, kata-kata sederhana dari bahasa Inggris jauh lebih universal daripada beberapa simbol khusus aneh dari bahasa pemrograman yang agak aneh ...
Ichthyo
3
Ironi mengatakan bahwa andlebih mudah dibaca dan kemudian menulis " and&& or" meskipun :)
Ivan Vergiliev

Jawaban:

111

Mereka berasal dari C di header <iso646.h>. Pada saat itu ada keyboard yang tidak dapat mengetikkan simbol yang diperlukan untuk &&(misalnya), sehingga header berisi #define's yang akan membantu mereka dalam melakukannya, dengan (dalam contoh kami) mendefinisikan andmenjadi &&. Tentu saja, seiring berjalannya waktu, hal ini semakin jarang digunakan.

Di C ++, mereka menjadi apa yang dikenal sebagai token alternatif . Anda tidak perlu menyertakan apa pun untuk menggunakan token ini dalam kompiler yang sesuai (misalnya, header C versi C ++ - ified <ciso646>,, kosong). Token alternatif sama seperti token biasa, kecuali untuk ejaan. Jadi selama parsing andadalah persis sama dengan &&, itu hanya cara yang berbeda dari ejaan hal yang sama.

Adapun penggunaannya: karena jarang digunakan, menggunakannya seringkali lebih mengejutkan dan membingungkan daripada membantu. Saya yakin jika itu normal, mereka akan jauh lebih mudah dibaca, tetapi orang-orang sudah terbiasa &&dan ||hal lain hanya mengganggu.

EDIT: Saya telah melihat sedikit peningkatan dalam penggunaannya sejak saya memposting ini. Saya masih menghindari mereka.

GManNickG
sumber
Jadi, apakah interpretasi token alternatif ini hanyalah fitur kompiler atau dalam spesifikasi C ++?
cacathalt
2
@Kavon: Ini ditentukan di bagian 2.5 dari standar; itu adalah fitur bahasa.
GManNickG
15
Saya pribadi berpikir mereka jauh lebih baik ... tapi kemudian saya bias Python. Saya tidak tahu mengapa beberapa orang berpikir bahwa jika tidak kacau itu bukan kode ...
Matthieu M.
Jadi ini tidak valid di C tanpa menyertakan file header itu? Saya terkejut bahwa ini tidak digunakan oleh semua orang; mereka membuat Python jauh lebih mudah dibaca.
endolith
1
Setidaknya Visual Studio 2015 CTP 6 tidak menyukai saya oratau nottanpa menyertakan header.
usr1234567
19

Mereka memang ada untuk kegunaan (dukungan karakter dalam rasa keyboard / tampilan) dan keterbacaan umum, tetapi ada alasan lain yang saat ini lebih jelas. Hampir tidak ada jawaban disini , disini , atau bahkan jawaban utama disinimenguraikan alasan inti banyak dari kita lebih memilih versi kata daripada versi simbol (dan alasan utama bahasa lain menggunakannya): bug. Perbedaan antara versi kata sangat terlihat. Perbedaan antara versi simbol sangat sedikit, sampai pada titik bug yang menggoda ke tingkat yang relatif jauh lebih besar: "x | y" sangat bukan "x || y", namun ketika disematkan dalam ekspresi yang lebih besar banyak dari kita rindu perbedaannya. Ini mirip dengan pencampuran kebetulan yang umum dari operator penugasan vs kesetaraan. Untuk alasan ini saya telah menyapih diri saya dari versi simbol (itu tidak mudah) untuk mendukung versi kata. Saya lebih suka seseorang melakukan penilaian ganda pada mereka karena kecintaan kita pada hal-hal lama daripada menggoda serangga.

mr3
sumber
4
Sayangnya, dalam Visual Studio (per VS2013), Anda harus menetapkan opsi kompiler tertentu ( /Za) untuk mendukung kata kunci alternatif (lihat stackoverflow.com/a/555524/368896 ). Itu diduga juga berdampak lain. Jadi, di Visual Studio, tidak selalu aman untuk menerima saran ini.
Dan Nissenbaum
FWIW / - saat saya meletakkan spasi di sekitar operator, x | ysecara visual cukup berbeda (dalam font monospace) dari x || y, tetapi saya menemukan !in eg if (!f(xyz) && ...lebih mudah untuk dilewatkan daripada if (not f(xyz) && ....
Tony Delroy
@Tony D ketika Anda meletakkan spasi di sekitar operator, itu adalah konvensi pribadi Anda dan tidak jelas bagi pembaca. Tetapi menggunakan kata-kata bahasa alami seperti and, ordan notdalam ekspresi boolean, sebenarnya meningkatkan keterbacaan dan menyoroti perbedaan manipulasi bit. Jadi IMHO kita harus mempertimbangkan untuk mengubah kebiasaan lama kita tercinta menjadi lebih baik ...
Ichthyo
@DanNissenbaum Saya menemukan opsi ini di bawah nama C / C ++> Bahasa> Nonaktifkan Ekstensi Bahasa , jadi relatif aman untuk mengharapkan efek samping;)
Wolf
6
Tahukah Anda berapa banyak bug Python yang telah diperkenalkan karena kata-kata anddan orbias pemikiran orang tentang bagaimana mereka harus bekerja? Misalnya if (a == b or c)alih-alih if (a == b || a == c)- sesuatu seperti ini muncul hampir setiap hari di sini di StackOverflow. Simbol abstrak yang terputus dari bahasa Inggris mengurangi kesalahan ini.
Markus Tebusan
10

Di C ++, mereka adalah kata kunci yang nyata. Di C, mereka adalah makro yang ditentukan di <iso646.h>. Lihat http://web.archive.org/web/20120123073126/http://www.dinkumware.com/manuals/?manual=compleat&page=iso646.html .

Chris Jester-Young
sumber
6
Secara teknis, mereka adalah token alternatif, bukan kata kunci. :)
GManNickG
2
@GMan: +1 Panggilan yang bagus, halaman Dinkumware menyebut mereka kata kunci, jadi, saya kira mereka tidak terlalu peduli tentang perbedaannya.
Chris Jester-Young
Tautan yang diperbarui: f3.tiera.ru/1/addesio/computer-science/C&C++/…
kevinarpe
Jadi, apakah MSVC mendukung mereka di luar kotak di C ++ tetapi tidak di C?
pertama
1
@rwst Saya tidak dapat mengomentari MSVC secara khusus, tetapi jika itu menerapkan standar C ++ dan C dengan setia, maka itu memang akan terjadi. Lihat juga: stackoverflow.com/questions/2376448/…
Chris Jester-Young
2

anddan &&secara fungsional sama di C ++. The anddan oroperator yang benar-benar valid C ++ dan bagian dari standar bahasa.

Untuk menguraikan jawaban lainnya dengan contoh konkret, ada alasan lain selain hanya "dibaca" untuk memilih andlebih &&. Mengeja "dan" secara eksplisit saat logika AND adalah yang Anda maksud menghilangkan kemungkinan bug halus.

Pertimbangkan ini:

int x = 3;
int y = 4;

// Explicitly use "and"
if (x and y) {
    cout << "and: x and y are both non-zero values" << endl;
}

// Using "&&"
if (x && y) {
    cout << "&&: x and y are both non-zero values" << endl;
}

// Oops! I meant to type "&&"!
if (x & y) {
    cout << "&: x and y are both non-zero values" << endl;
}
else {
    cout << "How did I get here?" << endl;
}

Ketiga pernyataan-jika akan dikompilasi, tetapi yang terakhir berarti sesuatu yang sama sekali berbeda dan tidak diinginkan!

Jika Anda selalu menggunakan andsaat yang Anda maksud adalah logika AND, Anda tidak akan pernah bisa secara tidak sengaja mengetik satu "&" dan kode Anda berhasil dikompilasi dan berjalan dengan hasil yang misterius.

Latihan bagus lainnya: Coba hilangkan karakter "dan" secara tidak sengaja dan lihat apa yang terjadi. ;)

tjwrona1992
sumber
1
Ini sebenarnya bukan jawaban untuk pertanyaan itu. Anda hanya menyatakan apa yang menurut Anda lebih terbaca. OP bertanya tentang cara kerja versi tertulis, bukan mana yang lebih baik. Dan orang lain telah membuat poin yang sama dengan yang Anda coba buat.
Nicol Bolas
Bukan berarti itu benar-benar memberikan informasi yang lebih berguna tetapi saya akan menambahkan " anddan &&secara fungsional identik" ke jawabannya ... Dan jika Anda membaca jawaban saya, Anda akan melihat bahwa saya mengatakan ini BUKAN tentang keterbacaan;)
tjwrona1992