MFC、Win32++を超えるライブラリを作るスレ

1 ：2010/10/09 〜 最終レス ：2012/11/07

一緒にMFC風のクラスライブラリを作りましょう。
今、ここまで作りました。
http://www.geocities.jp/katayama_hirofumi_mz/mzc.zip

2 ：

マジで聞くけどタダのラッパーならもう十分だろ？
何でイマサラ？

3 ：

どんな面で超えるのかも明確にしないと。

4 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

5 ：

1>リンコしています...

6 ：

どうせ作るなら少なくともUnix系/Mac/Win対応のクロスプラットフォームで。

7 ：

こんなんだったら、WTLで十分だと思う。Win32++は知らないんでノーコメント。

8 ：

自分のツッコミどころ自体がツッコミどころ満載って感じがする。
mzc.cpp
FormatV→_vscprintfとvsprintfに丸投げしろ。
TrimLeft/TrimRight→boost::algorithm::trim_rightあたりで十分。
そもそもCString要らん。std::basic_stringでいいよ。MFCと全く同じもの作るつもりではないんだろ、な？
mzc.h
ASSERT_POINTER周りでIsBadXxxPtr使っているけど、
そんな使わってもしょうもないって中の人も言っている。
http://blogs.msdn.com/b/oldnewthing/archive/2006/09/27/773741.aspx
今時CObjectとかやめてくれ。そんな共通基底クラスなんて百害あって一利なしなのがC++なんだから。
（まさにそのCStringみたいにCObjectを継承しないクラスがいくらでも作れるし、
intとか組込型も平等に扱いたいとなると共通基底クラスなんて一瞬で破綻する）
CString、コピー構築・コピー代入ありのクラスでswapないのはいただけない。
あと、CStringTクラステンプレート作ってCStringA/CStringW用意している最近のMFCを見習え。
AllocSysStringとかBSTRもクラス化しろよ。そこMFCに似せなくていいから。

9 ：

mzc.inl
swap無いことから想像どおりコピー代入は強い例外安全になっていない。
参照カウントなんかshared_ptrに任せましょうね。
mzcmsg_.h
ON_ナンチャラは言うことない、MFCっぽいって言ったらこうなるよなあって感じ。
ON_WM_XXXでコールバック関数名なのは若干気になる。それと、まだ品揃えが足りない感じがする。
あと、GET_X_LPARAM/GET_Y_LPARAMとか使ってやってください。
mzcsync.h
コンストラクタでLock→デストラクタでUnlockする補助クラス欲しい。ただ、それ含めWinSTLで事足りるからなあ。
文字列引数を取るCCriticalSectionコンストラクタは非デバッグ時にも定義しろよ（中身は空でもいいから）。
CCriticalSection x(TEXT("Hoge"));って同じコードを使い回せないよ。
あと、InitializeCriticalSectionAndSpinCount呼ぶコンストラクタも作るべき。
InitializeCriticalSectionと違って、エラーか否かを戻り値で返す優れ物。Windows 2000ですら使える。

10 ：

mzcwin.cpp
えー、またCXxxクラスオブジェクトを生ポインタで持つの。だから、そこMFC真似なくていいって。
CBitmap::SaveBitmapToFile
うーん、DDBをファイルに書き出すのは少々やり過ぎに思う。せめて、CreateCompatibleBitmapしたときのDCでGetDIBitsしたい。
常にモニタ対象のDCってわけでもないんだし。たしかに、大抵の場合はそれで困らないだろうけど。
CDC::PlayMetaFile Windows APIのPlayMetaFileでダメな理由のコメント書いて。
MzcWindowProc/MzcSubclassWndProc せめてCWndの静的メンバ関数だろ。privateに隠せ。
あと、複数のスレッドでウィンドウ作る設計だったら、mapに排他制御要るよね（map使う実装の是非は置いておいて）。
MzcModalDialogProc/MzcDialogProc 戻り値INT_PTR型だろ
mzcwin.h
GDI/メニュー関係はスルー。
CWndのGetWindowとかGetActiveWindowとかCWndコピー返しで本当にいいのか？
CWndの派生クラスCMyWndを定義、CMyWndオブジェクトを作ってCreate(Ex)した。
そいつがたまたまアクティブウィンドウだったら、こんな風にGetActiveWindowから再びCMyWndを取り出せるようにしたい。
CMyWnd* w = dynamic_cast<CMyWnd*>(CWnd::GetActiveWindow());
あ、もちろんこれは例だから、実際こんな生ポインタむき出しは勘弁してくれ。

