[過去ﾛｸﾞ] 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
ラブジュースだろ
上下前次1-新書関写板覧索設栞歴
あと 932 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.039s