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

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

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

**デフォルトの名無しさん** · 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#は完全に逆コンパイルできるからソースコードにリテラルでパスワード埋め込んでも隠せないけど
汎用性がーとかは別として

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

>>21
ん？C++詳しくないんだけどリテラル文字列を勝手に暗号化してくれるの？

**デフォルトの名無しさん** · 2021/05/07(金) 15:16:04.45

>>21
そんなわけないだろう

**デフォルトの名無しさん** · 2021/05/07(金) 16:45:14.90

内部で色々演算駆使してその結果がパスワードになるとかでも無い限り結局リテラルがそのままバイナリに現れるから同じ
探しやすさで言えばC#のほうが探しやすいだろうけど、探す気になってる人＆探す技術が多少なりともある人から見れば大差は無いかと思う

**デフォルトの名無しさん** · 2021/05/07(金) 21:11:38.60

ネイティブC と　C#(.NET)じゃ速度が違いすぎだろ。
今でもコントロールが描かれる順番が分かるくらい。

**デフォルトの名無しさん** · 2021/05/10(月) 14:48:33.28

アプリを使うユーザー側から見れば

C#アプリ「まず.NETのなになにバージョンが必要です　インストールされていますか？」
C++アプリ「（大抵）そのまま使えます」
この差でC++の圧勝だな
C++でも追加ライブラリが必要なこともあるだろとかいう奴がいるが
C#はその追加ライブラリのほかにさらに.NET環境というバカでかいものが必要とされてる
という大きすぎるハンデを抱えている

**デフォルトの名無しさん** · 2021/05/10(月) 15:05:41.77

>>26
判ります
ほんそれ
++

**デフォルトの名無しさん** · 2021/05/10(月) 16:20:56.43

>>26
WindowsUpdateで.NETの最新版自動でインストールされるじゃん

**デフォルトの名無しさん** · 2021/05/10(月) 17:16:19.43

>>25
.NET製のアプリは遅いものは本当に極端に遅い。
マザーボードのドライバなどのインストーラーが極端に遅くて困った。
昔は.NET製ではなかったのでこんなこと無かったのに。
35年前に戻ったみたいな遅さ。

**デフォルトの名無しさん** · 2021/05/10(月) 19:40:18.44

>>26
まるでC++にはランタイムライブラリが無いような言い分だな
.NET Framework は Windowsにデフォでインストールされるって知らないの？

**デフォルトの名無しさん** · 2021/05/11(火) 12:43:48.22

遅くないC#アプリもあることは有るようだけど、MS純正のVisual Studio、
Expression Web 4や、PIXELAという会社のStationTVというテレビキャプチャ
ボードのテレビ視聴/番組予約/録画管理ソフト、AsusやGigaByte製のM/B用の
ドライバインストーラはどれも非常に遅かった。
ExpressionWeb 4なんかは、その先祖はもともとC++で書かれたFrontPageだったが
そっちは快適に使えていたのにC#製になったとたん、激遅になってしまって使ってない。
FrontPageは有料だったのになぜか売られなくなってしまい、ExpressionWeb4は無料化した。
無料でも遅すぎて使いたくない。

**デフォルトの名無しさん** · 2021/05/12(水) 09:26:33.63

FrontPageなんて使ってたやついたのか

**デフォルトの名無しさん** · 2021/06/08(火) 17:01:48.11

>>26
VC++でアプリ作ったらなんかランタイム必要とかなかったっけ？
なんか前自作アプリ別のマシンで動かそうとして動かなかった記憶があるのだけれど

**デフォルトの名無しさん** · 2021/06/08(火) 21:55:26.99

VC++ランタイムはピンズドのバージョンがないと叱られる
サイドバイサイドができるのとバーター

**デフォルトの名無しさん** · 2021/06/09(水) 03:26:14.98

スタティックにリンクすれば不要だし、ダイナミックにリンクすれば必要。選択式。
スタティックが多いかね。
70-250kぐらいファイル大きくなるだけだから。
.NETだとスタティックにリンクすると仕組み上10-30Mになっちまうから...

**デフォルトの名無しさん** · 2021/07/02(金) 08:01:56.39

c ++はスマートポインタ頑なに使わないやつとかそもそも知らないやつとか多い。
そして落ちる

**デフォルトの名無しさん** · 2021/11/14(日) 23:10:05.57

+の差が戦力の差でないことを教えてやる！！

**デフォルトの名無しさん** · 2023/04/02(日) 15:01:06.16

価値を見出せない