ふらっとC#,C♯,C#( ..
[2ch|▼Menu]
159:デフォルトの名無しさん
08/10/01 19:54:44
>>155
マルチうざい

160:155
08/10/01 19:57:42
>>158
おまえがうざい
やっぱC#スレってカスばっかだな
Delphiにしとくわ

161:デフォルトの名無しさん
08/10/01 19:59:02
>>155です
マルチじゃないですよ
他すれで聞いたらここを紹介されたので改めてこちらで聞きました
よろしく

>>159
氏ねよ粘着

162:デフォルトの名無しさん
08/10/01 20:00:39
>>160
おいおい
>>155は私ですよ
応援はありがたいけど
やりすぎです^^;

163:デフォルトの名無しさん
08/10/01 20:53:45
>>154
Dictionary<T>なんてものはBCLに存在しません

164:デフォルトの名無しさん
08/10/01 20:58:16
>>154
数字の添え字もNext系の操作も出来ないから無理だろ

165:デフォルトの名無しさん
08/10/01 21:03:14
CやC++ならまだしも、string型が正式にサポートされたC#に
いまだchar型が存在する理由ってなんでしょうか?
CやC++に慣れ親しんだプログラマ用の救済措置ですか?

166:デフォルトの名無しさん
08/10/01 21:03:19
GetEnumeratorでIEnumerator取って自分で操作すればおk

167:デフォルトの名無しさん
08/10/01 21:04:58
>>165
パフォーマンスでしょ
文字列から一文字ずつ取り出すような処理を全部一文字のstringにしたら恐ろしいことになりそう

168:デフォルトの名無しさん
08/10/01 21:07:33
いやそれ以前に char は文字で string は文字列なんで違うものだろというか

169:デフォルトの名無しさん
08/10/01 21:21:31
>>167
C#ではcharもstringもみなクラス扱いされていますがそんなにパフォーマンスに
違いが出るものですか?

>>168
stringでも1文字だけ格納すれば実質的にcharと同じになると思うんですが。

170:デフォルトの名無しさん
08/10/01 21:23:38
そもそも値型と参照型では?

171:デフォルトの名無しさん
08/10/01 21:25:01
>>169
Charは整数型ですが

172:デフォルトの名無しさん
08/10/01 21:25:11
ならintも長さ1のint[]があれば必要ないねそうだね。

173:デフォルトの名無しさん
08/10/01 21:25:40
おいおい大丈夫か

174:デフォルトの名無しさん
08/10/01 21:25:58
>>171
なにw

ユーザー定義型ではない値型で実質プリミティブ型になる。

175:デフォルトの名無しさん
08/10/01 21:26:15
>>169
charはクラスじゃねーよカス
処理速度も倍違う

>stringでも1文字だけ格納すれば実質的にcharと同じになると思うんですが。
ならねーよバカ

176:デフォルトの名無しさん
08/10/01 21:26:17
スクリプト言語だと文字列と文字を同一視するのもあるみたいだよ

177:デフォルトの名無しさん
08/10/01 21:28:02
格納してるブツがそもそも違うだろ
stringは参照位置だけどcharはユニコードだろ?

178:デフォルトの名無しさん
08/10/01 21:32:33
デュアルコアの時代に倍違うとかどうでもいいだろ

179:デフォルトの名無しさん
08/10/01 21:33:29
string だけあれば char がいらないって発想なら、
int[] だけあれば int もいらないな。

180:デフォルトの名無しさん
08/10/01 21:34:53
GCの負担にもなるから倍どころじゃないはず

stringって内部的にはやっぱりcharの配列なんだよ
fixed (char* p = str)でポインタ取れたりするw

181:デフォルトの名無しさん
08/10/01 21:36:59
ここまでstringbuilderなし

182:デフォルトの名無しさん
08/10/01 21:38:02
札束があれば札は要らないないってレベル

183:165
08/10/01 21:40:11
釣りでした(^^)v

184:デフォルトの名無しさん
08/10/01 21:40:49
>>182
それは何か変だ。
札は束にしても額が変わるだけだけど。
char と string は点と線くらい違う。次元がそもそも違うというか。

185:デフォルトの名無しさん
08/10/01 21:43:00
>>165
救済措置っつーか、C/C++やってて、文字型のない言語に移っても、べつになんにも困らんだろ。

186:デフォルトの名無しさん
08/10/01 21:43:23
string=文字列
char=文字

これはなんでこうなるの?

187:デフォルトの名無しさん
08/10/01 21:44:03
VBにも文字単体あるだろ

188:デフォルトの名無しさん
08/10/01 21:44:45
C#.NET でWindowsアプリを書くときに、メソッドをフォームのソース
(という言い方が正しいかどうか分かりませんが)に書くことも、
フォームではない別のクラスに書くこともできると思います。

ある画面内で完結する機能はフォームのソースに書くとか
なるべくフォームのソースには書かないようにするとか
方針はいくつか考えられますが、
C#.NET ではどうするのが主流なのでしょうか?

アドバイスよろしくお願いします。

ちなみに、Javaでコンソールアプリを書いたことはありますが
その程度の経験しかありません。

189:デフォルトの名無しさん
08/10/01 21:46:00
フォームをコンソールだと思えばおのずと窓口なはず

190:デフォルトの名無しさん
08/10/01 21:48:01
>>178
私も486DXで十分だと思っていた時がありました

191:デフォルトの名無しさん
08/10/01 21:51:45
>>188
フォームとはイベントドリブンを処理するわけで条件反射みたいなもん
フォームに直接関係しない機能や重複した機能は別途クラスを用意する

192:デフォルトの名無しさん
08/10/01 21:52:55
>>188
愚問だね。
OOPというかクラスを使ったプログラミングが分かればそんな疑問は持たない。

