トップページ⇒tech
1001コメント299KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2007/08/26(日) 12:42:25
(#ﾟーﾟ)つ ＜ C#、.NETの話題はこちらでどうぞ。

前スレ
C#, C♯, C＃相談室 Part41
http://pc11.2ch.net/test/read.cgi/tech/1184840053/

過去スレは>>2-5あたり。
0253デフォルトの名無しさん2007/09/03(月) 02:07:34
＞場合によっては普通にLL言語にさえ後れを取る
絶対にLL言語に遅れをとらない言語ってなんだよｗ
0254デフォルトの名無しさん2007/09/03(月) 02:09:30
VC++しかつかないやつは他の言語で開発してる部署に行ったらほぼ終わり
0255デフォルトの名無しさん2007/09/03(月) 02:14:15
>>246
・300kのIO速度の計算をスルー
・300kのSJISから内部コードの変換(UTF-16やutf8)コストもスルー
・(C#)2000行の無駄なnew StringBuilderとToString、+演算子置き換えで高速化

正規表現のベンチになってないよ
0256デフォルトの名無しさん2007/09/03(月) 02:17:16
>>255
うん、正確な正規表現のベンチのつもりで書いたのではないよ
それが求めるものなら自分でやってくれ

IO処理は「どの言語でも」やっている
ユニコードへの変換も「どの言語でも」やっている
オーバーヘッドの大きそうなフォーマット処理も、PerlやPythonでもやっている

概ね、カリカリに書かずに適当に同じレベルで「普通に」書きなぐったものだ
特に何かをひいきしたつもりは無い

そうやって書いたものが、スクリプトが案外速かった(C#より速い）ってのが
重要ね。
02572562007/09/03(月) 02:28:23
ちなみにC++も三種類書いてみたが大して速くなかったね。
ソースを見れば分かるが、LL言語で書くよりずっと複雑でトリッキーで
エラーを産みがちなコードになるというのに。

こんな仕事はLL言語向きだ。他の解は馬鹿げている。そう思ったよ。
そして、そういう仕事は案外多いのだと思う。
0258デフォルトの名無しさん2007/09/03(月) 02:37:29
プロセスの生成負荷も考慮されてない…
C#、C++、Perl、Pythonではエンジンの起動時間は大きく違うし、
いくらなんでも、これで決めつけるのは早計だと思うが。

俺のPCでは、C#の方がPerlより速かったり遅かったりだった。
一瞬すぎて測れない。
Core 2 Duo E6600, 2GB, Win Vista
Super Fetchがどこまで効いているかはわからない。

明日ｋｗｓｋ調べようかな。
0259デフォルトの名無しさん2007/09/03(月) 02:45:50
正規表現の処理の話をしてるときにこれはない
0260デフォルトの名無しさん2007/09/03(月) 02:46:28
つうか試してないけどコンパイルしないほうが早かったりしてよｗ
02612562007/09/03(月) 02:54:56
>>258
入力ファイルデカくしてみそ
二回目以降はキャッシュが効くし、入力が十分デカければ起動時間は誤差の範疇に
持ち込めると思うが
ちなみに俺の環境はXP、Pentium M(1.7GHz), RAM 500Mだからずっとショボい

>>259
純粋に正規表現エンジンの性能を計りたいんなら、そうだね
俺がやったのは、正規表現を用いた典型的なPerlの使い捨てスクリプトレベルの
仕事を各種の言語で書いてみた、それだけのことで、やっている仕事自体は
どの言語でも同じだよ
0262デフォルトの名無しさん2007/09/03(月) 03:15:34
せめてマッチ対象文字列は、メモリに確保しておかないとベンチにならんだろｗ
0263デフォルトの名無しさん2007/09/03(月) 05:29:41
起動が早い言語の勝負じゃないからな
0264デフォルトの名無しさん2007/09/03(月) 09:15:08
>161
ご回答ありがとうございます。

そんなことを頻繁にするかどうかは知らんよ。
俺がちゃんとわかってる人かどうかは
あんたが決めることじゃねえよ。スキルチェックでもしてくれ。
0265デフォルトの名無しさん2007/09/03(月) 10:34:36
プログラマーなんだから、C++とC#両方使えるようになろうや。
0266デフォルトの名無しさん2007/09/03(月) 11:35:59
C++なんぞ使ってると脳みそが腐るぜ
0267デフォルトの名無しさん2007/09/03(月) 11:39:14
C++使ってる奴がまだ居たなんて･･･
0268デフォルトの名無しさん2007/09/03(月) 12:30:18
C++は使えませんが、C++でできています。
0269デフォルトの名無しさん2007/09/03(月) 12:58:35
C++はC++でできています
0270デフォルトの名無しさん2007/09/03(月) 13:29:49
gccがgccでコンパイルできるようになりました、というのは結構画期的なことだったらしいが
0271デフォルトの名無しさん2007/09/03(月) 14:01:15
foreachループ変数が書き込み禁止だってことを今更ながら知ったのだが・・・
なんでこんな制限があるんだ？
コレクションに変更を加えるわけじゃないし問題ないと思うんだけど。
0272デフォルトの名無しさん2007/09/03(月) 15:49:14
C#で変数名に変数を使うやり方ってどうやるんですっけ？
test_i(i=1,2,3・・・)みたいな。
0273デフォルトの名無しさん2007/09/03(月) 15:54:20
配列を使いましょう
0274デフォルトの名無しさん2007/09/03(月) 16:06:14
>>271
たとえば
string[] strArray = new str[]{"a","b","c"]
foreach(string str in strArray)
{
s="d"
}

ってやってもstrArrayには反映されない。

foreachの列挙子はIEnumerableの実装いかんによっては、何を
参照しているのか全く保障されない。
IEnumeratorは上記の例のようにコピーを返してくるかも知れない。
あと、IEnumuratorの実装クラスは「列挙」できればよく、要素の概念
を持たないものだってあるからね。
MSDNのIEnumerableのサンプルをみてみそ。
0275デフォルトの名無しさん2007/09/03(月) 16:30:21
>>271
「変数の使いまわし」ができないようにするのが最近の流行だから。
バグが減ると信じられてる。
0276デフォルトの名無しさん2007/09/03(月) 16:36:34
foreachって実際は

while(strEnumerator.MoveNext())
{
　string str = strEnumerator.Current;
　...
}
こんな感じでしょ
代入しても無意味というか、元が配列だったりすると
書き換えられるという錯覚を与えかねない
というか配列のforeachは
for(int i = 0; i < strArray.Length; ++i)...
に置き換える最適化がされるらしいから
実際に書き換えられちゃうんでそうするとforeachの意味が変わっちゃう
02772712007/09/03(月) 16:55:47
>>274
>>276
foreach変数ってIEnumeratorの実装に関わらずスタック上に置かれるものでは。
構文上もそこで宣言してるわけだし、直接書き換えられると誤解される余地もないと思うけど。

>>275
それで余分な変数を導入する方が場合によっては可読性が落ちると思うんだけどなあ。
というかforeach変数だけ禁止しても意味がないような・・・
0278デフォルトの名無しさん2007/09/03(月) 17:01:33
>>277
たしか、usingとかfixedとかで宣言した変数も使いまわしできないな。
0279デフォルトの名無しさん2007/09/03(月) 17:55:02
むしろforが例外か
0280デフォルトの名無しさん2007/09/03(月) 19:45:58
>>271は単に参照型と値型の区別がついてないというか、データがメモリにどう
配置されるかのイメージがつかめてないだけの気がする。
>>275は意味不明だと思う。

繰り返し変数はもとの変数のビットイメージのコピーであってもとの変数そのものではない。
これが理解できていれば271はそもそも愚問であって、こんな疑問は抱きようがないんじゃないか？
0281デフォルトの名無しさん2007/09/03(月) 19:55:24
その後の流れをちゃんと読めよｗ
271はforeachでコレクションの内容を変更したいんじゃなくて、例えば
//引数に与えられた値+2を返すメソッド
int Plus2(int value){
value += 2;
return value;
}
みたいなことをforeachの繰り返し変数でもやりたいんだろ
0282デフォルトの名無しさん2007/09/03(月) 20:13:55
int Plus2(int value){
return value + 2;
}
でいいじゃん
0283デフォルトの名無しさん2007/09/03(月) 20:20:09
なんという正論
0284デフォルトの名無しさん2007/09/03(月) 20:20:50
>>282 頭悪そうだな・・・
0285デフォルトの名無しさん2007/09/03(月) 20:22:57
まあ281の例えも悪いよ。
変に例える必然性なんて全然ないのにね。
0286デフォルトの名無しさん2007/09/03(月) 20:24:32
というか、+2と決めうちなのにメソッド作る意味があるか？
0287デフォルトの名無しさん2007/09/03(月) 20:26:09
281の方が頭悪そうだ
0288デフォルトの名無しさん2007/09/03(月) 20:26:40
>>271
あるいは逆にコレクションに変更を加えようとしてミスるプログラマが出るのを予防するためだな。

D言語ではforeachの制御変数には明示的にrefキーワードをつけないと、代入できないようになってる。
0289デフォルトの名無しさん2007/09/03(月) 20:30:55
それどんな感じで列挙子を実装するの?
0290デフォルトの名無しさん2007/09/03(月) 20:33:54
>>288
そんなアホグラマは正直無視でいい・・・
と思うのは俺だけ？

だってそんなこといったら仮引数だって変更不可にするべきじゃん
0291デフォルトの名無しさん2007/09/03(月) 20:42:45
>>289
int opApply(int delegate(ref T));というメンバ関数を実装する。
http://www.kmonos.net/alang/d/statement.html#ForeachStatement

>>290
Dでは仮引数にinキーワード（あるいは、finalキーワード）を追加することによって、仮引数への代入が制限されますよ。

要するに、最近は酔っ払いでも使えるような言語設計が流行っているのだ。
0292デフォルトの名無しさん2007/09/03(月) 20:50:44
フェイルセーフがあるのは結構な事じゃないか
0293デフォルトの名無しさん2007/09/03(月) 21:01:28
いつも酔っぱらってこーでぃんぐしてるからありがたい
0294デフォルトの名無しさん2007/09/03(月) 21:45:38
参照型の場合
foreach (Hoge h in Hoges) {
  h = new Hoge(); // はダメでも
  h.Member = 123; // は全然OKだから
あまりガードにはなってないよね。
0295デフォルトの名無しさん2007/09/03(月) 21:55:27
…なんか勘違いしてないか？
0296デフォルトの名無しさん2007/09/03(月) 22:11:00
>>295
なんかって何？一言主さん
0297デフォルトの名無しさん2007/09/03(月) 22:13:01
フェイルセーフがいいならC++のconstなんか真っ先に導入しなきゃダメだろ
キャッチしなきゃいけない例外も必要だろ
C#はそういうのが意図的に外されてるんだな
意味ないから
0298デフォルトの名無しさん2007/09/03(月) 22:15:50
VC++(2005)のMS拡張構文ではconstのあるなしで調整できるようだ。
// cl /EHsc
#include <vector>
#include <iostream>
int main() {
  std::vector<int> v;
  v.push_back(1); v.push_back(3); v.push_back(5);
  for each(int r in v) {
    r++; // OK
    std::cout << r << std::endl;    
  }
  for each(const int r in v) {
    r++; // Error
    std::cout << r << std::endl;    
  }
}
0299デフォルトの名無しさん2007/09/03(月) 22:18:01
>>297
いや、チェック済み例外は明らかに設計ミス。
0300デフォルトの名無しさん2007/09/03(月) 22:21:40
しかしネットワークなんかだと、
絶対に間違いが起きる可能性がある処理はあるわけじゃない
そういうのをどうやって実装すればいいの
0301デフォルトの名無しさん2007/09/03(月) 22:27:25
そんなのインテリセンスなりナンチャラペットの水準でサポートすれば
済むことじゃないの？

まあ、それ以前にドキュメントをちゃんとして欲しいよねw
0302デフォルトの名無しさん2007/09/03(月) 23:09:05
constもチェック済み例外も問題の根は同じ。不必要に実装に結び付く(透けて
見せる)シグニチャである点。
0303デフォルトの名無しさん2007/09/03(月) 23:15:15
>>277

あんた、単なる素朴な疑問かと思ってたけど
真正のあほだな
0304デフォルトの名無しさん2007/09/03(月) 23:16:10
VC#　ExpressEditionダウンロードしたんだけど
オフラインでMSDN見ることってできないんですか？
0305デフォルトの名無しさん2007/09/03(月) 23:21:54
ふらっとに行くべき
0306デフォルトの名無しさん2007/09/03(月) 23:31:16
>>302
意味がよくわからないから詳しく説明してくれ
0307デフォルトの名無しさん2007/09/04(火) 01:41:01
>>290に同意。費用対効果の低いフェースセーフ要らないぽ
constだので縛ってもバグは斜め上からやってくるね。
sealedつけてたのにsealed外されるとか。

foreachといえば、配列に関してはfor文と同等の速度が出ますが、こういう情報はどこにあるのでしょうか？
パフォーマンスガイドラインに重いループではforeachよりforって書いてあったので
わざわざ変えたのに・・悲しい。
0308デフォルトの名無しさん2007/09/04(火) 02:21:04
英語だけどパフォーマンスの話題はここが詳しいかな
http://msdn2.microsoft.com/en-us/library/ms998547.aspx
1.1に基づいてるからまだforが速いって書かれてはいるが・・・

http://msdn2.microsoft.com/en-us/library/aa137140.aspx
ここにもパフォーマンスの記事が結構たくさんあるね
特にKnow What Things Costは命令ごとのコスト表が載ってて面白いかも
0309デフォルトの名無しさん2007/09/04(火) 02:52:52
>>307
2.0だとforeachのほうが若干早くなってますね。
foreach (int v in ar) csum += v;
for (int i=0; i < 10000; i++) csum += ar[i];

これを下のように書くとforeachと同じスピードになるからそういう最適化をしてるのでしょう。
fixed (int *sp = &ar[0]) {
 int *ep = sp + 10000;
 for (int *p = sp; p < ep; p++) csum += *p + j;
}

ただ、foreachの制御変数が読み取り専用なのは、フェイルセーフのためなのか、
最適化のためなのかは判断がつきません。
0310デフォルトの名無しさん2007/09/04(火) 07:54:38
アンセーーーーーフ！！
なるほど、「処理を直接記述されると最適化できないが
抽象度を高くすると最適化しやすい」というやつか
forよりforeachの方が早い
LINQも早くなるという

しかしループ変数への代入を許すとこの最適化が出来なくなるわけか
0311デフォルトの名無しさん2007/09/04(火) 09:28:17
アンマネージドのコードと同期をとりたく、
EventWaitHandle.Handle プロパティで
ネイティブのハンドルを取得しようと思ったのですが、
「古い形式です」と起こられてしまいます(警告)。
新しい形式ではどのように書くのでしょうか？


0312デフォルトの名無しさん2007/09/04(火) 09:37:04
>>311
MSDNにずばり書いてあるから、まず自分で調べるくせをつけろ。
0313デフォルトの名無しさん2007/09/04(火) 09:37:06
あ、
EventWaitHandle.SafeWaitHandle.DangerousGetHandle()
でいいみたい。
Safeなんだか、Dangerousなんだか。
0314デフォルトの名無しさん2007/09/04(火) 10:15:09
>>313
DangerousGetHandle()は必要?
MSDNでは、
>このクラスを使用すると、派生クラスのインスタンスでラップされたアンマネージ リソースを
>識別するハンドル (オペレーティング システム ハンドルなど) をアンマネージ コードに
>渡すことができます。
となってるし、使用例にあるWindowsAPIの呼び出しサンプル見ても、IntPtrの代わりに使ってる。
というか従来のIntPtrの代わりに使うべきもののように見える。
DangerousGetHandle()はデバッグのためにハンドル値を16進でダンプしたいとかの特殊用途のために
残してあるんじゃないか。
0315デフォルトの名無しさん2007/09/04(火) 11:08:29
>>314
なるほど。ほんとだ。

ハンドルは、PVOIDだろ、と、
[DllImport("native.dll")]
public static extern void NativeFunc(System.IntPtr hHandle);
して、Handleプロパティから渡していたので、、
替わりにSafeWaitHandle使えと言われても、型が違ってこまってました。

[DllImport("native.dll")]
public static extern void NativeFunc(SafeWaitHandle hHandle);
こうすればいいんですね。
0316デフォルトの名無しさん2007/09/04(火) 12:42:53
デンジャラスなんてついてるメソッド使いたくないお
0317デフォルトの名無しさん2007/09/04(火) 13:35:00
IntPtrで問題が発生したら泣き寝入りするお
0318デフォルトの名無しさん2007/09/04(火) 18:41:40
>>316-317
正直、「ボキュはキモヲタだお」って言ってるようにしか聞こえない。
そういうの気色悪いと思わない自分を気色わるいと感じるべきだ。
0319デフォルトの名無しさん2007/09/04(火) 18:48:43
どうか、次のVBをC#に直して下さい。

Label1.Text = Replace(Session("body"), vbCrLf, "<br />")

-----------------------------------------------
VBの本の中にソースが載っていたのですが、
この１文が、どうにもわかりません。

そのコード意味は、どうやらセッションというデーター内の改行を
HTMLの改行に変換するっぽいのですが・・・。（推測）

ちなみに、他の行は自力で調べましたが肝心のこのコードが分りませんし、
C#でどう書けば良いのか分りません。

賢者の方々、どうか愚者の私にご指導をお願い申し上げます
0320デフォルトの名無しさん2007/09/04(火) 18:54:20
>>319
少しはググるとか努力しろよ

VB.NET固有の関数をC#で使用するには？
http://www.atmarkit.co.jp/fdotnet/dotnettips/254vbfunc/vbfunc.html

でも、それただの部分文字列の置換でしょ？
String.Replaceか正規表現で代用できるでしょ。
0321デフォルトの名無しさん2007/09/04(火) 18:54:33
>>319
http://zoosir.hp.infoseek.co.jp/tips/string/string03.htm
C#だと省略可能引数(Optional)が無いから、全部書く必要があるらしい。
0322デフォルトの名無しさん2007/09/04(火) 21:35:51
>304
MSDNも普通にフリーとして公開されてなかったか？
0323デフォルトの名無しさん2007/09/04(火) 21:54:39
csc.exeやvbc.exeって開発環境がなくてもインストールされるものなんですか？
C:\windows\Microsoft.NET\framework\以下にあるのでそんな気がしますが。
0324デフォルトの名無しさん2007/09/04(火) 21:57:13
はい。実行時に使用する場合もあるので、全ての環境に含まれています
0325デフォルトの名無しさん2007/09/04(火) 22:03:35
>>324
おお、そうだったんですか。
これで安心してCodeDomが使えます。
0326デフォルトの名無しさん2007/09/04(火) 22:17:14
標準添付はcsc/vbc/jscの三つ、だったかな確か　clは非標準だよね
標準なのにドマイナーなのがひとつ
0327デフォルトの名無しさん2007/09/05(水) 00:09:57
Control.Invoke系のメソッド呼ぶとどっかで内部的にファイナライザが必要になるっぽいな。
ループの中から呼んだりして大丈夫なんだろうか。
何千何万って呼んだらなんか嫌なことになりそうな気がする。
0328デフォルトの名無しさん2007/09/05(水) 00:15:47
ここは散文を書くところではない。
説明調の、他人に意味がちゃんと通じる文章書けよ
0329デフォルトの名無しさん2007/09/05(水) 00:23:22
え、ファイナライザのコストが高いことを説明しろってこと？
それは説明するまでもないと思ったけど。

何が通じてないのかわからん。
Invoke系のメソッドってのはInvoke、BeginInvokeのことだよ
それらを呼んだら内部的に生成されるオブジェクトでファイナライザが呼ばれるっぽいんで嫌だなって話。
0330デフォルトの名無しさん2007/09/05(水) 00:37:10
何をみてそう思ったの？
0331デフォルトの名無しさん2007/09/05(水) 00:38:28
＞何が通じてないのかわからん。
読む側の立場に立って自分の文章推敲できない人間はたいていそうだ。

ついでに、ファイナライザのコスト？
意味がわからない。
デリゲートを処分するコストがそんなかかるのかね？

仮にかかるとして、コストとは「時間当たりのCPUの使用量」のことだと思うが、
どのみちmsのオーダーでInvokeとか不可能だから意味がないだろう。
0332デフォルトの名無しさん2007/09/05(水) 00:39:31
＞それは説明するまでもないと思ったけど。
いったいどんな頻度でControl.Invokeなんかを実行する気だ？
0333デフォルトの名無しさん2007/09/05(水) 00:44:23
>>327
再描画を伴わないControl.Invokeの使い道って
あんまり思いつかないんだけどどうだろ？

経験上、何千何万って単位でControl.Invokeを呼ぶと
再描画コストが恐ろしいことになる。

WinFormsなら1秒間に10回ぐらいの更新でいいんじゃないかね？
まあそれ言い出すとTimerでいいじゃんて話も多いんだけど。
0334デフォルトの名無しさん2007/09/05(水) 00:44:31
>>330
CLR Profilerで見れるよ。

>>331
http://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/jpdndotnet/htm/dotnetgcbasics.asp
この辺でも読んでくれ。
なんでデリゲートが出てくるのかわからんが・・・

>>332
別スレッドでなんかの処理中にUIを更新するために呼んだりしない？
まあ何万は言いすぎかも。
0335デフォルトの名無しさん2007/09/05(水) 01:04:23
>>322
ヘルプから見れるキーワードとか目次がMSDNなんですか？
0336デフォルトの名無しさん2007/09/05(水) 01:05:13
>>334
読んでくれって、どこにもお前さんが主張しているような類のことは書いてないだろw
0337デフォルトの名無しさん2007/09/05(水) 01:10:27
>334 CLR Profilerで見れるよ。
Control.Invokeを使ったらファイナライザが実行されたってこと？EndInvokeしてても？
0338デフォルトの名無しさん2007/09/05(水) 01:13:32
ファイナライザのコストが高い（高くなりうる）ということ自体はわかるが、
Control.Invokeで実行されるというファイナライザを持つオブジェクトが内包するオブジェクトとか。
Control.Invokeを実行する通常の頻度とかから考えて、それが問題になるほどコストが高いとは思えん
ということだよ。

「ファイナライザのコストが高い」という表現自体をそのまま疑ってるんじゃない。
ついでにEndInvokeしたらファイナライザは実行されないんじゃないの？普通に考えて。
と思っただけで、まあこれはプロファイラで確認してそうなってるってんならそうなのかもしれん。
0339デフォルトの名無しさん2007/09/05(水) 01:17:46
>>335
VS2005 Ｅｘｐｒｅｓｓのヘルプに標準で何が入っているかは知らないが、MSDNライブラリはこれ。
ttp://www.microsoft.com/downloads/details.aspx?FamilyID=b8704100-0127-4d88-9b5d-896b9b388313&DisplayLang=ja

2.5Gバイトほどあるから注意してくれ。
0340デフォルトの名無しさん2007/09/05(水) 01:22:22
ファイナライザはそれを行わなければならないものが一つでもあると
GCを二回行わなければならず単純計算でGCにかかる時間が倍になるんじゃなかったか
0341デフォルトの名無しさん2007/09/05(水) 01:27:36
>>337
>>338
EndInvokeしても呼ばれるみたい。
やっぱgen0でちゃちゃっと回収されるから問題が少ないってことなのかな？
具体的にはControl.ThreadMethodEntryってオブジェクトだけど
ファイナライザの処理自体はシンプルだけど他のオブジェクトへの参照は割とごっそり保持してるみたいだな。

まあ他に代替手段があるわけじゃなしどうこういっても仕方ないんだけどね。
0342デフォルトの名無しさん2007/09/05(水) 01:42:58
おお？なんだこの意味なしFinalizeはｗ
いらねーじゃねーかよ。
0343デフォルトの名無しさん2007/09/05(水) 01:48:44
＞他のオブジェクトへの参照は割とごっそり保持してるみたいだな。
そんなに困らないオブジェクトが多いけどな。
まあ引数とか戻り値はクリアしてほしいところだが
0344デフォルトの名無しさん2007/09/05(水) 01:58:26
だいたい、GEN1までで回収できたら、負荷的にはまあそんなに大きくはならないようだな。
GUIアプリだし、特にControl.Invokeなんて同期実行なんだから、まあ普通はまずGEN1ですべて回収できるだろう。
0345デフォルトの名無しさん2007/09/05(水) 02:05:06
SuppressFinalizeを書き忘れてるんじゃないか
03463192007/09/05(水) 11:20:12
>>321賢者
一応、下記ソースに変更出来ました。
的確な助言、ありがとうございました。

if ((string)(Session["Body"]) == null)
{
　　Label1.Text = "<br />";
} else {
　　Label1.Text = ((string)(Session["Body"])).Replace("\r\n", "<br />");
}
0347デフォルトの名無しさん2007/09/05(水) 11:24:43
暇があったら as 演算子を調べとくといいよ
03483192007/09/05(水) 11:45:52
>>347 神へ

ご助言の通り、as演算子をしらべました。
お陰でたまに出るエラーがなくなりました。
さすがは神ですね。
即レスにも関わらず、１００％的中でした。

なぜ、私がたまに出る意味が理解できないエラーで苦労している所を
お察し出来たのか愚民にはわかりませんが、
貴方の英知で、救われました。
再びお礼を申し上げます。

string s = (string)(Session["Body"]) as string;
if (s == null)
{
　　Label1.Text = "<br />";
} else {
　　Label1.Text = ((string)(Session["Body"])).Replace("\r\n", "<br />");
}
03493192007/09/05(水) 12:08:38
※すみません。下記に訂正しました。

string s = (string)(Session["Body"]) as string;
if (s == null)
{
　　LabelBody.Text = "<br />";
} else {
　　LabelBody.Text = s.Replace("\r\n", "<br />") + "<br />";
}
0350デフォルトの名無しさん2007/09/05(水) 12:18:23
まだキャストしてんじゃん。

string s = Session["Body"] as string;

じゃないとエラーでるっしょ
03513192007/09/05(水) 12:22:14
>>350
いいえ。
今の所、何もエラーがでませんが？

でも、助言ありがとう。
0352デフォルトの名無しさん2007/09/05(水) 12:39:14
>351
エラーは出ないけど
string m = ((string)"Hello")

とはやらないだろって事じゃない？
■ このスレッドは過去ログ倉庫に格納されています