C#とC++を無理矢理戦わせたい人専用スレ

**デフォルトの名無しさん** · 2019/11/27(水) 20:03:08.03

C#とC++
敢えて適材適所に挑戦し、どちらが優れているかを議論します
ファイッ

**デフォルトの名無しさん** · 2019/11/27(水) 22:06:26.88

君、アフィリエイトブログ転載用スレを立てすぎだよ

**デフォルトの名無しさん** · 2019/11/27(水) 22:10:51.21

>>2
WPFスレから出てって欲しかっただけなんだが

**デフォルトの名無しさん** · 2019/11/27(水) 22:45:39.59

C# のもとは Delphi。
はい、論破。

**デフォルトの名無しさん** · 2019/11/27(水) 23:25:47.03

C#は、VB.NETと対になって説明されることが多い。
ということは、表面的な違いだけで C# は本質的には　VB ということ
なのではなかろうか。

**デフォルトの名無しさん** · 2019/11/27(水) 23:58:09.53

逆だろ。VB.NETが従来のVisual Basicとは違って本質的にはC#ということ。

**デフォルトの名無しさん** · 2019/11/28(木) 00:24:31.99

本質的にはどっちも.NETだろ

**デフォルトの名無しさん** · 2019/11/28(木) 00:54:52.57

>>6
このような場合、折衷案として、C# と VB.NET が本質的には同一、という
ことになります。

**デフォルトの名無しさん** · 2019/11/28(木) 00:56:24.63

C# == VB.NET
と
VB.NET == C#
は、数学的には同値です。

**デフォルトの名無しさん** · 2019/11/28(木) 12:51:34.22

適材適所というか、c++の便利機能がc#で削ぎ落とされていてしんどい。
constな引数やメソッド
ある程度型安全なダックタイピングのジェネリック
目指してる方向性が違うようだから仕方ないと割り切ってるけど。

**デフォルトの名無しさん** · 2019/11/28(木) 22:36:53.14

C++は本格言語。
C#はスクリプト言語。

比べるほうがおかしい。

**デフォルトの名無しさん** · 2019/11/28(木) 22:42:43.69

>>11
C#もJavaもある種のRAD開発言語的な要素を含んでいると考えて
いいんでしょうね。

**デフォルトの名無しさん** · 2019/11/28(木) 22:50:41.55

>>11
な…なんだって…

**デフォルトの名無しさん** · 2019/11/28(木) 23:06:26.23

それぞれの登場時期には、既に C++言語が、gccによってどんなCPUに対しても
native binaryを出力できるようになっていたのに、どうしてJavaやC#がどうして
native binaryを出さずに、仮想コードを出す仕様にしたかについては誰でも
時々疑問に思うと思うんですが、自分なりに出した答えは：

1. gccは有ったが、それをバックエンドに使おうとすると、gcc のソースの一部
　をJavaやC#のコンパイラの中に組み込むか、中間コードを C 言語の形式で出力して
　gccをバックエンドとして動かす必要があった。これはライセンス、gcc環境のサイズの
　大きさ、言語処理系会社としてのプライドなどの観点から問題があった。

2. 実は、そもそも gcc が対応していないアーキテクチャも世の中にはあって、
　その環境でも Java や C# を動かしたい場合には、駄目であった。
　また、新しいCPUが出てきたときには、gccの方を修正しなくてはならなく
　なるが、gccのソースを解読するのは難しいので難しい。

3. C言語が対応しているCPUであっても、そもそも、プログラミングのフレームワーク的な
　構造が、Windowsとは全く異なっているプラットフォームが時々ありえる。
　例えば時代が違うかもしれないが、Objective-Cの環境でWindows風のプログラミングを
　するのは難しい。そもそも、GUIプログラムは特殊言語で書くようになっているプラット
　フォームや、Waitや効率的なメッセージループを書けないプラットフォームが存在しており、
　そのような環境に同じソースコードで書いたプログラムを移植するには、インタプリタ的にも
　動作しうる仮想コードで無いと困ることがある。