そんなウダウダ疑問を抱くのは一通り理解してからにすべきで、
物事の順序が違うんじゃないのかな?

193:デフォルトの名無しさん
08/10/01 21:54:12
>>175
え( ´・ω・)?

194:デフォルトの名無しさん
08/10/01 22:00:00
構造体です

195:デフォルトの名無しさん
08/10/01 22:00:17
>>188
主流といえるほど主流な方法はないんじゃないかな

196:デフォルトの名無しさん
08/10/01 22:01:04
フォームのボタンを押すことでクリップボードの文字列を取得する

@ボタンが押された
AFormクラスGUI-----処理するメソッドを呼び出し------>クリップボードを処理するクラス.GetText()
BFormクラスGUI<-----------文字列を返す-----------クリップボードを処理するクラス
CFormクラスGUI--------- 文字列を送る------------->テキストボックスに表示//Formクラス内で処理

クリップボードを処理するクラスを作ってしまえば、コンソールアプリにした場合も流用できる

197:デフォルトの名無しさん
08/10/01 22:13:39
窓口のお姉さんと、お姉さんが操作する端末みたいなもん

198:デフォルトの名無しさん
08/10/01 22:18:00
C#のフォームでMVCに挑戦するも、途中でめんどくさくなって結局イベントハンドラにロジック直書き。

199:デフォルトの名無しさん
08/10/01 22:22:52
DirectXならウィンドウとか単なる依り代

200:デフォルトの名無しさん
08/10/01 23:55:34
構造体の場合コンストラクタは1つだけしか無理ですか?

201:デフォルトの名無しさん
08/10/01 23:59:13
いいえ

202:デフォルトの名無しさん
08/10/02 00:00:21
と、思ったら1つも作れないのか・・・
データに値を入れるときが面倒だなぁ

203:デフォルトの名無しさん
08/10/02 00:03:46
引数なしのコンストラクタが作れないだけ
引数のあるコンストラクタはいくつでも作れる

204:デフォルトの名無しさん
08/10/02 00:03:51
>>155です
メインメソッドに突っ込むってどういう意味ですか?
VC#2008を立ち上げて
ファイル→新しいプロジェクトを開くと
Windowsフォーム、クラスライブラリー、WPFアプリケーション、WPFブラウザ、コンソール、空のプロジェクトとあります
どこを開いてどうすればよいですか?
>>155を動くように教えてください

205:188
08/10/02 00:06:02
レスをくれた皆さんありがとうございました。

フォームに直接絡む機能以外は別のクラスに書く、という感じのようですね。

206:デフォルトの名無しさん
08/10/02 00:09:02
>>204
ネタ?

コンソールでプロジェクトを立ち上げると
static void Main(string[] args)
{
}
というのが自動で書かれているからその間に実行させたいものを書く
static void Main(string[] args)
{
 Console.WriteLine("hoge");
}



207:デフォルトの名無しさん
08/10/02 00:09:50
>>155です
よくわからないけど
下記のようなエラーでました
エラー 1 プログラム 'C:\Documents and Settings\don\Local Settings\Application Data\Temporary Projects\Project1\obj\Debug\Project1.exe' は、エントリ ポイントに適切な静的 'Main' メソッドを含んでいません Project1


208:デフォルトの名無しさん
08/10/02 00:11:47
>>206さん
ありがと
今からやってみます
コンソールですね

209:デフォルトの名無しさん
08/10/02 00:13:06
>>203
引数は無理なのねーやっぱり

かといって、クラスで定義するといろいろ面倒だったり
例えばListViewのような構造をもった自作クラスを作った場合
listView1.items=listView2.items
なんてしてもsubitemsまではコピーされなかったり、
また、参照コピーになるから、これは参照しているだけだって意識しながら
やらないとどこかで値を変更されたりするし、かといって、privateにしたりすると
値をコピーしたい場合非常に面倒だし
だから、できるだけ構造体でやってるんだけど

みんなどうしてんのかな?構造体なんて数学的な関数以外使わない?

210:デフォルトの名無しさん
08/10/02 00:16:39
>>205
最初はフォームに全部書いちゃって、あとで必要になったときに
バラす、ってので十分だろ。

211:デフォルトの名無しさん
08/10/02 00:17:23
>>207
だって、Main メソッドがないじゃん。

212:デフォルトの名無しさん
08/10/02 00:22:02
>>155です
コンソールを開いて>>206さんに教えてもらった箇所に貼り付けました
デバッグしたところ黒色の画面が数秒間出て終わりました
エラー表示とかは無いです
これは成功しているのでしょうか?
下記のコードでは接続を確立しただけ?
それともリクエストしたけど
レスポンスを受け取れない?
どのような状態なのでしょうか?

static void Main(string[] args)
{
string url = "URLリンク(www.yahoo.co.jp)";
System.Net.WebClient wc = new System.Net.WebClient();
wc.Encoding = System.Text.Encoding.GetEncoding(51932);
string src = wc.DownloadString(url);
wc.Dispose();
}

213:デフォルトの名無しさん
08/10/02 00:24:24
>>212
だからお前は概念から勉強しろと言ってるだろカス

214:デフォルトの名無しさん
08/10/02 00:24:49
>>212
ブレイクポイントでもはって確認するか、src をコンソールに出力すれ

215:デフォルトの名無しさん
08/10/02 00:25:59
>>209
正確な理由は中の人しか知らないけれど、普通に考えると引数なしの
コンストラクタを用意できると配列確保したとき要素数だけコンストラクタ
呼ばないといけなくなるから、こうなっていると思われる。
・・・というかむしろ 3.0 以降の初期化はイニシャライザのほうが推奨かな
という気がする

後その質問に関して言えば「非常に面倒」というほどでもないとしか。
気になるほどでかいデータセットになるとバインディング(+同期機構利用)前提
で考えるわけだし

