WPF(.NET4.x, .NET Core) GUIプログラミング Part23

**デフォルトの名無しさん** · 2019/05/16(木) 07:52:32.39

Windows Presentation Frameworkについて語るスレ。

前スレ
WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part22
https://mevius.5ch.net/test/read.cgi/tech/1513175747/

関連スレ
Windows 10 UWPアプリ開発 Part 2
http://mevius.2ch.net/test/read.cgi/tech/1499658092/

コードを貼る場合は以下のサイトの利用をお勧め。
run codeのチェックは外しておきましょう。
http://ideone.com/

**デフォルトの名無しさん** · 2019/11/17(日) 02:04:26.01

https://www.reddit.com/r/dotnet/comments/bmq1py/is_wpf_going_to_be_cross_platform_in_net_5/

6 months ago

No. The whole point is to move WPF and WinForms to be able to target .Net Core, that's it.
Just because something targets .Net Core doesn't necessarily mean it is cross platform.
There is just too much existing software using WPF and WinForms and the point is to have
a migration path to newer technologies. .Net framework is not getting any more new features
so if MS wants WPF and WinForms to live on, they need to make it work for core.

Maybe one day they will be cross platform, but right now they are just too reliant on Windows
specific features. At this time they have explicitly said they do not want PRs adding cross platform
　　　　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
capability. Maybe sometime in the future they will work on cross platform capability, or maybe
~~~~~~
a group forks it, who knows.

I'd love to see WPF being cross platform. While it has a steep learning curve, you can do
some great things with it.

**デフォルトの名無しさん** · 2019/11/17(日) 02:05:25.06

6ヶ月前:

Q: Is WPF going to be cross platform in .NET 5

A: At this time they have explicitly said they do not want PRs adding cross platform
capability.

**デフォルトの名無しさん** · 2019/11/17(日) 02:09:37.66

6ヶ月前の時点で「.NET 5 がクロスプラットフォーム能力を持つことになるという
PRをしたくない」ということをMSは明確に述べていたそうだ。

つまり、.NET 5 は、来年年末も、クロスプラットフォームにはなって無いという
ことらしい。似た説は、海外のサイトで何度も見た。MSがマルチプラットフォーム
に積極的になった事は無いとのことだ。

**デフォルトの名無しさん** · 2019/11/17(日) 02:15:22.33

Q: WPFは.NET 5のクロスプラットフォームになりますか

A: 6か月前
これは、Windowsシェル全体とパッケージ化サブシステムをパッケージ化しないと技術的に不可能です。
これは、明らかにMicrosoftの予定リストにはありません。

Winformsは、グラフィックスデバイスインターフェイスであるGDI +に対する非常に薄い抽象化です。
アプリケーションのUIを直接描画する方法を変更できるように、非常に薄いということです。WPFは、
この抽象化を拡張し、コンポジターアプローチと新しいマークアップ言語に置き換えて、
その合成エンジンを活用します。また、グラフィックデバイスサブシステムの3D機能へのアクセス
（DirectXおよびDirectDraw経由）を提供します。これにより、WPFはWinFormsができないすべての
素晴らしいことを（とにかく多大な労力なしで）実行できます。

言うまでもなく、いいえ。今ではなく、実際にはありません。これらの技術はどちらも、Windows
コンテキスト以外では意味がありません。ターゲットプラットフォームのネイティブグラフィック
エンジンが何であれ、Quartz、Weyland、XOrgを介して両方の抽象化を再作成する必要があります。
繰り返しになりますが、これらのプラットフォームには既に独自の同等のツールがあるため、
そうすることに興味のある人はあまりいません。

**デフォルトの名無しさん** · 2019/11/17(日) 02:24:30.93

すみません、>>797 から >>800 は、Xamarin スレへの誤投です。

**デフォルトの名無しさん** · 2019/11/17(日) 04:37:35.56

> WPFはWinFormsができないすべての素晴らしいことを（とにかく多大な労力なしで）実行できます。

いや、まずWinformsでできることをWPFにも労力なしでできるようにしてほしいんだが。

**デフォルトの名無しさん** · 2019/11/17(日) 07:27:47.44

xamlの場合はxmlに馴染みがあるかどうかが分かれ目だな。
それさえわかっていれば本当に楽。

**デフォルトの名無しさん** · 2019/11/17(日) 11:53:59.90

