ふらっとC#,C♯,C＃（初心者用） Part92

1 ：2012/04/26 〜 最終レス ：2013/03/30

ふらっとVisual C#,C♯,C＃（初心者用）
このスレッドは
「どんなにくだらないC#プログラミングやVisual C#の使い方に関する質問でも誰かが優しくレスをしてくれるスレッド」です。
ほかのスレッドでは恐ろしくて書き込めないような低レベル、もしくは質問者自身なんだか意味がよく分からない質問、
ググろうにもキーワードが分からない場合など、勇気をもって書き込んでください。
内容に応じて、他スレ・他板へ行くことを勧められる、あるいは誘導される場合がありますがご了承下さい。
なお、テンプレ2行目が読めない回答者は邪魔なので後述のC#相談室に移動して下さい。
>>980を踏んだ人は新スレを建てて下さい。
>>980が無理な場合、話し合って新スレを建てる人を決めて下さい。
関連スレ
ふらっとC#,C♯,C＃（初心者用） Part91
http://toro.2ch.net/test/read.cgi/tech/1335089085/
C#, C♯, C＃相談室 Part71
http://toro.2ch.net/test/read.cgi/tech/1332575004/

こんな感じでソフトウェア板に立てたらどうかな

2 ：

─ここは、プログラム板における同名スレにおいて、
　 IDが付与されないがため生じる定期的な荒れ進行を度々経験し、
　 疲れてしまった同スレの住人が、透明あぼーんの活用でまったりと
　 本来のスレの目的を果たし続けるために設けられた、
　 一種の避難所です。

3 ：

ム板開いたのかと思ったわ
避難所part1で良かったんじゃね？

4 ：

>>3
感情的になった出て行け論者が立てたスレなので、
スレタイ名がメチャクチャになってしまったんだ。すまない。

5 ：

荒れ気味の板がIDなしだと大抵ろくな事にならないのは分かるが、この板でする話なのか

6 ：

ム板から逃れる先として、ソフトウェア板以外に何かあるかな？

7 ：

ム板でやれ

8 ：

>>7
巣に帰れってことだな。言い返す言葉もないよ。
だが、避難所を同じ板に作ってもしょうがないからな。

9 ：

荒れてる時はこっちに誘導したらいいんじゃないかな

10 ：

まあ、あっちに来た質問を無理にこっちに誘導する気はあんまり無いんだ。
向こうでも書いたけど、あっちのスレが回答不能なレベルに達してるってわけじゃないし。
むしろ、「IDがあった方が議論しやすい」と感じた人間だけが、こっちで議論すれば良いと思ってる。

11 ：

こっちを擁護しておいてなんだが、これで本スレのテンプレに
こっちのスレを追加すべき/すべきでない議論とか巻き起こるのは嫌だなあ。
テンプレ周りの変更議論はもめるし。
もめるくらいなら追加したくない。

12 ：

問題は回答者がここにくるかだな

13 ：

俺が一番回答してるから俺がいれば大概大丈夫だろう

14 ：

>>12
俺も一応回答者。どんくらい回答したかまでは覚えてないけど。

15 ：

じゃあ、ちょっと質問
インターフェイス使うと改変に強いっていうけどプロパティとどう違うの？
プロパティも内部の構造変えても他のクラスに影響がない
影響が出るとしたら、プロパティの型を変更した場合
インターフェイスも引数の型変更したら結局使いものにならないし
改変に強いって説明の仕方おかしくない？
内部の違うクラスを同じようにアクセスできるのを明示するということならわかるけどね

16 ：

クラスというのは、実体を作れる型。
インターフェースとしいうのは、実体を作れない型。

17 ：

「改変に強い」のは、インターフェイス自体の改変ではないよ。
改変に強い、って説明自体確かに誤解を招く表現で、
実際は「内部実装を気にしなくて良い」が正解だと思う。
インターフェイスとはちと違うけど、Streamなんかその最たるものじゃない。
Stream自体が何をソースにどうやって実現されているかは気にしなくてよくて、
処理する側はStreamクラスのオブジェクトに対して必要な処理（メッセージ）を要求すればいい。
インターフェイスを定義する、ってのはそれだけのことでしかない。
「Hoge(FileStream stream)」って定義したメソッドより、「Hoge(Stream stream)」って定義されたメソッドの方が、
汎用的に使えるじゃない。

18 ：