11 ：

VCLを知らぬとな

12 ：

そうだ、mzc.hのMzcIsXPThemedでLoadLibraryしているけど、
LoadLibraryは絶対パス指定しておけ。
偽物のDLLを読み込む脆弱性が話題になったばっかり。
http://slashdot.jp/security/article.pl?sid=10/08/23/072200
LoadLibraryで絶対パスを指定しなくていいのはSxS DLLの場合だけ。
http://d.hatena.ne.jp/NyaRuRu/20040931

13 ：

この板は>>1の日記スレなのか？
まあどうでもいいが、MFCはともかくとして、
Win32++では何が問題で、このMZCは何を解決する方針なんだ？
まずはそれから始めろや>>1

14 ：

>>2 ただのラッパーでいいのがありますか？
>>3 Rebarが簡単に扱えて、ツールバーやダイアログバーの取り外しができるような。。。
>>6 それは私の専門外です。
>>7 WTLを使うにはATLが必要じゃなかった？
>>8 修正しました。
basic_stringは書き込み可能なバッファとして使えないから、
あまり好きじゃない。
>>9 WinSTLって初めて聞いた。使ってみることにする。
> コンストラクタでLock→デストラクタでUnlockする補助クラス欲しい。
検討中。

15 ：

>>10
>えー、またCXxxクラスオブジェクトを生ポインタで持つの。
mzcwin.cppのどのあたりのコードのことですか？
>CWndコピー返しで本当にいいのか？
アップキャストはできたほうがいいですね。
やっぱりポインタの方がいいのかな。。。
ハンドルむき出しだと、
コンストラクタでメンバーが初期化できないからだめか。
コンストラクタの代わりのものを用意するか（FromHandleとか）？
検討中。
Version 0.0.1になりました。全然できていない。

16 ：

HandleMapについてはMFC方式がベストと判断しました。
CWnd::FromHandleを実装したいと思います。

17 ：

>>14
今度のC++の規格改定で、basic_stringの要素が連続する保証がつく。
そのため、こんなコードも合法になる。
std::basic_string<TCHAR> s;
s.resize(MAX_PATH);
DWORD length = GetTempPath(MAX_PATH, &s[0]); // エラー処理省略
s.resize(length);
まあ、それを根拠に今までのC++ライブラリの実装でそんなことやっていいのか、と言う点は意見の割れるとこだろう。
一応、どいつもこいつもこんなコード動くような実装にはなっているけど。

18 ：

コンパイラは何をどのバージョンからサポートすんの

19 ：

VC++しか眼中にないライブラリ
日本語がまともに通らないライブラリ
なんだかんだでWinAPIなみにグチャグチャになるライブラリ
そんなものならいくらでもある
gccで安心して利用でき、日本語がごく普通に通り、見通しのいいライブラリはあまりない
そんなGUIライブラリがあるなら喜んで利用させていただくよ

20 ：

あー、確かにg++で使えるのは魅力的だなあ。
あとなんでDT_METAFILEのときだけPlayMetaFileなの？
と思ったが、MFCもWTLもそうしているのかー。
DisableThreadLibraryCallsはDLL_PROCESS_ATTACHのときに呼ぶんだぞ。
ただ、コンストラクタ・デストラクタの呼び出しが絡むから、
C++では本当に使って大丈夫かよく調べておいた方がいい気がする。

21 ：

あと、拡張メタファイルを描画する関数も用意してよ。
Win32ではただのメタファイルなんて過去との互換のためでしかないから、めったに使わないよ。

22 ：

バージョンアップ! 0.0.3
>18 BCC55、MinGW、VC++6はサポートしたいと考えています。
>20 修正しました。
>21 拡張メタファイルをサポートしました。

23 ：

BCC5.5もサポートするなら早めに検証やっといたほうがいいぞ
あれはいろいろ面倒くさい

24 ：

車輪の再発明

25 ：

バージョンアップ0.0.4

26 ：

それよりOSASKかMONAOSのSATAドライバ作ってよ
AHCI対応で

27 ：

MFCってIDE前提っぽいとこあってエディタ上で書くにはめんどすぎる上に
結局Win32API併用しないと役に立たない
クロスプラットフォームなんて夢のまた夢
いっそもっと抽象化してAWTみたいなのに徐々に発展していって欲しい
そしたらマジ使いたいです…

