C++相談室 part154

**デフォルトの名無しさん** · 2021/01/08(金) 17:54:00.55

※前スレ
C++相談室 part153
https://mevius.5ch.net/test/read.cgi/tech/1602339500/

テンプレここまで

**デフォルトの名無しさん** · 2021/01/08(金) 17:56:28.28

おつかれー

**デフォルトの名無しさん** · 2021/01/08(金) 19:34:40.54

STLつかうと一気に実行ファイルサイズが10倍に?！

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

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

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

#include <stdafx.h>
後死ね。

言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

**デフォルトの名無しさん** · 2021/01/08(金) 19:38:13.11

operator->*を好き勝手にオーバーロードするのは
C++厨二病なら誰しもが通る道だと思ってる

**デフォルトの名無しさん** · 2021/01/08(金) 20:05:42.45

厨二病以下だね沼二病か幼長病レベル

**デフォルトの名無しさん** · 2021/01/08(金) 20:33:39.47

>>3
お前が死ね

**デフォルトの名無しさん** · 2021/01/08(金) 20:55:30.03

だって演算子オーバーロード楽しいし！
それSpirit作者のジョエルさんにも言えるの？

**デフォルトの名無しさん** · 2021/01/08(金) 21:03:27.15

% を三次元ベクトルのクロス積にするのはかつて自分も思いついたけど、勧められないって立場の人も居て
演算子オーバーロードが自然かそうでないかってのは人に拠るなと思った
自分の価値観で言えばiostreamの >> とかってあんまり自然じゃないが
他に何がいいかって言われてもないので仕方ない

**デフォルトの名無しさん** · 2021/01/08(金) 21:08:29.47

<filesystem>のディレクトリ区切りがoperator/なのとかオモロイやん

**デフォルトの名無しさん** · 2021/01/08(金) 21:17:01.55

絵文字プログラミングが来る
なので独自オペレータは出来た方がいい

**デフォルトの名無しさん** · 2021/01/08(金) 21:44:49.24

>>4
わしは20年ぐらい前にその道を通った
だから若者がその道を通ることについては何もいわない
ほっといて気がつかないならダメ人材だし
使える人材は自分で気がつく

**デフォルトの名無しさん** · 2021/01/09(土) 00:35:22.39

キーワードも再定義可能にしてﾎｽｲ

**デフォルトの名無しさん** · 2021/01/09(土) 01:15:10.33

#defineでイケるやろ

**デフォルトの名無しさん** · 2021/01/09(土) 01:39:13.52

#define private public
ってテクニックのことか。

**デフォルトの名無しさん** · 2021/01/09(土) 04:17:16.54

>>14
それコンパイル通っちゃうの？
プリプロセスだからOKなのか・・・

**デフォルトの名無しさん** · 2021/01/09(土) 09:21:23.56

キーワードをdefineするのは規格上は未定義動作
でもだいたい通っちゃうな

**デフォルトの名無しさん** · 2021/01/09(土) 09:27:02.27

その条文どこだっけ

**デフォルトの名無しさん** · 2021/01/09(土) 10:07:37.60

この辺かな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すんな）

**デフォルトの名無しさん** · 2021/01/09(土) 11:17:12.79

ｔｈｘ

**デフォルトの名無しさん** · 2021/01/09(土) 20:30:21.03

>>13
何言ってんだおめー；；；

**デフォルトの名無しさん** · 2021/01/09(土) 21:18:55.59

C++はプリプロセッサが発展する方向にいかなくて本当に良かった
プリプロセッサを吸収して凄いことになってる気はするが

**デフォルトの名無しさん** · 2021/01/09(土) 21:24:33.16

禿の方針だからね
スコープに従わない反逆者の排除は

**デフォルトの名無しさん** · 2021/01/09(土) 21:37:52.40

(でも楽しいよね
(コンパイル直前のコードが数個のプリミティブにまで還元されちまう楽しい言語もあるしな))

**デフォルトの名無しさん** · 2021/01/09(土) 22:11:02.76

プリプロセッサはC言語の目的（OSを様々なプラットフォームに移植可能な共通ソースコードとして書く）ための
必要欠く書くべからざるしくみとして導入され、できた時点で仕様としてはほぼ過不足なかった
という印象

そういう目的のブツなので、キーワードの再定義には全く不向き