改変に強いっていうのはどうなんだろうな
個人的には別に強くないと思うが
interfaceごしだと実装クラスを入れ替えられるけど
改変前と改変後の2つの似たようなクラスを両方保持して
interface越しにどっちを使ってるか分からなくするなんて考えただけでゾッとする
一つの具体クラスをただ書き換えるほうがずっといい
だから改変に強いと言うよりは
ライブラリを作る側が使う側に処理を実装してもらう時に使うものだと思うよ
IComparableを実装してもらってSortメソッドで使う比較関数に利用したり
まあC#3.0からラムダ式が使えるからそういう用途はもうほとんどお役御免だけどね
interface自体ほとんどお役御免といっていいと思う
ライブラリに残ってれば使うけど自作する意味は殆ど無い

19 ：

ム板って取扱いと人種的に宗教戦争余裕なのに未だにIDないのか

20 ：

インターフェースは、お役御免には、ならないと思うがな。

21 ：

interface I{ int Hoge(); string Hoge2(); }
こんなのを作るより
class C{ public Action Hoge; public Func<string> Hoge2; } こんなのを作って
new C{ Hoge = () =>{ ... }, Hoge2 = () => "hogehoge" }
こうしたほうが早いしわかりやすいし個別に設定できて汎用性も上だから
もうinterfaceを作る意味は無いはず

22 ：

例えば、UnityやXNAやDxLibなどを同じように扱えるようにするにはどうするべき？
ゲーム本体部分とライブラリとの丁度境界線上にあるクラスはどのように定義すべき？

23 ：

お役ご免ってのは言い過ぎでしょう。後々機能追加が考えられる場合、
その機能追加に耐える様Interfaceを定義するコトなんて、（自分は）ザラにありますよ。
たとえば、画像ファイルに対して順次いろんな処理をするようなソフトを作ったとき、
最初はjpgとbmpしか対応しないでおいて、いずれpngとかtiffもやりたいなあ、と思った場合、
interface ImageProcessor { ... }
class JpegImageProcessor { ... }
class BmpImageProcessor { ... }
なんて。
処理自体が短ければ>>18の言うとおり、ラムダ式で十分なんだけど、
色んな段階を踏む処理の場合、処理自体をクラス化しちゃう方が後々追加し易い。
>2つの似たようなクラスを両方保持して〜一つの具体クラスをただ書き換えるほうがずっといい
っていうような懸念がある場合は、interfaceじゃなくて抽象クラスでやればいいし。
共通部分は抽象クラスで処理して、後々追加したい機能毎に変わりうる部分は具象クラスに任せて抽象メソッドを定義だけしておく、とか。

24 ：

>>23
もっともですねぇ

25 ：

>>23
これだと違いはファイル読み込んでビットマップ作る
ビットマップをファイルに書き出す
ところが違うだけじゃないの
具体的なクラス一個作って
public Image(Pixel[][] bitmap)
こんなコンストラクタにして
new Image(JpegLoader.Load(file))
new Image(BmpLoader.Load(file))
書きだす時は
JpegWriter.Write(image.Pixels);
BmpWriter.Write(image.Pixels);
こんなもんでよくね

26 ：

まあ、オブジェクト指向を完全に理解して常に完璧な形で実現出来てる、
なんて境地には到底達せないと思うので、今の自分の実装が正しいとも言い切れないんですけど。
Rxとか見てると、ラムダ式で全部・・・なんてのも決して非現実的ではないと感じるし、
「一つ一つの処理は短く」という基礎的なことを突き詰めていけば、
そういうこともきっとできるんだろうなあ、とは思う。
ただ、それでもinterface自体が無くなる可能性は低いだろうな。
俺は逆に、Rxが駆逐しようとしているのは開発者がclassを定義する、
という行為じゃないかと感じる。

27 ：

変数名につける英単語がわからなくて悩みまくる

28 ：

>>25
それだと、あっちこっちで処理対象がJpegなのかBmpなのか判定しなきゃいけなくなるでしょう。
処理が読み込みと保存だけでいいなら、2箇所ぽっきりだしそれもありだと思いますけど。
Classとインターフェース作っちゃえば、インターフェースを介して処理してる本体側は大きな変更することなく、
一番アタマで対象の判定だけやって、クラスの実態をnewした後は同じ処理を続けるだけ、で行ける。

29 ：