216:デフォルトの名無しさん
08/10/02 00:28:31
効率が重視されるときは構造体にはイニシャライザ使っちゃダメ
無駄なコピーが発生する

217:デフォルトの名無しさん
08/10/02 00:32:20
>>155です
何度もすいません
「C# src コンソールに出力」でググッたんですが
コンソールに出力されるって文字はいっぱい出てくるんですけど
コンソールへ出力の仕方わかりません
「srcをコンソールに出力」
↑これわかるかた教えてください

218:デフォルトの名無しさん
08/10/02 00:35:57
>>217
Console.WriteLine(src);

参考書でも買った方が早いよ。俺はもうレスしないから。

219:デフォルトの名無しさん
08/10/02 00:37:34
>>215
確かに構造体配列が問題なんだよねぇ。

.NETの規格上は構造体にも引数無しのコンストラクタが作れるんだけど、
配列確保のときには要素ごとにはコンストラクタが呼ばれない。
代わりにArray.Initializeメソッドを使うことになっている。
URLリンク(msdn.microsoft.com)

220:デフォルトの名無しさん
08/10/02 00:37:34
using namespace System::Diagnostics;

〜略〜

Debug::WriteLine(src);

221:デフォルトの名無しさん
08/10/02 00:43:48
>>220
>>1

222:デフォルトの名無しさん
08/10/02 00:44:43
違和感がするな

223:デフォルトの名無しさん
08/10/02 00:46:53
>>155です
下記のようにしてからデバッグするとエラーになりました手直しできる方お願いします
using System.Linq;
using System.Text;
// debugoncon.cs
using System;
using System.Diagnostics;
public class DebugOnConsole
{
static void Main()
{
Debug.Listeners.Add(new TextWriterTraceListener(Console.Out));
Debug.WriteLine("デバッグ・メッセージを出力");
}
}
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
string url = "URLリンク(www.yahoo.co.jp)";
System.Net.WebClient wc = new System.Net.WebClient();
wc.Encoding = System.Text.Encoding.GetEncoding(51932);
string src = wc.DownloadString(url);
wc.Dispose();
}
}
}


224:デフォルトの名無しさん
08/10/02 00:49:56
>>217
1行命令文書く度に質問しているのかい?
ごくろうさま。死んでいいよ。

225:デフォルトの名無しさん
08/10/02 00:51:35
実在するサイトのアドレスを書くな!
サイトへの攻撃とみなして報告しておく

226:デフォルトの名無しさん
08/10/02 00:51:48
>>224
そだよ
粘着キモイぞ氏ね

227:デフォルトの名無しさん
08/10/02 00:52:17
回答したい奴がすればいい

228:デフォルトの名無しさん
08/10/02 00:53:35
>>225
実在するアドレス書いたら駄目だったのか
しらなんだ
これから気をつけるよ
あんまし細かいこと言ってたら神経性の病気になるよ
あなたも気をつけたほうがいいね

229:デフォルトの名無しさん
08/10/02 00:54:29
>>227
質問回答以外はあおりですね
さよなら煽りくん
もうこなくていいからね

230:デフォルトの名無しさん
08/10/02 00:54:42
Mainが二個

231:デフォルトの名無しさん
08/10/02 00:56:10
>>229
質問回答以外はあおりですね
さよなら煽りくん
もうこなくていいからね

232:デフォルトの名無しさん
08/10/02 00:56:30
>>230さん
それ>>155へのヒントですよね
メインってのを2個にすればいいんですか?
それとも現在2つあるので1つにすればいいですか?
何から何まですいません
よろしく^^

233:デフォルトの名無しさん
08/10/02 01:00:06
>>232
氏ね低学歴。お前には一生プログラム無理

234:デフォルトの名無しさん
08/10/02 01:00:32
書いてみるからちょっと待て

235:デフォルトの名無しさん
08/10/02 01:01:05
>>233
お前は>>231を100万回読んでから氏ねカス

236:デフォルトの名無しさん
08/10/02 01:01:55
>>235
質問回答以外はあおりですね
さよなら煽りくん
もうこなくていいからね

237:デフォルトの名無しさん
08/10/02 01:02:59
あわわ、あわわわ

238:デフォルトの名無しさん
08/10/02 01:03:58
>>155さんへ

お前が低学歴なのはこのスレの住民のせいではない
八つ当たりもほどほどにしておけよハゲ
お前はまず概念理解しろ
それすらもできない低学歴は2度と来るなカス
悔しいのか?悔しいから荒らすのか?
もっとポジティブな思考ができないのかねぇこの池沼はw

239:デフォルトの名無しさん
08/10/02 01:05:01
ネットワークプログラミング相談室にいたやつだな
解決したんじゃなかったのか?

240:デフォルトの名無しさん
08/10/02 01:06:02
>>236
わかったよ
あんまし怒らなくていいだろ
仲良くしよう
これからも応援よろしく^^

241:デフォルトの名無しさん
08/10/02 01:11:26
>>238
質問回答以外はあおりですね
さよなら煽りくん
もうこなくていいからね

242:デフォルトの名無しさん
08/10/02 01:14:34
C#の環境が今ないんだがこんな感じで動いた
てゆーかソース自体に問題は無いような…

using namespace System;
using namespace System::Diagnostics;
using namespace System::Net;
using namespace System::Text;

int main(array<System::String ^> ^args)
{
  String ^url = "URLリンク(www.yahoo.co.jp)";
  WebClient ^wc = gcnew WebClient();
  wc->Encoding = Encoding::UTF8;
  String ^src = wc->DownloadString(url);
  Console::WriteLine(src);
  delete wc;

  Console::WriteLine("エンターキーで終了。");
  Console::ReadLine();
return 0;
}