**デフォルトの名無しさん** · 2021/01/10(日) 07:00:15.18

プリプロセスおもしろいやん
俺プリプロセス大好き

**デフォルトの名無しさん** · 2021/01/10(日) 07:04:45.26

最近は#includeと#defineしか使ってない。

**デフォルトの名無しさん** · 2021/01/10(日) 08:03:37.57

#defineじゃなくて#pragma onceだった。

**デフォルトの名無しさん** · 2021/01/10(日) 10:29:09.95

どうやったらその2つを取り違えできるんだww
ほんとにつかってる？？

**デフォルトの名無しさん** · 2021/01/10(日) 10:29:46.47

#pragma onceとか#inlude_nextとか標準に入れてほしくはある

**デフォルトの名無しさん** · 2021/01/10(日) 10:45:39.55

#pragma onceはもう標準のつもりで使ってるわ

**デフォルトの名無しさん** · 2021/01/10(日) 11:35:58.46

>>25
そういう時期もあったな…（遠い目）

**デフォルトの名無しさん** · 2021/01/10(日) 11:49:17.12

#pragma便利よね　ライブラリのリンク指定とかも

**はちみつ餃子** ◆8X2XSCHEME · 2021/01/10(日) 11:50:54.98

>>8
そう、 iostream は「仕方ない」と思うんだよな。

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

>>9
そういう観点から見ると、パスや日付の区切りに / を使うのは
演算子にしなければならない仕方なさは感じられない。
演算子にするなら / は比較的自然な選択ではあると思うけど。

**デフォルトの名無しさん** · 2021/01/10(日) 11:53:18.07

シフト演算なんてほとんど使わんしなあ

**デフォルトの名無しさん** · 2021/01/10(日) 11:57:06.83

ファイルパスってチェーンしたいものの筆頭格だから演算子にするのは妥当だと思うけど

**デフォルトの名無しさん** · 2021/01/10(日) 12:20:31.40

>>28
使ってるわい。

**デフォルトの名無しさん** · 2021/01/10(日) 12:20:58.71

とはいえレスくれてありがとうｗ

**デフォルトの名無しさん** · 2021/01/10(日) 12:38:01.52

>>35
std::path だと operator/= だな。
優先順位とか戻り値の型とか理由はあるんだろうが、やはり無理してる感は拭えない。

**デフォルトの名無しさん** · 2021/01/10(日) 23:28:34.84

mutexって同時だとどうなるの？

**デフォルトの名無しさん** · 2021/01/10(日) 23:32:27.11

信用して使うしかないけど…本当に同時で来たら…どうなるのかなぁ…と思って…。

**デフォルトの名無しさん** · 2021/01/10(日) 23:43:03.84

同時に入ろうとしたら同時に入るのではない別の世界線に分岐するから
結局同時にならない

**デフォルトの名無しさん** · 2021/01/11(月) 00:43:54.84

posix平行宇宙論

**デフォルトの名無しさん** · 2021/01/11(月) 00:44:15.09

それだと…CPUの負荷や調子によって…同時になるって…事だよ…。

**デフォルトの名無しさん** · 2021/01/11(月) 00:45:46.62

mutex…危ういな…どうしよう…。運に任せて…諦めるか…。

**デフォルトの名無しさん** · 2021/01/11(月) 00:54:29.81

運任せは辛い…。

**デフォルトの名無しさん** · 2021/01/11(月) 01:30:50.91

https://stackoverflow.com/questions/7373202/what-happens-if-two-theads-lock-a-mutex-concurrently
大丈夫だと言っているが…ほんまかいな…と思います…迷信はつきもの。

**デフォルトの名無しさん** · 2021/01/11(月) 01:37:51.07

テストプログラム作ってさっさと検証しろ無能

**デフォルトの名無しさん** · 2021/01/11(月) 01:59:20.31

>>46
信用できないならソースやアセンブリ読めよ。ここで名無しに答えてもらっても、信用できないんだろ？

**デフォルトの名無しさん** · 2021/01/11(月) 03:08:34.69

MutexはOSに依存するので絶対に大丈夫ということはないですが、数々のトラブルを引き起こし最も懸念されたLinuxが安定してきてるので、現在では実用上問題がないレベルにあると思います。

**デフォルトの名無しさん** · 2021/01/11(月) 03:36:14.65

