X
C++相談室 part154
■ このスレッドは過去ログ倉庫に格納されています
0002デフォルトの名無しさん
垢版 |
2021/01/08(金) 17:56:28.28ID:GG1sOSQC
おつかれー
0003デフォルトの名無しさん
垢版 |
2021/01/08(金) 19:34:40.54ID:hBRzO/B9
STLつかうと一気に実行ファイルサイズが10倍に?！

環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない

すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？

#include <stdafx.h>
後死ね。

言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
0004デフォルトの名無しさん
垢版 |
2021/01/08(金) 19:38:13.11ID:8XBZO/70
operator->*を好き勝手にオーバーロードするのは
C++厨二病なら誰しもが通る道だと思ってる
0007デフォルトの名無しさん
垢版 |
2021/01/08(金) 20:55:30.03ID:lmjqKHzd
だって演算子オーバーロード楽しいし！
それSpirit作者のジョエルさんにも言えるの？
0008デフォルトの名無しさん
垢版 |
2021/01/08(金) 21:03:27.15ID:NkKDsd1u
% を三次元ベクトルのクロス積にするのはかつて自分も思いついたけど、勧められないって立場の人も居て
演算子オーバーロードが自然かそうでないかってのは人に拠るなと思った
自分の価値観で言えばiostreamの >> とかってあんまり自然じゃないが
他に何がいいかって言われてもないので仕方ない
0010デフォルトの名無しさん
垢版 |
2021/01/08(金) 21:17:01.55ID:U7HVBqAl
絵文字プログラミングが来る
なので独自オペレータは出来た方がいい
0011デフォルトの名無しさん
垢版 |
2021/01/08(金) 21:44:49.24ID:gxkYqo9D
>>4
わしは20年ぐらい前にその道を通った
だから若者がその道を通ることについては何もいわない
ほっといて気がつかないならダメ人材だし
使える人材は自分で気がつく
0012デフォルトの名無しさん
垢版 |
2021/01/09(土) 00:35:22.39ID:8yDnsj0x
キーワードも再定義可能にしてﾎｽｲ
0014デフォルトの名無しさん
垢版 |
2021/01/09(土) 01:39:13.52ID:InkVVK6p
#define private public
ってテクニックのことか。
0018デフォルトの名無しさん
垢版 |
2021/01/09(土) 10:07:37.60ID:c2CH7ey/
この辺かな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すんな）
0020デフォルトの名無しさん
垢版 |
2021/01/09(土) 20:30:21.03ID:w9vYk25X
>>13
何言ってんだおめー；；；
0021デフォルトの名無しさん
垢版 |
2021/01/09(土) 21:18:55.59ID:jpx8Mcv4
C++はプリプロセッサが発展する方向にいかなくて本当に良かった
プリプロセッサを吸収して凄いことになってる気はするが
0023デフォルトの名無しさん
垢版 |
2021/01/09(土) 21:37:52.40ID:Te5slSqE
(でも楽しいよね
(コンパイル直前のコードが数個のプリミティブにまで還元されちまう楽しい言語もあるしな))
0024デフォルトの名無しさん
垢版 |
2021/01/09(土) 22:11:02.76ID:w9vYk25X
プリプロセッサはC言語の目的（OSを様々なプラットフォームに移植可能な共通ソースコードとして書く）ための
必要欠く書くべからざるしくみとして導入され、できた時点で仕様としてはほぼ過不足なかった
という印象

そういう目的のブツなので、キーワードの再定義には全く不向き
0026デフォルトの名無しさん
垢版 |
2021/01/10(日) 07:04:45.26ID:pzwk9NYM
最近は#includeと#defineしか使ってない。
0027デフォルトの名無しさん
垢版 |
2021/01/10(日) 08:03:37.57ID:pzwk9NYM
#defineじゃなくて#pragma onceだった。
0032デフォルトの名無しさん
垢版 |
2021/01/10(日) 11:49:17.12ID:WbJbdET/
#pragma便利よね　ライブラリのリンク指定とかも
0033はちみつ餃子 ◆8X2XSCHEME
垢版 |
2021/01/10(日) 11:50:54.98ID:smlN1G6e
>>8
そう、 iostream は「仕方ない」と思うんだよな。