243:デフォルトの名無しさん
08/10/02 01:18:34
C# だとこんなん

using System;
using System.Net;
using System.Text;

class GetTest {
public static int Main(string[] args) {
WebClient ua = new WebClient();
ua.Encoding = Encoding.UTF8;
string text = ua.DownloadString("URLリンク(www.yahoo.co.jp)");
Console.WriteLine(text);
return 0;
}
}

サイトにアクセスする前に Encoding 設定するのが良くないね
DownloadString じゃ無理なのかな

244:デフォルトの名無しさん
08/10/02 01:22:20
>デバッグしたところ黒色の画面が数秒間出て終わりました
>エラー表示とかは無いです

コンソールが勝手に閉じるからだろ

245:デフォルトの名無しさん
08/10/02 01:27:56
>>242
>>243
お疲れのところ本当にありがとうございます
>>243さんのコードでエラーなくリクエスト送信は成功していることを確認できました
ありがとうございます^^

246:デフォルトの名無しさん
08/10/02 01:28:05
へッダから文字コード取れば?

247:デフォルトの名無しさん
08/10/02 01:28:28
失せろゴミ

248:デフォルトの名無しさん
08/10/02 01:33:42
>>246
GET するユーティリティの実装ってそうしてるのかな?
今回はとりあえずバイト列として読み込んでそのまま吐いて妥協

WebClient ua = new WebClient();
Stream stream = ua.OpenRead("URLリンク(www.yahoo.co.jp)");
StreamReader streamReader = new StreamReader(stream);
Console.WriteLine(streamReader.ReadToEnd());
stream.Close();
return 0;

249:デフォルトの名無しさん
08/10/02 01:35:35
>>246
応援ありがとう
ヘッダから文字列取得は今日のところはやめておくよ
ここの>>155に貼り付けたのと
リクエスト成功した>>243さんのコードとの違いを調べてみるよ
ありがと

250:デフォルトの名無しさん
08/10/02 01:45:37
>>249
2度とくるなカス

251:デフォルトの名無しさん
08/10/02 02:06:27
うっせーはげ

252:デフォルトの名無しさん
08/10/02 02:59:46
   class Program
   {
      static void Main(string[] args)
      {
         Test t = new Test();
         t.Str = new List<string>();
         t.Str.Add("dsf");
         t.Str = new List<string>();
         Console.WriteLine(t.Str.Count);
      }
   }

   class Test
   {
      public List<string> Str;
   }

問)この場合コンソールには何が表示されるでしょうか?

253:デフォルトの名無しさん
08/10/02 04:07:18
List<>が万能過ぎるんだけどあえて配列使う意味ってあるの?

254:デフォルトの名無しさん
08/10/02 04:24:17
配列の方が速いだろ

255:デフォルトの名無しさん
08/10/02 06:21:08
>>252
何かひねったのかと思いきや予想通り0なんだけど何が言いたいの…?

256:デフォルトの名無しさん
08/10/02 09:06:40
.NET 4.0って何が変わるんですか
URLリンク(msdn.microsoft.com)

257:デフォルトの名無しさん
08/10/02 09:18:07
>>256
それの日本語記事↓
URLリンク(itpro.nikkeibp.co.jp)

「詳細は,数カ月以内に発表する予定」だそうだ。

258:デフォルトの名無しさん
08/10/02 10:37:40
>>253
とりあえず複数渡したい・返したいときは配列が速い
List<>を可視メンバの戻り値や引数にしたらマイクロソフトのガイドライン違反!

259:デフォルトの名無しさん
08/10/02 11:11:51
Listは容量を増やす時にコピーが発生するし
最悪半分ぐらいの容量が使われてなかったりするし
気分的に嫌だから作業が終わったらすぐToArrayしちゃう

260:デフォルトの名無しさん
08/10/02 11:14:52
>>258
せんせー、Enumerable.ToList がガイドライン違反ですー

261:デフォルトの名無しさん
08/10/02 11:15:22
それはCollection<T>継承したの返してあとからいじれるようにしとけと
そういう意味合いだった気がするが

262:デフォルトの名無しさん
08/10/02 11:25:32
生のListを渡すってことは
自分の知らないところでListの中身が増えたり減ったりするのを許容するってことだろ
じゃあそのListを管理してるのは誰なのよという話になるだろ

263:デフォルトの名無しさん
08/10/02 11:35:26
>>260
同じの作ってFxCopで検査したら違反になるよ
ToListやToDictionaryはコンストラクタのヘルパみたいなもんなんだから
>>261の意味合いから考えれば問題ない

264:デフォルトの名無しさん
08/10/02 11:36:56
>>259
ToArrayにする作業のほうが時間がかかったりすることはないの?

>>258
可視メンバって、privateメソッドとか?

>>262
なるほど。それはありますね

追加などの作業が終わったら、配列に戻すのがいいのかな
でも、戻り値を配列にした場合、foreach内でそのメソッドを使用するとなると
AddRangeができないから、手間ですよね?

265:デフォルトの名無しさん
08/10/02 11:39:49
ガイドラインを問題にするときの可視メンバは
publicな型のpublicメンバとprotectedメンバ

266:デフォルトの名無しさん
08/10/02 11:46:56
むむ、XNAでContentPipeline作ってLoad<>でList<>返してたが、もしかしてまずいのか。

267:デフォルトの名無しさん
08/10/02 11:48:12
それこそ配列返せばいいじゃん

268:デフォルトの名無しさん
08/10/02 11:48:14
>>265
publicで使っちゃだめなのかー
確かにわけわからなくなるもんなー
ガイドライン天才だなー

269:デフォルトの名無しさん
08/10/02 11:59:57
>>266
Content.Loadってキャッシュでしょ?
弄る前提でList返すのはダメだろ
配列でも微妙だけど