マルチCPUでバスリクエストが同時に出た場合の制御なんて明確に定義されてんだろうが
OS依存だハード依存だと逃げているから見えない不安に怯えることになるんだよ

**デフォルトの名無しさん** · 2021/01/11(月) 06:01:13.69

LinuxのMutexって使いにくいよね
俺はWindowsから入ったからMutexって名前付きが当たり前だと思ってたんだけどLinuxのMutexには名前がない
どうやって複数のプロセス間で同じMutexを使うんだよ・・・って悩んだ
共有メモリなんかでMutexのアドレスを受け渡しするらしいんだけどさ
面倒くさくなってLinux版の同期制御はファイルロックにしちゃった。。

**デフォルトの名無しさん** · 2021/01/11(月) 06:47:08.93

LinuxのファイルロックはNFSで（※私たちにはバグのように見える）仕様通りの動作をするので気を付けたほうが良いですよ。

ユーザーが指定したファイルやディレクトリを不用意に使用すると再現性の無いバグに悩まされます。

**デフォルトの名無しさん** · 2021/01/11(月) 06:56:23.61

>>52
アドバイスありがとう
Linuxで共有メモリの使い方もよく分からなくて
共有メモリも書いてる途中で読み取りされたら困るから
「書いたよー」「読み終わったよー」ってプロセス間同期したいんだけどMutex受け渡しの前に同期処理って・・・
それで共有メモリの読み書きをファイルロックで同期してMutexを渡すかなーって考えてるうちに
もうファイルロックだけでいいんじゃないかってなってしまった

一般的にはどうやってやるのがよかったんだろ？

**デフォルトの名無しさん** · 2021/01/11(月) 07:35:12.79

>>53
結局、「NFSではバグります」と注意したうえでファイルロックを使うことが一般的に行われてるみたいですよ。

逆に言うと、NFSだけ気を付ければ、問題が起きないみたいです。

**デフォルトの名無しさん** · 2021/01/11(月) 08:06:23.60

ちょっとググっただけだけどそんなに難しいかなぁ？
https://www.geekpage.jp/programming/linux-network/book/07/7-41.php

**デフォルトの名無しさん** · 2021/01/11(月) 08:06:43.86

>>54
ありがとう　ちょと安心した

**デフォルトの名無しさん** · 2021/01/11(月) 08:16:58.50

>>55
コード見てみましたけどMutexの作成と共有メモリの書き込みが終わってからforkしてますね
forkした親と子ならそれでもいいんでしょうけど
実際は親子ではないプロセス間でMutex使いたくなったりするじゃないですか
Mutexが作成される前や共有メモリへの書き込み完了前にスレーブがMutexを要求しに来ると困ります

**デフォルトの名無しさん** · 2021/01/11(月) 08:38:54.12

>>51
名前付きも普通にある
sem_open
名前はセマフォだが当然mutexとして使える

目的がメッセージのやり取りならmkfifoも使える

**デフォルトの名無しさん** · 2021/01/11(月) 08:48:31.88

mutexじゃなくて名前付きセマフォなら普通にプロセス間で使えなかったっけ？

**デフォルトの名無しさん** · 2021/01/11(月) 09:14:02.58

>>57
応用力ないの？
>>58-59みたいにセマフォ使うこともできるし、名前付き共有メモリー + Mutexでもいいだろ

**デフォルトの名無しさん** · 2021/01/11(月) 09:22:15.64

>>60
Linuxではファイルロックで良いよ。

**デフォルトの名無しさん** · 2021/01/11(月) 09:28:25.14

セマフォのほうには名前付きあったんですね見落としてました
ありがとう！

**デフォルトの名無しさん** · 2021/01/11(月) 09:39:24.93

あと別のところでソケットを排他リソースで使うというアイデアを教えてもらったことあります
同じポート番号をバインドできるのは1つだけだからこれを排他に使うという案

**デフォルトの名無しさん** · 2021/01/11(月) 09:52:46.06

3年ぶりの建設的なスレだな。

**デフォルトの名無しさん** · 2021/01/11(月) 10:09:50.89

>>61
ファイルロックはロックしたままプロセス死ぬとリブートしても解消できないのがね

**デフォルトの名無しさん** · 2021/01/11(月) 10:39:47.37

>>51
pthread周りはなんであんな仕様なのか謎
CPUのアーキテクチャーを深く知れば合理性を得心できるのかどうか、