28 ：

Object Windows Library
Inprise/Borland
http://cc.codegear.com/partners/bcb5/exclusive/object_windows_library/index.html
This release of the Object Windows Library is based on the OWL 5.4
release and is denoted as OWL 5.5.
It has been ported to Borland C++Builder 5 by Yura Bidus, author of OWLNExt.
It includes source code and debug and release libraries of, OWL, BIDS and OCF

29 ：

OWLNext project home ~
http://owlnext.sourceforge.net/
~ About OWLNext ~
http://owlnext.sourceforge.net/about.html
Advantages of using OWLNext:
* OWLNext is an object-oriented framework, built on top of the Windows API without adding much overhead.
* OWLNext is pure C++ library, which does not use any vendor- or compiler- specific extensions.
* OWLNext fully supports developing Unicode applications.
* OLE, OCX and ActiveX support (server and consumer)
* OWLNext can be used with wide range of C++ compilers. Currently it is tested with
o CodeGear Developer Studio 2007 and 2009
o Borland Developer Studio 2006
o Borland C++ Builder 6.0
o Borland Free C++ Compiler 5.5
o Borland C++ 5.01/5.02
o Microsoft Visual C++ 2003, 2005, 2008
o Microsoft Visual C++ 6.0
Also in the past it has been working with Borland C++ Builder 1.0-5.0, Microsoft Visual C++ 5.0 and GCC and has been ported to Linux using WINE
* OWLNext offers easy upgrade path for porting legacy OWL applications to modern compilers and operating systems.
* OWLNext is open-source project, it's based on contributions and directions from it's community

30 ：

バージョンアップ！
0.0.5

31 ：

>>30
車輪の再発明乙！

32 ：

新Ｖｅｒおつかれさま

33 ：

PreTranslateMessageをどんな風に実装しようか。。。

34 ：

ん？どういうことだ片山
何を悩んでいる

35 ：

使ってないクラスをトリムしてスマートなライブラリをリリース時にバンドルできる仕組みを設けてくださいな。

36 ：

>>31
四角い車輪を作ってるから再発明じゃないよ

37 ：

LGPL v2.1 なら動的リンク用のヘッダ用意してくれ

38 ：

0.0.6
>>35 そういうときはスタティックライブラリを使ってください。
>>37 mzcver_.hに動的リンクのコードを書きました。

39 ：

VC10でコンパイル通らないんだけど

40 ：

スタティックにしてもdllのファイルサイズは変わらないじゃない。

41 ：

0.0.7
>>39　VC++を用意しているのでもう少しお待ちください。
>>40　DLLを使わなければいいじゃん。

42 ：

ver 0.0.9
次のようなエラーが出たんだけど、どうすればいい？
LINK : fatal error LNK1104: ファイル 'mzc0vdam.lib' を開くことができません。
NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 10.0\VC\BIN\link.EXE"' : リターン コード '0x450'
Stop.

43 ：

VC++6.0を使う

44 ：

ver. 0.0.10
VC++でもnmakeを使えばビルドできるようになりました。ところで
#pragma comment(lib, "...")
みたいにソースコードからリンクする方法がMinGWでもありませんか。

45 ：

Borlandでプリコンパイル済みヘッダーを使う方法を教えてください。
それと、Borland Implibで次のような警告がでるけど、
どういう意味でしょうか。教えてください。
Warning duplicate symbol: @CWnd@SendMessageW$quiuil
Warning duplicate symbol: @CWnd@UnsubclassWindow$qv

46 ：

厨房でも辞書の使い方くらい知ってるぜ

47 ：

「警告：シンボルが重複している」
英語の意味くらいは分かりますが対処法が分かりません。
関数のインライン化を無効にすればいいのでしょうか？

48 ：

>>45
-Hc プリコンパイルヘッダをキャッシュする。
（詳しい説明がほとんどないのでよくわからんが、たぶん一時的にメモリに確保するんだと思う。ユーザーズガイドの「C++Builder のコンパイル時間の最適化」あたりを参照）
-He 外部ファイルを使ってプリコンパイルヘッダを使用可能にする。
（詳細不明。ヘルプのどこを見ればいいですか？）
-Hs スマートキャッシュしたプリコンパイルヘッダを使用可能にする。
（詳細不明）
-Hu プリコンパイルヘッダを生成しないが、すでに存在すれば利用する。
（プリコンパイルヘッダ名を指定したい場合は、-H=filename と共に使えばいいようだ）