極端に汎化するなら、こういうインターフェースを作るかな
interface ImageProcessor {
　　/// <summary>指定されたファイルがサポートされているかどうかを判定します。</summary>
　　bool Supported(string fileName);
　　/// <summary>指定されたファイルを読み込んで、オブジェクトを初期化します。</summary>
　　void Load(string fileName);
　　〜
}
本体側は
AssemblyからImageProcessorを継承してるクラスを全部引っ張ってきておいて、
private static readonl List<T> processors;
private ImageProcessor processor=null;
private Load (string fileName){
　foreach (var p in processors){
　　if (p.Supported(fileName)){
　　　processor=p;
　　　break;
　　}
　}
　if (processor==null) throw new NotSupportedException(string.Format("{0}は未対応のファイル形式です", fileName));
　processor.Load(fileName);
}
みたいな。こうすれば、処理本体側は変更なしで対応形式の追加が出来るだろうし。

30 ：

まあ別にいいんだけどねこれでも
public Image(Func<Pixel[][]> reader, Action<Pixel[][]> writer)
public void Load()
{
　Pixels = reader();
}
public void Save()
{
　writer(Pixels);
}
これでinterfaceと大体同等だけど最初に入れてから入れ替えができなくて無意味に汎用性が下がるし
呼び出し側もメソッドの中で何が起こるのか分からなくなってソースがわかりにくくなるんで
必要がなければ避けるべき形だよね
public void Save(Action<Pixel[][]> writer)
{
　...　
}
処理の汎用化が必要でも、こんな風にライブラリ側だって必要なときに必要な物だけ渡してくれた方がわかりやすいし使う側も使いやすい
interfaceを使うと呼び出す場所(たとえばSaveを実際に呼び出すところ)とそれが定義されてる場所(Save処理を実装したクラス)が離れちゃうからわかりにくくなる
なにより「interfaceにそのメソッドが必要かどうか」という難しい判断をする必要がなくなるから問題がすごく簡単になる

31 ：

まあ、やりたいことにあった方を選べば良いんじゃないかな。
実際、その二つの方法を提供しているライブラリも多いよ。
俺もそういうやり方することあるし。処理が端的に済む場合なんかは特に。
で、じゃあどっちかしか使わないか、っていうと、時と場合に依った。
どっちでも実現できる場合もあれば、どっちかじゃないとどうにもならん、とか
一方のやり方だとやたら遠回りなやり方になる、とか色々あったさ。
ライブラリを公開する、って観点で言うと、>>30みたいなやり方の方が使いやすいだろうな。多分。
実際、interfaceを定義する、っていう手間はあれで結構大変だし、ホントやりやすい方でやればいいと思うよ。

32 ：

ただ、制限がクリアできるならabstractの方が便利だけどね
interfaceで同一視したいクラスって、共通の処理がある程度有るし

33 ：

（　・ω・）ｙ─┛〜〜

34 ：

まあ実際、interfaceとabstract classどっちが多いかっつったら、
今まで書いてきたような目的下だと、abstract classの方が多いな。

35 ：

>>22
ゲームで必要な機能だけを、ある程度そのゲームに特化した形で抽象メンバにする
間違っても汎用的なライブラリを作ろうなどと考えてはいけない

36 ：

落ちた？

37 ：

そんな早くdat落ちするのかこの板

38 ：

しないね。サーセン誤爆だ。

39 ：

基本プログラミングっていうのは自分でライブラリを書いて自分で使うことの繰り返しだからな
汎用性が高く使いやすいライブラリを書いていくと良いプログラムになる
使いにくく汎用性が低いライブラリを作るとソースがなんだかわからなくなったり仕様変更できなくなったりする

40 ：

最初はそれも上手く行かなくて辛いけどな。試行錯誤を繰り返していく内に、
どうすれば汎用性が上がるかが分かってきて楽しい。

41 ：

さんざ苦労してライブラリ作っても、意外と使わなかったりするな
使わずに温存してるうちに陳腐化したり、もっといいライブラリが登場したり…

42 ：

今必要じゃないライブラリ作ってもしょうがないよな
テストもろくに出来ないだろうし

43 ：

それあるよな。必要な物書いていったらいつのまにかライブラリになってたってのが理想的。

44 ：

もはやライブラリを作るほうが本来の目的になってる時、あるよねw

45 ：

作りたいツールを思いつく→ツールに必要なパーツを作る
→そこで満足する、または飽きる

46 ：

そこが楽しさだからなぁ
完成が見えた時点でやる気が無くなる

47 ：