C++11 で variadic template が導入されるまでは
可変長引数を安全な型システムの中で扱えなかった。
仕方がないから演算子でなんとかそれっぽくしただけ。
演算子の中で比較的それっぽいのが << や >> だっただけ。

>>9
そういう観点から見ると、パスや日付の区切りに / を使うのは
演算子にしなければならない仕方なさは感じられない。
演算子にするなら / は比較的自然な選択ではあると思うけど。
0035デフォルトの名無しさん
垢版 |
2021/01/10(日) 11:57:06.83ID:uVXyGOJo
ファイルパスってチェーンしたいものの筆頭格だから演算子にするのは妥当だと思うけど
0036デフォルトの名無しさん
垢版 |
2021/01/10(日) 12:20:31.40ID:pzwk9NYM
>>28
使ってるわい。
0037デフォルトの名無しさん
垢版 |
2021/01/10(日) 12:20:58.71ID:pzwk9NYM
とはいえレスくれてありがとうｗ
0038デフォルトの名無しさん
垢版 |
2021/01/10(日) 12:38:01.52ID:stlWAB5c
>>35
std::path だと operator/= だな。
優先順位とか戻り値の型とか理由はあるんだろうが、やはり無理してる感は拭えない。
0039デフォルトの名無しさん
垢版 |
2021/01/10(日) 23:28:34.84ID:9cXVj8qL
mutexって同時だとどうなるの？
0040デフォルトの名無しさん
垢版 |
2021/01/10(日) 23:32:27.11ID:9cXVj8qL
信用して使うしかないけど…本当に同時で来たら…どうなるのかなぁ…と思って…。
0041デフォルトの名無しさん
垢版 |
2021/01/10(日) 23:43:03.84ID:1knBg1rC
同時に入ろうとしたら同時に入るのではない別の世界線に分岐するから
結局同時にならない
0043デフォルトの名無しさん
垢版 |
2021/01/11(月) 00:44:15.09ID:AtO8PUuj
それだと…CPUの負荷や調子によって…同時になるって…事だよ…。
0044デフォルトの名無しさん
垢版 |
2021/01/11(月) 00:45:46.62ID:AtO8PUuj
mutex…危ういな…どうしよう…。運に任せて…諦めるか…。
0045デフォルトの名無しさん
垢版 |
2021/01/11(月) 00:54:29.81ID:AtO8PUuj
運任せは辛い…。
0048デフォルトの名無しさん
垢版 |
2021/01/11(月) 01:59:20.31ID:3nmpeNiQ
>>46
信用できないならソースやアセンブリ読めよ。ここで名無しに答えてもらっても、信用できないんだろ？
0049デフォルトの名無しさん
垢版 |
2021/01/11(月) 03:08:34.69ID:KSKcxhht
MutexはOSに依存するので絶対に大丈夫ということはないですが、数々のトラブルを引き起こし最も懸念されたLinuxが安定してきてるので、現在では実用上問題がないレベルにあると思います。
0050デフォルトの名無しさん
垢版 |
2021/01/11(月) 03:36:14.65ID:dLrb5ZQk
マルチCPUでバスリクエストが同時に出た場合の制御なんて明確に定義されてんだろうが
OS依存だハード依存だと逃げているから見えない不安に怯えることになるんだよ
0051デフォルトの名無しさん
垢版 |
2021/01/11(月) 06:01:13.69ID:vFi9Z+AQ
LinuxのMutexって使いにくいよね
俺はWindowsから入ったからMutexって名前付きが当たり前だと思ってたんだけどLinuxのMutexには名前がない
どうやって複数のプロセス間で同じMutexを使うんだよ・・・って悩んだ
共有メモリなんかでMutexのアドレスを受け渡しするらしいんだけどさ
面倒くさくなってLinux版の同期制御はファイルロックにしちゃった。。
0052デフォルトの名無しさん
垢版 |
2021/01/11(月) 06:47:08.93ID:KSKcxhht
LinuxのファイルロックはNFSで（※私たちにはバグのように見える）仕様通りの動作をするので気を付けたほうが良いですよ。