>>794
WPF Menuでググれよ…
https://blog.okazuki.jp/entry/2014/08/12/122541
ただデザイナでやろうとするとめちゃ大変（まあ慣れてないだけかも知れんが）
素直にxaml直書きのほうが楽だと思う

**デフォルトの名無しさん** · 2019/11/18(月) 22:32:11.90

> WinFormsができないすべての素晴らしいこと

これに対する需要がないんだな

**デフォルトの名無しさん** · 2019/11/18(月) 22:43:55.11

少なくとも画面レイアウトとテストは楽になった。
formsの方が良かったことって何かあったかな。もはや思い出せない。

**デフォルトの名無しさん** · 2019/11/19(火) 16:42:13.40

WPFアプリはおれおれレイアウトが多く使いにくいよな。とにかく操作に統一感がなく不便で最悪。
MFC、winform縛りだとレイアウト、操作性に統一性があって操作に迷わない。
無能デザイナというのは独自性、おもいつきばかりで使う人のことをまったく考えてない。

**デフォルトの名無しさん** · 2019/11/19(火) 19:52:58.83

使いやすさより作るのが楽しいほうが重要

**デフォルトの名無しさん** · 2019/11/19(火) 21:37:07.35

>おれおれレイアウトが多く

たとえばどんな？
VSCodeとかElectronのアプリだと従来のUIガイドラインから遠いものが多い印象だが。

**デフォルトの名無しさん** · 2019/11/20(水) 00:44:49.82

13年頑張っても普及しなかったゴミをMSが切り捨てられない理由はなんだろうなw

MSの中にはもう技術的な話ができる管理職がいないんだろうな。

**デフォルトの名無しさん** · 2019/11/20(水) 07:42:01.90

そもそも普及に頑張ってたか？　というレベルだしなあ
まあWindowsチームにWPFに限らず.NET技術自体が嫌われたってのは
MSのなかのひと達からもよく出てくる話よね

**デフォルトの名無しさん** · 2019/11/20(水) 08:56:56.98

WOW64は完璧だし、x86バイナリをARMで動かしたり、LinuxバイナリをWindows上で動かしたり、MSSQLのWin32バイナリをLinuxで動かしたりといったトンデモ技術も難なく実用化してしまった
これほどネイティブコードの移植技術に長けたMSに果たして.NETが必要だったのかは激しく疑問だよね
Windowsの進歩を見限ってWPFを作ったらWindowsに背後から殴られた件もそうだけど、Javaなど他社の成功を後追いすることに躍起になるあまり、
自社の強みに目を向けず、Windowsチームに技術的チャレンジをさせてこなかった反動が来てるんだろうね

**デフォルトの名無しさん** · 2019/11/20(水) 09:06:31.94

.NETは成功してるだろ。
C#があのVB6のOCX地獄をどれだけ駆逐したか。

**デフォルトの名無しさん** · 2019/11/20(水) 09:17:33.09

OCXはバージョニングの仕組みに問題があったが、だからといって全てを抽象化してWindowsから独立したシステムを構築しようなどというのはあまりにも暴論極論
現に.NET Coreでは.NETはWindowsの中核技術から単にアプリに組み込まれるインプロセスなランタイムに「格下げ」されたわけで、
当初の構想からすると成功と言うにはあまりにも残念な結果だ

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

vs2017だと
1.デザイン画面でGridをDockPanelに変更する
　　コンテキストメニュー/レイアウトの種類の変更
2.ツールボックスからMenuをDockPanelにドロップする
3.Menuのプロパティ/レイアウト/Dock/Top
4.Menuのプロパティ/レイアウト/Width,Height,VirticalAlignmentをクリアする。
5.Menuのプロパティ/共通/Itemsのボタンを押す。
6.コレクションエディターが表示される。
7.左下のコンボボックスからMenuItemを選び、追加を押す
8.右側のプロパティ/共通/Headerに文字列を入力してOk>90
9.DockPanelにGridをドロップして、GridのWidth,Height,VirtiacalAlignmentをリセット
ドロップダウンメニューは MenuItemのプロパティ/共通/Itemsのボタン

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

"Ok>90" --> "Ok"

**デフォルトの名無しさん** · 2019/11/22(金) 15:16:56.99

>>811
WinFormsはまだ、Win32のコントロールを使っていたそうですが、WPFは
使ってないそうですから、もっと嫌われている可能性もありますね。
しかも、WPFは書き方もWindows伝統とはかけ離れて、HTML+JSの書き方に
近いようですし。

**デフォルトの名無しさん** · 2019/11/22(金) 21:16:37.05