270:デフォルトの名無しさん
08/10/02 12:10:27
>>269
いや中身読んだら終わりなんだけど、中が配列の配列だったからさらに配列にしたくなかっただけ。
まあいったん配列にしますわ。

271:デフォルトの名無しさん
08/10/02 12:21:10
ん?なんでList<>を返しちゃいけないのか詳しく

272:デフォルトの名無しさん
08/10/02 12:32:22
オーバーライドできないから
フィールドじゃなくてプロパティを使うのは後で実装変えられるようにするためだけど、それと同じ
URLリンク(msdn.microsoft.com)

273:デフォルトの名無しさん
08/10/02 12:33:01
>>271
List<>を返すということは元の値を直接操作してもいいよと言っているようなものだから
1人でプログラミングする分には覚えていればいいが、多分忘れる

274:デフォルトの名無しさん
08/10/02 12:50:20
C#てWindows専用?

275:デフォルトの名無しさん
08/10/02 12:58:11
配列で返すようにしたんだけど、foreachだと使えないんだけど
こういう場合どうすればいいんでしょうか?
あと、配列を初期化したい場合どうすればいいですか?

struct Point
{
  public int X;
  public int Y;
}


class Zahyou
{
  public void GetArray()
  {
    List<Point> pList=new List<Point>();
    .
    .
    return pList.ToArray();
  }
}

class Main()
{
  Point[] pArr;

  foreach()
  {
    pArr=GetArray();
  }
}

276:デフォルトの名無しさん
08/10/02 12:59:58
>>260
そいつは新しいListを作り出すメソッドだから問題なし。
内部のListの参照をそのまま見せるのがいけない。
ただしプロパティの場合は予防的コピーを返すことも非推奨となっている。


277:デフォルトの名無しさん
08/10/02 13:10:59
264とか275が何を言いたいのか良く分からない

278:275
08/10/02 13:19:15
Zahyouクラスで計算したPoint[]を
kitai内の座標を保存している配列にコピーしたいんだけど
やり方がわからないんです

foreach(Tekiki kitai in Guntai)
{
  kitai.PArray=Zahyou.GetArray();
}

↑だとエラーがでる

Tekikiのデータ構造を
Point[] PArray
ではなくて
List<Point> PList
にすれば簡単に追加できるんだけど
でも、publicでListを返したらだめなんですよね?
こういう場合どうすればいいの?

279:デフォルトの名無しさん
08/10/02 13:29:42
>>275
voidなのにreturnしてるとか、
foreachの中に何も書いてないとかは関係してないの?

280:デフォルトの名無しさん
08/10/02 13:30:17
エラーが出る(笑)

281:デフォルトの名無しさん
08/10/02 13:39:58
>>275
あとclass Main()ってのもおかしいな

282:275
08/10/02 13:46:33
>>279
>>281
すいません。要点だけわかればと思って他はさらっと書いたので
foreach内は実際はいろいろ処理してます。
List<>を返して、AddRangeで追加していたときは普通にいけましたが
配列を返すようにしたら、どうすればいいかよくわかりません

エラー内容
'kitai' は 'foreach 繰り返し変数' であるため、このメンバを変更できません。

283:デフォルトの名無しさん
08/10/02 13:48:14
どれをどこにAddRangeするのよ

284:275
08/10/02 13:57:52
変更点はList<>を返すところを配列を返すようにしただけです

struct Tekiki
{
 public string Name;
 public List<Point> pList;
}

class ShoriMain
{
 public void SetZahyou()
 {
  foreach(Tekiki kitai in Guntai)
  {
   kitai.pList.AddRange(ZahyouKeisan.GetZahyou());
  }
 }
}

static class ZahyouKeisan
{
 public static List<Point> GetZahyou()
 {
  List<Point> pList=new List<Point>();
  //いろいろ計算
  return pList;
 }
}

こんな感じだとうまくいきます。
GetZahyouをList<>ではなく、配列で返す方法がわからないんです

285:デフォルトの名無しさん
08/10/02 14:00:56
kitai.AddRange(ZahyouKeisan.GetArray());

こんなんでいいだろ
AddRangeの中で内部のListのAddRangeを呼んでやればいい

286:デフォルトの名無しさん
08/10/02 14:07:26
C#ってはやってるの?
Javaとどっちが強い?

287:275
08/10/02 14:13:02
>>285
それって同じことじゃないんですか?
List<>.AddRangeに配列を格納することはできないですよね?

288:デフォルトの名無しさん
08/10/02 14:13:12
>>286
当然Javaの方が主流。
ただし、Winアプリを作るだけならC#3.0の方が生産性が高い。

スキルとして持っていた方が有利なのはJava、
Winアプリのみを作る状況で生産性が高いのはC#。

Javaの求人の方がまだまだ多いな。

289:デフォルトの名無しさん
08/10/02 14:20:44
C#で作ったアプリって.NETだったら
linuxでもmacでも動くんだよね?

290:デフォルトの名無しさん
08/10/02 14:21:04
そして結局日本で一番多いのはVB/VBA

291:デフォルトの名無しさん
08/10/02 14:23:16
>>287
コレクションなら全て入れられる
配列でもなんでも

292:デフォルトの名無しさん
08/10/02 14:54:19
>>291
kitai.pList.AddRange(new List<Point>(ZahyouKeisan.GetToArray()));

適当に記述してたらこれでいけたっぽいんだけど、これでいいのでしょうか?

293:275
08/10/02 14:57:54
>>284の部分で

struct Tekiki
{
 public string Name;
 public Point[] pArr;
}

static class ZahyouKeisan
{
 public static List<Point> GetZahyou()
 {
  List<Point> pList=new List<Point>();
  //いろいろ計算
  return pList.ToArray();
 }
}