**デフォルトの名無しさん** · 2021/01/11(月) 11:25:14.07

>>65
それはファイルロック（flock関数）ではなく、単純にファイルの存在チェックをしているだけじゃないですか？
flockを使ったファイルロックならプロセス異常終了時にOSによってロックが解放されます

**デフォルトの名無しさん** · 2021/01/11(月) 12:46:20.78

ミックスジュースよりセックスジュースが好きですね

**デフォルトの名無しさん** · 2021/01/11(月) 14:25:33.73

唐突に何いいだすねん君は!
(‘д‘⊂彡☆))Д´)ﾊﾟｰﾝ <ミックスジュースよりセックスジュースが好きですね

**デフォルトの名無しさん** · 2021/01/11(月) 14:41:16.25

ラブジュースだろ

**デフォルトの名無しさん** · 2021/01/11(月) 16:14:45.22

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だと仮定しても…カーネルを疑うなんて…
本当に…ナンセンスな話なので…一応…信用して使うことにします…。

**デフォルトの名無しさん** · 2021/01/11(月) 16:55:02.21

39です…。
結局…fullでなくても…atomic_exchange_acqが呼ばれているようです…アトミック操作です…。
なので…みなさん…安心して使いましょう…。

**デフォルトの名無しさん** · 2021/01/11(月) 16:56:14.48

>>72
そこでやめずに、atomic_exchange_acqの中まで追いかけてみませんか？

**デフォルトの名無しさん** · 2021/01/11(月) 16:56:26.10

https://blog.sakasin.net/pthread-mutex-with-glibc
ソースです…。

**デフォルトの名無しさん** · 2021/01/11(月) 21:32:01.48

Debian woody の頃まで posix thread は使い物にならなかったが Debian etch からようやく使い物になった印象だな
当時から利用している身にしては

**デフォルトの名無しさん** · 2021/01/12(火) 05:50:41.37

わりと最近ですね。

**デフォルトの名無しさん** · 2021/01/12(火) 07:34:00.56

woodyって20年くらい前だっけ
最初はJavaVMもグリーンスレッドというVM内の仮想スレッド実装だったんだよね
あれもOSネイティブのスレッドが信用されてなかったからなのかな
もちろん、現在のJavaVMはOSのネイティブスレッド使う実装になってるけどね

**デフォルトの名無しさん** · 2021/01/12(火) 07:44:47.10

Javaといえばブラック何とかプロジェクトがSUNに文句言ってなかったっけ？

**デフォルトの名無しさん** · 2021/01/12(火) 07:45:53.88

Etchが2007年と書いてあるな。

**デフォルトの名無しさん** · 2021/01/12(火) 09:08:57.41

設計思想的なことについて質問があります。
クラスの使い方がよく分かりません。

僕が今何かを作ろうと思ったら、関数の集まりが引数や返り値のやり取りを通じて協調するような設計をしてしまいます。
この引数や返り値が多く複雑になったりしてきたらクラスを用いた設計を考える、という理解は正しいでしょうか？

**デフォルトの名無しさん** · 2021/01/12(火) 09:22:47.73

>>80
正しいかどうかは知らないし気にしないでいいと思うけど、
そういう場合はただのデータの集まりとして構造体（これもクラスの一種だけど）を使うだけでも簡単になるだろうね。

**デフォルトの名無しさん** · 2021/01/12(火) 13:35:30.39

個人的には、一度無理にでも概念(ウインドウとか表示とか作ってるソフトの主要な概念)をクラス名にして作ってみるといいとおも
やってるうちに慣れてくる

**デフォルトの名無しさん** · 2021/01/12(火) 14:01:10.35

そうだね
なにかを題材にしてオブジェクト指向やってみるのがいいと思う
でもウインドウはどうかなー　そもそもUIツールキットをある程度知らないといけないし
GUIってオブジェクト指向らしからぬ部分も多いので

もっとビジネスロジック中心の題材がいいと思うよ　たとえば掲示板システムとか
板には複数のスレがあって、各スレの中には複数のレスが並んでて、スレの書き込むメソッドでレスが1つ増えてーみたいな

**デフォルトの名無しさん** · 2021/01/12(火) 15:56:33.61

>>4 >>11
. を再定義したいと思った

