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で（※私たちにはバグのように見える）仕様通りの動作をするので気を付けたほうが良いですよ。

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