こういう場合foreach内はどう記述すればいいですか?

294:デフォルトの名無しさん
08/10/02 14:59:56
>>282
> エラー内容
> 'kitai' は 'foreach 繰り返し変数' であるため、このメンバを変更できません。

このエラーが重要。

foreach(Kitai kitai in Guntai){
kitai = Zahyou.GetArray(); // (A)
}

(A)のように、foreachの()内部で宣言した変数は
変更できない。だから、エラーがでてるんだと思う。

これが、

foreach(Kitai kitai in Guntai){
kitai.pArr = Zahyou.GetArray();
}

のように、変数のメンバーとかなら変更可能。

295:294
08/10/02 15:01:39
あれ。違うか。
メンバも変更出来ないんだっけ?

296:デフォルトの名無しさん
08/10/02 15:10:07
違う。
foreach(var item in collection)
のitem変数はコレクション内のオブジェクトのコピーだから、
構造体配列等の値型のコレクションにおいてそれをやってもダメだよ〜って話。
変数のメンバといってもその変数自体がコピーされたものだから、メンバを変更しても
元のコレクションには当然反映されない。

参照型のコレクションだったらコピーされた変数はそのまま参照が渡されているので、
foreach内でメンバの変更が可能となる。

せっかくC#を使っているのにCでゴリゴリ書いているコードとレベルが変わらんぞ。

297:294
08/10/02 15:10:48
structだと変更不可能なようですorz

だとすると、forで回すのがよさそう。

for(int i = 0; i < Guntai.Length; ++i){
Tekki kitai = Guntai[i];
      kitai.pArr = ZahyouKeisan.GetArray();
   }


298:デフォルトの名無しさん
08/10/02 15:13:19
kitai.pList.AddRange(new List<Point>(ZahyouKeisan.GetToArray()));
まずnew Listはいらない
kitai.pList.AddRange(ZahyouKeisan.GetToArray());

pListを直接公開するのはオススメしない

>>293
List<Point>を返すメソッドで配列を返しちゃいけない
AddRangeでPointを増やしていく予定があるならpArrは配列にすべきじゃない
あとZahyouKeisanクラスがkitaiの情報をもっていないのに
Zahyouを返せる理由が分からない

299:294
08/10/02 15:22:29
>>296
解説どうもです。

300:デフォルトの名無しさん
08/10/02 15:35:35
>>293
どうしても配列でやりたいみたいだから書いてみた。

void ShoriMain(){
int now_enemyCount = enemy.pArr.Length;
Point[] tmpArr = ZahyouKeisan.GetZahyou();
int add_enemyCount = tmpArr.Length;
int new_enemyCount = now_enemyCount + add_enemyCount;
//配列の長さを変更
Array.Resize(ref enemy.pArr, new_enemyCount);

//新しい配列を末尾に追加
int count = now_enemyCount;
for (int i = 0; i < tmpArr.Length; i++)
{
count += i;
enemy.pArr[count] = tmpArr[i];
}
}

struct Tekiki{
 public string Name;
 public Point[] pArr;
}
static class ZahyouKeisan{
 public static Point[] GetZahyou(){
   List<Point> pList=new List<Point>();
  //いろいろ計算
  return pList.ToArray();
 }
}

301:デフォルトの名無しさん
08/10/02 15:38:06
変数名が now_enemyCount と new_enemyCount ってのは殺人的だぞ

302:300
08/10/02 15:42:45
VS2008使ってるなら拡張メソッド使ってもうちょっと楽に書けそうだな。

Tekiki enemy = new Tekiki();

void ShoriMain(){
enemy.pArr.Concat(ZahyouKeisan.GetZahyou());
}

struct Tekiki{
 public string Name;
 public Point[] pArr;
}
static class ZahyouKeisan{
 public static Point[] GetZahyou(){
   List<Point> pList=new List<Point>();
  //いろいろ計算
  return pList.ToArray();
 }
}

303:デフォルトの名無しさん
08/10/02 15:59:34
あまりにも汚いコードなんで俺が書き直してやったぞ

struct Tekiki
{
public string Name;
public void AddPoints(IEnumerable<Point> newPoints){
this.pList.AddRange(newPoints);
}
private List<Point> pList;
public Point[] pArr{
get { return pList.ToArray(); }
}
}

class ShoriMain
{
public void SetZahyou(){
foreach (Tekiki kitai in Guntai){
kitai.AddPoints(ZahyouKeisan.GetZahyou());
}
}
}

static class ZahyouKeisan
{
public static List<Point> GetZahyou()
{
List<Point> pList = new List<Point>();
//いろいろ計算
return pList;
}
}

304:300
08/10/02 16:07:17
あー悪い、>>303は俺です。

当然GetZahyou関数がTekkiの座標計算関係のみに使うのであれば、
Tekiki構造体のstaticメンバにしてもっと簡潔に書くことも出来る。

struct Tekiki
{
public string Name;
public void AddPoints(IEnumerable<Point> newPoints){
this.pList.AddRange(newPoints);
}
private List<Point> pList;
public Point[] ZahyouArr{
get { return pList.ToArray(); }
}
public static List<Point> GetZahyou(){
List<Point> pList = new List<Point>();
//いろいろ計算
return pList;
}
}

class ShoriMain
{
List<Tekiki> Guntai = new List<Tekiki>();
public void SetZahyou(){
foreach (Tekiki kitai in Guntai){
kitai.AddPoints(Tekiki.GetZahyou());
}
}
}

305:デフォルトの名無しさん
08/10/02 16:50:39
だめだめじゃないか

- GetZahyouメソッド
  × 戻り値がList<T>
- ZahyouArrプロパティ
  × 型が配列
  × ToArrayが内部状態のコピーとみなせる