ユーザーが指定したファイルやディレクトリを不用意に使用すると再現性の無いバグに悩まされます。
0053デフォルトの名無しさん
垢版 |
2021/01/11(月) 06:56:23.61ID:vFi9Z+AQ
>>52
アドバイスありがとう
Linuxで共有メモリの使い方もよく分からなくて
共有メモリも書いてる途中で読み取りされたら困るから
「書いたよー」「読み終わったよー」ってプロセス間同期したいんだけどMutex受け渡しの前に同期処理って・・・
それで共有メモリの読み書きをファイルロックで同期してMutexを渡すかなーって考えてるうちに
もうファイルロックだけでいいんじゃないかってなってしまった

一般的にはどうやってやるのがよかったんだろ？
0054デフォルトの名無しさん
垢版 |
2021/01/11(月) 07:35:12.79ID:KSKcxhht
>>53
結局、「NFSではバグります」と注意したうえでファイルロックを使うことが一般的に行われてるみたいですよ。

逆に言うと、NFSだけ気を付ければ、問題が起きないみたいです。
0056デフォルトの名無しさん
垢版 |
2021/01/11(月) 08:06:43.86ID:vFi9Z+AQ
>>54
ありがとう　ちょと安心した
0057デフォルトの名無しさん
垢版 |
2021/01/11(月) 08:16:58.50ID:vFi9Z+AQ
>>55
コード見てみましたけどMutexの作成と共有メモリの書き込みが終わってからforkしてますね
forkした親と子ならそれでもいいんでしょうけど
実際は親子ではないプロセス間でMutex使いたくなったりするじゃないですか
Mutexが作成される前や共有メモリへの書き込み完了前にスレーブがMutexを要求しに来ると困ります
0058デフォルトの名無しさん
垢版 |
2021/01/11(月) 08:38:54.12ID:WYfXTDe9
>>51
名前付きも普通にある
sem_open
名前はセマフォだが当然mutexとして使える