デバッグが一番大変だわ
コード書いてる時は楽しいんだけど
バグを出すために色々やってみるとかキツい
自分が使うツールじゃなかったらまず無理

48 ：

>>44-47
よう、おれ

49 ：

前スレ埋まったw
ここに移動すんのか？

50 ：

おかしい・・・みんなどこに行ったんだ

51 ：

まあム板には相談室があるからふらっとがこっちにあっても
最悪質問者が誰もここまでこれなくて潰れても大して問題はないんだよな

52 ：

じゃちっと立てれるか試してくるわ

53 ：

あっ・・・ソフトウェア板様に、って貼られたテンプレをつかっちまった
スレタイ・・・すまない。

54 ：

ふらっとVisual C#,C♯,C＃（初心者用） Part92
http://toro.2ch.net/test/read.cgi/tech/1335703825/

55 ：

なんだかよくわからないことになってきたな・・・
どっちに来ても質問が来たら答えるだけだけど

56 ：

VC#のデザインでコピーして貼り付けた時、Nameプロパティをコピー元に似せる方法ってないですか？
input_data_Box1ならinput_data_Box2とかinput_data_Box1(1)とかになってほしいです・・・

57 ：

継承するかユーザーコントロールにしてInput_data_Boxっていうクラス名にしたらいいんじゃないの

58 ：

ありがとうございます
特に付加する機能のない継承をやるくらいしかないんですね

59 ：

多少手間だからユーザーコントロール作るか・・・！

60 ：

俺はなにもかもユーザーコントロールにしてる
1クラスに配置するコントロールは4つぐらいまで
超えたらユーザーコントロールにまとめる

61 ：

ユーザーコントロールって再利用性が全くないよね

62 ：

>>61
んなことないでしょ
よく出てくる複数のコントロールの組もあるし(追加、削除ボタンの付いたリストとか)
WinFormは継承しなくても基本全部いじれるようになってるから
単一のコントロールでもDock.Fillしてユーザーコントロールのなかで機能追加したりも出来るし

63 ：

>>62
俺は、コントロールのプロパティをバインドさせたりすることがよくあるから、
INotifyPropertyChangedインターフェースを実装したUserControlの派生クラスを作ってる。
他にも共通機能とかをまとめておけば、いちいち実装し直す必要ないし、便利。

64 ：

>>61
まあ、変な基準でまとめると全く無くなる。
でもたとえば、ファイルパスを入力するテキストボックスと、参照ボタンのセットとか、
意外とよく使う組み合わせ、ってのは多いからな。
>>60のいう4つくらいまで、っていうのは何だか凄いな、と思うけど。
レイアウト系のパネル配置し出すと、4つなんて容易に越えてしまいそうなもんだが・・・

65 ：

×パネル
○コンテナ

66 ：

荒らしの人は相談室に行ったみたいだな

67 ：

全部作り終わってから、ちまちまとライブラリに落としこんで行ったら動かなくなった。元に戻しても動かない(´・ω・｀)

68 ：

>>66
素人考えの眩暈のするような間違った内容だけど、自分の考えを書いてはいるんで別の人かな。
JITの話が出てたんで関連Tips
・JITとインタプリタは違う
・JIT結果はAppDomainをまたいで共有される
・Assemblyにする段階で構文解析終わって中間コードになってるためJITは高速
・コールドスタートアップだとJITコンパイラの読み込みに時間がかかる
・全部NGENしとけばJITコンパイラの読み込み自体がスキップされる
・JITさせたくないならNGENしときましょう

69 ：

>>67
動かなくなるようなライブラリの落とし込み方ってどうやるんだ・・・
クラス単位で名前空間移して別DLLにするだけだろ？
アプリ側で随時using追加すれば動かなくなることなんてないだろ・・・

70 ：

いまさらだがテンプレ抜けていたので

■備考
コードの量が多い場合は下記サイトを使うなどしたほうがいいかも
http://ideone.com/
http://pastebin.com/
コードを貼り付けてrun codeのチェックをはずしてsubmitボタンを押すと
コードを鯖側にアップして専用のアドレスが発行されます

71 ：

複数のテキストボックスを入れたコントロールを用意し、
テキストボックスのTextプロパティ等をコントロールのプロパティで変更できるようソースに追記しました
（デザイナーで初期値を変更すること、プログラム上で参照することが目的）
デザイナーで初期値を変更することはできたのですが、プログラム上で参照することができません
using ディレクティブまたはアセンブリ参照が不足しています。
とエラーが出ます
検索するとNamespaceを追記すると良いと出てくるのですが、コントロールと本体のNamespaceは同じで、
最初から付いているコントロールのTagプロパティは参照できます
Modifierをprivateからpublicに変えたりもしたのですが、駄目でした
ソースは次レスで書きます

