[過去ﾛｸﾞ] 【初心者歓迎】C/C++室 Ver.104【環境依存OK】 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1: 2018/12/28(金)06:04 ID:ufThBpcD(1/2) AAS
エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります
コードを貼れる所
外部ﾘﾝｸ:codepad.org
外部ﾘﾝｸ:ideone.com
前スレ
省2
922(1): 2019/04/21(日)19:47 ID:ECfCuHga(12/27) AAS
>>920
人間のやることなので完璧は無理でしょうな
比較の問題になります
例外とエラーコード返しを比べればどちらが標準的な型式に収まりやすいか？という問題なら例外が圧倒的に優勢でしょう
923: 2019/04/21(日)20:14 ID:sE/qbOcV(1) AAS
例外にすればエラー検知は簡単になるでしょうが
そのエラーに対してどう処理するのかはケースバイケース
標準的な方法なんて無いと思うけど
そこが肝心な所で優勢かどうかは些末のことだと思うよ
924: 2019/04/21(日)20:21 ID:ECfCuHga(13/27) AAS
例外はcatchで標準化されますが？
その後のことは例外とエラーコードの比較って文脈で語ることじゃないな
強いて言えば例外の方が再通知の仕方もより標準的と言えるが
925(2): 2019/04/21(日)20:24 ID:ym7YjNtF(4/6) AAS
戻り値がboolならそれが正常終了したかどうかを表していることは誰にでもわかる
呼び出し元を正常系と異常系の単純な分岐にでもしておけば致命的なバグになることはない
例外の場合はその発生率が極めて低い場合にｔｒｙ-catch忘れが起こると致命的なバグを含んだままリリースされかねない
926: 2019/04/21(日)20:34 ID:ECfCuHga(14/27) AAS
>>925
boolの解釈は人それぞれ
bool is_invalid() const;みたいなのもあるよね
あるいはただのビットフラグのON/OFFを示してるかもかもしれない
そもそもそれが処理の成否を表しているかどうかすら統一されてない
リターンコード方式ではリターンコードと分岐の洪水による目くらましでコーディングミスが多発する
それは必要なcatchを書き忘れる確率よりもずっと高い確率で発生する
省3
927(1): 2019/04/21(日)20:43 ID:baAUkWKA(1) AAS
catch 以降でエラー内容に応じて振り分ける訳ですか？
気が遠くなりませんか？
928: 2019/04/21(日)20:47 ID:ECfCuHga(15/27) AAS
>>927
あぁ
そもそも例外の文法すら知らないのか
929(1): ◆QZaw55cn4c 2019/04/21(日)20:56 ID:MozNv5pX(6/19) AAS
>>919
リターン値方式に比べて exception のメリットは何でしょうか？
そしてそのメリットは本当にメリットでしょうか？
930: ◆QZaw55cn4c 2019/04/21(日)20:57 ID:MozNv5pX(7/19) AAS
>>916
エラー値を取得するタイミングがずれるようだとスレッドセーフを保障できなくなるのでは？
931(1): ◆QZaw55cn4c 2019/04/21(日)21:00 ID:MozNv5pX(8/19) AAS
>>922
＞標準的な型式
なにを「標準的」とするかは世代差があるのではないですか？
java や c# に慣れた人は exception を推すでしょうし
ここで >>922 を私が強く非難している理由は、「標準的」というバズワードで自説を合理化する、その自分勝手さという点にあります
932(1): ◆QZaw55cn4c 2019/04/21(日)21:04 ID:MozNv5pX(9/19) AAS
>>925
＞ｔｒｙ-catch忘れ
>>925 が return-value 派か exception 派かはここでは問題にしません
しかし、この「try-catch」忘れ、という単語の存在そのものが、exception の利点が利点になっていないことを如実に表現していると思います
忘れないようにするための exception が忘れるもとになってしまっている、とか、全然おかしいんじゃないのでしょうか
933(1): 2019/04/21(日)21:08 ID:ECfCuHga(16/27) AAS
>>929
レスを読んでください
>>931
異なる世代の衝突があった場合は今を優先すべきでしょう
過去の過ぎ去ったことにいつまでも縋り付いては先へ進めません
ちなみにC++の標準ライブラリは例外を採用しました
934(2): 2019/04/21(日)21:11 ID:ECfCuHga(17/27) AAS
>>932
例外はエラー対応を忘れないようにするためのものではありません
例外はエラーの通知方法を標準化することとコーディングの労力を大幅に低減するための機構です
エラーコード形式でも分岐を忘れることはありえます
むしろ不要な分岐も定型処理として書かなければならないエラーコード形式ではノイズが多くミスや忘れが多く発生します
935(1): ◆QZaw55cn4c 2019/04/21(日)21:22 ID:MozNv5pX(10/19) AAS
>>933
＞レスを読んでください
どのレスかアンカーをいただけませんか？
>>933
＞異なる世代の衝突があった場合は今を優先すべきでしょう
＞過去の過ぎ去ったことにいつまでも縋り付いては先へ進めません
「今の方が昔よりよくなった」という世界観に立脚しているのであれば、その説は説明できますが
省4
936(3): ◆QZaw55cn4c 2019/04/21(日)21:28 ID:MozNv5pX(11/19) AAS
>>934
私の考えるところの exception の利点の一つは、exception の発生した階層から遠く離れたところでも、その exception を catch して処理を記述できるところにある、と考えています
もう一つは exception を catch するとき指定するのは class だから、このエラークラスを派生関係として階層化することで、エラー体系の構造化ができるところでしょうか（派生クラスでも基底クラスでも catch できる、という点です）
しかし exception の話が持ち上がる度に、私の思う上記二点の excption の利点は言及されたためしがありません…
これでは exception の本当にいいところがメリットとして理解されていない、というか、メリットになり得ていないようですね…
exception は単なる無駄コスト食らいなんじゃないですかね…
937(2): 2019/04/21(日)21:29 ID:ECfCuHga(18/27) AAS
>>935
沢山あるので面倒です
今日のレスを読み直してください
悪くなったのが事実であれば新しいものが普及する前に消えるでしょう
普及してしまった時点で一部のロートル以外は良くなったと考えている証拠です
938: 2019/04/21(日)21:34 ID:ECfCuHga(19/27) AAS
>>936
離れた位置で捉えられる点はコーディングの省力化に暗に含まれると考えていいでしょう
全ての階層で定型処理を書かなくてもいい==離れた階層でも捉えたいところでだけ処理を書けばいい
ということです
例外の階層化についてはその通りですね
地味なので忘れがちですが便利です
939(1): ◆QZaw55cn4c 2019/04/21(日)21:36 ID:MozNv5pX(12/19) AAS
>>934
＞エラーの通知方法を標準化することとコーディングの労力を大幅に低減する
ここでもバズワード「標準化」を使っていますね、漠然とした抽象的な単語を並べればいい、という思考の粗さが気になります
それに異常系の記述はどうあがいても、場合わけして都度逐一記述するしかないのは、return-value 派にしても exception 派にしても同じで、記述する中身が減るわけじゃありません
それとも exception で書けば記述が減るというのなら、何か書いてみてください
>>934 を読むにつけても、>>934 は本当に物事を突き詰めて考えているのですか？
世間がこういっている、とか、Java や C# ではそうしている、とかいう空気の読みあい、ポジション取りの忖度しかしていないのでは？
省1
940: ◆QZaw55cn4c 2019/04/21(日)21:36 ID:MozNv5pX(13/19) AAS
>>937
アンカーを書くことくらいもできないのですか？
941(1): ◆QZaw55cn4c 2019/04/21(日)21:38 ID:MozNv5pX(14/19) AAS
>>937
＞悪くなったのが事実であれば新しいものが普及する前に消えるでしょう
google のコーディング規約では exception を推奨しないようですよ
外部ﾘﾝｸ[html]:ttsuki.github.io
悪いものでも消えずに、もっと悪いことには悪疫として蔓延しているものもありますよ、もしかすると C++ の exception もその一つなのでは？
942(1): 2019/04/21(日)21:38 ID:ECfCuHga(20/27) AAS
ちなみに例外はもうすでに新しいものではありません
長年多くのプログラマによって効果が実証され続けてきた枯れた機能です
例外に変わるエラー処理機構が流行らなかったという事実が例外の完成度の高さを裏付けています
943(1): 2019/04/21(日)21:41 ID:ECfCuHga(21/27) AAS
>>939
エラーに対するハンドリングのコードについては例外とエラーコードの比較の外だとすでになんどか書きました
例外によって削減されコードは無意味な定型処理のことです
944(1): 2019/04/21(日)21:41 ID:dJmpMhpq(7/9) AAS
googleが例外使わない理由は、例外を否定する類いのものでは無かったような
945(1): ◆QZaw55cn4c 2019/04/21(日)21:45 ID:MozNv5pX(15/19) AAS
>>942
＞例外に変わるエラー処理機構が流行らなかった
というか exception そのものが流行らなかった、というべきでは…
なんども繰り返しますが「新しいものがいいもの」「枯れた機能」とかいう主観はいらないから、「exceptionの具体的な利点」を書くべきです
>>943
言っている意味がわかりません、お手数ですが、少し字数を使って説明いただけますでしょうか？
946(1): ◆QZaw55cn4c 2019/04/21(日)21:46 ID:MozNv5pX(16/19) AAS
>>944
「例外安全」を保障するのが、これは滅茶苦茶しんどいので、その一点で嫌われているんだとおぼろげながら感じています
947(2): 2019/04/21(日)21:52 ID:ECfCuHga(22/27) AAS
>>941
googleが常に正しいわけではないでしょう
例えばそのページでは、例外安全性を考慮していないコードのリスク、つまりリソースリークについて書かれてますがリターンコード形式でも解放を忘れればリークするのは同じことです
そして、さっきも書きましたがリターンコード形式では余計な定型処理がノイズとなってそういったミスをしやすくなることが問題です
コントロールフローが追跡難化するリスクも全く逆でダラダラと必要ない定型処理を書かれた方が追跡が難しくなります
自分で考えずに権威を盲信する人を文系と揶揄することがありますが
もしかしてあなたも文系なのでしょうか？
948(1): 2019/04/21(日)21:56 ID:ECfCuHga(23/27) AAS
>>945
例外を受け取ると何もせず上位に通知するメソッドを考えてください
例外形式ではコーディング量は0です
リターンコード形式では少なくともリターンコード値が正常系か異常系か判断して戻す分岐が必要です
これは少なくとも1行の無意味な定型処理を追加しなければならないということです
実際にはそのプロジェクトの規約によって1行どころでは済まないことが多いのですが…
949(1): 2019/04/21(日)21:56 ID:ym7YjNtF(5/6) AAS
>>947
リターンコード形式で発生する余計な定型処理のノイズの例と例外でそれを回避できるケースの例をください
書かなきゃいけないコード量は本来大差ないはずです
950: 2019/04/21(日)21:57 ID:dJmpMhpq(8/9) AAS
例外安全というか、googleで想定しているリソース解放漏れって要はRAIIになっていないって事だよね
951: 2019/04/21(日)22:02 ID:ECfCuHga(24/27) AAS
>>946
リターンコード形式でも例外安全性(エラー安全性とでもいうのでしょうか)を守るには大きな労力がかかるはずです
リターンコード形式なら自動的にリソースが安全に解放されて全ての状態が実行前にロールバックされるといったことはありません
例外でもリターンコード形式でもリソースの解放と状態のロールバックの責任はプログラマあります
952(1): ◆QZaw55cn4c 2019/04/21(日)22:03 ID:MozNv5pX(17/19) AAS
>>947
＞例えばそのページでは、例外安全性を考慮していないコードのリスク、つまりリソースリークについて書かれてますがリターンコード形式でも解放を忘れればリークするのは同じことです
そこで exception の実装に話が戻るのです
exception の実装（例えば sjlj, seh のどちらかひとつでいい）はどうしても（隠れたところに）グローバル変数を必要とするのではないですか？
これはスレッドセーフや例外安全を考えるときに、大きな癌になりうるでしょう
一方、return-value 方式は、頑張ればローカル変数だけで記述できる
return-value 方式の方が考えるのが楽ではないですか？
省2
953(1): 2019/04/21(日)22:06 ID:ECfCuHga(25/27) AAS
>>949
例外の場合
T val = f(...);
エラーコード場合
T val;
int ret = f(..., val);
if (is_error(ret)) return ret;
省2
954(1): ◆QZaw55cn4c 2019/04/21(日)22:10 ID:MozNv5pX(18/19) AAS
>>948
その例外の上位への素通し、って、確かに >>936 では私も例外の利点だと書いてしまいましたが、でも実際には嫌われることなんではないですか？
java は下位ルーチンが発生させる例外（のうちのある種類）は、上位側で catch しとかないとコンパイラが怒るんではないでしょうか？
955: 2019/04/21(日)22:12 ID:ym7YjNtF(6/6) AAS
>>953
ｔｒｙ文を含めれば大差ありませんね？
956(1): 2019/04/21(日)22:12 ID:dJmpMhpq(9/9) AAS
嫌われないよ
RAIIじゃない場合
一度キャッチしてリソース解放したあとスローし直さなきゃリソース漏らすというだけ
957: ◆QZaw55cn4c 2019/04/21(日)22:15 ID:MozNv5pX(19/19) AAS
>>956
なるほど、だとすると、>>936 で書いた「exception の発生した階層から遠く離れたところでも、その exception を catch」できる、というのは無条件では c++ では利点にならないですね、return-value 式とほとんど変わらない…
958: 2019/04/21(日)22:20 ID:ECfCuHga(26/27) AAS
>>952
たとえグローバル変数を使った実装だったとしても例外の利用者にとっては透過的なので問題はありません
スレッド処理でも問題はありません
同じスレッドでは利用者は何も気にせずに例外使えます
スレッドを結合するところでは例外を転送してください
そのための標準的な方法も用意されています
エラーコード形式の場合はスレッド間転送も標準のない独自形式になるのでより難しそうですね
959: 2019/04/21(日)22:34 ID:ECfCuHga(27/27) AAS
>>954
Javaには例外時に自動でリソースを閉じるための構文が存在しない時期がありました
検査例外はそのときの名残です
GCされるまで自動で閉じられることはないからちゃんと手動で解放しろと注意喚起する意味では検査例外にも価値があります
逆に言うとRAIIやusing/IDisposeのような機構が適切に使われている場合はうっとおしいお節介でしかないわけです
ちなみにリターンコード形式場合はリソースを確保していない場合でも定型処理を書かなければなりません
したがってそのうっとおしさは検査例外とは比較にならないほどの負担になります
960(1): 2019/04/21(日)23:25 ID:2X82VWTJ(1) AAS
いつもはうっとうしいQZ某が、今日は概ね論理的な物言いをしているように感じる。
対する例外推しの彼は、饒舌だが自説を貫こうとするだけで相手を納得させるような説明はしようとせず、議論をしていつもりで議論できてない人のように見える。リアルなフォーク准将を見ているような気持ち悪さがあるよ。
ちなみに俺は例外も戻り値も適材適所で使い分けて一貫性がとれていればいいんじゃね、という意見だけど、議論に加わる気は無いのでスルーしてくれ。
961: 2019/04/22(月)00:23 ID:W/PqoVz0(1) AAS
納得させる気は最初からないからね
ただ単に事実を語っただけ
962: 2019/04/22(月)01:28 ID:zAZ+Y0tC(1) AAS
機械学習とかアプリケーションレイヤの開発をしてて普段はJavaとかpythonで書いてるんだけど相談。
手間や保守を考えるといくら早く動作しても全部cで実装は厳しくて、複雑な計算とかだけcに渡そうと思うんだけど、このレイヤだとそんなもんだろうか？実際の仕事での使われ方の例があれば教えてほしい。
963(1): はちみつ餃子 ◆8X2XSCHEME 2019/04/22(月)05:12 ID:oO3SHMUw(1) AAS
例外安全という言葉には色々と含まれるけど、
とりあえず最低限度の保証としては「リソースリークが起こらないこと」とすると、
C++ ではデストラクタで後始末するのが基本だ。
(RAII)
私が強調しておきたいのは、リソース管理の配慮はクラス定義に押し込めることが出来るということと、
可能な限り押し込めるべきだということ。
エラー発生の通知に使うのが返却値であれ例外であれ、
省13
964: 2019/04/22(月)07:22 ID:kinTds5M(1) AAS
ON ERR GOTO 100
965: 2019/04/22(月)08:55 ID:H+0HJxEG(1) AAS
#define return goto
966: ◆QZaw55cn4c 2019/04/22(月)16:34 ID:UIaMmjmK(1) AAS
>>960
＞いつもはうっとうしいQZ某が、今日は概ね論理的な物言いをしているように感じる。
あれ？れれ？
おっかしーなー、私もプログラムを書く人だし最低限自分の作ったバグくらいはさっさと片付けたいので、そのためにも、いつも論理的でありたいと願っているのですが…
967: 2019/04/23(火)13:32 ID:TjU3QAMI(1) AAS
そういうとこだよ
こういうのってたいてい本人は自覚してないもんだからやっかい
968(2): ◆QZaw55cn4c 2019/04/23(火)19:01 ID:JSYnwir1(1/2) AAS
>>963
＞違いはないがどちらかに一貫させるのが望ましいと考えると、
＞C++ の基本的なライブラリに併せるべきだということになって例外を使うのが妥当という判断になる。
この意見に対しては私は痛烈な批判を浴びせることになるでしょう
曰く、C/C++ の人なら言語的な統一感よりもコスト、というか単純性を優先したくなるのではないですか？
UML のグジャグジャ感をみるにつけても、「言語法律家」なるものはきわめて忌むべき存在と私は考えています
exception を実装するためには、隠れグローバル変数をどうしても準備しなければならない
省3
969: 2019/04/23(火)19:28 ID:TE76XOKd(1/12) AAS
単純さを選んだら例外になったというお話だったのさ。ちゃんちゃん
970: 2019/04/23(火)19:47 ID:BSgCsXpz(1) AAS
なぜsjljにこだわるのか
コルーチンとか標準化されても使わなそうだな
971(1): 2019/04/23(火)19:58 ID:TE76XOKd(2/12) AAS
c++の言語仕様に例外の実装にはグローバル変数使えとかSJLJ使えなんて縛りあったっけ？
972(1): ◆QZaw55cn4c 2019/04/23(火)20:09 ID:JSYnwir1(2/2) AAS
>>971
実装方法までは言語仕様に記述されないでしょうね…
973: 2019/04/23(火)20:23 ID:TE76XOKd(3/12) AAS
>>972
ということは例外の実装にまで踏み込んで考えるのはナンセンスなのでは？
974: 2019/04/23(火)21:32 ID:lLaZpSEH(1/10) AAS
>>968
例外がos丸投げってのは事実誤認
975: 2019/04/23(火)21:35 ID:lLaZpSEH(2/10) AAS
ちなみにおれはc++の例外は大規模開発でworkしないと思ってるから
経験上ひたすら面倒な事態になる
言語仕様決めてるやつらは言語オタクで大規模開発の経験ないと思ってる
976(1): はちみつ餃子 ◆8X2XSCHEME 2019/04/23(火)21:51 ID:K0ADJPpo(1) AAS
>>968
いつの話をしてるんだよ。 モダンな環境では例外送出の実行コストは充分に小さい。
特別な環境で特別な対処をしなきゃならない場合を例に出しても意味がないぞ。
ふーん、そういう場合はそうするんですねとしか言いようが無い。
977(2): 2019/04/23(火)21:58 ID:lLaZpSEH(3/10) AAS
>>976
sjljでない場合
例外がおこらない分にはオーバーヘッドないけど、起こったときのスタック巻き戻しが重い
こういうこと知らずにクリティカルなとこで気軽に例外発生させるバカをよく見る
978(1): 2019/04/23(火)21:59 ID:TE76XOKd(4/12) AAS
抽象化ができずどんな粒度でも低級のセオリーを通そうとする
早すぎる最適化がとにかく大好き
C++erに多いねこのタイプ
979(1): 2019/04/23(火)22:01 ID:TE76XOKd(5/12) AAS
>>977
クリティカルってどんな時？
980(1): 2019/04/23(火)22:03 ID:lLaZpSEH(4/10) AAS
>>979
リアルタイム性が求められるとき
981(1): 2019/04/23(火)22:04 ID:lLaZpSEH(5/10) AAS
>>978
アホみたいにmap使いまくって後でひどい目に遭うアホもよく見るな
982(1): 2019/04/23(火)22:12 ID:TE76XOKd(6/12) AAS
>>980
それが必要なのってC++コード全体からすると何パーセントくらいなの？
983: 2019/04/23(火)22:15 ID:lLaZpSEH(6/10) AAS
>>982
しらないけどクリティカルな処理ないならc++使わなくていいんじゃないの
なんでわざわざこんなしんどい言語使う？
984(1): 2019/04/23(火)22:18 ID:TE76XOKd(7/12) AAS
>>981
別にmap使いまくってもいいよ
ちゃんと抽象化しとけば後でチューニングするのは簡単だから
985(1): 2019/04/23(火)22:21 ID:lLaZpSEH(7/10) AAS
>>984
まさかw
データ構造大事だよ初心者さん
986: 2019/04/23(火)22:26 ID:5E3fgZzA(1/2) AAS
痛い目に遭ったのかｗ
987: 2019/04/23(火)22:28 ID:TE76XOKd(8/12) AAS
>>985
君はまだ話の流れを理解してないようだ
988(1): 2019/04/23(火)22:34 ID:lLaZpSEH(8/10) AAS
合ってるね
スクリプト言語あがりと一緒に仕事すると高い確率でそうなる
同じ事をいうんだよ
最初は抽象度高く作ってあとで最適化って
結局しないからね
だいたい薄く広く積もったオーバーヘッドは表面化しないから
んでもっさりアプリの出来上がり
省1
989(1): 2019/04/23(火)22:36 ID:TE76XOKd(9/12) AAS
>>988
そこで作り直すから低スキルなんだよな
前任者がせっかく変更に強いシステムを組んでやったのに台無しにするんだ
990(1): 2019/04/23(火)22:43 ID:lLaZpSEH(9/10) AAS
>>989
変更に強いとかの内輪の都合よりUXの方が大事だよ
初心者さん
991: 2019/04/23(火)22:44 ID:5E3fgZzA(2/2) AAS
システム解析能力が無いせいじゃないか
992: さまよえる蟻人間 ◆T6xkBnTXz7B0 2019/04/23(火)22:47 ID:DAl4rXky(1) AAS
そろそろ次スレ
993: 2019/04/23(火)22:49 ID:TE76XOKd(10/12) AAS
>>990
その大事な大事なUXを向上させるために抽象化するんだよ新人君
994(1): 2019/04/23(火)22:59 ID:be9PrXZY(1) AAS
さすがにそれは意味不明では？
過剰なオブジェクト指向でダメになったプロジェクトは数知れず
995: 2019/04/23(火)23:01 ID:TE76XOKd(11/12) AAS
>>994
やっぱり流れを理解してないね
996: 2019/04/23(火)23:05 ID:lLaZpSEH(10/10) AAS
そういうのいいから
説明できないならそこでおしまい
997(1): 2019/04/23(火)23:13 ID:TE76XOKd(12/12) AAS
UXの向上にはフィールドバックと変更のループが必要
度々の変更を容易たらしめるためには適切な抽象化が必要
最初から速度最適化に傾倒して抽象性を失ったシステムは変更しにくいゴミUXを抱え続ける
998: 2019/04/23(火)23:47 ID:NBxQbW0f(1) AAS
御託ご苦労さん
でそれどっからの流れなの？
お前さんに一度map乱用ボトルネックを一晩でtableに置き換える作業やらせてみたいわ
多数のモジュールと繋がってるやつな
最初から見積り立てて設計しとけよボケってどなられるやつな
999: はちみつ餃子 ◆8X2XSCHEME 2019/04/24(水)00:43 ID:kf0sNkPB(1/2) AAS
>>977
そりゃあクリティカルなところという特別な場合には特別扱いが必要ですねって
だけのことで、そんなこともわからんやつは例外を使おうと使うまいと駄目だよ。
1000(1): はちみつ餃子 ◆8X2XSCHEME 2019/04/24(水)00:43 ID:kf0sNkPB(2/2) AAS
>>1000 なら長門は俺の嫁
1001(1): 1001 ID:Thread(1/2) AAS
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 116日 18時間 38分 57秒
1002(1): 1002 ID:Thread(2/2) AAS
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
省7
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.355s*