Windows伝統ってWin32のことかねぇ？FormsやMFCだってだいぶかけ離れてるように思うが。
イベントドリブンなところは共通しているかもしれないがHTML+JSだってそうだしなぁ。

**デフォルトの名無しさん** · 2019/11/22(金) 21:29:13.98

.netはDelphiから来たから嫌われてるのか

**デフォルトの名無しさん** · 2019/11/22(金) 22:18:50.38

主にコア部分の性能面での問題を抱えたまま
一級開発環境としてねじ込もうとしてたのが原因なので
WinformsだのWPFだのは関係ないのだ

**デフォルトの名無しさん** · 2019/11/23(土) 06:18:03.05

一級開発環境ってなぁに？

**デフォルトの名無しさん** · 2019/11/23(土) 20:28:48.27

WPFの遅さが気にならない奴はプログラマの才能がない。

**デフォルトの名無しさん** · 2019/11/23(土) 20:40:22.92

昔はjavaは遅いからダメだ！って主張多かったよねー
じゃあ今のjavaは良いのか？って言われると困るけど結果的には広がりは見せたわけで
速度なんてあとからどうにでもなるんじゃね？って思う
20年前のハード性能の向上比率と今のそれは違うので比較するようなものでは無いかもしれんが

**デフォルトの名無しさん** · 2019/11/23(土) 20:53:06.15

JavaのGUIコンポーネントはクソ遅いしダメダメだろ
結果的に広がってませんが。

**デフォルトの名無しさん** · 2019/11/23(土) 20:53:25.02

javaの代わりにspanだの今後はutf8string?とか高速化を頑張ってるc#で書けば、クラウド代金3割くらい減らせたりしないものなのか?

**デフォルトの名無しさん** · 2019/11/23(土) 21:14:38.33

WPFは見た目がしょぼくて客から金を取れないのがすべて

**デフォルトの名無しさん** · 2019/11/23(土) 21:34:37.51

バックエンドはクラウド時代になって多少遅くてもとか言えなくなっちゃったからしんどい
まあでもWPFはデスクトップだから多少遅くてもいいけど

**デフォルトの名無しさん** · 2019/11/23(土) 22:02:36.52

>>825
さすがにJavaとC#なら有意な差は出ない
少なくとも、書き直してる暇があったらその手間をボトルネックの最適化に注ぎ込んだほうが間違いなく速くなる
MS製のものを除けばC#はJavaに比べてOSSライブラリの品質が低い傾向があるしな

**デフォルトの名無しさん** · 2019/11/23(土) 22:06:40.44

>>828
SpringとASP.NET Core、みたいなFrameworkの観点で考えると圧倒的な差があるけどね

**デフォルトの名無しさん** · 2019/11/23(土) 22:07:26.43

もう全部CUIにしよう！

**デフォルトの名無しさん** · 2019/11/23(土) 22:13:12.75

javaが昔遅くてダメだって言われてたのはJVMを経由するからという部分
世界的には微妙かもしれんが国内では間違いなく相当普及してる
20年前のエンジニアに言えば卒倒するレベルには普及してる
これを普及してないと言うなら普及してる言語ってなんだよｗ

**デフォルトの名無しさん** · 2019/11/23(土) 22:36:08.94

Java開発してておせーしねって思ったことは数え切れないほどあるけどC#では滅多にない
ビルドも実行も速い

**デフォルトの名無しさん** · 2019/11/23(土) 22:44:40.45

Javaは100%完全にサーバー向けにチューニングされてるし、
MSスタックほど開発環境とランタイムが統合されてるわけじゃないから、
開発中に手元では遅く感じやすいよね

**デフォルトの名無しさん** · 2019/11/23(土) 22:53:50.65

>>831
昔は、ローカル変数をスタックではなくヒープで確保するアホ実装してたからだよ。
一度書けばどこでも動くなんていうJavaの理想はコードを碌に書いたことのないアホどもの夢だったのさ。
JVMの最適化が始まれば途端に処理系によって動きが違うようになって速度は速くなったが理想は捨てられ、
世界的なJavaブームは終わった。なのになぜか日本だけがずっと使い続けて今に至る。

Javaは日本ではCOBOLの代替の地位は得たが、C#は何も得てない。

**デフォルトの名無しさん** · 2019/11/24(日) 10:19:33.23

仕事はJavaでwebアプリ作ってるけどめっちゃ速いぞ