プリコンパイルヘッダって勝手にでかいファイル作られて気分悪い
コンパイルなんか遅くてもいいからコンパイラは余計な事しないで欲しい

49 ：

定義を *.inl に分けてるみたいだけど *.h から常に読み込まれてて意味なくないか？
それが解決したところで dll にしても CThreadLocal とかを使う限り LGPL 感染を免れない
もうちょっと考えてくれよ

50 ：

コンパイルに3時間とかかかっても同じことを言うのか？

51 ：

>>50
そのくらいの規模のソース扱う場合は少しの変更でもコーディングの何倍も
時間をかけて設計書書くのが普通だけどもしかしてPMが無能な不幸環境にいるのか
コンパイルなんか何度もするものじゃないだろうよ

52 ：

windows2000のコンパイルで一晩とか言ってたな
MSの開発者も無能なのか

53 ：

キャッシュが機能気に入らないなら
自分でpch無効に設定して毎回リビルドすりゃいいだろ
勝手に時間の浪費しとけ

54 ：

定義をinlに分ける（それを.hからincludeする）のは別に珍しくないと思う。
ATLやMFC、WTL、Boostでもときたま見かける。

55 ：

dllなりlibなりにして使うときにinlまでincludeしてたらだめだろ
それならそれで別のヘッダを用意しなきゃならなくなる

56 ：

ライセンスの問題をコンパイル時間がどうとか
問題をすりかえてるのがおかしいんだろ
つまらん流れにした >>50 がわるい

57 ：

作者の方は、どの程度、LGPLであることにこだわってます
でしょうか？GNUの考え方に賛同して行動されているのなら
ゴメンなさいですが、あまり強く思われていないならば、
wxwindowライセンスやCPLのようにバイナリ配布制限の
緩いライセンスについて考えてもらうことはできますでしょうか？
それらならば、dll化の必要性がかなりなくなるでしょうし、
(L)GPLを敬遠してる人でも興味をもつ可能性が増えそうに
思うのですが。
※wxwindowライセンスは基本はLGPLだけどバイナリ配布に
ついてはアプリ作者がわりと自由にライセンスできる。
CPLもバイナリはとやかくいわず、ただ、ライブラリ自体を修正
した場合は弄ったライブラリをCPLで公開する必要がある。
（といった感じだったはず）

58 ：

s抜けてた.
wxwindow ライセンス → wxWindowsライブラリ・ライセンス

59 ：

バージョンアップ0.0.12！
FreeBSDライセンスにしました。CTimeとCTimeSpanを追加しました。
コンパイルが速くなりました。
<mzc/config.h>で_MZC_NO_INLINESを#defineすると、
次のようなエラーが出てきます。なぜでしょうか？
Error: 外部シンボル
'CThreadLocal<MZC_THREAD_DATA>::~CThreadLocal<MZC_THREAD_DATA>()'
が未解決

60 ：

初心者スレみたいなこときくなよ
あとstd::stringとか継承するな

61 ：

VC++2008だけどこれなんだろ？
-ologoてどっから出てきたんだろう
リソースコンパイラが/nologoを誤解釈してるのか
rc /r /nologo /i"include" /D_DEBUG /d"MBCS" /d"_MBCS" /fo"mzcdll.res" mzcdll.rc
fatal error RC1106: invalid option: -ologo

62 ：

古いrc.exeにはnologoオプションがない
っていうかちゃんとテストしてからリリースしてくれ
mzcdll.rcの#include "config.h"だってエラーになるし

63 ：

>>59
ぱっとみたところ、メンバー関数テンプレーﾄを .inl 側に
置いてるのが不味そう。ヘッダ側へ。
ところで、メインで使ってるコンパイラは何？

64 ：

0.0.13！　ライブラリ名の間違い修正。
CWndの規定のメッセージ処理を追加。mzccmn.cppを追加。
>>60 検討中。>>62 /nologoを取り除いた。>>63 BCC55
MinGWはUnicodeアプリをサポートしていますか？

65 ：

>>64
MinGWでのUnicode化については自己解決しました。

66 ：

>>65
BCC55(フリー版)で試したけど mzcres.h だと下のヘッダコメント化しないとだめだった
#ifdef RC_INVOKED
//#include <winresrc.h>
#endif
//#include <dlgs.h>

67 ：

