デコーダーがイベント監視してる時点でなんかおかしいって気が付かなきゃダメだよ
クラスの責務は1つなのだからデコーダーはデコードすることに集中しなきゃならん
なのでイベントの購読、デコーダーへのデータ供給は別のクラスの仕事というわけだ
どうしてもデコーダーにイベントソースを掴ませたいならより抽象化されたストリームを渡すべきだろうね
前スレ>>999
酷い言い掛かりだなw
この人、自分の議論が
(1) FrameDecoderは使い捨てされるオブジェクトである（CommunicationPortより寿命が短い）
(2) FrameDecoderを使う側（メインクラス？）はプログラムと同じ寿命
っていう自分勝手な前提に立ってることに気付いてるのかな。
そんな勝手な前提を置いたらどんなイチャモンでも言えるよw
既に書いたが、結局抽象的に言えるのは
----
使い捨てのオブジェクトが自分より長寿のオブジェクトのイベントに
メソッドを紐づけする場合は、イベント購読解除を忘れるとリークする
----
これ以上でも以下でもない。
だから俺の書いたコードhttp://2chb.net/r/tech/1523004019/985
に対して、「FrameDecoderがプログラムと同じ寿命じゃない、使い捨てされるオブジェクトなら
いらなくなったタイミングでイベント購読解除するようにしないとリークするよ」と質問者にアドバイスするのなら
意味があると思う
イベント発行側を引数でもらったらイカンとか、そんな訳わかんない
俺様ルールを他人にごり押ししてどうすんの。 それとさあ、、これも繰り返しになるけど、
だから俺は質問者の参考になるかもしれんコードの骨組みのサンプルを書いてるだけであって、
そんな細かい別の話をしてるんじゃないってばw
何でもっと建設的になれないかな
>>4
分かってないなあ
FrameDecoderの寿命はFrameDecoder自身が決めることではなくてそれを使う側が決めることでしょ
引数をはじめとして、自分の管理外にあるものに対して自分自身を登録することは、その了解を破ってるという点で好まれない
OSSのソースとか読んだことないかもしれないけど、実際滅多にないよ？
FormやTimerのようにGCRoot持って自分自身で寿命を制御してる例外も無くはないが、
それはフォームはXボタン、タイマなら一定時間経過、というように自分自身の性質が寿命を決めているからそれが自然なんだよ >>4
分かってないなあ
FrameDecoderの寿命はFrameDecoder自身が決めることではなくてそれを使う側が決めることでしょ
引数をはじめとして、自分の管理外にあるものに対して自分自身を登録することは、その了解を破ってるという点で好まれない
OSSのソースとか読んだことないかもしれないけど、実際滅多にないよ？
FormやTimerのようにGCRoot持って自分自身で寿命を制御してる例外も無くはないが、
それはフォームはXボタン、タイマなら一定時間経過、というように自分自身の性質が寿命を決めているからそれが自然なんだよ >>7
分かってないのは君
だから、君は勝手に「FrameDecoderを使う側の寿命はCommunicationPortと同じが
それより長い」という前提に立っている。
何度も言うが、そんな勝手な前提を置いたら何でも言える。
じゃあFrameDecoderを使うオブジェクトの寿命がCommunicationPortより短い場合はどうするのか。 >>9
なるほど、そんな初歩的なところを勘違いしてたのか
イベントを使うにしろ何にしろ、CommunicationPortから引数の受け渡しによってデータを受け取る以上、
当然、CommunicationPortからFrameDecoderへは参照を辿って到達可能でなければならないよ
問題にしてるのはその参照を登録したり解除したりする責任の話ね つか、シリアル通信クラスって標準のがあった気がするけど
それが合わないとしても、それを模倣して作れって言うのが普通じゃないのか
>>10
何を言ってるのかさっぱり分からない
だれか分かる人がいたら解説してw
「CommunicationPortからFrameDecoderへは参照を辿って到達可能でなければならない」
必要なんかどこにあんのw
しかし、こういう「俺様ルール」を正当化するために
勝手な前提条件を設定してかつその自覚がない人ってのは困っちゃうね >>12
別にもめてるわけじゃw
プログラミングは技術の一種なんだから質問スレであっても
議論に発展することがあるのは当たり前で、それを異常なことのように
感じる人間の方が病気で、そういう人間こそ無視していいと思う
以前「マウンティング」って言葉が好きな御仁がおったけど、
ようするに彼はそんなくだらないことでマウントを取りたい自分を
表出することで何かを語るに落ちてることにも気が付かない素朴なお方だw どうでもいい質問ですがvisual studioの初期設定で
C#が中括弧だけで1行使うのはなにか理由があるんでしょうか？
C++他の言語だと最初の中括弧の前では改行しないスタイルの方が多いと思うんですが
俺はブロックが解り易くて良いと思うけどな
縦に長くなるのが嫌だって人がいるのも理解しない事はないが
>>17
C++は { だけで一行使うスタイルの方が一般的だと思うぞ
C#はもともとC++開発者の取り込みを狙って作られた言語なので、ソースのスタイルも含め、意図的に全体的な雰囲気をC++に似せている 言いたい事は解るけど、それは言語仕様でなくIDEの機能では……
あのコード畳める機能って極悪だよな。
もうそろそろ終わりだなぁと思ったら畳まれているコードが数百行隠れてましたとか泣いたよ。
畳まれてるコードがあって泣くってどういう状態だよ・・・
クラスの作成について教えてください。
内部でstring程度の情報しか持たない場合でも、Disposeは実装しなければならないですか？実際、何もやる事ないですが。
しなければならないと言った人に聞いてくださいよ
一般的に、決定権がある人が必要ないと判断すればしません
すみません、聞き方が悪かったです。
しなければならないと言われた訳ではないのですが、作法としてどうなのかな？と心配になって質問しました。
自分だけで使うならどうでもいいのですが、他人にも公開するものなので、恥ずかしくないものを作りたくて。
作法というかIDisposableは主にアンマネージリソース解放の用途だよ
OS機能を直接扱うとか、メンバーが使用してるとか。インスタンス解放ではない
むしろ実装の仕方に作法があるのでMicrosoft DocsなりMSDNなりを
>>32
やることが無いならDisposeやファイナライザを実装してはいけない
それらを実装するのは例外的なケースであり、無いのが普通 >>33
>>34
レスありがとうござます。完全に勉強不足でした。
IDisposableが実装されてないクラスなんて山ほどあるのに何を勘違いしてたんでしょうか。聞いてよかったです。 コントロールが表示されないのですがなぜでしょう
Microsoft.Toolkit.Win32.UI.Controls.WinForms.WebView wv = new Microsoft.Toolkit.Win32.UI.Controls.WinForms.WebView();
wv.Dock = DockStyle.Fill;
this.Controls.Add(wv);
wv.Navigate("http://www.yahoo.co.jp/"); >>35
アンマネージなシステムリソースを確実に解放するときに使うよ どういう考え方をすればできるようになるんだよ！教えろお前ら！！ﾎﾗﾎﾗﾎﾗﾎﾗ！！！！
プロセスゾンビを確実にkillするにはどうすればよい？
>>17
私は { は単独にしない派ですね。
理由は、少しでも多く画面内にソースを表示して見通しやすくするためと、昔からの Basicの名残で、ifなら thenに相当する { は行末。endifの } は単独という位置づけですね。
今はideの進化で { } のペアの書き忘れがほとんどないというのもあるかな。 >>37
試してないけど、対応OSで実行してないとか? >>44
その言語の流儀に素直に従った方がいいんじゃないかと int c = 5;
for(c = 1; c < 61; c++)
{
//処理
}
Console.WriteLine(c.ToString());
これで一番最後でCが62になるのですが
C<61の判定後でも++のインクリメントは行われているってことでいいのですか？
>>48
新規でコンソールアプリ用のプロジェクト作ってそれをコピペして実行してみたら？
処理の中身に問題が無ければ62になるはずがない つーか、この程度の検証もせずに他人に質問を投げる神経が分からんマジで
>>47
パブリックなAPIかそうでないかによって違う >>45
OSのバージョンは問題なさそうなんですよね。 >>52
え、何が？
｛の位置にそんなこと関係ある？ 構造化制御文はインデントされた行を1行と1行、例えば if (a == b) { と } で挟むのが、
パッと見たとき一体に見えて分かりやすい。{ を単独行にすると、{ と } で挟まれた
無名ブロックがあって、その上に構造的に無関係な1行のif文があるように見えてしまう。
もう少しじっくり見れば、行末の ; の有無で下のブロックとの関係を判別できるが、
その一瞬の認知の遅れに違和感を覚え、もっとはっきり言えばキモいコードだと思う。
同じ理由で、条件が真のときの文が1つの場合の
if (a == b)
c = d;
e = f;
のようなスタイルもキモいし、Pythonの
if a = b:
c = d
e = f
g = h
はもっとキモくて、まさに蛇蝎のように嫌いだ。
関数・メソッド定義と制御文の見分けという観点からも、前者は
int func(int arg)
{
後者は
if (cond) {
で始めて、( の前のスペースの有無と { の前の改行の有無のどちらでも前者と後者で
違いをつけた方が、すんなりと見分けられて良い。
>>55
if (cond) {
}
と書くのだったら、関数の場合も
int func(int arg) {
}
とするのが統一がとれていいんじゃない？なぜ関数と if 文とで書き分けるのか、その理由がわからない メソッドとif文に差付けなくてもインデント違う時点で判別付くんじゃないのか
と思ったが、ローカル関数出てきたんだっけか
if (cond) statement;
if (cond) call();
if (notcond) return;
statement;
statement;
statement;
{}がなくても見やすいね
>>56
それぞれの制御文 (if, for, whileなど) 同士は機能が似通っているが、
関数は全く違うから、見た目も書き分けた方が良い。
Pascalだと関数は
function func(arg: integer): integer;
begin
で、制御文は
if cond then begin
で始まり、前者は begin の前に ; が入り、関数頭部を書いて一旦区切ってから
関数本体を書く格好になるので、頭部の行の独立性が比較的高い。これに倣い、
C系でも関数は頭部だけで改行した方がすんなり読める。
>>58
じゃあ、スレ立ててよ。 >>60
1行if文は否定しないし、自分自身も割とよく使うよ。 >>61
pascal に習う必要はないと思いますが…なぜ pascal を持ち出してきたのでしょうか？
私は関数と if/for/while を別にする必要性はないと思っています
{
}
とかスペースの無駄にみえてしまいます 構造がクリーンなコードを心がければ自然と{}を使わないコードになる
まあ俺から言わせてもらうと{}は綺麗なコードが浮かばない時に仕方なく使う苦肉の策ってところだね
>>63
Pascalの悪い所、例えば条件を ( ) で囲まないので条件が目立たないのは真似する
必要はないが、良い所は参考にすべきだろう。C#は開発主導者がTurbo Pascalの
作者だったこともあり、Pascalからもいくらかの影響を受けていて、赤の他人ではない。
関数と制御文は機能が違うし、関数の方がより大きなブロックだから、書き分けた方が
すんなり読める。自然言語で小さな区切りには , を、大きな区切りには ; を使って
書き分けるのに似ている。あるいは章や節の見出しのスタイルに視覚的な差を
つけるようなもの。 >>65
>>61
昔のpascalのif 文は
if cond
begin
..;.
end;
が主流だった気がします
if cond begin
end;
はむしろCの影響を受けているのでは？ >>54
うん。C#のコーディング規約はあくまでもパブリックなライブラリに関するものだから。
プライベートなものについてはお好きにどうぞって感じ。 改行コードが構文に影響を与えない言語仕様なんだから、好きにすればいいんだよ。
pascal流はマジキモイな
func() {
}
if () {
}
else {
}
が一番利に適ってる
これ以上続けても宗教の違いみたいな話で
なにも建設的なハナシにはならないからここらで終わりにしておけば？
いくら議論したところで、お仕事なら我が社のコーディング規約で終わっちゃう話だしな
この手の嗜好がただの慣れと思い込みにすぎないっていい歳こいて気付かない人は
プログラマとしてかなり筋が悪いと思うw
たぶん知能もあんまり高くないw
2週間も違う書式で作業してたらすっかりそっちが「普通」になるw
人間なんてそんなもの。
これフォントにも言えるね
>>70
泥仕合にならないかぎり、意義があると思っています、これから泥仕合になるのかもしれませんが… エディタとコーディングスタイルの話はしないのが紳士のたしなみ
>>73
フォントは目に優しいのを使った方がいい
カッコの位置などというくだらない問題とは違う VisualStudio2017 でコンソールアプリケーションを作っています。
System.Windows.Forms.Clipboardクラスを使いたいのですが
ビルドの設定をReleaseにしているとエラーはでないのに
Debugにすると FormsがSystem.Windowsに存在しないといわれてしまいます。
（アセンブリ参照はしています）
どなたか原因分かる方いないでしょうか。
>>80
新しいソリューションを作成してコードをコピペしたら問題が発生しなかったので
とりあえず解決したということにします。
ありがとうございます フォームアプリで画面の真ん中に線を引きたいと思って単純に
(System.Windows.Forms.Screen.PrimaryScreen.Bounds.Height)/2
のところに線を挽けばいいと思ったんですが、モニタのピクセルの半分のところに線を引くと
フォームの上の -□× のあるバーの下から0ピクセルになるから20ピクセルほどが下にずれてしまいます。
フォームの中央に線を引く方法ってないでしょうか？
フォームの中央なのかディスプレイの中央なのかどっちだよ
自分でもどっちでいいかわからなくなったw
最初単純にフォーム最大化してるんだから、モニタの真ん中が真ん中だろと思ったら、
windowsって下にタスクバーあるわ、モニタの下に非表示領域20ピクセルほど隠れてるわ、フォームにフォームバーあるわで、
モニタの真ん中が真ん中に見えない。
たぶん無意識化でフォームの真ん中が人は真ん中と認識しているので気持ち悪い。
ということでフォームの真ん中にしました。
>>86
タスクバーの位置なんて自由に変えられるんだけど ＞モニタの下に非表示領域20ピクセルほど隠れてるわ
そんなものはないと思うけど...
今時CRT使っててオーバースキャン表示でもやってるなら別かもしれんけどw
フォームバーってタイトルバーのことかな
非クライアント領域もあるぞ
どうにかイベントを発生させることができました。ここから5バイトの受信データを分解して処理を分岐したいんですが、どのような手法、便利な関数がありますでしょうか。
オペコード1バイト+データ4バイトという形式です。データは4バイトで表現する数値だったり、1ビットごとのフラグだったりします。
昔ながらのswich~caseで分岐って使うんでしょうか
オペコードが増えたり、データの予約ビットが変わると変更が大変そうです
switchでいいよ
たかがイベント一個作るのに何日もかかるようなレベルで今どんな凝った設計しようが、結局後で全部やり直しになる
今は余計な手間をかけないこと、シンプルに保つこと、それだけ考えてりゃいい
デバイスドライバーみたいに処理をチェーンさせるってのもあり
スクリプト言語のインタプリタなんかでも巨大switchが普通だぞ
断言するが、先を見通せない状況でヘタにコマンドパターンとか入れても、後で横断的な変更が多発して
すべてのコマンドクラスに手を入れて回るアホみたいな作業に追われることになるだけ
>>90
どっちにしろ「便利な関数なんかないでしょうw
ちっとも汎用的じゃない処理をエレガントに書く方法なんか用意されてるはずがないw
泥臭い物は泥臭く書くしかないかと
オペコードがそれ以上分解できない前提で
(1) オペコードをenumにキャストしてswith、でも
(2) ジャンプテーブル（デリゲートの配列）を使う、でもお好みで
もし仮に受信するデータが常にこちらから要求したデータである、
つまり、どういうデータが送信されてくることをこちら側が期待しているか事前に分かっている場合は
別の方法論もあると思う
その場合はこちらがリクエストを出す段階で、期待する種類のデータだけを読解できるオブジェクトを
生成してタイムアウト付きで待機させればいい >>93
横断的な変更を最小限の労力でやるために最初にほんのすこしだけ投資する
これがシステム開発のコツな それより、データの先頭を識別できるフォーマットにしたか？
固定長なら先頭コード種類分のデリゲートを割り付けるってのもあるが、こればっかしは好みだな。
ありがとうございます。
ベタベタに書いてみます。
1バイトが1ビットごとのフラグになっている場合はビットマスクで一つずつ抽出するのが一般的でしょうか？
SQLについて質問ですが
INSERT INTO T_USER (
ID, PASSWORD
) VALUES (
@ID, @PASSWORD
);
のINSERT分を
INSERT INTO T_USER (
ID = @ID,
PASSWORD = @PASSWORD
);
のように書く場合はどのようにしたらよいでしょうか。
そういうメソッド作ったらいいじゃん
setInsert(new dictionary略);
みたいなの
クラスの構造体(ただint型のデータが複数個しかない)をXMLに変換したいのだが
XMLSerializer以外に何かないかな？
XMLSerializerは以前にバグを起こしたことがあって使いたくないんだ
最終的に配列を書きだしたいのですが
それまでに色んなクラスのインスタンスからその配列の読み書きがされるのですが
どういうふうにクラスを作ればいいですか？
その配列はグローバルでstaticで宣言するか、インスタンス作るごとに参照を引き渡すのですか？
>>107
グローバルなpublic staticでいい
良い悪いを問題にするのであれば、あちこちから共通の配列をいじくるという前提の時点で設計に問題があるので、正解なし、が答えになる アクセス関数を作ってインスタンス取得用に一つスタティック関数を用意するだけ。
アクセス関数介さないと、排他処理とかいちいち入れるの面倒だぞ。
初歩的な質問なんだけど
プロパティ？(get;set;)ついてるやつと、ついていないやつの差がわからないから教えてほしい
プロパティつけててもprivateはアクセスできないみたいだから
結局、両方ともpublicになって何が違うん？ってなってる
クラスのプロパティに「型」を変数みたいにおけますか？
外部から「型」をセットして、クラスの中でその型を使って new して実体を作って利用したいのです。
気持ちをコードで表すと
public class Test
{
public <T> PersonClass;
public void Unko()
{
var p = new PersonClass();
p.unko();
}
}
ってな感じです。
※PersonClass にメソッド unko() がある前提
>>115
unkoを定義するインターフェイス作って、
Tをwhereでそのインターフェイスとnew()で絞った上で、default(T)でインスタンス作って、呼べばよいのでは？ >>114
賭けてもいい
初心者がこの手の処理が必要だと思う時、それは100%勘違いw >>99
enumにFlagsAttributeを付ける
[Flags]
enum Hoge : byte
{
Bit0 = 1 << 0,
Bit1 = 1 << 1,
Bit2 = 1 << 2,
Bit3 = 1 << 3,
Bit4 = 1 << 4,
Bit5 = 1 << 5,
Bit6 = 1 << 6,
Bit7 = 1 << 7,
}
var hoge = Hoge.Bit1 | Hoge.Bit4;
if ( hoge.HasFlag( Hoge.Bit3 ) )
{ >>119
そんな見てて痒くなる書き方しなくても今のC#は2進数リテラル使えるぞ 1
2
4
8
16
32
64
128
でいいよ。
>>119みたいなのならHexで書くのが一番だろうねw
少なくとも俺ならそうする 10進よりマシだが一番ではない
2進があるならどう考えても2進が一番
書いてみりゃ分かるよw
単に一つのビットだけ立っている値を列挙するなら2進リテラルは冗長過ぎる。
そもそも何のためにHexなんかあると思ってるの
2進リテラルっていうのは、例えば組み込みで7セグのパターンのテーブルを定義する時とか、
bit5-bit7みたいにニブル単位じゃないビット範囲のビットマスクを定義する時とかに使う
君にとってはCが頭に染み付いてるからそうかもしれないけど、
現に>>119にとっては分かりにくいからわざわざこんな書き方をしてるんだろう
今時のプログラマはC経験ない人も多いんだから実情に合わせることも必要
そういう連中を見下すのもいいけど老害呼ばわりされないように気をつけてね >>125
しょうもな
偉そうにするな！と偉そうに言うバカw
どこが偉そうにしてるのか。
そもそも俺は>>119を必ずしも否定してない。
少なくとも10進表記や2進数リテラルよりマシだ どーでもいいけど、こういう自分を客観視できない単細胞な奴がネトウヨとかなるんだろうね
ﾈﾄｳﾖってつまりどういう定義なんですか
マンコ吸わせてくださいｓ
5分かけて最後に煽っていくというだけで
自分が嫌ってるゴミと大差なくなっているというね
>>119
ありがとうございます
bitarrayってのがあるらしいんですけど、これって共用体とかに一括で代入できないんですかね
3バイトデータの内の下位1バイトは1bitごとのフラグなのでbitarrayで分解できそうなんですが そういえばちょっと疑問なんだけど、enum定義する時に>>119みたいにbyteとか指定するのは何か意味があるの？
指定したところでbyte型の変数に代入しようとしたらキャストしなきゃいけないし、やる意味がわからないんだけど ああ、enumで作った型なんだからenum型になってるだろ。
受ける変数も同じ型じゃないとダメなのは当たり前。
>>133
シリアライズとかネイティブとの相互運用目的 動的にenumで作った型のsizeof求めりゃいいんだが、静的に解決しなきゃならない時は指定するしか無いって話だよな？
>>116-117
コンパイル時点で型が定まらない（実行時に型が決まる）ものを new する手段という風ですよね？
使えそうです。ありがとうございました。
あとは、外部から「型」を受け取って new するまでの間、保管しておきたいのですが
型を変数（プロパティ）に格納するにはどうしたらいいんでしょ >>139
117はジェネリクスなのでコンパイル時には一応定まってるハズ。
型を変数に入れたいならインスタンス.GetType()か、typeof(型)で、Type型の値が取れるけど…
本当にやりたい事と、実装の方法(型を受け取ってインスタンスを作ってそのメソッドを呼ぶ)がズレてないか心配。 >>140
ありがとうございます。
「型」を格納する変数の型は System.Type なんですね！！
やりたいことが出来ました！！
System.Type t = typeof(××フォーム); ← ここのところを公開して外部からセット
var f = (System.Windows.Forms.Form)System.Activator.CreateInstance(t);
f.ShowDialog(); >>142
それさあ、キャストしてる時点で何の意味があるんだと思わなきゃw >>143
Showなどのフォーム共通の操作をしたいんだろう
基底クラスにキャストする分には意味はある
設計として正しいかどうかは別問題であり今の情報だけでは何とも言えないが、
君は自分の個人的な好みを一般常識であるかのように主張して相手の事情を理解しようとせず人を一方的に批判する傾向があるようだね 本当は自作インターフェースを持った「なにか」から派生するクラスなのですが
そこまで書くと行数が凄いことになるので、Form を例にさせてもらいました。
>>144
そういうのはFafcoty Method的な方法でやればいい。
最初から質問者が何か勘違いしてるだけだと言ってるが、
>>114-115みたいな方法論を取る必要は何もない。
お前ごときに俺の何が分かるんだアホか
その批判、お前自身にちゃんと向けているか？
自己分析一つできない奴に限って安易に他人を批判したがるから笑える >>146
基底クラスから派生したクラスを動的に生成します。
142 みたいな方法が出来ることを知らなかったので
switch 〜 case でクラスの種類だけ new() やってたところをキレイにします。 >>145
それは自作インターフェイスに「『自作インターフェイスをもった何かのインスタンス』を返す関数」を定義しておいて、
何かの方で「その関数」を実装して、
呼び出す側では普通に「その関数」を使えば良いのではなかろうか。
抽象クラスと静的関数の方がキレイかな。
「その関数」のリストが作りたいなら、そこでやっとリフレクションで取ったらいいし。
いきなりCreateInstanceは宜しくないというか危ないし、後々、各小クラスでコンストラクタがどうしようもない状況に陥ると思うよ。 むしろ.NETのメインストリームがWebに移ってからはdynamic使われまくってる
JSONデータをたくさん扱ってるといちいち型付けてられない場面が多い
自作のインタプリタ作った時に
Dynamic使った記憶がある
意図は・・忘れたww
>>153
jsonからクラスへの変換なんてVisualStudio使えば一瞬じゃない？ 教えてください。
戻り値が async Task のメソッドで await を使わないと↓のような警告が出ます。
> CS1998 この非同期メソッドには 'await' 演算子がないため、同期的に実行されます。
> 'await' 演算子を使用して非ブロッキング API 呼び出しを待機するか、'await Task.Run(...)' を
> 使用してバックグラウンドのスレッドに対して CPU 主体の処理を実行することを検討してください。
独立したメソッドなら、await が必要ないなら async Task をやめて void にすればいいのですが、
仮想呼び出しなどの関係で戻り値を変更したくない場合の解決策に悩んでいます。
とりあえず、
[1] 警告を抑制する
[2] async だけ外して Task.CompletedTask を返す
という二つの解決策を思いついたのですが、どちらも到底正しい方法とは思えません。
いいアイディアがあれば教えてもらえると嬉しいです。
同期的に結果が分かるものを非同期にして結果が欲しいとか、コールバックでも仕込んで別処理で結果得ないと正しい結果なんて分からないだろうに。
>>158
レスありがとうございます。やはり他に正しい方法はないのですね。
非同期が必要になるまでは同期実行できるのが async の効果だと思っていたので
非同期が全く必要ないときに async が使えないのは逆のような気がして
違和感が拭えないのですが、とりあえず [2] の方法でやっていこうと思います。
>>159
申し訳ないのですが、同期ついて理解不足で仰っていることが理解できないので
もう少し詳しく説明していただけないでしょうか。 await Task.Run(()=>やりたいこと)
で済ますのはどうなんだろ。
>>161
無駄にスレッド消費するしマルチスレッドによる不要なトラブルを持ち込む可能性もある最低最悪の方法
awaitを外したくないなら await Task.CompletedTask の方がクリーン >>161
レスありがとうございます。せっかくなのですが、私もその方法はあまり良くないと思います。
ご存知でしたら失礼を許していただきたいのですが、以下の2つの効果は同じではないのです。
async Task X() => Thread.Sleep(1000);
async Task Y() => await Task.Run(() => Thread.Sleep(1000));
>>162
確かに await Task.CompletedTask をどこかに挟むだけなら
変な副作用もなさそうですね。
ただ、警告を抑制するためだけに意味のないコードを加えるのは正しくないように思います。
私がそんなコードを見たら、await Task.Yield() のような効果を期待しているのかなと
誤解してしまいそうです。
（もちろん、 await Task.CompletedTask を勧めてくださっているわけではなく、
「await を外したくないなら」という無理のある前提に合わせて話してくださっていることは
理解しています） これあえて警告出しっぱなしじゃ駄目なのかね
IDEがasyncメソッドをawait無しで実行しているから警告しているだけであって、意図的に同期実行するのならコメントとかで明示しておけば良いような気もするけど
>>164
レスありがとうございます。
たかが警告を消すために実際のコードを書き換える必要があるのかという考えは
実にごもっともだと思います。
ただその場合、警告を抑制するだけでも意図は十分に伝わると思うのですが、
やはり警告はそのままにしてコメントなどで説明を行うべきなのでしょうか。 #pragma warningディレクティブ使って警告を抑止するのが一番素直のような気がする。
知らんけど
っていうか、asyncなしで問題ない前提なら最初から何も悩む必要ないと思うんだけど...
>>166
レスありがとうございます。やはり警告の抑制も選択肢になりますよね。
警告を抑制することに対する考え方は人それぞれということもあると思いますので、
その都度状況に応じた対処法を考えるのが一番でしょうか。
> っていうか、asyncなしで問題ない前提なら最初から何も悩む必要ないと思うんだけど...
申し訳ありません。これについてよく意味が理解できませんでした。
詳しくご説明していただけないでしょうか。 >>167
ごめん後者アホなこと言いましたw
よく考えてみたら、asyncが付くかどうかはただのメソッドの中の実装によって決まる話であって、
ベースクラスやインターフェイスによってそれが強制されることはないよねw
普段深く考えずに使ってることがばれちゃったw なぜ同期させているのかが根本的に分かって無いから、警告を解く事だけに注意が向いてるんだな。
同期が必要ならコードどころか構造を変えるくらいしないてならないだろうに。
状況把握しきれていないが
async()=>{}という形でラムダにasyncつけることで解決できるケースもあるんじゃね？
>>167
ご説明ありがとうございます。 >>166 で仰っていた意味が理解できました。
async/await は糖衣構文なので確かにベースクラスなどで使用が強制されることはありませんが、
深く考えずに使えるところが糖衣構文のいいところですし、
async を使うメソッドに XxxAsync という名前をつけることが推奨されていることからも、
事実上 async/await を使うかどうかはベースクラスに依存していると言っていいと思います。
これを踏まえて、改めて >>166 にお返事したいと思います。
> っていうか、asyncなしで問題ない前提なら最初から何も悩む必要ないと思うんだけど...
文法上は async なしでも問題ありませんが、コードの一貫性を考えると async を意図した
メソッドのオーバーライドで async なしは問題だと思います。
それにもかかわらず、たまたま実装上 await を全く使わなかっただけで
async の使用をとがめるような警告が表示されてしまうので悩んでいるのです。
>>169
レスありがとうございます。他の方のご意見も聞かせていただいて、
やはりこの警告は不適切で、警告を解くことだけに注意を向ければいいように感じてきています。
それに対して異論を唱えてくださっているようなのですが、勉強不足で仰っていることが
よく理解できていないので、申し訳ないのですが詳しく説明していただけないでしょうか。 >>170
レスどうもありがとうございます。
このような返しばかりで情けないのですが、理解力が足りず仰っていることがよくわかりませんでした。
申し訳ありませんが詳しいご説明をお願いできないでしょうか。 先ず、同期と非同期で何が違うのか、
同期は目的の処理を完了して戻って来る事が大前提で作られている。
非同期は目的の処理を行う指示だけをして戻って来る。
だから戻り値も自ずと意味が違って来るのが普通。
同期の戻り値は実行結果、非同期の戻り値は指示出来たかどうかで結果はまだ分からない。
そこを根本的に間違えているから、問題なんだよ。
>>173
基底クラスやインターフェイスに合わせるためであったり、
後でDB使った実装に変更する予定で今はハードコードしておくみたいなときには普通にあるケースだよ
後で非同期に変えるのは影響が大きいからね >>173
レスどうもありがとうございます。
同期処理と非同期処理の違いは、一般論としてはおっしゃるとおりだと思うのですが、
それが >>174 でご指摘いただいているような目的を達成する上で障害になっていて、
そのような問題を解消するために async/await 構文が作られたのではないでしょうか。
だとすると、同期処理と非同期処理の違いを理由に await なしの async を
否定することは本末転倒のように感じてしまうのですがいかがでしょうか。
>>174
ご説明どうもありがとうございます。
具体例を含めてとてもわかりやすく感じたのでこのレスの前半で引用させていただきました。
私にはこれだけ要領よく説明することはできそうにないので助かりました。 まあ、メイン処理止めていいなら待てばいいじゃない。
止めたく無いならポーリングやコールバックで終わったの知ればいいじゃない。
コーディングでワーニング出るから構造を弄るって手法そのものが間違いって言ってるの。
>>176
メイン処理を止めたくないならポーリングやコールバックを明示的に記述する以外に
選択肢がないというように読めてしまったのですが、この部分に間違いはないでしょうか。
もしそうなら async/await 構文についてあまりお詳しくないようにお見受けしますので、
よろしければ一度お触りになってみてください。
非同期処理の大変さをご存知であればこそ、便利さを実感できるのではないかと思います。
（ちなみに、今の問題は非同期処理を行うことも可能なメソッドをオーバーライドする際に
非同期処理を全く使わないと警告が出てしまうということですので、
何かに妥協してメイン処理を止めるというわけではありません） そもそもasync修飾子そのものには、たんにawaitする目印としての意味しかないわけで
awaitしないメソッドをasyncにするのが根本的におかしいとしか思えんのだが
wpfのフォームってhtmlとcssが合わさったようなもん？
>>178
async Task Hoge() { }
↑は警告は出るもののコンパイルできますが
Task Fuga() { }
↑はコンパイルすらできないので、async がたんに awaitするための目印というのは語弊があるのではないでしょうか。 > async を使うメソッドに XxxAsync という名前をつけることが推奨されていることからも、
> 事実上 async/await を使うかどうかはベースクラスに依存していると言っていいと思います。
TAPはTaskを返す関数の実装にasync/awaitを強要せんし使う側も関知せんじゃろ
AsyncサフィックスなんてそれこそEAPの頃からの慣例でしかない
awaitを使わず何故か付いてるasyncよりTask.CompletedTaskを返すコードの方がよほど明確だと思うがね
>>180
ただの目印と理解していいよ
asyncって目印を見つけたらメソッド内だけ文法をちょっと変えますねっていう取り決めなの
目印もなしに勝手に文法を変えられたら仕事にならん
だから目印が必要なの
目印を付けただけでエラーになると言うけど
目印を付けたら文法が変わるのだから同じコードでエラーが出たってなにもおかしくないだろう？ >>181
レスどうもありがとうございます。
async Task SayHello3() { await SayHello(); await SayHello(); await SayHello(); }
async Task SayHello2() { await SayHello(); await SayHello(); }
async Task SayHello1() { await SayHello(); }
は問題ないのに
async Task SayHello0() { }
ではなく
Task SayHello0() { return Task.CompletedTask; }
と書かなければならないことに不自然さを感じていたのですが、
2つ目の SayHello0() を単独で見れば、おっしゃる通り何をしているかは明確ですし、
async に固執するのもあまり良くなさそうですね。
async はそのままにして警告を抑制する方法を提案してくださる方もいらっしゃいますし
私としてもそちらの選択肢を完全に切り捨てるまでの確信は持てていないのですが、
Task.CompletedTask を返す方法も決して悪いものではないと分かりとても勉強になりました。
>>182
確かにそのとおりですね。失礼いたしました。
ただ問題なのは、「目印を付けただけでエラーになる」のではなく、
「目印を付けないとエラーになるのに目印を付けても警告が残る」という点でして、
せっかくの目印の機能を気持ちよく使うことができず、どうしたものかと考えております。 結局質問者の疑問はこういうこと？
(1) サブクラスで非同期メソッドとして実装される可能性があるメソッドの名前は
Asyncでサフィックスすべきか？
(2) (1)がYesの場合、そのメソッドが非同期で実装されなくても（awaitを含まなくても）
asyncで修飾すべきか？
正解はYes-No？
理由は、非同期メソッドは使う側がそれを非同期メソッドだと理解している必要があるのに対し、
非同期メソッドじゃないものを非同期メソッドと誤認しても弊害はないから
もちろん不要な混乱を避けるために、「このメソッドは多態の都合上Asyncでサフィックスされてるけど
非同期メソッドじゃないよ」みたいなコメントは必要か？
>>184
整理していただきどうもありがとうございます。
(1) については実は疑問であるという認識をもっていたわけではなく、
ご指摘をいただくまで当然そうするべき事柄であると考えておりました。
(2) がまさに疑問点でして、(1) が Yes/No のどちらであっても
答えが得られると嬉しいと思っています。
> 非同期メソッドは使う側がそれを非同期メソッドだと理解している必要があるのに対し、
> 非同期メソッドじゃないものを非同期メソッドと誤認しても弊害はない
おっしゃる通りだと思います。（もちろん細かなオーバーヘッドが問題にならない場合の話ですが）
> 「このメソッドは多態の都合上Asyncでサフィックスされてるけど
> 非同期メソッドじゃないよ」みたいなコメントは必要か？
インターフェース等を介さずにメソッドを呼び出す可能性がある場合は
そのようなコメントがあると親切だと思いますが、
私としては、必ずしも必要ではないように思います。 >>183
気持ち良い悪いみたいな感覚の話にすると結論が出なくなる
・コードに統一感があったほうが気持ちがいい(俺はこの感覚がよくわからんが)
・使ってないものを使いますと宣言するのは気持ちが悪い
どっちも言い分としては間違いではないしどちらがより正しいかとも言えない
それは見た人によるとしか言えない
君が美しいと思って書いた統一感のあるコードは、俺からすれば必要のない無駄な記述の多い汚いコードに見えるかもしれない
それはさておき
asyncメソッドはTaskインスタンスの生成とスレッドの生成に繋がる可能性がある
インスタンスの生成はともかくスレッドを無駄に消費するってことはOS全体に負荷をかけることにも繋がりかねないので意味がないなら避けるべきだ
しかし文法上の間違いではないのでエラーと断言することもできない
間をとって警告を出すってのが妥当な落とし所じゃないかな あーこれゴミクズにありがちな燃えるコメントの仕方だわ
言い争いが始まるので、賢明な諸兄は3日ほどスレを閉じておくのがよろしい
静的メソッドの中で動的メソッドって呼び出せないってあるけど、自分のクラスのインスタンスのメソッドは呼び出せるの？教えて雑魚
> async Task SayHello3() { await SayHello(); await SayHello(); await SayHello(); }
> async Task SayHello2() { await SayHello(); await SayHello(); }
> async Task SayHello1() { await SayHello(); }
と書くより引数nで実行回数を渡してforループで制御したらいい
n=0でasync awaiｔのペアがあるにかかわらず一度も実行されないawaitのついたメソッドができる
勿論警告もでないし誰かの言う一貫性のある美しいコードじゃないか
わかってると思うけどawaitがついたメソッドに突入した時点で
内部が自動的に別のスレッドで実行されるわけじゃない
中に入っても最終的にタスクにたどり着かないと別スレッドはスタートしない
System.Threading.Thread.CurrentThread.ManagedThreadIdでスレッドIDがでるから確認したらいい
>>191
await後に書いた処理って元のスレッドに同期されると思ってたけど、awaitで実行されたスレッドのまま進むよね？
Formアプリであれ？invokeしなくていいの？って思った記憶ある。思い違いだったらすまぬ 非同期自体が複雑だし、(当時は)新しい構文ってことで、混乱を少しでも減らすために警告にしてるだけっぽいね
抑止しちゃっていいと思うよ
>>193
Formが作成された所謂UIスレッドでは同期されるが、コンソールアプリ等では同期されない
もうちょい突っ込むと、await文が実行されるスレッドにSynchronizationContextへの仕込みがあるかどうかで違ってくる
await後に実行されるスレッドはSynchronizationContext.Postの実装により決定される
Winformsは最初のフォーム作成時にWindowsFormsSynchronizationContextを現在のスレッドに設定し
WindowsFormsSynchronizationContext.Postはメッセージループを仲介してUIスレッドでawaitの続きを実行する
具体的な実装はReference SourceやmonoのWindowsFormsSynchronizationContextを読むのが良い 安価まちげーた>>192
なんかテキトーに書いたら分かりにくいな・・・
要はWinforms（WPFも同様）のスレッドでawaitするとその後の文は裏で勝手にControl.Invokeされてると思えばええねん >>180
>Task Fuga() { } はコンパイルすらできない
それは戻り値のチェックで、int Fuga...でもコンパイルできないだろ
Taskもasync/awaitも関係ない話
むしろ、async Task Hoge() { } がタスク戻さないのにコンパイル通ることのほうが問題じゃね
つかほんとにこれ警告だけで通って正常に動くの？
そのときHoge()で何が帰ってきてるんだ？ まあその例で統一したやり方でやりたいなら
async Task SayHello0() { await Task.CompletedTask; }
で良いんじゃないのか
>>196
最適化してCompletedTaskでも返すのかなとも思ったけど
IL見ると他と同じようにコード生成して実行してんね
このオーバーヘッドが必要な処理なら警告を無視してasync使えばいいと思う 