**デフォルトの名無しさん** · 2019/11/28(木) 23:18:49.00

>>14
4. 例えば、サーバーなどでは、インタプリタ言語しか許可されて無い事がある。
　この場合、そのインタプリタ言語で仮想マシンを作ってしまえば、JavaやC#
　の仮想コードを動かすことが出来る。gccのようにバイナリに直す仕様に
　していたならば、そもそもこのような環境には対応できなかったことになる。

**デフォルトの名無しさん** · 2019/11/28(木) 23:32:24.38

>>15
5. 当時のWin3.1系だと、アプリのバグはOS全体を停止させてしまうことが有った。
　このような環境だと native のコードにしてしまうよりも、Javaのように
　仮想コードをインタプリタで解釈実行できる機会を与えた方が安全であった。
　Win3.1系に限らず、native コードに致命的バグが有った場合に、OSにまで
　被害を及ぼさずに安定して停止させるのは、OS開発者に精密な設計を要求する。
　それに比べて、仮想コードを解釈実行するなら、致命的バグが有ったら安全に
　エラーを出力することは、とても容易に出来る。
　サーバーマシンなどの信頼性を要求する環境では、OSにバグがあった場合でも
　絶対にOSをダウンさせたくない。そのような目的では仮想コードを解釈実行する
　方式は有効である。

**デフォルトの名無しさん** · 2019/11/29(金) 00:03:04.59

>>14
「3」に関して。
Javaの登場時期と外れているが、例えば、iOSアプリは原則、Swiftで書かなければ
ならない。Swift は、native binaryに変換はされるが、OSのAPIの関数呼び出し規則の
仕様が非公開。だから、Swift以外の言語を独自にnative binaryに直した場合、
OSのAPIを呼び出す方法には、Appleの公式なドキュメントが無いので、
独自にリバースエンジニアリングをして対応する必要がある。
native binaryにいきなり直さずに、フロントエンドの処理系がJavaをパースして、
Swift言語に直すのも一つの方法である。
しかし、仮想コードに直す方式なら、このような場合でも対応できる。
仮想マシンをSwiftで書いておけば良いのだから。

**デフォルトの名無しさん** · 2019/11/29(金) 00:10:50.59

>>17
補足すると、iOSのアプリをC/C++言語で書く方法は、Apple公式では
公開されていないらしい。手短に書けば、C言語からOSのAPIを呼び出す
方法が公式ドキュメントでは分からない。そもそも、OSのAPIがCの関数ではなく、
Swiftの関数として定義されてしまっているのだから。
Windowsを使っていると、C言語やアセンブラからOSのAPIであるところの
Win32 APIを呼び出す方法が厳密にドキュメント化されているのが当たり前になっているが、
少なくとも iOSではそうはなっていないようだ。

当たり前すぎて気づかないが、DOSやWindowsは、native binary重視の環境だったの
かもしれない。実際、Unix系OSは、そもそも binary 互換性は重視しておらず、
同じOSであってもバージョンが変われば再コンパイルして対応するような、
ソースレベル互換の文化である。Windowsはバイナリ互換の文化である。

**デフォルトの名無しさん** · 2019/11/29(金) 08:20:28.82

>>11
なんでスクリプトだと思ってるの？
Unityで誤解してる？

ちなみに、C#からC#スクリプトを呼び出せます。

**デフォルトの名無しさん** · 2019/12/07(土) 05:37:08.95

C++はいずれRustに置き換えられるのでは。

**デフォルトの名無しさん** · 2021/05/07(金) 14:25:19.49

c++はソースコードにパスワード埋め込んでも解析出来ない？
c#は完全に逆コンパイルできるからソースコードにリテラルでパスワード埋め込んでも隠せないけど
汎用性がーとかは別として