目的がメッセージのやり取りならmkfifoも使える
0059デフォルトの名無しさん
垢版 |
2021/01/11(月) 08:48:31.88ID:3OtB0f6U
mutexじゃなくて名前付きセマフォなら普通にプロセス間で使えなかったっけ？
0061デフォルトの名無しさん
垢版 |
2021/01/11(月) 09:22:15.64ID:KSKcxhht
>>60
Linuxではファイルロックで良いよ。
0062デフォルトの名無しさん
垢版 |
2021/01/11(月) 09:28:25.14ID:vFi9Z+AQ
セマフォのほうには名前付きあったんですね見落としてました
ありがとう！
0063デフォルトの名無しさん
垢版 |
2021/01/11(月) 09:39:24.93ID:vFi9Z+AQ
あと別のところでソケットを排他リソースで使うというアイデアを教えてもらったことあります
同じポート番号をバインドできるのは1つだけだからこれを排他に使うという案
0064デフォルトの名無しさん
垢版 |
2021/01/11(月) 09:52:46.06ID:KSKcxhht
3年ぶりの建設的なスレだな。
0066デフォルトの名無しさん
垢版 |
2021/01/11(月) 10:39:47.37ID:sBoV/AFh
>>51
pthread周りはなんであんな仕様なのか謎
CPUのアーキテクチャーを深く知れば合理性を得心できるのかどうか、
0067デフォルトの名無しさん
垢版 |
2021/01/11(月) 11:25:14.07ID:vFi9Z+AQ
>>65
それはファイルロック（flock関数）ではなく、単純にファイルの存在チェックをしているだけじゃないですか？
flockを使ったファイルロックならプロセス異常終了時にOSによってロックが解放されます
0068デフォルトの名無しさん
垢版 |
2021/01/11(月) 12:46:20.78ID:vpEQZDgx
ミックスジュースよりセックスジュースが好きですね
0069デフォルトの名無しさん
垢版 |
2021/01/11(月) 14:25:33.73ID:EL34sMb+
唐突に何いいだすねん君は!
(‘д‘⊂彡☆))Д´)ﾊﾟｰﾝ <ミックスジュースよりセックスジュースが好きですね
0071デフォルトの名無しさん
垢版 |
2021/01/11(月) 16:14:45.22ID:AtO8PUuj
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だと仮定しても…カーネルを疑うなんて…
本当に…ナンセンスな話なので…一応…信用して使うことにします…。
0072デフォルトの名無しさん
垢版 |
2021/01/11(月) 16:55:02.21ID:AtO8PUuj
39です…。
結局…fullでなくても…atomic_exchange_acqが呼ばれているようです…アトミック操作です…。
なので…みなさん…安心して使いましょう…。
0073デフォルトの名無しさん
垢版 |
2021/01/11(月) 16:56:14.48ID:KSKcxhht
>>72
そこでやめずに、atomic_exchange_acqの中まで追いかけてみませんか？
0075デフォルトの名無しさん
垢版 |
2021/01/11(月) 21:32:01.48ID:KM6/Ii6v
Debian woody の頃まで posix thread は使い物にならなかったが Debian etch からようやく使い物になった印象だな
当時から利用している身にしては
0076デフォルトの名無しさん
垢版 |
2021/01/12(火) 05:50:41.37ID:pJAexhLb
わりと最近ですね。
0077デフォルトの名無しさん
垢版 |
2021/01/12(火) 07:34:00.56ID:V95G+u6D
woodyって20年くらい前だっけ
最初はJavaVMもグリーンスレッドというVM内の仮想スレッド実装だったんだよね
あれもOSネイティブのスレッドが信用されてなかったからなのかな
もちろん、現在のJavaVMはOSのネイティブスレッド使う実装になってるけどね
0078デフォルトの名無しさん
垢版 |
2021/01/12(火) 07:44:47.10ID:pJAexhLb
Javaといえばブラック何とかプロジェクトがSUNに文句言ってなかったっけ？
0079デフォルトの名無しさん
垢版 |
2021/01/12(火) 07:45:53.88ID:pJAexhLb
Etchが2007年と書いてあるな。
0080デフォルトの名無しさん
垢版 |
2021/01/12(火) 09:08:57.41ID:e5lAHXYT
設計思想的なことについて質問があります。
クラスの使い方がよく分かりません。

僕が今何かを作ろうと思ったら、関数の集まりが引数や返り値のやり取りを通じて協調するような設計をしてしまいます。
この引数や返り値が多く複雑になったりしてきたらクラスを用いた設計を考える、という理解は正しいでしょうか？
0081デフォルトの名無しさん
垢版 |
2021/01/12(火) 09:22:47.73ID:XkW3hQXX
>>80
正しいかどうかは知らないし気にしないでいいと思うけど、
そういう場合はただのデータの集まりとして構造体（これもクラスの一種だけど）を使うだけでも簡単になるだろうね。
0082デフォルトの名無しさん
垢版 |
2021/01/12(火) 13:35:30.39ID:lxco4c0J
個人的には、一度無理にでも概念(ウインドウとか表示とか作ってるソフトの主要な概念)をクラス名にして作ってみるといいとおも
やってるうちに慣れてくる
0083デフォルトの名無しさん
垢版 |
2021/01/12(火) 14:01:10.35ID:V95G+u6D
そうだね
なにかを題材にしてオブジェクト指向やってみるのがいいと思う
でもウインドウはどうかなー　そもそもUIツールキットをある程度知らないといけないし
GUIってオブジェクト指向らしからぬ部分も多いので