てか、それ以前に値型使ってること自体が不適切という指摘をしてあげないと
URLリンク(msdn.microsoft.com)

306:デフォルトの名無しさん
08/10/02 17:02:04
WebBrowserコントロールで、DocumentCompleteを使ってElementにマウスイベント登録すると、
javascriptトリガー用の"href=URLリンク(hoge.com)"をクリックしたときにまでNavigate系のイベントが発生するようになるんだが、
コレは仕様なの?(登録先がBody又は対象のA要素のとき発生)
しかも結果的にナビゲートに失敗するから困ってる。

イベント登録しなければ発生しないみたい。
またハンドラの中身が空でもなるみたい。
誰か回避方法知らない?

307:300
08/10/02 17:47:30
>>305
すまん良く分からないんだが、戻り値がList<T>の関数がガイドライン違反なのか?
リンク先を見てみたがその記述はどこにあるの?
この場合は特に問題ないと思うんだけどなあ。

ZahyouArrプロパティについても、配列を返すプロパティがもしかしてガイドライン違反?
っていうか俺よくList<T>のカプセル化のときにこういうプロパティをよく使ってた・・・
インデクサを使えってことなのかな。

仮に返されるものが参照型の配列だったりしたら内部を変更される可能性があって良くないとは思うけど、
この場合は構造体の配列だし、private List<Point> pListについては安全なように見えるんだけどな。
内部状態のコピーが危険なのは参照型コレクションだけとかではないの?
いまいち納得出来ん。

まあTekiki構造体についてはクラスにすべきだと言う意見は納得できる。

308:デフォルトの名無しさん
08/10/02 17:52:37
グーグーレーカースー

309:300
08/10/02 18:09:52
オーケー分かった。

配列を返す操作と内部状態のコピーの時はメソッドを使用して下さいと書いてあったな。
ZahyouArrプロパティ
の代わりに
public Point[] GetZahyouArr(){
return pList.ToArray();
}

とでもしておくか。

しかし戻り値がList<T>のメソッドは使うなという記事は見つけられんかった。
リンク先おせーてくれよ。

310:デフォルトの名無しさん
08/10/02 18:11:36
その代用で使う
〜Collectionってやつがうざい

311:デフォルトの名無しさん
08/10/02 18:22:46
俺もList<T>を返すメソッドを書く事はある
だめだというガイドラインがあるなら俺も知りたい

312:デフォルトの名無しさん
08/10/02 18:24:22
リスト返したらセットアクセッサが無意味化するぞ

313:デフォルトの名無しさん
08/10/02 18:28:44


314:デフォルトの名無しさん
08/10/02 18:29:29
とゆーかカプセル化が崩壊

315:デフォルトの名無しさん
08/10/02 18:30:56
ジェネリック リストを公開しません
URLリンク(msdn.microsoft.com)
Code Analysis Team Blog : FAQ: Why does DoNotExposeGenericLists recommend that I expose Collection<T> instead of List<T>? [David Kean]
URLリンク(blogs.msdn.com)

だそうです。

316:デフォルトの名無しさん
08/10/02 18:31:05
>>275
特別にいいもの教えてやる。

っ インデクサ

317:デフォルトの名無しさん
08/10/02 18:32:13
"do not return list" c# とか適当な英文でググるといいよ
URLリンク(blogs.msdn.com)

318:デフォルトの名無しさん
08/10/02 18:35:34
>>315
それはprivateフィールドのList<T>を公開するなってことでしょ?
そんなことがまずいのはみんな知ってるだろw

static List<Point> GetZahyou()
{
List<Point> pList = new List<Point>();
//いろいろ計算
return pList;
}

このメソッドがガイドライン違反というのが納得できないだけ。
中でnewしたListをいろいろ計算して、その結果を返すメソッドがガイドライン違反という説明にはなってない。

319:デフォルトの名無しさん
08/10/02 18:41:49
計算結果を返すだけなら別にいいんじゃね
それをどういじくろうが誰も困らないし

320:デフォルトの名無しさん
08/10/02 18:45:04
constがないからな

321:デフォルトの名無しさん
08/10/02 18:46:05
List<T>返す云々以前にまずまともな設計をするべき

322:デフォルトの名無しさん
08/10/02 18:49:40
>>318
わざわざList<T>で返されたら追加することに意味があるのかと思っちゃうじゃないか……

323:デフォルトの名無しさん
08/10/02 18:54:56
>>273
List<>を返すのも配列を返すのもかわらなくね?
結局どうすればいいんだろ

324:デフォルトの名無しさん
08/10/02 18:57:16
パフォーマンスを考えればToArrayしとくべきだろ
で、引数や返り値の配列は変更しないというのは暗黙の了解にしとく

325:デフォルトの名無しさん
08/10/02 18:59:55
Dictionary.ValueCollection みたいに

326:デフォルトの名無しさん
08/10/02 19:01:04
>>323
だよね
わざわざ、ToArrayしてまたList<>にいれるわけでしょ?
変換するのは無意味な気がするんだが

327:デフォルトの名無しさん
08/10/02 19:03:32
> わざわざ、ToArrayしてまたList<>にいれるわけでしょ?
これが言い切れるようなinternalな場合はどうでもいいよ

328:デフォルトの名無しさん
08/10/02 19:03:52
書き込み可能な配列で返すのもよろしくない。

329:デフォルトの名無しさん
08/10/02 19:19:57
それを言ったらオブジェクトを返すこと自体良くないきがするんだが

330:デフォルトの名無しさん
08/10/02 19:21:55
たとえば>>325のは返す本人以外は要素の取得しか出来なかったりする

331:デフォルトの名無しさん
08/10/02 19:25:54
親戚も弄れるけどなw