_MZC_NO_INLINESでODR違反になる
だいたい_MZC_NO_INLINESって予約語じゃないか他のにしてくれ
#define inlineでのキーワード削除も気に入らない
考えなしにこんなことしても今みたいにバグ出してるだけで何の恩恵も受けられない
そんなのはコンパイラオプションでやれ

68 ：

>>67 MFCのAFX_INLINEを参考にしているのだが、inlineかout-of-lineか
に関するODR違反はそれ程、重要なことだろうか。
_MZC_NO_INLINESはC/C++の予約語ではない。
inlineのout-of-line化のコンパイラオプションに関しては、
サポートしていないコンパイラもある。

69 ：

_MZC_NO_INLINESは、コンパイラオプションで定義しろ、という
意味なら、賛成する。それならば、<mzc/config.h>は使わないという
方向で。

70 ：

アンダースコアで始まる処理系予約の識別子を使ってることをつっこまれてるんだろ

71 ：

> MFCのAFX_INLINEを参考にしている
参考にしたならちゃんとMZC_INLINEとかでやるべき
> ODR違反はそれ程、重要なことだろうか。
ビルドが通らない
> サポートしていないコンパイラもある
インライン展開に関してinlineの有無を無視せず
無効にするためのオプションも存在しないコンパイラって>>22の中にあるの？
あるいはこれ以外の環境もサポートするの？
まあやりたいならやればいいと思うけど

72 ：

>>66のヘッダってincludeする必要あるの？使ってなくね？

73 ：

MFC,win32++超える、と大口のわりには、ライブラリをnamespaceで
まとめずグローバル名前空間汚しまくるとか、min,maxマクロとか
非常に残念なモノを見る思いなんだが。
60をどう解釈したのか…オレstringを造り始めてないよね？

74 ：

0.0.15! バージョン制御を厳密にした。MinGWで__wargvを使用可能に。
>>70-71　ありがとうございます。修正しました。
>>72 リソースを扱うときに必要です。>>73 min,maxを大文字にしました。
CWnd::CreateGrayCaret、CWnd::UpdateDataの実装がわからない。
次はサンプルを充実させなければ。MinGWで次のような警告がでます。
dllwrap: no export definition file provided.

75 ：

> min,maxを大文字にしました。
なにこれ笑うところ？
VC6対策かとも思ったけどコンパイル通らないし

76 ：

>>75
僕、VC++6を持っていないからエラーメッセージを載せてくれると
ありがたいのですが。

77 ：

VC6 なんてサポートする必要ないだろう。
いつまでそんな古いコンパイラつかってんだってかんじ

78 ：

VC6はVB6並に現役だろ
某スクリプト言語もWindows版はVC6でビルドされてるはずだし

79 ：

VC6使ってる人に質問だけど
プロジェクトがネットワークドライブ上にあると
コンパイル中にIDEまるごと死んだりする？

80 ：

>>78
VC6の現役って、メンテナンスやVC6資産活用のための現役じゃね？
今 VC6 使ってる人間が、わざわざVC6でコレを使うとは思えないよ。
だいたい今これに興味があるモノづきなら、少なくとも Express くらい
は入れるだろうし。
古いコンパイラ気にするよりも、boostとかいまどきの他のC++ライブラリ
との共存に気を配って欲しいよ。
そういう意味では BCC55 も…　C++98としては不十分な出来だし、
最適化へぼいからinlineでなくマクロ使う誘惑にかられるし。

81 ：

>>1がBCC5.5メインにしてるような化石君だからしかたないね

82 ：

今週はHTMLCONVの作成に忙しかったから、更新はなし。
ごめんなさい。

83 ：

列挙型は専用の名前空間に入れろ。
Signal::Type a=Signal::ON;
と呼び出せるようにしておくと、
列挙型の名前を表す名前空間をUSINGで省略出来て便利だ。
ただし、グローバルでUSINGはするなよ。

84 ：

そもそもそのままでSignal::ONと書けない仕様がおかしい

85 ：

C++0xまで待ってね

86 ：

車輪の再発明をするスレは、ここですか？

87 ：

BCC55つかうくらいならTurbo C++があるじゃん

88 ：

>>87
どこかに OWL の資料が落ちてませんかね。いちどチェックしたいと思って。

89 ：

mext owl だかなんかがあったような気がする

90 ：

http://en.wikipedia.org/wiki/Object_Windows_Library
http://sourceforge.net/apps/mediawiki/owlnext/index.php?title=Main_Page