**デフォルトの名無しさん** · 2019/11/24(日) 10:22:17.87

C#で作ってればもっと速かったのにね

**デフォルトの名無しさん** · 2019/11/24(日) 11:03:43.31

速さは究極的にはプログラマの能力次第
C#erってVBの存在のお陰でJavaに比べると平均的な能力は高いけど、
上位層同士で比べるとクラウドや分散処理には強くないイメージだな

**デフォルトの名無しさん** · 2019/11/24(日) 13:05:13.65

Javaで優秀だった人はみんな他の言語に行っちゃって今は残りカスしかいない
C#は今も昔も高スキル人材が安定してる

**デフォルトの名無しさん** · 2019/11/24(日) 13:21:43.73

親方のMSにも言えることだけど、C#の高スキル層って何でもC#のコード書いて解決しようとして
結果的に事業や開発のスケーラビリティを制約するような方法を選んでしまう傾向がある気がする
その辺、CLIツールやクラウドサービスなど出来合いの小道具をうまく使ってチョチョイとやっちゃうのはUNIX系の人のほうが遥かに上手い

**デフォルトの名無しさん** · 2019/11/24(日) 13:26:17.87

コード例も出さずに批判しても説得力ゼロです

**デフォルトの名無しさん** · 2019/11/24(日) 13:33:12.26

>>840
良いか悪いかは別にして、少なくとも「何でもC#書いて解決しようとする」は自分で心当たりあるだろ？
俺が今まで会った「C#が得意」

**デフォルトの名無しさん** · 2019/11/24(日) 13:33:39.72

失礼
「C#が得意」を自称する人は例外なくそうだったわ

**デフォルトの名無しさん** · 2019/11/24(日) 13:41:21.56

>>842
C#が得意と言った奴がたまたまC#だけが得意だったんじゃないか？色々できる人はわざわざC#が得意だなんて言わないだけで。
そもそも自分が会っただけの狭い範囲で語られても...

**デフォルトの名無しさん** · 2019/11/24(日) 13:48:16.04

なんでもC#で書いて解決
CLIツールやクラウドサービスなどの小道具
これ並列に語るもんなの？
C#erだってクラウドサービスは使うやろ

**デフォルトの名無しさん** · 2019/11/24(日) 13:51:44.18

今時はなんでもコンテナにして疎結合しちゃうから様々な言語やツールをそれなりに使えたほうがいい
既存資産ファーストで言語を選んでコンテナを実装することがやたら増えた
逆に言うと既存資産が無い新規開発のときは何を選んでもいいわけで
なんでもいいならC#やGoなど強力な言語が出揃ってる今、あえてJavaを選ぶ意味は殆どない
レガシーとコンテナの橋渡しが今のJavaが担ってる仕事

**デフォルトの名無しさん** · 2019/11/25(月) 00:02:02.10

javaとC#比べて速さ問題を比べてもあまり意味がない
ある程度しか変わらないから
10倍速いとかじゃないからな
速さを競うならC++
ネットゲームとか激しくパフォーマンスが要求される分野はC++が強い
俺は死んでもC++はもう触りたくない

**デフォルトの名無しさん** · 2019/11/25(月) 00:07:17.53

本日よりC++をやることになる呪い

**デフォルトの名無しさん** · 2019/11/25(月) 02:44:44.71

unmanagedのinlineでAVXを実装すればC#でも大差ないような。

**デフォルトの名無しさん** · 2019/11/25(月) 04:13:39.62

>>846
言語じゃなくてFrameworkならC#(ASP.NET Core)が圧倒的ってもう結論出てる

**デフォルトの名無しさん** · 2019/11/25(月) 04:24:01.36

FortunesはSpringの10倍、PlainTextは100倍…
https://www.techempower.com/benchmarks/#section=data-r18&;hw=ph&test=plaintext

**デフォルトの名無しさん** · 2019/11/25(月) 09:25:19.82

Javaは遅すぎる
実行速度も進化も

**デフォルトの名無しさん** · 2019/11/25(月) 09:28:14.97

jqとか使えば一瞬で済むことをLINQ Pad笑で書いちゃうのはC#erあるある

**デフォルトの名無しさん** · 2019/11/25(月) 11:55:35.63

