6

したがって、これらすべてのように見えます。http ://www.cplusplus.com/reference/clibrary/ciso646/はc++のキーワードです。

私の質問はです。これはC++標準の一部ですか？

主要なコンパイラでサポートされるようにこれを信頼できますか？gccがこれらのキーワードをサポートしていることは知っています。

最後に、おそらくこれは好みやスタイルの質問ですが、標準の演算子（！、！=、&& ...など）よりもキーワードを使用することに利点はありますか？

4

5 に答える 5

11

私の質問はです。これは C++ 標準の一部ですか?

はい。

主要なコンパイラでサポートされていることを信頼できますか?

はい。ただし、MSVC は既定でこれをサポートしていません。Microsoft 言語拡張機能を無効にするオプション/permissive-(または、これはバグがあり、時代遅れですが) を渡す必要があります。/Zaいずれにせよ、ほとんどすべての C++ プロジェクトでこのオプションを有効にするのは良い考えのようですが、デフォルトでオフになっているのは残念です。

しかし、標準の演算子よりもキーワードを使用する利点はありますか

一般的に、いいえ。しかし , , の場合、and多くの (おそらくほとんどではない) 人がより読みやすいと感じます。個人的にはそちらの使用をお勧めします。ornot

/permissive-コードをフラグなしで MSVC でコンパイルすることが絶対に必要な場合#include <ciso646>(これは、準拠する C++ 実装では空の標準ヘッダーですが、MSVC の演算子用のマクロを追加します)。

于 2012-07-20T16:04:10.907 に答える
7

これはC++標準の一部ですか？

はい。セクション[lex.digraph]の表を参照してください。

標準の演算子よりもキーワードを使用することに利点はありますか？

私の理解では、元の有向グラフ（など<%の代わりに{）は、単純なキーボードを使用する人々がCコードを記述できるようにするために導入されました（ウィキペディアはこれを裏付けています）。おそらく同じ論理的根拠がnot_eq、などにも当てはまります。しかし、AFAIK、特に99％のプログラマーが有効なC ++であることを知らないため、このようなものを書く理由はありません（スマートフォンでコーディングしている場合を除く）。

于 2012-07-20T16:01:41.130 に答える
5

はい、サポートされています。

質問の後半に関しては、特にビット単位の演算子と論理演算を同時に処理する場合に、より読みやすいコードにつながる可能性があります。次に例を示します。

if( a & 1 == 0 || c | a == 2 );

対

if( a & 1 == 0 or c | a == 2 );
于 2012-07-20T16:02:44.767 に答える
2

規格内にありますが、サポートには多少のばらつきがあります。経験豊富なプログラマーは、通常の記号 ( ||、&&、!=など) よりも読みにくいと感じるため、それらをサポートしていないコンパイラのベンダーについて政治的な声明を出したいだけでない限り、避けるのが最善です。

少なくとも私の意見では、それらの定義も不十分です。特に、それらはロジックではなく、トークンの観点から定義されています。一般的な代替トークン (trigraph、digraph、およびこれらのもの) が発明された本当の理由は、言語で使用される特殊文字をサポートしていない古代の端末で言語を使用できるようにすることでした。これらは、trigraph や digraph よりもわずかに煩わしさを軽減するために追加されました。それらはその点で成功していると思いますが、それでもわずかに煩わしさが減るだけであり、選択して使用する必要があるものではありません.

いくつかの例を考えてみましょう。正直なところ、これらの古い端末の 1 つを使用していて、参照によってパラメーターを渡すコード コードを作成したい場合、どのようにすればよいでしょうか?

void foo(T bitand param);

それから、右辺値参照で値を渡す方法は明らかです。

void foo(T and param);

ばかげていて醜いですが、少なくともそれはT& paramvsについての古くからの議論を解決すると思います -- 両側にスペースを残す必要があります. その見返りに、誤解を招き、混乱を招き、読みにくくなります。T &parambitand

bit_andああ、ではなくと綴らないように注意してbitandください。という名前のものもありますがbit_and、まったく異なりbitandます。 はプリプロセッサ トークンですが、bit_andは で定義された関数テンプレート<functional>です。間違ったものを使用すると、かなり紛らわしいコンパイラ エラーが発生する可能性があります。

そうは言ってもand、bitand、 などがおそらく正当化される状況を 1 つ考えることができます。(何らかの理由で) コードを入力できず、代わりにディクテーション ソフトウェアを使用する必要があるand場合は、&&. bitandとを区別するのは難しいかもしれませんbit_andが、後者はめったに使用されないため、おそらくそれほど問題にはなりません。

概要

一部の人々にとって、受け入れられた記号を使用してコードを入力することは非常に困難であり、代わりに単語ベースのトークンを使用することが合理的です。

他の人にとっては、個人的にはandよりも読みやすいと思っていても&&、そのようなコードを他人に課すことbiggerateは、5歳のときに足し算のかわいい名前だと思ったので、足し算関数に名前を付けることにしたようなものです。したがって、それらが好きで、他の誰も読まないことを絶対に確信しているコードを書いている場合は、ぜひ楽しんでください。それ以外の場合、それらを使用することはお勧めできません。

于 2012-07-20T16:14:52.663 に答える
-2

Microsoftのコンパイラはそれらをサポートしていません。ここでキーワードのリストを見ることができます。

それは単なるスタイルの問題です（そしておそらく一部の読者が主張するように読みやすさの向上）。個人的には、&&や||の代わりに使用するメリットはありません。等

于 2012-07-20T16:07:11.460 に答える