91 ：

0.0.16！ CComboBoxExを追加。サンプルのDialogAppを追加。
CWnd::EnableToolTips、CWnd::EnableTrackingToolTips、
CWnd::CancelToolTips、CWnd::FilterToolTipMessageあたりがわからない。
MFCのソースが見れる人、誰か教えて。

92 ：

http://www.codeproject.com/KB/toolbars/tearoffrebars.aspx
これ実現させてみたいな。。。

93 ：

VC10でエラー出るしTRACE0なんて古いMFCマクロどこからコピペしてきたんだ

94 ：

>>92
させりゃいいじゃん
ソース見てパクるだけでしょ

95 ：

ttp://www.dotup.org/uploda/www.dotup.org1335350.txt
VC6SP6 + Platform SDK 2003 February でのログ
まあVC6のサポートは荷が重すぎるだろうし考え直したほうがいいんじゃないか

96 ：

>>91
CWnd::EnableToolTips
ツールチップ有効？
　→
　// nothing to do if tooltips not enabled
　　→return TRUE
　// cancel tooltip if this window is active
　　→CancelToolTips(TRUE);
　// remove "dead-area" toolbar
　　→SendMessage TTM_DELTOOL
else
　// if already enabled for tooltips, nothing to do
CWnd::EnableTrackingToolTips
同上。フラグ変えてるだけ
CWnd::CancelToolTips
// check for active tooltip
　→SendMessage　TTM_ACTIVATE→FALSE
// check for active control bar fly-by status
　→CControlBar::SetStatusText
CWnd::FilterToolTipMessage
なげえ
キー、マウスメッセージ見たりウィンドウが生きてるか見たり
トラッキングツールチップの場合マウス追って動かしたり

97 ：

0.0.17！ CView、CScreenViewを追加。
CWnd::SetToolTipTextでツールチップを設定するようにした、が、
なぜかsamplesのDialogAppは、ツールチップが表示できない。
なぜかstringa_test.devがundefined reference to `WinMain@16'で失敗する。
Code::Blocks + BCC55でビルドすると、なぜか実行できない。

98 ：

うｐおつおつ

99 ：

VC10:
DEFS = /DWINVER=0x500 /D_WIN32_WINNT=0x500 /D_WIN32_IE=0x500 /DJAPAN
エラー
DEFS = /DWINVER=0x500 /D_WIN32_WINNT=0x500 /D_WIN32_IE=0x500 /DJAPAN /DMZC_NO_INLINES
エラー

100read 1read

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

C#は危険だ (336)
サウンドプログラミング5 (666)
ARToolKitでARを作ろう (245)
ゲームプログラムなら俺に聞け26 (501)
★初心者にVisual C++を教えるスレ★ Part38 (665)
MFC相談室 mfc22d.dll (304)
--log9.info------------------
【氏家ト全】　生徒会役員共　【五十手目】 (852)
【川井十三】タカマガハラ【第11柱】 (514)
【市川マサ】A-BOUT(アバウト!) BOUT 37 (394)
【藤巻忠俊】　黒子のバスケ　94点目 (822)
◆週刊少年ジャンプ総合スレッド◆Part464 (339)
【ｶﾙﾄに集う】ワンピースアンチスレ224【白痴信者】 (470)
ワンピース強さ議論と雑談スレ461 (387)
【稲山覚也】てんむす 二十二食目【チャンピオン】 (410)
【大高忍】マギ 第53夜【サンデー】 (678)
ハヤテのごとく！好きだと言える日がもう381度くる (381)
東大理三合格とジャンプ連載どっちが難しい？★２ (780)
【鹿賀】 おすもじっ！〜司の一貫〜 七貫目【加藤】 (328)
ワンピースの2年間修行とはなんだったのか (926)
週刊少年サンデー総合スレッド262冊目 (219)
【俺の名は】ｺﾃﾊﾝ雑談part.286【金色のシキ】 (805)
SKET　DANCE（スケットダンス）ネタバレスレPart22 (386)
--log55.com------------------
寝台特急サンライズ瀬戸・出雲☆彡PART93
上越E7系を北陸E7系に転用するのは大反対
E7系水没による今後の運用を考察するスレ
北陸新幹線敦賀以西ルートスレ★250
☆★★★ 四国新幹線Part57 ★★★★
(東武)東上線 Part241
◆神戸市営地下鉄・北神急行・神戸新交通 20◆
東海道・山陽新幹線227