でも、C#は遅いプログラムが多い。
M/Bに付属のドライバや基本アプリなどのインストーラーも遅かったし、
MSのC# 製のExpression Web 4も同等のC++製のFrontPageよりだいぶ遅い。
PIXELAのテレビキャプチャーカードに付属のテレビ視聴/録画再生アプリも
極端に遅い。途中でGCが入って30秒間くらい全く何も出来なくなる事が
あるし、テレビ番組表を表示するのも数十秒掛かるし。
一番技術が分かってるはずのVisual Studioも遅い。

**デフォルトの名無しさん** · 2019/11/25(月) 11:58:40.42

競技プログラムに詳しい人の感覚では、C#はC++の10倍遅い：
http://kumikomiya.com/competitive-programming-with-c-sharp/

**デフォルトの名無しさん** · 2019/11/25(月) 16:02:04.90

他のC#スレ見ても、C#信者は配列が遅い、LINQが遅い、WPFが遅いと言っても受け付けない低スキルの馬鹿が多い。
CPUに関する知識が皆無。まるで20年前のJava信者、MIPS信者のようだ。

**デフォルトの名無しさん** · 2019/11/25(月) 16:55:11.95

配列遅いって言って受け付けないって人は何使うの？
linqは言ってる人居るけど配列遅いなんて人居る？

**デフォルトの名無しさん** · 2019/11/25(月) 17:03:07.45

幻覚じゃないか？

**デフォルトの名無しさん** · 2019/11/25(月) 17:06:26.86

>>856
おそらく、
僕(>>855)が遅い遅いって言っているのに誰も取り合ってくれなかった！僕の話を聞かないアイツらがバカなんだ！
っ言いたいんだと思う。

**デフォルトの名無しさん** · 2019/11/25(月) 19:01:49.04

C++使ってる人はあらゆることにパフォーマンス求める人がが多いからなあ
C#使ってるとそこまで気にしない
例え10倍処理が速くても自分の糞アプリにはなんのメリットがないので速さはいらない

**デフォルトの名無しさん** · 2019/11/25(月) 20:46:21.36

>>841
まっっっっっったくありません
で、説得力は？

**デフォルトの名無しさん** · 2019/11/25(月) 21:41:20.62

配列が遅いって言うならポインタ使えばいいだろ
C#の昔からの標準機能だ

**デフォルトの名無しさん** · 2019/11/25(月) 21:57:22.45

ポインタ使ったら早くなる？
配列使ったほうが最適化しやすくて早そうだけど
ケースバイケースかな？

**デフォルトの名無しさん** · 2019/11/25(月) 22:30:54.03

>>862
ケースバイケース
配列のインデックスを計算で求めてるような場合は最適化が効かず境界チェックが毎回実行されて遅い
そういう場合はポインタにするとめちゃくちゃ早くなる

**デフォルトの名無しさん** · 2019/11/26(火) 04:50:45.09

無駄なロジック見直した方が早いぞ。

**デフォルトの名無しさん** · 2019/11/26(火) 18:13:42.70

逆に言えばC++なら糞みたいなロジックでもよく検討されたロジックのC#より余裕で早い可能性もある
でも大体はC++プログラマの方が一段上

**デフォルトの名無しさん** · 2019/11/26(火) 18:17:32.18

やっぱり GCというのは遅いもんなんだよ。

◆QZaw55cn4c · 2019/11/26(火) 19:56:36.01

>>866
でも free()/delete が難しい環境では GC はありがたいですね

**デフォルトの名無しさん** · 2019/11/26(火) 20:26:45.31

>>867
組み込みなどの事を言ってるなら、GCの中でfree()/deleteが呼び出されるので同じ
どころか、もっと複雑になってしまう。

**デフォルトの名無しさん** · 2019/11/26(火) 21:01:10.58

GCが遅いってGen0はそこまでじゃないだろ
まさかGen2前提じゃないだろうな

**デフォルトの名無しさん** · 2019/11/26(火) 21:03:42.29

コントロールを縮小して印刷するのにおすすめの方法を教えてください

**デフォルトの名無しさん** · 2019/11/26(火) 21:05:17.89

プリンタドライバで縮小印刷

**デフォルトの名無しさん** · 2019/11/27(水) 02:56:56.91

>>866
遅くなる原因はGCだけじゃないし

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

テンプレートはc++よりc#の方が早かったり
するので使い方次第だと思うのですけどね

◆QZaw55cn4c · 2019/11/27(水) 06:33:20.48

>>873
それはコンパイル時間なのではないですか？

**デフォルトの名無しさん** · 2019/11/27(水) 07:09:23.78

ちゃんとテストしてみてから異議を唱えよう

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