72 ：

//○プロパティの追加（1例）
public string Text_Box_Tag
{
set
{
input_tag_Box.Text = value;
}
get
{
return input_tag_Box.Text;
}
}
//○本体
//Tagの代入
foreach (Control item in Text_input_group.Controls)//コントロールはText_input_group内に配置しています
{
if (item.GetType().Equals(typeof(Control)))
{
int a=(int)item.Tag;//元からコントロールにあるTagプロパティは取得できます　中身は0〜です
Tag[a]=item.Text_Box_Tag;//追加したプロパティ　エラー
Key1[a]=item.Text_Box_Key1;//追加したプロパティ　エラー
Key2[a] = item.Text_Box_Key2;//追加したプロパティ　エラー
Data[a] = item.Text_Box_Data;//追加したプロパティ　エラー
}
}
処理が足りていないのでしょうか？
へ、ヘルプ・ミー

73 ：

一例、でわかるかよ。
そのプロパティの中に原因があるんだろ。

74 ：

ン？違うな。なんだこのソース。
そもそもコンパイルできねえじゃん。

75 ：

プロパティを追加したとかいうクラスの名前はなんだかしらないが、
そのクラスでキャストしなきゃそのプロパティにアクセスできるわけないだろう。

76 ：

複数のテキストボックスを入れたコントロールのクラス名をTextBoxesControlとすると
if (item.GetType().Equals(typeof(TextBoxesControl)))
{
//ちゃんとTextBoxesControlにキャストする
TextBoxesControl boxes = (TextBoxesControl)item;
int a=(int)boxes.Tag;//元からコントロールにあるTagプロパティは取得できます　中身は0〜です
Tag[a]=boxes.Text_Box_Tag;
Key1[a]=boxes.Text_Box_Key1;
}
みたいなかんじでキャストすると、追加したプロパティにアクセスできるよ
Controlのままでは追加したプロパティにはアクセス出来ない

77 ：

エラー、ってコンパイルエラーのことだったのね。浅はかな回答して済まん。

78 ：

>>76
なるほど
クラス名でキャストしてあげる必要があるんですね
無事コンパイルが通りました
ありがとうございました
>>77
いえ、私の説明不足ですみません

79 ：

本スレはいよいよ崩壊しているな・・・
回答がままならない

80 ：

初心者の質問に初心者が答える正に初心者用スレッド

81 ：

あの状態で答えられるエスパーは確かにあのスレにはおらんな。
たまにエスパーのいるスレがあるけど、ああいうエスパー達はどういう次元にいるのか理解が及ばない。

82 ：

あれはIDの必要性を分からせるための自作自演に違いない

83 ：

ふと思えば、そもそも、あのプログラムでxcopyを使う必要はあったんだろうか・・・

84 ：

>>77
コンパイルエラーと言えば、今作っている奴がコンパイル完と共にVSがエラーで落ちるorz
その後再起動すると普通に動くんだが、修正するとコンパイル後に落ちる
どっかのシンボル名が問題起こしているっぽいのだが情報有ったら教えて貰えませんかね？

85 ：

マイクロソフトのサポートに電話すれば

86 ：

TextRenderer.MeasureText のオーバーロードの一つ
public static Size MeasureText(
　IDeviceContext dc,
　string text,
　Font font,
　Size proposedSize,
　TextFormatFlags flags )

proposedSizeの意味がさっぱりわからないんですが
誰かバカな私に噛み砕いて教えて下さいませんか？
ちなみにバストは86cmです
MSDNにはこうありますが……
When measuring text on a single line, if the proposedSize parameter represents a Size with a height dimension greater than Int32.MaxValue , the returned Size will be adjusted to reflect the actual height of the text.
1 行のテキストを計測したときに proposedSize パラメータが Int32.MaxValue より大きい高さを持つ Size を表している場合、返される Size が調整されて、実際のテキストの高さが反映されます。

87 ：

>proposedSize パラメータが Int32.MaxValue より大きい高さを持つ Size を表している場合
ここんところが意味不で困ってます
Size.HeightはintですからInt32.MaxValueより大きいってどゆこと？