もっとビジネスロジック中心の題材がいいと思うよ　たとえば掲示板システムとか
板には複数のスレがあって、各スレの中には複数のレスが並んでて、スレの書き込むメソッドでレスが1つ増えてーみたいな
0084デフォルトの名無しさん
垢版 |
2021/01/12(火) 15:56:33.61ID:LUlB/OIG
>>4 >>11
. を再定義したいと思った
0085デフォルトの名無しさん
垢版 |
2021/01/12(火) 17:32:55.18ID:+0XoTmdG
>>82
初歩的な質問なのですが、クラスってモノじゃなくて概念でも良いのでしょうか
つまり、歩く人のプログラムを作るとき、人というクラスが歩くというメソッドを持っていても良いし、歩くというクラスが一歩進むというメソッドを持っていても良いのでしょうか
言語の仕様上はもちろんどちらでも良いと思いますが、どちらの設計の方が筋が良いということはないと思って良いですか？
0086デフォルトの名無しさん
垢版 |
2021/01/12(火) 17:34:51.31ID:fQCYjk84
ナントカ系の関数群みたいに相互に関連し合っているものを
暗黙じゃなく明確化するのがクラスだよ
0087デフォルトの名無しさん
垢版 |
2021/01/12(火) 17:38:10.34ID:V95G+u6D
>>85
「歩く」をクラスにするよりは「歩ける」をインターフェースにしたらどうかな
人間クラスに「歩ける」インターフェースを実装することで「歩く」メソッドがあることを保証できる

対象ドメインをどのようにモデル化するかは状況や要件次第
0089デフォルトの名無しさん
垢版 |
2021/01/12(火) 19:50:41.34ID:YNFRivpW
>>87
「歩け」インターフェースを定義したらインスタンスが歩ける想定であることは自明なのでは…

ちなメソッドは一般にオブジェクトの状態変化を引き起こすﾌﾞﾂなので
命令型プログラミングの範疇であり命令形で命名すうるが正しい

※ 個人の感想です
0090デフォルトの名無しさん
垢版 |
2021/01/12(火) 19:52:42.41ID:YNFRivpW
しかしインスタンスの生成というプロセスは関数型プログラミングから拝借しており、
命令型と関数型のいいとこ取りしようとして失敗した
classベースのオブジェクト志向は
0091デフォルトの名無しさん
垢版 |
2021/01/12(火) 19:58:16.79ID:GTfU1r+6
何ベースのが成功なの？
0092デフォルトの名無しさん
垢版 |
2021/01/13(水) 09:25:15.89ID:X1FbeZvQ
場合によっては歩くクラスもありだと思うよ。
ゲームで次の行動を一つずつ記憶させたい場合とか。
commandパターン、mementoパターンでググって
0093デフォルトの名無しさん
垢版 |
2021/01/13(水) 09:45:27.73ID:D0cZCa+j
歩くということは、位置が変化する。
現在位置は人オブジェクトのプロパティなのか？
それでええのか？
0094デフォルトの名無しさん
垢版 |
2021/01/13(水) 11:14:57.57ID:XODVGtfI
>>93
良くね？


>>87
インターフェースって継承される前提のものなんですよね？
どのクラスが「歩ける」を継承するんですか？
0095デフォルトの名無しさん
垢版 |
2021/01/13(水) 12:34:30.18ID:QVnLWQ3q
>>85
数値化できるものなら何でもオーケーだ
歩行を数値化するにはN個の関節を持つM本の脚をパラメータとし時間経過ごとの接地点と関節の位置をジェネレータみたいに連続的に返すような設計が考えられる
0096デフォルトの名無しさん
垢版 |
2021/01/13(水) 13:12:01.01ID:D0cZCa+j
>>94
じゃあ将棋の駒オブジェクトはプロパティとして位置を持っているのか？
0097デフォルトの名無しさん
垢版 |
2021/01/13(水) 14:09:32.74ID:D0cZCa+j
俺の考えるOOシステムでは、駒オブジェクトは盤面オブジェクトやルールブックオブジェクトへの参照を持っいる。

駒オブジェクトへ前へ3移動とメッセージを送ると、駒オブジェクトはルールブックオブジェクトと盤面オブジェクトを用いて、移動可能であれば盤面オブジェクトへ自身を移動するようメッセージングする。
0099デフォルトの名無しさん
垢版 |
2021/01/13(水) 15:38:23.35ID:CyYDkVRJ
システム次第でしょ。
もしも将棋の駒が自律歩行多脚戦車だったら、GPSシステムがすべての位置情報を管理してるなんておかしいし。
0100デフォルトの名無しさん
垢版 |
2021/01/13(水) 15:38:43.61ID:D0cZCa+j
enum class なら可能。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況