**デフォルトの名無しさん** · 2021/01/12(火) 17:32:55.18

>>82
初歩的な質問なのですが、クラスってモノじゃなくて概念でも良いのでしょうか
つまり、歩く人のプログラムを作るとき、人というクラスが歩くというメソッドを持っていても良いし、歩くというクラスが一歩進むというメソッドを持っていても良いのでしょうか
言語の仕様上はもちろんどちらでも良いと思いますが、どちらの設計の方が筋が良いということはないと思って良いですか？

**デフォルトの名無しさん** · 2021/01/12(火) 17:34:51.31

ナントカ系の関数群みたいに相互に関連し合っているものを
暗黙じゃなく明確化するのがクラスだよ

**デフォルトの名無しさん** · 2021/01/12(火) 17:38:10.34

>>85
「歩く」をクラスにするよりは「歩ける」をインターフェースにしたらどうかな
人間クラスに「歩ける」インターフェースを実装することで「歩く」メソッドがあることを保証できる

対象ドメインをどのようにモデル化するかは状況や要件次第

**デフォルトの名無しさん** · 2021/01/12(火) 19:05:06.19

メタファとして生き物がよく用いられるけどなんだかなあっていつも思う

**デフォルトの名無しさん** · 2021/01/12(火) 19:50:41.34

>>87
「歩け」インターフェースを定義したらインスタンスが歩ける想定であることは自明なのでは…

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

※ 個人の感想です

**デフォルトの名無しさん** · 2021/01/12(火) 19:52:42.41

しかしインスタンスの生成というプロセスは関数型プログラミングから拝借しており、
命令型と関数型のいいとこ取りしようとして失敗した
classベースのオブジェクト志向は

**デフォルトの名無しさん** · 2021/01/12(火) 19:58:16.79

何ベースのが成功なの？

**デフォルトの名無しさん** · 2021/01/13(水) 09:25:15.89

場合によっては歩くクラスもありだと思うよ。
ゲームで次の行動を一つずつ記憶させたい場合とか。
commandパターン、mementoパターンでググって

**デフォルトの名無しさん** · 2021/01/13(水) 09:45:27.73

歩くということは、位置が変化する。
現在位置は人オブジェクトのプロパティなのか？
それでええのか？

**デフォルトの名無しさん** · 2021/01/13(水) 11:14:57.57

>>93
良くね？

>>87
インターフェースって継承される前提のものなんですよね？
どのクラスが「歩ける」を継承するんですか？

**デフォルトの名無しさん** · 2021/01/13(水) 12:34:30.18

>>85
数値化できるものなら何でもオーケーだ
歩行を数値化するにはN個の関節を持つM本の脚をパラメータとし時間経過ごとの接地点と関節の位置をジェネレータみたいに連続的に返すような設計が考えられる

**デフォルトの名無しさん** · 2021/01/13(水) 13:12:01.01

>>94
じゃあ将棋の駒オブジェクトはプロパティとして位置を持っているのか？

**デフォルトの名無しさん** · 2021/01/13(水) 14:09:32.74

俺の考えるOOシステムでは、駒オブジェクトは盤面オブジェクトやルールブックオブジェクトへの参照を持っいる。

駒オブジェクトへ前へ3移動とメッセージを送ると、駒オブジェクトはルールブックオブジェクトと盤面オブジェクトを用いて、移動可能であれば盤面オブジェクトへ自身を移動するようメッセージングする。

**デフォルトの名無しさん** · 2021/01/13(水) 15:31:14.00

intを継承してmyintクラスを作ることは可能ですか？

**デフォルトの名無しさん** · 2021/01/13(水) 15:38:23.35

システム次第でしょ。
もしも将棋の駒が自律歩行多脚戦車だったら、GPSシステムがすべての位置情報を管理してるなんておかしいし。

**デフォルトの名無しさん** · 2021/01/13(水) 15:38:43.61

enum class なら可能。

**デフォルトの名無しさん** · 2021/01/13(水) 20:01:32.91

C++はテンプレートがあるので設計の詳細を先送りできる。
その特徴を生かせるように、プッシュ型を流行らせませんか？
プッシュ型は、前提が少ないので、利用者が自由に組み合わせることが出来ます。

これは、インターフェースによって事前に詳細を設計してしまう方式と真逆かもしれないが、組み合わせによって機能を作ることが出来まっする。