88 ：

MaxValueより大きい・・・・ジャスコだな

89 ：

MaxValueって31bit+符号で表現できる最大ってことじゃなかったっけ？
ファイル長なんかだとLongも一緒につかえるよね

90 ：

見た感じproposedSizeに収まるテキストの最大のサイズを返すんじゃないか
MSDNがバグってるんだろう

91 ：

DataGridViewのFillの挙動が気にくわない。
「表示幅が余ったときはFill、それ以外の時はAllCells(ExceptHeader)」みたいな挙動をさせたい場合、
DataGridViewの継承クラスで容易に実装できないもんかな・・・
FillWeightとの絡みとか考えたら大変そうっちゃ大変そうなんだけど、
元々のFillの挙動（表示幅が不足すると、見切れてしまうしサイズの変更も出来ないしで詰む）が頭悪すぎて
どうにもこうにも。

92 ：

protected virtual CalculateColumnSizeCode とかそういうメソッドが隠れてねえかなあ、と
探したけど、それっぽいの無いんだよね・・・。

93 ：

×Code
○Core

94 ：

知らんけど一個一個MeasureTextして入るかどうか調べればいいんじゃねえの？

95 ：

相談室荒れてるな
韓国コピペも相談室言ったか

96 ：

失礼します。改行コードについての質問です。
改行1つをRead()で読み込むと10進で1310が返ってくるのですが、
これはCR(10進で13)とLF(10進で10)をまとめて1文字として読んでいるという認識でいいのでしょうか。
だとすると、CR+LFと\u051E（16進51Eは10進で1310）とはどう区別して判定するのでしょうか。
（\u051Eなんてめったに使うものではないでしょうが。）
もうひとつ、int型の1310をString.Format(string, Object)で16進変換すると"DA"が返ってます。
1310を分割して13->"D",10->"A"としているのだと思いますが、
これはどういうロジックでこうなるのでしょうか。なぜ"51E"ではないのでしょうか。
よろしくお願いします。

97 ：

CRが13,LFが10の2文字でしょ
2文字をいっぺんに読んで、何かよくわからない過程を経て1310に到達してるんだろうと思うけど
http://ideone.com/FlooQ
1310は16進数だと51Eになるみたいだよ

98 ：

自己解決しました。一度のつもりの処理を二度行っていただけでした。
こんなことで小一時間悩んでいたなんて・・・

99 ：

文字コードの制御コードはすべてアスキーコード互換じゃないかな？
http://e-words.jp/p/r-ascii.html

100read 1read

1read 100read
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲

Adobe ソフトウェア総合★5 (201)
Twitterクライアント「Tween」総合 Part.3 (290)
Google Chrome 59プロセス (267)
+++ ファイラーを語ろう Part27 --- (404)
【PSVita】 2chSharp 【Android】 (298)
Twitterクライアント kurotwi Part1 (255)
--log9.info------------------
五輪柔道代表暴力問題 (313)
少林寺拳士の技の効果・威力は証明されていない (552)
【弱い】 何で少林寺は総合に出ないんだ【怖い】 (599)
JKJOを語りましょう (220)
東京で評判の良いキックジムを書き込むスレ (569)
【燃えよ】ヌンチャク・スレ５【ドラゴン】 (623)
居合って剣道と違って実戦じゃ役に立たないよな (287)
【路上の喧嘩に】大道塾空道【最適だぜぇ〜】 (285)
★(☆∀☆)少林寺の剛法を語る　�\ (226)
★英武館　松本英樹を語ろう★3 (475)
英国少林寺拳法連盟、脱退を宣言 (644)
日本拳法はなぜ分裂したのか (812)
ボクシングのスレ (314)
【CAPOEIRA】カポエラを語ろう13【ｶﾎﾟｴｲﾗ】 (711)
【暗殺君】素肌剣法や剣道はスポーツだ【専用】 (588)
【マット】もぎゅ康子＆女性柔術家【エンジェル】 (295)
--log55.com------------------
チラシの裏＠同人板1356枚目
【訃報】黄泉ケット【追悼】
まさかなーテストスレっ
アニメーター本スレ55
北海道の同人＆イベント事情 その29
【イチタナ信者】イチタナ厨専用タナイチアンチスレ改二甲【タナオカ御用達】
【艦これ信者】艦これ厨専用アズレンアンチスレ悔惨【ネトウヨ老害提督御用達】 Part.3
大手サークル情報交換スレ255