14

C# (および Java) では、文字列は格納された長さといくつかのメソッドが追加された char 配列にすぎません。同様に、(参照と値は別として) オブジェクトは、継承とインターフェイスが追加された美化された構造体にすぎません。

あるレベルでは、これらの追加はそれ自体が明確な機能と機能強化のように感じます。別のレベルでは、「シンタックス シュガー」の状態からわずかにアップグレードしたように感じます。

この考えをさらに進めるために、次のことを考えてみてください (詳細が間違っているかもしれませんが、要点は変わりません)。

transistor
elementary logic gate
compound gate
  |         |
 ALU    flip-flop
   |    |       |
   | register  RAM
   | |
   CPU
   microcode
   assembly
   C
   C++
   | |
MSIL JavaScript
C#   jQuery

多くの場合、単一の抽象化レイヤーはシンタックス シュガーのように見えますが、分離された複数のレイヤーは互いに非常に離れているように感じます。

何かがシンタックス シュガーではなくなり、正真正銘の機能になり始めたとき、どうすればわかりますか?

4

9 に答える 9

26

別の考え方を暗示する場合、それは構文糖衣ではなく機能であることがわかります。

オブジェクトが実際にはメソッドと継承を備えた栄光の構造体であると言うとき、あなたは正しいです。ただし、これは実装の詳細にすぎません。オブジェクトが許すのは、別の方法で考えることです。オブジェクトについて考えるとき、より簡単に実世界のエンティティに関連付けることができます。同じことが、さらに昔に、go-toの使用から手続き型プログラミングにジャンプしたときにも起こりました。内部的には、プロセッサは引き続きOPからOPへのジャンプを続けますが、別の、よりブラックボックス的な方法で考えることができます。

そうは言っても、極端な場合、すべてが糖衣構文であると言えますが、その糖衣の一部は、考え方を変えることができる場合の機能です。

于 2009-09-07T18:06:21.153 に答える
12

シンタックス シュガーが特徴です。

于 2009-09-07T17:54:48.447 に答える
5

変更が価値をもたらすのはいつですか？アセンブラでコーディングしました。Cに切り替えて、コンパイラからの出力を確認しました。コードは私の手作りのアセンブラーと比べて95％以上優れていて、書くのはずっと簡単でした。私にとってそれは価値を提供したので、砂糖ではなかったと思います。

C ++は、オブジェクト指向の考えをコードに変換するのに役立ちます。オーバーヘッドがそれほど高くない限り、それは機能だと思います。

私は実用的な種類です。「私がそれが価値があるのを見ることができれば」は私の答えです

于 2009-09-07T18:07:59.093 に答える
5

すべてのソフトウェアは、他の抽象化の上に構築された抽象化の巨大なスタックです。文字列は文字の配列に過ぎないかもしれませんが、文字列では自然に感じられても、文字配列では扱いにくい操作がたくさんあります。これらすべての抽象化の目的は同じです。無関係な詳細を削除して、開発者が問題の重要な部分に集中できるようにすることです。

ご指摘のとおり、最新のプログラミング言語はすべて排除され、アセンブリ言語での作業に戻る可能性があります。しかし、私たちの生産性は急落するでしょう。

あまりメリットがないと感じた場合はシンタックス シュガーと呼び、メリットが大きいと感じた場合は機能と呼ぶのではないでしょうか。これにより、区別が非常に曖昧になり、非常に主観的になります。

于 2009-09-07T17:52:58.250 に答える
3

構文シュルガーは、言語の能力について何も変更しない構文であり、別の構成を使用してもまったく同じことが達成されるようです。文字列 (Java で考える) は、char 配列に対する単なる構文糖衣ではありません。char 配列は変更可能です (長さではない場合、内容で)。String 配列を使用せずに、既存の言語機能を使用して char 配列を不変にすることはできませんでした。

一方、文字列に作用するプラス演算子は、実際には、StringBuilder を使用して追加を呼び出すための構文糖衣です。

于 2009-09-07T18:21:02.467 に答える
3

「シンタックス シュガー」は気に入らない機能です

于 2009-09-07T17:59:55.427 に答える
2

構文糖を使用するのと同じタイプの「時間制約」を使用して、異なるコードを記述するだけでは同じ結果を達成できない場合は、私は言わなければなりません。

私の例はラムダ式で、ループを書くのにforeachそれほど労力はかかりませんが、.Foreach()sure を使うのもいいです。HttpRequest自分でクラス全体を書き直すのではありません。1 つは構文、もう 1 つは機能です。どちらも時間を節約します。一方は他方よりもはるかに大きな方法です。

于 2009-09-07T17:52:27.170 に答える
0

構文糖衣と言語機能は基本的に同じことを記述していますが、構文糖衣が蔑称的に使用されることがありますが、機能は言語アーキテクチャのより深い変更（ラムダの導入など）に関連付けられることがよくあります。しかし、この区別は、個々の視点（および主観的に感じられる有用性）に大きく依存しています。

言語設計の側面ととの例に関してstringsはchar-arrays、これは機能でも砂糖でもないはずですが、言語の基本構文（LOP-言語指向プログラミング）で簡単に表現できるはずです。一般的な概念（型クラス、メタプログラミングなど）を使用すると、言語が新しい機能を取得するのを待たずに、多くの新しく便利な構造を自分で表現できます。HaskellまたはC++のメタプログラミング機能を見てください。

于 2009-09-07T18:11:25.450 に答える