定期的に湧く、C++より速いとか、C#は遅くないと言ってる低スキル君が、Java信者と言ってることがいつも同じでむかつく。

**デフォルトの名無しさん** · 2019/11/27(水) 08:14:47.64

>>874
同じ内容の処理でC#がC++より速くなるケースが想像できないのだが、具体的なケースを教えてくれないか？

**デフォルトの名無しさん** · 2019/11/27(水) 09:37:28.69

>>877
coreclr見てみ。ネイティブからマネージドコードに置き換えてパフォーマンスとメンテナンス性向上させてるPRいっぱいあるから。

**デフォルトの名無しさん** · 2019/11/27(水) 09:48:42.73

バカの自作C++コードよりC#libraryの方が当然早いだろう。
libraryの中身はC++だったりするが
C++の演算libraryも中身はアセンブラだから同じこと。

**デフォルトの名無しさん** · 2019/11/27(水) 09:51:27.67

それはC++が遅いんじゃなくて呼び出しのオーバーヘッドが大きかったりOSやネイティブライブラリの機能が不必要に豪華で遅かったりするのを回避してるだけ

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

いいかげん他所でやれ

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

スレ立てたんでこっちでやってくれ

C#とC++を無理矢理戦わせたい人専用スレ
https://mevius.5ch.net/test/read.cgi/tech/1574852588/

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

C++/CLIでWPFをやる私は異端ですか？(*´･ω･)

**デフォルトの名無しさん** · 2019/11/27(水) 21:38:22.50

邪教徒や

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

昔試してみたような記憶があるが、C++/CLIでWPFってできたっけ？

**デフォルトの名無しさん** · 2019/11/28(木) 01:38:13.56

もう10年以上C#使って、自前ツールはほぼC#オンリーだけど、C#が速いと思ったことないよ。
ストールしまくる配列の遅さとか致命的だからライブラリとか作るには向かないが、
むしろ使い捨て、やっつけツールを作るにはちょうどよい。ポジション的は昔のPerlの立ち位置だな。
そういう立ち位置と理解すればWPFが普及しない理由も分かる。

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

>>886
>ストールしまくる配列の遅さ
詳しくお願いします。

>そういう立ち位置と理解すればWPFが普及しない理由も分かる。
C#のポジションが昔のPerlの立ち位置であることが、WPFが普及しないこと
にどのように結びつくのか解説をお聞かせくだされば幸いです。

**デフォルトの名無しさん** · 2019/11/28(木) 01:44:22.06

今はマシンパワーでゴリ押し出来るからねぇ
苦労してC++で組むメリットは少ない

**デフォルトの名無しさん** · 2019/11/28(木) 01:48:59.29

>>888
実は、C++を苦労と思わない人なら、C#で組む必要性も低いのです。つまり、
　「C++が出来るなら、C#を使う必要はない」
のです。

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

>>887
> >ストールしまくる配列の遅さ
> 詳しくお願いします。

マジかw こんなとんでもない低スキルの馬鹿がWPFスレにいるのか。
こんな基本的なことはパソコン少年でも知ってると思うが、条件分岐はストールする。
君のようなパソコンはじめて素人君はあと5年くらいROMってろなw

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

>>889
素人ではなくリアル馬鹿だったか・・・

**デフォルトの名無しさん** · 2019/11/28(木) 01:59:55.35

それもMSの経営戦略なのですが、Visual Studio は、C++ と C# で分かれて無い
ので、使われ方の比率は誰にも分からない状態になっていますね。
果たしてどっちがすかれているのかも、本当ははっきりしません。
「層」によって好みが明確に分かれている可能性も有り得ます。
また、新しいものは、時代に乗り遅れまいと試しに使う人も多いので、
その影響もあります。

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

「新し物好き層」なるものがあり、その人達は新しいものが素晴らしいと思います。
ネットにはそのタイプの人による新しいものを褒める記事が多く見受けられます。
逆に新しいもの、古いものに限らず、ネットでは物事の欠点や負の側面
を書く人は少数派です。何故かは分かりませんが、炎上を恐れる人が多い
からかも知れません。

**デフォルトの名無しさん** · 2019/11/28(木) 09:01:39.41

いつまでスレチやってんだこのガイジ共

**デフォルトの名無しさん** · 2019/11/28(木) 10:15:37.74

C#で10年ツール作り続けていることを誇るが紛れ込んでしまった

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

ちょっと消えてますね
ガイジとちゃんと書かないと