332:デフォルトの名無しさん
08/10/02 19:27:01
今時ならジェネレータにして使う側がToList()なりToArray()なりするというのが良さそう

333:デフォルトの名無しさん
08/10/02 19:34:11
>>321
まともな設計をお願いします

334:デフォルトの名無しさん
08/10/02 19:41:17
引数なしのstaticメソッドで座標を作ってそれを様々な敵機に入れるなんてのはまともな設計じゃないな
普通に考えたら全部同じ座標になるし、それなら何度もメソッドを実行する意味がない

335:デフォルトの名無しさん
08/10/02 19:58:19
なるほど
やっぱりガイドライン違反じゃないんだな


336:デフォルトの名無しさん
08/10/02 20:23:45
>>334
引数無しなのは質問の要点をわかりやすくするために省略しただけ
実際は玉をよけたり、当たり判定だったりあるし、
敵機の目的地点までの経由地点の座標群を敵機ごとに保持しているだけ
「usingディレクティブがない」と揚げ足取るぐらい蛇足な指摘だと思うんだがな

337:デフォルトの名無しさん
08/10/02 20:29:41
>>335
お前がそう思うんなら そうなんだろう お前ん中ではな

338:デフォルトの名無しさん
08/10/02 20:30:54
>>334
怒るな
怒ったら負けだ

339:デフォルトの名無しさん
08/10/02 20:39:39
既に負けてる

340:デフォルトの名無しさん
08/10/02 20:48:35
なんでわざわざ作りにくい実装にするのよ


341:デフォルトの名無しさん
08/10/02 21:03:40
>>340
作りやすい実装をお願いします

342:デフォルトの名無しさん
08/10/02 21:30:54
戻り値の型にList<T>がまずいのは当然として、
IList<T>なら遥かにいいと思っているんだが違う?

343:デフォルトの名無しさん
08/10/02 21:49:22
List<T>を返すのがなんでまずいんだ?初めて聞いたぞ
それを言ったらオブジェクトの中にList<T>が含まれてたら何にも返せなくなっちゃう

344:デフォルトの名無しさん
08/10/02 21:50:05
>>343
ラッパを返せばいい

345:デフォルトの名無しさん
08/10/02 21:56:16
っ ほい

URLリンク(msdn.microsoft.com)

346:デフォルトの名無しさん
08/10/02 22:04:54
いちいち継承してらんねーよ

347:デフォルトの名無しさん
08/10/02 22:10:43
今日のレスは勉強になったなー

348:デフォルトの名無しさん
08/10/02 22:14:52
なんしか、フィールド変数の値を返す場合はプロパティで
オブジェクトを返す場合メソッドを通して値のやり取りをしろってことでしょ?

349:デフォルトの名無しさん
08/10/02 22:28:04
ボタンをクリックしたら、エクスプローラで全選択するように、ボタンにCtrl+Aを割り当てたプログラムを作ろうとしています。
ところが、当然ボタンをクリックするときには、エクスプローラではなく、作っているプログラムがアクティブになってしまうので、アクティブにならないようにしてみました。
しかし、ボタンを押しても全選択はできないままです。
アドバイスお願いします。

namespace CtrlA {
public partial class CtrlA : Form {
const int WM_MOUSEACTIVATE = 0x0021;
const int WA_NOACTIVATE = 3;
public CtrlA() {InitializeComponent();}

protected override void WndProc(ref Message m){
switch (m.Msg) {
case WM_MOUSEACTIVATE:
m.Result = (IntPtr)WA_NOACTIVATE;
return;}
//Console.WriteLine(m.Msg);
base.WndProc(ref m);
}

private void CtrlA_Click(object sender, EventArgs e) { SendKeys.SendWait("^A") ;}
}
}


350:デフォルトの名無しさん
08/10/02 22:28:11
変更可能なオブジェクトの参照を流出させることのリスク、
そのリスクの管理ができていればどうしようとかまわないと思う。
ようは外部から参照経由で変更された場合に、
そのオブジェクトを内包させているクラスが
値が変わったことを知ることができないということ。

メソッドの場合はメソッド名で内部の参照をさらしているのか、安全なコピーを返しているのか
区別が付くような名前にしておくとか工夫して置けばよい。
プロパティの場合はメソッドを使うよりはいろいろルールがある。


351:デフォルトの名無しさん
08/10/02 22:34:21
>>349
エクスプローラの画面のハンドルが必要になるような。
どうやるかはWin32APIの範疇になる。

352:デフォルトの名無しさん
08/10/02 22:38:51
>>350
>そのリスクの管理ができていればどうしようとかまわないと思う。
そのリスクを減らすためのものがガイドラインでしょ?守らないと不幸なことが起きるかもしれないのがガイドライン。
俺仕様がしっかりしてるならそれでもかまわないが、それが通用しないところではガイドラインが役に立つ。

Delphiで言うと、クラス名はTうんちゃらで始めるという習慣があるが、厳密な言語仕様でもないので守る必要はない
ただ、守らない理由なんて無いけどな(Delphi.netは例外)
TTBaseって支援ソフトがあるんだが、これのプラグインSDKにはTTTBasePluginというクラスがあって、1カ所(ry

353:デフォルトの名無しさん
08/10/02 22:50:36
>>346
何を継承して何をしたいのか知らんが、
>>344-345をするならAsReadOnly()呼ぶだけじゃん

354:デフォルトの名無しさん
08/10/02 22:57:18
>>352
プロパティに関してはそういうガイドラインがあることは承知しているが、
通常のメソッドに関しては見たことがないな。
メソッドの場合は自己責任じゃないかと。



次ページ
最新レス表示
スレッドの検索
類似スレ一覧
話題のニュース
おまかせリスト
▼オプションを表示
暇つぶし2ch

5377日前に更新/215 KB
担当:undef