C#, C♯, C＃相談室 Part94

1 名前：デフォルトの名無しさん mailto:sage [2017/04/22(土) 15:36:53.26 ID:S+KK7a41.net] ■Visual Studio 2015 Community & Express (無償の統合開発環境)等はこちら www.visualstudio.com/downloads/ ■コードを貼る場合はこちら ideone.com/ ■前スレ C#, C♯, C＃相談室 Part92 （実質93） echo.2ch.net/test/read.cgi/tech/1485589613/ ■次スレは>>970が建てる事 建てられない場合は他を指定する事。 136 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 09:20:10.02 ID:CWb9U0nP.net] >>128 少数のことを考えなくて済むように、nullがあった方が助かる場面もあるだろ そう思ってないようなおまえは早々にやめたほうが良いと思うよ 137 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 09:38:54.50 ID:dFpq1SmP.net] ついでにundefinedも導入してほしい 138 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 10:29:24.60 ID:4XHCBZ7H.net] ぬるぽ 139 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 10:36:49.92 ID:0w0qPph2.net] どうしてnull非許容型を導入するって話をnullの根絶なんて話に持っていこうとするんだろうね？ 140 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 10:46:19.73 ID:xvW9RZ2K.net] >>128 間違ってるよその発想 その発想って>>1254の記事にもあるけど、メソッドが引数にnullを受け入れる 確信もないのに意図してnullを渡すプログラマなんかいません。 nullを受け入れないメソッドにnullを渡してしまう事態が起こるのは、 バグによってプログラマの意図に反してそうなるからだよ。当たり前でしょ。 だからnull非許容型を導入したところで、「プログラマの意図の反して変数の能がnullであるバグ」が 「プログラマの意図に反して変数の値が不適切であるバグ」に置き換わるだけ。 そして後者は前者より発見が困難な分、悪性度はより高い。 こんな簡単なことが分からん奴ってアホだろほんっと。 141 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 11:09:16.07 ID:PQqcAP89.net] >>133 一つより二つ覚える方が大変だろ 未開人だと三つ以上は沢山だぞ そんなにプログラミングの要素を増やすな 覚えきれない 142 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 11:32:23.53 ID:fJwJIEtw.net] 変数がnullである　は　変数が不適切である　に含まれる 変数が不適切なケースのうち変数がnullであるケースを言語仕様として排除できるって話じゃないの？ 確かにこのnullのケースを排除しても他に不適切なケースがある設計なら完璧な対策ではないだろうけど有用なケースも認められるなら検討の価値はあるんじゃないかな？ 143 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 11:40:03.52 ID:lmoDZ3Fc.net] >>134 意図してNull値を渡すつもりがないなら Null値が入る可能性があることがコンパイル前に判明するほうが あきらかに修正もしやすいだろ なに言ってんだ 144 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 12:07:37.15 ID:xvW9RZ2K.net] >>137 何を言ってるのか意味が分からんね 145 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 12:11:17.02 ID:QZczTL/V.net] >>138 お前がな 146 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 12:23:14.46 ID:Em+sDdPu.net] 全部Object型でやってろってのと変わらんがな 147 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 12:55:24.52 ID:cF0VKHZde] Linux上でC#を使ってAndroid開発って出来ますかね？ 今までC/C++やJavaでやってきたのですが、 C#で上記が可能ならC#に移行したいなと考えてまして。 148 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 15:17:32.97 ID:IRME+Rk/.net] >>134 ただの理解不足。具体的にTypeScriptとかのコードでその状況を示して見てよ。 多分、nullが入れられなくなるので初期値に別に値(stringならstring.Empty的なもの)を入れるもんだと思ってるんだろう。 それは間違った考え ・nullの考慮忘れ ・過剰なnullチェック というのを防ぐのが目的 <従来> void Hoge(string arg){ 〜 } //listが要素を持っていなければfirstはnull string first = list.FirstOrDefault(); //何らかの処理 //nullの考慮忘れ。実行時例外 Hoge(first); <null非許容型> //Hogeの引数はnull非許容 void Hoge(string! arg){ 〜 } //ここは「何らかの処理」の都合でnull許容とする string first = list.FirstOrDefault(); //何らかの処理 //nullの考慮忘れ。コンパイルエラー Hoge(first); 149 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 15:28:42.02 ID:9Gf4SnqN.net] 実行時例外でるならそれでいいじゃんｗ 150 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 15:34:09.87 ID:xvW9RZ2K.net] >>142 具体的で 151 名前：素晴らしい 確かにその例で示されているような「nullの考慮忘れ」を防ぐ一定の効果は 期待できることは認める。 でもそれ、よく考えると机上の空論でしょ。 普通のプログラマならある変数やコレクションが仕様上nullを持ちうるかどうかは 常に気にしながらコーディングするので、そこに例示されている「nullの考慮忘れ」は 実際にはそんなにありがちな問題ではないと思う。 ありがちなのは、その例でいえばリストに値を入れる段階で プログラマの意図に反してnullが混入する問題だよね。 [] [ここ壊れてます] 152 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 15:55:01.74 ID:fJwJIEtw.net] 実行されるまで気づかないならインタプリタと一緒じゃん 153 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 16:07:24.68 ID:IRME+Rk/.net] >>144 ＞ありがちな問題ではない ありがちかどうかではなく、その機能を導入するメリットとデメリットの釣り合い。 エラーが未然に防げたり、記述が簡潔で見やすくなるならメリット。 文法が複雑になったり、別のバグの原因になったり、動作が遅くなったり、実装に手間がかかるならデメリット。 現状は「新バージョンではnull許容はstring?にしろよ」から「文法は変更せずフロー解析でどうにかしようぜ」までいろんなアイデアがある 個人的には、標準ライブラリの頭nullチェックをしてArgumentNullExceptionを出すようにしているところがいらなくなってライブラリ作者にはメリットがデカそうかなとはおもってる null入れてArgumentNullExceptionがでるテストも書かなくて良くなる 154 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 16:22:43.45 ID:IRME+Rk/.net] >>144 >リストに値を入れる段階でプログラマの意図に反してnullが混入する nullを含まないリストならList<null非許容型>にすれば意図に反してnullが混入しうる状況ではエラーや警告にしてくれるようになる List<null許容>から変えられないなら、取り出す時にnull非許容にすればその場でエラーが確認できる フロー解析で検出が無理な状況も当然存在するけど、多分こんなことをするのかな <現状> string A(){ string a = Hoge();//Hogeの戻り値はnull 別の処理 return a;//意図せずnullを返してしまう } これだと、別の処理中にぬるぽになったり、戻り値がnullになるかも。 Hogeの戻り値が不適切なのに、別の処理中でエラーが起こるのでスタックトレースとかではバグが探しにくい。 <null非許容> string! A(){ string! a = Hoge().ToNull非許容;　//null非許容に変換 別の処理 return a; } これが以下のようにコンパイルで展開される string A(){ string a = Hoge(); if( a == null)throw new Null非許容型変換例外(); 別の処理 return a; } 例外発生箇所が確定するので、バグの位置がすぐにわかる この例だとnull比較のコストが入ってるけど、俺の知識が浅いだけなのでもっとうまいやり方も多分あると思う 155 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 17:14:59.24 ID:rw+7fc+A.net] そうだねーPHPから出てこないでね 156 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 18:01:59.69 ID:9Gf4SnqN.net] null許容にするメリットを実感できないんだろうな 157 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 19:54:58.94 ID:wmLMN2ht.net] 使えとは言ってないのにな 親でも殺されたか？ ゴミムシの親なんか区別がつかないだろうが 158 名前：デフォルトの名無しさん mailto:sage [2017/05/24(水) 23:36:34.45 ID:a2/m6a7T.net] >>147 コンパイル後の出力にnullチェックが入ってるってことは string! aにnullが入る可能性が出来てしまうってこと！？ そこはコンパイルエラーにしてもらおうよ >>142の > ・nullの考慮忘れ > ・過剰なnullチェック > というのを防ぐのが目的 （＋テスト） は、防ぐというより無くしたい 159 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 01:11:21.81 ID:lqQtAs3j.net] >>151 nullチェックはNull許容型からNull非許容型にする際の話 nullの可能性があるならタイプマッチとかで消すほうが素直だけど、kotlinとかでは例外を投げる変換を用意してるみたい 修正されてない古いライブラリとかだとnullにはならないけどnull許容型みたいのが存在せざるを得ないので、そういう機能もほしい 160 名前：ということじゃないかな [] [ここ壊れてます] 161 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 03:16:43.36 ID:ezJU1k3U.net] 今のところ超過激なトンデモ案が優勢なのかな？ 採用されたら仕事が捗りそうなので、とても期待しているww 162 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 03:37:28.50 ID:XcDeaOpm.net] null非許容型が追加されるならconstメソッドも 追加してほしいもんだ。 163 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 03:38:41.10 ID:K8EeLAYg.net] いまだに2.0とか3.0やってる化石には全く関係のない話だから 足引っ張らないで欲しいわ 164 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:11:39.41 ID:raX4nowj.net] Linqすら使えない自分の職場の悪口は止めてくれないか 165 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:17:54.20 ID:TdXNYUaP.net] 職場？お遊戯会の間違いだろ 166 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:41:19.09 ID:OZ9w4Yf7.net] ロック問題で、価値ないつまらんネタ書いている奴こっち来い 適当にあしらってやるよ 167 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:44:07.67 ID:raX4nowj.net] >>158 向こうに行ってやれよw 168 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:50:35.84 ID:OZ9w4Yf7.net] 最近は、こっちではnull非許容ネタやってるのか・・・ これ導入されたらガベージコレクタの性能落ちたりしないかな 4G越えのでかいツリー構造とか作っていると、参照つなぎ替えだけで色々やばいことが起こるんだよな できるかぎり、用のないフィールドに参照ぶら下げたくないと最近しつこくnull入れてたりするんだが。 あと、event関係、弱参照で全部作り直さないとヤバないかな。 Taskとかと相性悪くて簡単にメモリーリーク起こすし、 WeakEventManagerでWPFは変態回避してただでさえコード変態状態だし。 VMごと作り直さないと色々噴き出しそうだ 169 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 11:51:39.74 ID:OZ9w4Yf7.net] >>159 ここはキチガイの建てたゴミ箱、ちょうどいいんだよ。 170 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 12:35:35.78 ID:KYr+IXo2.net] >>160 そんな場合はnull許容型を今迄通り使えばよろし 171 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 12:39:51.97 ID:doyjLZp2.net] なんで択一の考えしか出来ないんだろうな 頭悪いのか？ 頭悪いならゴミ回収みたいなルーチンワークしてろよ 172 名前：デフォルトの名無しさん [2017/05/25(木) 12:40:36.41 ID:OZ9w4Yf7.net] >>162 統一性のないコードになりそうだw ここまで破壊的変更をするなら同じVM上で動く別言語として全く新しく設計した方が良い気がしてきている。 C#と混合してプロジェクトに登録できるようにすればシームレスにつながると思う。 今のC#には、アクロバテックな予約語追加とかも増えてきているし、いろいろ限界が来ていると思うんだ。 173 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 13:22:25.50 ID:OZ9w4Yf7.net] どうせならC#を改造するのではなく、新規言語にして、ここにあるパターンをサクっと言語仕様として実装してみてほしいな。 https://ja.wikipedia.org/wiki/%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3_(%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2) >一部のデザインパターンは、プログラミング言語（例: Java, C++）の機能の欠損の印であると主張されることがある。 >計算機科学者のピーター・ノーヴィグは、GoFによるデザインパターン本の23パターンのうち16パターンは、 >言語によるサポートによって単純化または除去できることをLispやDylanを用いて実演した。 あと、マルチスレッドプログラミングに関するパターンも、C#で書いていて本当に冗長と感じる。 文法は、Pythonみたいにインデントでネストを書けるようにしてくれれば、Pythonと交互に書くときに {} 忘れで判りにくいバクにならなくて済む。 174 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 13:37:43.42 ID:Gj1BXJi/.net] >ID:OZ9w4Yf7 基地外こっちでも大暴れかwww 175 名前：デフォルトの名無しさん [2017/05/25(木) 13:39:20.53 ID:OZ9w4Yf7.net] >>166 ようキチガイ、ここは、お前が建てたスレだろ。 向こういくなや、あっちはマジ質問なんだから。 お前とは、ここで遊んでやる。 176 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 16:36:05.73 ID:Wjjn5VOT.net] まじで基地外だからな・・・ 177 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 17:37:12.65 ID:KYr+IXo2.net] >>164 swiftもkotlinも同じ感じの仕様だから適切に使い分けられれば良いんでないのかな それがスキルだし 178 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 18:24:15.44 ID:6uvmeYQm.net] c#がもし最初から作り直せるとしたらどんなふうにする？ 俺は yield returnじゃなくてyieldにする ジェネリックをsystemに入れる 179 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 18:31:48.41 ID:ISg+EccP.net] 取り敢えずintは64ビットでstringはnull無し 180 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 18:55:20.09 ID:QWlkLrx5.net] switchのbreakは省略可能にする 181 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 18:57:08.84 ID:yV0yCNuL.net] Nodeが快適すぎる C#ってなんだったの？ 182 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 18:57:54.98 ID:6uvmeYQm.net] >>173 言語と動作環境比べられても… 183 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 19:21:56.48 ID:KYr+IXo2.net] immutable保証の構文は欲しい if forは文でなくて式でありたい 副作用隔離文法も欲しい 184 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 19:24:16.19 ID:BYkVp2J8.net] ジャップなんて99%素人に毛が生えたレベルなのに使い分けとか酷だ 185 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 19:36:21.23 ID:6uvmeYQm.net] ダック・タイプの問題も最初からすっきり仕様作る 186 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 19:39:01.89 ID:1nEgUyka.net] constとreadonlyの整理 c++のconstが好きだった 187 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 19:56:07.17 ID:KYr+IXo2.net] デフォルトでconst キーワード指定した時だけ非const が良いなあ 188 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:07:38.18 ID:ZdIAUNK0.net] 何が嫌かと言えばVMだな。最初からネイティブコードコンパイラーならC++すら凌駕したかもしれん 189 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:09:09.51 ID:lGDY6SHI.net] 少なくともC#のconstとreadonlyは機能的に違うし、 どちらを無くされても困ると思うけど... 190 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:10:14.40 ID:VSmfM+8N.net] >>173 フレームワークって知ってる？ 191 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:18:46.47 ID:6uvmeYQm.net] 名前空間の分割をもっと簡素にする 今はusing増えすぎでめんどい あと一ファイルに名前空間一つに限定で ファイル先頭で指定、｛　｝なしにする namespace Hoge.Hoge : これでwebからのコードのコピペが楽になる 192 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:24:26.30 ID:vS0Oxp45.net] switch の最後の節の break は不要にする ってかこれぐらいすぐやれ 毎回モヤモヤするんだよ 193 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:26:15.77 ID:1nEgUyka.net] >>181 だから整理って書いたんだけど… 統合って意味じゃないよ 194 名前：デフォルトの名無しさん [2017/05/25(木) 20:28:33.23 ID:SU7CE5fr.net] readonlyは長すぎる javaのfinalもだけど頼むから多用する奴は3文字以内にしてくれ scalaなら定数も変数も同じ3文字だから揃って見やすいのに 195 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:29:42.51 ID:lGDY6SHI.net] >>185 では整理とは具体的にどういう意味でしょう 196 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:33:29.10 ID:OZ9w4Yf7.net] 細かい機能系だと == オーバーロードが割と収集つかない感じなっているので object.ReferenceEquals object.Equals を毎回書く羽目になり始めている これは無駄なので == オーバーロードは廃棄して object.ReferenceEquals object.Equals の糖衣構文として === !== == != という形にして欲しい。 Java屋がC#登場時に==オーバーロードはヤバイと警告していたが、今のC#は本当にそうなってしまった。 当初は気にしすぎと思っていたが、これは良くなかったな。 <= >= なんかも最低1個書けば残りは自動的に実装してほしいな。 == != はobject.Equalsは必須なので、あとは < <= >= > のいずれか一個を定義すれば残りは全部生成可能。 IComparable<A>を実装したのなら、逆にそこからobject.Equalsを実装してほしい。 object.ReferenceEquals に対応する GetHashCode() は簡単に利用できるべきだ。 LINQを使うときに、Distinct()などで、object.ReferenceEqualsを使いたいケースは多い。 どの比較を使うのか簡単に指定できるようになって欲しい。 比較演算子は、三引数の演算子にして、比較方法、比較対象1、比較対象2という感じにして a ==[比較方法] b のような感じで扱えるようになると見通しが良くなると思う。 今のC#は、ラムダ式と比較用interfaceが入り混じって混沌の世界と化している。 197 名前：デフォルトの名無しさん [2017/05/25(木) 20:35:22.76 ID:SU7CE5fr.net] >>188 トレイトがあれば自動実装出来るのにな… 198 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:37:17.55 ID:yV0yCNuL.net] C++に回帰するのだ 199 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:42:49.06 ID:OZ9w4Yf7.net] >>190 今のC#はまさにそこに向かっているので嫌なんだよね。 収集のつかない言語拡張、誰も知らない大量の構文と予約語で築かれた謎の言語仕様。 C++は、21世紀のCOBOLだ 200 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:44:09.62 ID:6uvmeYQm.net] c++はほらバカには便利だろう見たいな新機能をいれてるけどそれすら使いこなしにくい 201 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:46:56.61 ID:lm8UuBKM.net] 型宣言は後置の方がいい >>175 >immutable保証の構文 デフォルトでimmutableにして、 必要ならmutableに出来ればよくね 202 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 20:47:18.02 ID:yV0yCNuL.net] C#が滅んでも困らないからいいや node.jsがあれば安泰 203 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 21:04:38.19 ID:dzSQ5kE9.net] >>189 キチガイに触るな 204 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 21:08:44.13 ID:B4esX4Id.net] >>191 糖衣構文を要求したその口で「収集のつかない言語拡張」とか一体何の冗談？ 205 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 21:10:56.06 ID:OZ9w4Yf7.net] immutableを構文を作るのであれば、new でプール中にすでに同じ内容のオブジェクトが無いか調査して 既にあるならそちらを利用する仕組みも欲しいな。 これを利用する場合比較演算子EqualsとReferenceEqualsは同じ結果になるのでEqualsもGetHashCodeも自動実装の物でよい。 オブジェクトプールは、弱参照のHashSetで実装される事になると思うが、弱参照の先が死んでいた場合、HashSetの登録項目も整理できる。 ガベージコレクトと一緒にこれを整理できればより効率的だが、これは現状ライブラリベースで作る事は出来ない、VM側のサポートが必要。 これについては、メモリ管理にリファレンスカウンタを実装しても良いと思う、基本はリファレンスカウンタでマークスイープはゴールキーパーとして機能させる感じで。 206 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 21:11:49.39 ID:lGDY6SHI.net] >>188 何言ってるのかよく分からうけどカオスを増加させるだけにしか思えんな 参照型の==がデフォで参照の比較になっているのが混乱の元だと言いたいならそこは同意する。 VBと同じように参照等価検査専用の演算子を用意して==はオーバーロードしない限り 使えないようにしてくれた方が分かりやすかったと思う 207 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 21:14:05.32 ID:OZ9w4Yf7.net] >>196 お前みたいな馬鹿には分からないのですw 208 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 21:18:19.71 ID:OZ9w4Yf7.net] >>198 オーバーロードしたらEqualsとの違いが不明確になる。 使う側にはそれはとても伝わりにくい。 だから==と書けばそれはEqualsの事であるという事にした方が簡潔だと思うよ。 比較は頻発するので毎回Equalsを書くのはさすがに面倒。 209 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 21:18:19.88 ID:iDw56Z9j.net] c#とc++の違いが分からん 210 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 21:24:52.13 ID:VSmfM+8N.net] >>201 +が2個多いだろ、よく眺めてみろ 211 名前：デフォルトの名無しさん [2017/05/25(木) 21:27:49.57 ID:SU7CE5fr.net] >>201 C++…うんこ c#…B級グルメ 212 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 21:54:41.07 ID:sQqbIl08.net] C#を食ったらケツからC++が出るのか 213 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 21:58:44.98 ID:1nEgUyka.net] >>187 そんなん知らんよｗ なんで具体的な提案なんかしなきゃならんのだ 2種もキーワードがあるのにc++のconstに比べて貧弱だなーって思っただけ この部分がもっと便利になればいいねーくらいで話ししてんのに難癖つけられてもなー 214 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 22:05:37.39 ID:OZ9w4Yf7.net] 関数型のように値は一度割り当てたら変更不能というストリクトな仕様は 変数一つ一つに意味を考えて名前を付けるようになれるので見通しは良くなるね。 半面、ビギナーには辛いやり方だと思う。 変更できない物だけでどうやって変化していくものを表現するのか分からなくて途方にくれそうな絵が見える。 果たして吉とでるか凶とでるか？ 215 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 22:07:44.05 ID:06apVH37.net] >>202 どっちも+2個だろー 216 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 22:16:44.94 ID:dzSQ5kE9.net] ┏━ ╋╋ ┗━ ╋╋ 217 名前：デフォルトの名無しさん mailto:sage [2017/05/25(木) 23:36:14.82 ID:VSmfM+8N.net] >>207 C#は4つだろ 218 名前：デフォルトの名無しさん [2017/05/26(金) 00:05:23.61 ID:grHVRT/B.net] やっぱメモリ管理は自動の方がいいですか？ 219 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 00:15:54.83 ID:R9lW8EDm.net] >>210 自動の方がいいと思うよ、安心感が全然違う。 ただ、マークスイープはオブジェクト総数増大につれてパフォーマンスに問題が出始めている感じがする。 ガベコレはすべてのスレッドを止めないと始められないが、オブジェクト総数増大とともに停止時間がやばくなる。 極力、マークスイープ以外の方法で回収できる感じにした方が良いかもしれないと最近は思う。 220 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 00:29:53.59 ID:4xYFMnBo.net] >>197 思い込みで変なことを語る前に今のGCについて勉強した方がいいのでは 殆どのオブジェクトはマークアンドスイープ「ではない」GCによって回収されるんだぜ 221 名前：デフォルトの名無しさん [2017/05/26(金) 00:33:29.03 ID:R9lW8EDm.net] >>211 少なくともC#では、スタック周りだけでしょう。 シンプルな世代別ガベコレで実装されていると思われます。 C#ではC++のスマートポインタのようにスコープ抜けた瞬間に回収される所は見ないです。 それでは解決しきらないというのが自分の環境では起こり始めつつある。 222 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 00:38:57.52 ID:R9lW8EDm.net] まぁ、C#の場合すべて強参照状態なんで参照カウンタで実装したところで よほど意識してくれないかぎり有効に機能してくれない可能性は現状では高いですね。 特にevent回りとasync/await/Task回りに言えます。 223 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 00:40:01.31 ID:Mhihnqx0.net] >>213 余計な工夫でmidlife crisis起こしてそうw オブジェクトはすぐに使い捨てたほうがGCの負担になりにくいんだよ 224 名前：デフォルトの名無しさん [2017/05/26(金) 00:43:15.17 ID:R9lW8EDm.net] >>215 規模が小さいなら、使い捨てても使い捨てなくても、もともとパフォーマンスが問題になる事はないんですよ。 パフォーマンスが問題になるほど規模が大きくなっているので負担が大きいのは必然なんです。 トートロジーみたいな議論だからその反論は無意味。 225 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 02:06:01.59 ID:7MLVuo4L.net] >>205 自分で言ったことを知らないって無茶苦茶だな というか、そもそもC++のconstって肯定的に語る人はほ� 226 名前：ﾆんどいないよ。 [] [ここ壊れてます] 227 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 03:47:01.99 ID:jh4BS3n9.net] >>217 え？金も出ないのに次期言語仕様のドラフト上げろっていうの？ 君がどれくらいの人にアンケート取って肯定的な人が居ないと言ってるのか知らんが逆に否定的な人はどうなの？ 肯定的な人が居ないのはそもそもちゃんと使ってる人が少ないからってだけでは？ assertionとかもそうだけど無くても問題もないものは当然初心者向けサイトでは扱われず使用者も少なくなりがち ちなみにconst c# c++ってググれば検索上位は似たような内容が国内外含め結構出てくるよ 228 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 09:30:04.80 ID:g456XZgo.net] C++を肯定的な奴少ないが使ってるのは多い。置き換えきれる言語がないんだよ 229 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 11:01:05.91 ID:2e/JbZY2.net] constは地獄でしょ 230 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 11:41:49.76 ID:2utmFH39.net] >>219 いい得てるわw 231 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 13:10:14.69 ID:V0QADimW.net] c#でポインタが使えれば俺はc++はもういらない。 232 名前：デフォルトの名無しさん [2017/05/26(金) 17:16:27.99 ID:Vk2AXjGC.net] メモリ管理はRustのゼロコストGC(正確にはGCじゃないけど)に期待してる >>222 っunsafe 233 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 18:58:46.42 ID:4GVMWdle.net] >>222 使えるよ 234 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 19:35:43.26 ID:R9lW8EDm.net] パフォーマンスを上げるのに new するときにどの世代のメモりに生成するか指定できると便利になりそうな気がする 明らかに長期生存が分かっているオブジェクトを若いからというだけでガベコレに晒すのは無駄なんだが、現状無差別でしか生成できない。 アプリケーション終了時点まで消えてなくなることが無いと分かっているオブジェクトに至っては、生成直後に管理から外してもらえると良いんだけど。 235 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 19:47:07.58 ID:R9lW8EDm.net] >>220 天国だよ 特にラムダ式とかローカル関数では、コピーとキャプチャを区別しなくてよくなる。 というかキャプチャとか考えたやつ、もうちょっとマシな方法思いつかんかったんかよって思う。 どのスコープの物なのか判りにくくてバグの温床 C++みたいに、キャプチャかコピーか明示できるようにして欲しかった。 236 名前：デフォルトの名無しさん mailto:sage [2017/05/26(金) 20:08:39.93 ID:bEaQUHBT.net] キャプチャーがそんなに分かりづらいとは思わんけどな

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef