[過去ﾛｸﾞ] C++相談室 part154 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
1(2): 2021/01/08(金)17:54 ID:0DW9z0rL(1) AAS
※前スレ
C++相談室 part153
2chｽﾚ:tech
テンプレここまで
2: 2021/01/08(金)17:56 ID:GG1sOSQC(1) AAS
おつかれー
3(1): 2021/01/08(金)19:34 ID:hBRzO/B9(1) AAS
STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
4(2): 2021/01/08(金)19:38 ID:8XBZO/70(1) AAS
operator->*を好き勝手にオーバーロードするのは
C++厨二病なら誰しもが通る道だと思ってる
5: 2021/01/08(金)20:05 ID:gKD5AY0L(1/2) AAS
厨二病以下だね沼二病か幼長病レベル
6: 2021/01/08(金)20:33 ID:eZ2LT3hD(1) AAS
>>3
お前が死ね
7: 2021/01/08(金)20:55 ID:lmjqKHzd(1) AAS
だって演算子オーバーロード楽しいし！
それSpirit作者のジョエルさんにも言えるの？
8(1): 2021/01/08(金)21:03 ID:NkKDsd1u(1) AAS
% を三次元ベクトルのクロス積にするのはかつて自分も思いついたけど、勧められないって立場の人も居て
演算子オーバーロードが自然かそうでないかってのは人に拠るなと思った
自分の価値観で言えばiostreamの >> とかってあんまり自然じゃないが
他に何がいいかって言われてもないので仕方ない
9(1): 2021/01/08(金)21:08 ID:gKD5AY0L(2/2) AAS
<filesystem>のディレクトリ区切りがoperator/なのとかオモロイやん
10(1): 2021/01/08(金)21:17 ID:U7HVBqAl(1) AAS
絵文字プログラミングが来る
なので独自オペレータは出来た方がいい
11(1): 2021/01/08(金)21:44 ID:gxkYqo9D(1) AAS
>>4
わしは20年ぐらい前にその道を通った
だから若者がその道を通ることについては何もいわない
ほっといて気がつかないならダメ人材だし
使える人材は自分で気がつく
12: 2021/01/09(土)00:35 ID:8yDnsj0x(1) AAS
キーワードも再定義可能にしてﾎｽｲ
13(1): 2021/01/09(土)01:15 ID:CT/R4i5r(1) AAS
#defineでイケるやろ
14(1): 2021/01/09(土)01:39 ID:InkVVK6p(1) AAS
#define private public
ってテクニックのことか。
15: 2021/01/09(土)04:17 ID:kjQQkk+g(1) AAS
>>14
それコンパイル通っちゃうの？
プリプロセスだからOKなのか・・・
16(1): 2021/01/09(土)09:21 ID:c2CH7ey/(1/2) AAS
キーワードをdefineするのは規格上は未定義動作
でもだいたい通っちゃうな
17: 2021/01/09(土)09:27 ID:lvRTpcj7(1/3) AAS
その条文どこだっけ
18: 2021/01/09(土)10:07 ID:c2CH7ey/(2/2) AAS
この辺かなC++20ドラフトより
16.5.1.2 Headers [headers]
8 Identifiers that are keywords or operators in C++ shall not be defined as macros in C++ standard library headers.
（標準ライブラリはキーワードをマクロにすんな）
16.5.4.3.2 Macro names [macro.names]
2 A translation unit shall not #define or #undef names lexically identical to keywords, to the identifiers listed in Table 4, or to the attribute-tokens described in 9.12, except that the names likely and unlikely may be defined as function-like macros (15.6).
（キーワード・文脈依存キーワード・予約済み属性トークン(ただしlikelyとunlikelyを除く)をdefineやundefすんな）
19: 2021/01/09(土)11:17 ID:lvRTpcj7(2/3) AAS
ｔｈｘ
20: 2021/01/09(土)20:30 ID:w9vYk25X(1/2) AAS
>>13
何言ってんだおめー；；；
21: 2021/01/09(土)21:18 ID:jpx8Mcv4(1) AAS
C++はプリプロセッサが発展する方向にいかなくて本当に良かった
プリプロセッサを吸収して凄いことになってる気はするが
22: 2021/01/09(土)21:24 ID:lvRTpcj7(3/3) AAS
禿の方針だからね
スコープに従わない反逆者の排除は
23: 2021/01/09(土)21:37 ID:Te5slSqE(1) AAS
(でも楽しいよね
(コンパイル直前のコードが数個のプリミティブにまで還元されちまう楽しい言語もあるしな))
24: 2021/01/09(土)22:11 ID:w9vYk25X(2/2) AAS
プリプロセッサはC言語の目的（OSを様々なプラットフォームに移植可能な共通ソースコードとして書く）ための
必要欠く書くべからざるしくみとして導入され、できた時点で仕様としてはほぼ過不足なかった
という印象
そういう目的のブツなので、キーワードの再定義には全く不向き
25(1): 2021/01/10(日)07:00 ID:NGSbpihh(1) AAS
プリプロセスおもしろいやん
俺プリプロセス大好き
26: 2021/01/10(日)07:04 ID:pzwk9NYM(1/4) AAS
最近は#includeと#defineしか使ってない。
27: 2021/01/10(日)08:03 ID:pzwk9NYM(2/4) AAS
#defineじゃなくて#pragma onceだった。
28(1): 2021/01/10(日)10:29 ID:eq9L0D9i(1) AAS
どうやったらその2つを取り違えできるんだww
ほんとにつかってる？？
29: 2021/01/10(日)10:29 ID:Cbi+hphF(1) AAS
#pragma onceとか#inlude_nextとか標準に入れてほしくはある
30: 2021/01/10(日)10:45 ID:J1w4FPK7(1) AAS
#pragma onceはもう標準のつもりで使ってるわ
31: 2021/01/10(日)11:35 ID:MuZPu68S(1) AAS
>>25
そういう時期もあったな…（遠い目）
32: 2021/01/10(日)11:49 ID:WbJbdET/(1) AAS
#pragma便利よね ライブラリのリンク指定とかも
33: はちみつ餃子 ◆8X2XSCHEME 2021/01/10(日)11:50 ID:smlN1G6e(1) AAS
>>8
そう、 iostream は「仕方ない」と思うんだよな。
C++11 で variadic template が導入されるまでは
可変長引数を安全な型システムの中で扱えなかった。
仕方がないから演算子でなんとかそれっぽくしただけ。
演算子の中で比較的それっぽいのが << や >> だっただけ。
>>9
そういう観点から見ると、パスや日付の区切りに / を使うのは
演算子にしなければならない仕方なさは感じられない。
演算子にするなら / は比較的自然な選択ではあると思うけど。
34: 2021/01/10(日)11:53 ID:5+d8OMjE(1) AAS
シフト演算なんてほとんど使わんしなあ
35(1): 2021/01/10(日)11:57 ID:uVXyGOJo(1) AAS
ファイルパスってチェーンしたいものの筆頭格だから演算子にするのは妥当だと思うけど
36: 2021/01/10(日)12:20 ID:pzwk9NYM(3/4) AAS
>>28
使ってるわい。
37: 2021/01/10(日)12:20 ID:pzwk9NYM(4/4) AAS
とはいえレスくれてありがとうｗ
38: 2021/01/10(日)12:38 ID:stlWAB5c(1) AAS
>>35
std::path だと operator/= だな。
優先順位とか戻り値の型とか理由はあるんだろうが、やはり無理してる感は拭えない。
39: 2021/01/10(日)23:28 ID:9cXVj8qL(1/2) AAS
mutexって同時だとどうなるの？
40: 2021/01/10(日)23:32 ID:9cXVj8qL(2/2) AAS
信用して使うしかないけど…本当に同時で来たら…どうなるのかなぁ…と思って…。
41: 2021/01/10(日)23:43 ID:1knBg1rC(1) AAS
同時に入ろうとしたら同時に入るのではない別の世界線に分岐するから
結局同時にならない
42: 2021/01/11(月)00:43 ID:KM6/Ii6v(1/3) AAS
posix平行宇宙論
43: 2021/01/11(月)00:44 ID:AtO8PUuj(1/7) AAS
それだと…CPUの負荷や調子によって…同時になるって…事だよ…。
44: 2021/01/11(月)00:45 ID:AtO8PUuj(2/7) AAS
mutex…危ういな…どうしよう…。運に任せて…諦めるか…。
45: 2021/01/11(月)00:54 ID:AtO8PUuj(3/7) AAS
運任せは辛い…。
46(1): 2021/01/11(月)01:30 ID:AtO8PUuj(4/7) AAS
外部ﾘﾝｸ:stackoverflow.com
大丈夫だと言っているが…ほんまかいな…と思います…迷信はつきもの。
47: 2021/01/11(月)01:37 ID:KM6/Ii6v(2/3) AAS
テストプログラム作ってさっさと検証しろ無能
48: 2021/01/11(月)01:59 ID:3nmpeNiQ(1) AAS
>>46
信用できないならソースやアセンブリ読めよ。ここで名無しに答えてもらっても、信用できないんだろ？
49: 2021/01/11(月)03:08 ID:KSKcxhht(1/6) AAS
MutexはOSに依存するので絶対に大丈夫ということはないですが、数々のトラブルを引き起こし最も懸念されたLinuxが安定してきてるので、現在では実用上問題がないレベルにあると思います。
50: 2021/01/11(月)03:36 ID:dLrb5ZQk(1/2) AAS
マルチCPUでバスリクエストが同時に出た場合の制御なんて明確に定義されてんだろうが
OS依存だハード依存だと逃げているから見えない不安に怯えることになるんだよ
51(2): 2021/01/11(月)06:01 ID:vFi9Z+AQ(1/7) AAS
LinuxのMutexって使いにくいよね
俺はWindowsから入ったからMutexって名前付きが当たり前だと思ってたんだけどLinuxのMutexには名前がない
どうやって複数のプロセス間で同じMutexを使うんだよ・・・って悩んだ
共有メモリなんかでMutexのアドレスを受け渡しするらしいんだけどさ
面倒くさくなってLinux版の同期制御はファイルロックにしちゃった。。
52(1): 2021/01/11(月)06:47 ID:KSKcxhht(2/6) AAS
LinuxのファイルロックはNFSで（※私たちにはバグのように見える）仕様通りの動作をするので気を付けたほうが良いですよ。
ユーザーが指定したファイルやディレクトリを不用意に使用すると再現性の無いバグに悩まされます。
53(1): 2021/01/11(月)06:56 ID:vFi9Z+AQ(2/7) AAS
>>52
アドバイスありがとう
Linuxで共有メモリの使い方もよく分からなくて
共有メモリも書いてる途中で読み取りされたら困るから
「書いたよー」「読み終わったよー」ってプロセス間同期したいんだけどMutex受け渡しの前に同期処理って・・・
それで共有メモリの読み書きをファイルロックで同期してMutexを渡すかなーって考えてるうちに
もうファイルロックだけでいいんじゃないかってなってしまった
一般的にはどうやってやるのがよかったんだろ？
54(1): 2021/01/11(月)07:35 ID:KSKcxhht(3/6) AAS
>>53
結局、「NFSではバグります」と注意したうえでファイルロックを使うことが一般的に行われてるみたいですよ。
逆に言うと、NFSだけ気を付ければ、問題が起きないみたいです。
55(1): 2021/01/11(月)08:06 ID:RSMcM3e3(1/3) AAS
ちょっとググっただけだけどそんなに難しいかなぁ？
外部ﾘﾝｸ[php]:www.geekpage.jp
56: 2021/01/11(月)08:06 ID:vFi9Z+AQ(3/7) AAS
>>54
ありがとう ちょと安心した
57(1): 2021/01/11(月)08:16 ID:vFi9Z+AQ(4/7) AAS
>>55
コード見てみましたけどMutexの作成と共有メモリの書き込みが終わってからforkしてますね
forkした親と子ならそれでもいいんでしょうけど
実際は親子ではないプロセス間でMutex使いたくなったりするじゃないですか
Mutexが作成される前や共有メモリへの書き込み完了前にスレーブがMutexを要求しに来ると困ります
58(1): 2021/01/11(月)08:38 ID:WYfXTDe9(1) AAS
>>51
名前付きも普通にある
sem_open
名前はセマフォだが当然mutexとして使える
目的がメッセージのやり取りならmkfifoも使える
59(1): 2021/01/11(月)08:48 ID:3OtB0f6U(1) AAS
mutexじゃなくて名前付きセマフォなら普通にプロセス間で使えなかったっけ？
60(1): 2021/01/11(月)09:14 ID:RSMcM3e3(2/3) AAS
>>57
応用力ないの？
>>58-59みたいにセマフォ使うこともできるし、名前付き共有メモリー + Mutexでもいいだろ
61(1): 2021/01/11(月)09:22 ID:KSKcxhht(4/6) AAS
>>60
Linuxではファイルロックで良いよ。
62: 2021/01/11(月)09:28 ID:vFi9Z+AQ(5/7) AAS
セマフォのほうには名前付きあったんですね見落としてました
ありがとう！
63: 2021/01/11(月)09:39 ID:vFi9Z+AQ(6/7) AAS
あと別のところでソケットを排他リソースで使うというアイデアを教えてもらったことあります
同じポート番号をバインドできるのは1つだけだからこれを排他に使うという案
64: 2021/01/11(月)09:52 ID:KSKcxhht(5/6) AAS
3年ぶりの建設的なスレだな。
65(1): 2021/01/11(月)10:09 ID:RSMcM3e3(3/3) AAS
>>61
ファイルロックはロックしたままプロセス死ぬとリブートしても解消できないのがね
66: 2021/01/11(月)10:39 ID:sBoV/AFh(1) AAS
>>51
pthread周りはなんであんな仕様なのか謎
CPUのアーキテクチャーを深く知れば合理性を得心できるのかどうか、
67: 2021/01/11(月)11:25 ID:vFi9Z+AQ(7/7) AAS
>>65
それはファイルロック（flock関数）ではなく、単純にファイルの存在チェックをしているだけじゃないですか？
flockを使ったファイルロックならプロセス異常終了時にOSによってロックが解放されます
68: 2021/01/11(月)12:46 ID:vpEQZDgx(1) AAS
ミックスジュースよりセックスジュースが好きですね
69: 2021/01/11(月)14:25 ID:EL34sMb+(1) AAS
唐突に何いいだすねん君は!
(‘д‘⊂彡☆))Д´)ﾊﾟｰﾝ <ミックスジュースよりセックスジュースが好きですね
70: 2021/01/11(月)14:41 ID:dLrb5ZQk(2/2) AAS
ラブジュースだろ
71: 2021/01/11(月)16:14 ID:AtO8PUuj(5/7) AAS
39です…。
mutexの信頼性をずーと疑ってたら…POSIXスレッド…pthread_mutex_lockに行き着きました…
ブロックもするそうです…ソース見てたら…カーネルの様です…pthread_mutex_lock_fullであれば…atomic_compare_and_exchange_val_acq…などもあります…テストアンドセットです…
アトミック操作です…しかし…普通にmutexを実装してpthread_mutex_lock_fullが呼ばれるかは…
分かりません…どんなmutexライブラリも最終的に…このカーネルを呼んでるだけだと思います…
呼ばれてるのは…fullではなく…弱い方のpthread_mutex_lockだと仮定しても…カーネルを疑うなんて…
本当に…ナンセンスな話なので…一応…信用して使うことにします…。
72(1): 2021/01/11(月)16:55 ID:AtO8PUuj(6/7) AAS
39です…。
結局…fullでなくても…atomic_exchange_acqが呼ばれているようです…アトミック操作です…。
なので…みなさん…安心して使いましょう…。
73: 2021/01/11(月)16:56 ID:KSKcxhht(6/6) AAS
>>72
そこでやめずに、atomic_exchange_acqの中まで追いかけてみませんか？
74: 2021/01/11(月)16:56 ID:AtO8PUuj(7/7) AAS
外部ﾘﾝｸ:blog.sakasin.net
ソースです…。
75: 2021/01/11(月)21:32 ID:KM6/Ii6v(3/3) AAS
Debian woody の頃まで posix thread は使い物にならなかったが Debian etch からようやく使い物になった印象だな
当時から利用している身にしては
76: 2021/01/12(火)05:50 ID:pJAexhLb(1/3) AAS
わりと最近ですね。
77: 2021/01/12(火)07:34 ID:V95G+u6D(1/3) AAS
woodyって20年くらい前だっけ
最初はJavaVMもグリーンスレッドというVM内の仮想スレッド実装だったんだよね
あれもOSネイティブのスレッドが信用されてなかったからなのかな
もちろん、現在のJavaVMはOSのネイティブスレッド使う実装になってるけどね
78: 2021/01/12(火)07:44 ID:pJAexhLb(2/3) AAS
Javaといえばブラック何とかプロジェクトがSUNに文句言ってなかったっけ？
79: 2021/01/12(火)07:45 ID:pJAexhLb(3/3) AAS
Etchが2007年と書いてあるな。
80(1): 2021/01/12(火)09:08 ID:e5lAHXYT(1) AAS
設計思想的なことについて質問があります。
クラスの使い方がよく分かりません。
僕が今何かを作ろうと思ったら、関数の集まりが引数や返り値のやり取りを通じて協調するような設計をしてしまいます。
この引数や返り値が多く複雑になったりしてきたらクラスを用いた設計を考える、という理解は正しいでしょうか？
81: 2021/01/12(火)09:22 ID:XkW3hQXX(1) AAS
>>80
正しいかどうかは知らないし気にしないでいいと思うけど、
そういう場合はただのデータの集まりとして構造体（これもクラスの一種だけど）を使うだけでも簡単になるだろうね。
82(1): 2021/01/12(火)13:35 ID:lxco4c0J(1) AAS
個人的には、一度無理にでも概念(ウインドウとか表示とか作ってるソフトの主要な概念)をクラス名にして作ってみるといいとおも
やってるうちに慣れてくる
83: 2021/01/12(火)14:01 ID:V95G+u6D(2/3) AAS
そうだね
なにかを題材にしてオブジェクト指向やってみるのがいいと思う
でもウインドウはどうかなー そもそもUIツールキットをある程度知らないといけないし
GUIってオブジェクト指向らしからぬ部分も多いので
もっとビジネスロジック中心の題材がいいと思うよ たとえば掲示板システムとか
板には複数のスレがあって、各スレの中には複数のレスが並んでて、スレの書き込むメソッドでレスが1つ増えてーみたいな
84: 2021/01/12(火)15:56 ID:LUlB/OIG(1) AAS
>>4 >>11
. を再定義したいと思った
85(2): 2021/01/12(火)17:32 ID:+0XoTmdG(1) AAS
>>82
初歩的な質問なのですが、クラスってモノじゃなくて概念でも良いのでしょうか
つまり、歩く人のプログラムを作るとき、人というクラスが歩くというメソッドを持っていても良いし、歩くというクラスが一歩進むというメソッドを持っていても良いのでしょうか
言語の仕様上はもちろんどちらでも良いと思いますが、どちらの設計の方が筋が良いということはないと思って良いですか？
86: 2021/01/12(火)17:34 ID:fQCYjk84(1) AAS
ナントカ系の関数群みたいに相互に関連し合っているものを
暗黙じゃなく明確化するのがクラスだよ
87(2): 2021/01/12(火)17:38 ID:V95G+u6D(3/3) AAS
>>85
「歩く」をクラスにするよりは「歩ける」をインターフェースにしたらどうかな
人間クラスに「歩ける」インターフェースを実装することで「歩く」メソッドがあることを保証できる
対象ドメインをどのようにモデル化するかは状況や要件次第
88: 2021/01/12(火)19:05 ID:mPDSlMxM(1) AAS
メタファとして生き物がよく用いられるけどなんだかなあっていつも思う
89: 2021/01/12(火)19:50 ID:YNFRivpW(1/2) AAS
>>87
「歩け」インターフェースを定義したらインスタンスが歩ける想定であることは自明なのでは…
ちなメソッドは一般にオブジェクトの状態変化を引き起こすﾌﾞﾂなので
命令型プログラミングの範疇であり命令形で命名すうるが正しい
※ 個人の感想です
90: 2021/01/12(火)19:52 ID:YNFRivpW(2/2) AAS
しかしインスタンスの生成というプロセスは関数型プログラミングから拝借しており、
命令型と関数型のいいとこ取りしようとして失敗した
classベースのオブジェクト志向は
91: 2021/01/12(火)19:58 ID:GTfU1r+6(1) AAS
何ベースのが成功なの？
92: 2021/01/13(水)09:25 ID:X1FbeZvQ(1) AAS
場合によっては歩くクラスもありだと思うよ。
ゲームで次の行動を一つずつ記憶させたい場合とか。
commandパターン、mementoパターンでググって
93(1): 2021/01/13(水)09:45 ID:D0cZCa+j(1/5) AAS
歩くということは、位置が変化する。
現在位置は人オブジェクトのプロパティなのか？
それでええのか？
94(1): 2021/01/13(水)11:14 ID:XODVGtfI(1) AAS
>>93
良くね？
>>87
インターフェースって継承される前提のものなんですよね？
どのクラスが「歩ける」を継承するんですか？
95: 2021/01/13(水)12:34 ID:QVnLWQ3q(1) AAS
>>85
数値化できるものなら何でもオーケーだ
歩行を数値化するにはN個の関節を持つM本の脚をパラメータとし時間経過ごとの接地点と関節の位置をジェネレータみたいに連続的に返すような設計が考えられる
96: 2021/01/13(水)13:12 ID:D0cZCa+j(2/5) AAS
>>94
じゃあ将棋の駒オブジェクトはプロパティとして位置を持っているのか？
97: 2021/01/13(水)14:09 ID:D0cZCa+j(3/5) AAS
俺の考えるOOシステムでは、駒オブジェクトは盤面オブジェクトやルールブックオブジェクトへの参照を持っいる。
駒オブジェクトへ前へ3移動とメッセージを送ると、駒オブジェクトはルールブックオブジェクトと盤面オブジェクトを用いて、移動可能であれば盤面オブジェクトへ自身を移動するようメッセージングする。
98: 2021/01/13(水)15:31 ID:Dg6tKq+M(1) AAS
intを継承してmyintクラスを作ることは可能ですか？
99: 2021/01/13(水)15:38 ID:CyYDkVRJ(1) AAS
システム次第でしょ。
もしも将棋の駒が自律歩行多脚戦車だったら、GPSシステムがすべての位置情報を管理してるなんておかしいし。
100: 2021/01/13(水)15:38 ID:D0cZCa+j(4/5) AAS
enum class なら可能。
101: 2021/01/13(水)20:01 ID:D0cZCa+j(5/5) AAS
C++はテンプレートがあるので設計の詳細を先送りできる。
その特徴を生かせるように、プッシュ型を流行らせませんか？
プッシュ型は、前提が少ないので、利用者が自由に組み合わせることが出来ます。
これは、インターフェースによって事前に詳細を設計してしまう方式と真逆かもしれないが、組み合わせによって機能を作ることが出来まっする。
102: 2021/01/13(水)21:14 ID:XHABqTxh(1) AAS
プッシュ型って何？
103: 2021/01/14(木)06:54 ID:mrWYZ3Pm(1/8) AAS
Caper や Bison でプッシュ型を調べてみるとわかると思います。
104: 2021/01/14(木)06:59 ID:mrWYZ3Pm(2/8) AAS
あらゆるソフトウェアで使いまわされるライブラリにおいて、詳細が既に決まっているのは不自由なことです。
105(1): 2021/01/14(木)07:12 ID:FFXK54Rt(1/2) AAS
templateと比べてプッシュ型の利点が分からん。
106: 2021/01/14(木)07:23 ID:mrWYZ3Pm(3/8) AAS
>>105
プッシュ型はパーサーでよく使われます。
ユーザーが柔軟性を求めるからです。
Caperはプッシュ型、Bisonはパーサー側が文字を読む方式ですが、オプションとしてプッシュ型を選べます。
パーサにおいてプッシュ型とは、（パーサではなく）パーサを呼び出す側が文字を送り込みます。
それによって何が起きるでしょうか？
従来のパーサーは状態と共に行番号を保存します。
プッシュ型の場合、行番号を保存するのは呼び出し側です。
パーサーが読む文字とは何でしょうか？
プッシュ型において、Cではint、C++ではユニコード。コードポイントです。
文字デコードを行うのは、呼び出し側です。
では従来のパーサでは？
行番号を管理するためには、文字デコードもパーサーの仕事です。
つまりパーサーは大きな塊でアリ、組み合わせる部品ではありません。
107: 2021/01/14(木)07:27 ID:mrWYZ3Pm(4/8) AAS
プッシュ型はUNIXに通じるものがありますが、UNIXでは実現されませんでした。
108: 2021/01/14(木)07:47 ID:mrWYZ3Pm(5/8) AAS
パーサーは本来、構文解析が仕事です。
しかし、現状多くのパーサーは、構文解析以外の機能を密に結合している。
本来の仕事以外は分離して、小さな部品にすることで再利用性が高まる。
という感じですかね。
これはテンプレートと同じでもろ刃の剣でもあるんですよ。
詳細を設計しないんですから。
しかし、STLの寿命の長さを見て分かる通り、詳細が設計されていないという事は利用者が自由に設計できるという事で、使い出があるんです。
109: 2021/01/14(木)07:48 ID:mrWYZ3Pm(6/8) AAS
もちろん、パーサーに限った話ではないですよ。
例です。
110(1): 2021/01/14(木)09:22 ID:EIDQMz1r(1/2) AAS
みんながみんなパーサーを開発する側じゃないからなー
もっと身近な例はないですか？
このようなデザインパターンがプッシュ型だとこうなる、みたいな
111(1): 2021/01/14(木)09:29 ID:mrWYZ3Pm(7/8) AAS
>>110
使う側にとって良いことなんですよ。
それと、プッシュ型は万能ではないんですよ。
一部のコンポーネントの部品化に対して利益があるのです。
112: 2021/01/14(木)10:01 ID:mp+NLhBe(1/2) AAS
>>111
身近な例はないかという問いに対しその回答は意味不明では？
113: 2021/01/14(木)10:15 ID:mrWYZ3Pm(8/8) AAS
まあそうですね。
すいませんでした。
114: 2021/01/14(木)10:22 ID:FFXK54Rt(2/2) AAS
身近な例で利点があるなら広めるのに協力するのもいいが今の時点で利点が分からん。
115: 2021/01/14(木)15:40 ID:qrpkNJTC(1/3) AAS
別にC++だけの問題じゃないんだけど…質問…例えば…エクスプローラのようにファイル一覧出すじゃん…
画像や動画は…サムネイルを出すじゃん…このサムネイルは非同期で更新になるじゃん…
一度開いたら…キャッシュから読み込みたいじゃん…このキャッシュの保存ってさぁ…一意にするのに…
ファイルパス・更新日時・サイズである程度一意になるけど…完璧な一意ではないじゃん…
同じ名前・同じ更新日時・同じサイズで上書きされたら、前の画像がサムネイルに出るじゃん…
どうすんの？
116: 2021/01/14(木)15:42 ID:qrpkNJTC(2/3) AAS
キャッシュなんてそんなものだから…それでいいのかなぁ…
117: 2021/01/14(木)15:53 ID:mp+NLhBe(2/2) AAS
その気持ち悪い｢...｣をやめてくれ
118: 2021/01/14(木)15:55 ID:EIDQMz1r(2/2) AAS
ファイルパスと更新日時で一意になると考えていいでしょ
コンテンツが変更されれば更新日時が進むという前提で
それさえも許せないクリティカルなシステムならファイルの全バイト列から衝突率の低いハッシュ作るとかファイル読むのと変わらんことになる
クリティカルなシステムではキャッシュ使わんな
119: 2021/01/14(木)16:05 ID:qrpkNJTC(3/3) AAS
なるほど…。
120: はちみつ餃子 ◆8X2XSCHEME 2021/01/14(木)16:09 ID:9qLPLWCT(1/2) AAS
外部ﾘﾝｸ[html]:martinfowler.com
> There are only two hard things in Computer Science: cache invalidation and naming things.
計算機科学においては二つの難しいことがあります。
キャッシュの無効化と名前の付け方です。
121: はちみつ餃子 ◆8X2XSCHEME 2021/01/14(木)16:16 ID:9qLPLWCT(2/2) AAS
ファイルシステムによるけど iノード番号だったり
それに近い管理機構で一意に特定できる場合もあるんじゃないの。
サムネイルくらいなら雑でいいやという割り切りもあると思うけど、
ある程度は不整合がないようにする努力もしてると思う。
122: 2021/01/14(木)23:16 ID:9gUF6PTW(1/2) AAS
特徴的な文体はblogでも見た！
123: 2021/01/14(木)23:49 ID:9gUF6PTW(2/2) AAS
スヌープとLRUでおｋ
この2つでダメだという香具師は、
スヌーピングのロジック設計をサボっているか、
メモリをケチって必要量に未達なだけ
124: 2021/01/16(土)08:13 ID:dLwYQ6PK(1/2) AAS
おはようございますみなさま、質問させてください
ユーザー定義クラスを作成し、循環参照を防止するためweak_ptrをメンバに持たせています。
そして任意の処理でshared_ptrをweak_ptrに代入し使用したいと思っておりました。
しかし、メンバ関数内部でweak_ptrを使用すると、式にはポインタ型が必要です、旨のエラーが出てしまいます。
調べてみたところ、lock（）でshared_ptrに再度権利委譲するとshared_ptr側から動くのですが、私が初心者な事もあり何か釈然としません（我が儘でしょうか……）
一度weak_ptrに落とし込んだものを再度shared_ptrに戻す部分が引っかかっているのだと思います（気にしすぎですかね）
そこでお聞きしたいのですが、クラス内部で動的に定めたいと思っているweak_ptrを使う際に、これ以外の方法はありますでしょうか？
それとも上記の通りlock()で一時的なshared_ptrに束縛した方がいいのでしょうか？
朝から長文失礼しました
125(1): 2021/01/16(土)08:49 ID:ld2GCDwz(1) AAS
ロックしないと知らない間に参照先のshared_ptrで持ってるオブジェクトが破壊されてても文句言えないけどそれでもいいの？
weak_ptrってそういうものだぞ
126: 2021/01/16(土)09:17 ID:dLwYQ6PK(2/2) AAS
>>125
ありがとうございます。
おっしゃる通りだと思います。
納得いたしマスター！
127: 2021/01/19(火)02:35 ID:y82ZfCrD(1) AAS
移譲って要は継承せずにオブジェクトとして使うってことですよね？
なぜ「移譲」なんてわけわからない名前がついてるんですか？
上下前次1-新書関写板覧索設栞歴
あと 875 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.028s