C++相談室 part165

2023/10/31(火) 07:37:38.52

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

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

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2025/03/23(日) 21:04:30.15

>>789
shared_ptrを使えと言ってるのでなくunique_ptrの意味が特にないと言ってる
別に使ってもいいけどお前それをわかってんの？ってこと？
ついでに言っておけばshared_ptrを使う場合ってのは参照カウントがゼロになったらシングルトンを破棄するみたいな凝った実装する場合に使う

2025/03/24(月) 00:16:57.44

unique_ptrじゃなくてナマポ使えって言ってんの？どこでdeleteする気なの？

2025/03/24(月) 00:22:30.84

>>791
static Fooでいいだろってことだよ
自分で気づけなかったな

2025/03/24(月) 07:56:52.11

えぇ・・・？

2025/03/24(月) 08:43:05.04

>>792
マルチスレッドで問題あるんじゃなかったっけ？
資料どこにあるか忘れたけど。

2025/03/24(月) 08:50:28.31

>>794
ずいぶん前に問題無くなっているのね。
https://cpprefjp.github.io/lang/cpp11/static_initialization_thread_safely.html

2025/03/24(月) 09:19:49.44

>>795
もし解決されてないならunique_ptrでも問題出るでしょ

2025/03/24(月) 23:17:27.23

Makefileについて教えてください。

ベースディレクトリにMakefileがあり、サブディレクトリは以下の構造としたいです
・src\内にhello.c func1.c func2.cが、include\内にfuncs.hがある
・*.oはobj\内に作る
・最終成果物は.\sample.exeとして作る

ソースファイル、ヘッダファイルの増減時にSRCS、INCSを修正すれば済むようにと、
以下のようなMakefileを作っているのですが、makeすると
*** No rule to make target 'obj/hello.o', needed by 'c_sample.exe'. Stop.
となってしまいます
ソースはsrc、オブジェクトはobjディレクトリとしている場合のサフィックスルールが正しくないので
src/hello.cからobj/hello.oを作るルールを表現できていない、と個人的に思っているのですが、
どのようにすれば動作するか教えてください

SRCDIR = ./src
OBJDIR = ./obj
INCDIR = ./include
SRCS = hello.c funcs1.c funcs2.c
OBJS = $(SRCS:%.c=%.o)
INCS = funcs.h
PROGRAM = c_sample.exe
CC = gcc
CFLAGS+= -g -Wall -I$(INCDIR)

.SUFFIXES: .c .o
all: $(PROGRAM)
$(PROGRAM): $(OBJDIR)/$(OBJS) $(INCDIR)/$(INCS)
$(CC) $(CFLAGS) -o $(PROGRAM) $^
.c.o:
$(CC) $(CFLAGS) -c $(SRCDIR)/$<

**797** (ﾜｯﾁｮｲ 4602-BGJw) · 2025/03/24(月) 23:24:39.28

すいません、タブが崩れました

下の方ですが、全角スペースで記載してますが

$(PROGRAM): $(OBJDIR)/$(OBJS) $(INCDIR)/$(INCS)
　　$(CC) $(CFLAGS) -o $(PROGRAM) $^
.c.o:
　　$(CC) $(CFLAGS) -c $(SRCDIR)/$<

こうです

申し訳ありませんでした

**Fish** (ﾜｯﾁｮｲ 652f-MaZR) · 2025/03/25(火) 02:35:59.65

OpenCVについての質問です。VS2022を使用し、includeやopencv_world4100d.libの設定が終わり、検証のためにMatを宣言してimread、imshowのみを書いて検証しようとしたのですが、dllの設定がうまくいってなかったのかコンソールにdllのloadがfailedと大量に出力されます。OpenCVの入れ方を教えてほしいです…まだC++初心者で5チャンの投稿も初心者なので何か変だったらすみません…

2025/03/25(火) 04:37:37.58

>>798
.o:
　　$(CC) $(CFLAGS) -c $(SRCDIR)/$<

>>799
環境変数

2025/03/25(火) 12:24:02.95

>>799
exeと同じディレクトリにloadがfailedと言われるdll置いてみたら?

2025/03/26(水) 11:17:13.88

Makefileを作る時の$<と$?と$^の使い分けを教えて下さい
特に$<が何のためにあるのか分かりません。これだと2番目以降の材料が無視されてしまって動かない場合があるんじゃないかと心配になります。あと、makeは常に新しい材料のみコンパイルするという事は、すべてのケースで$?で良いのではと思ってしまいます。超初歩的な質問だと思いますがよろしくお願いします

2025/03/26(水) 13:48:44.59

C言語だとオブジェクトファイルの依存ファイルは，cファイルとそのcファイルが使うhファイルだけどコンパイルするのはあくまでcファイルだけ
だから依存関係の1つ目にcファイルを，2個目以降にhファイルを書いておけば$<でコンパイルできる

とかかな

2025/03/26(水) 15:00:53.93

>>802
っ https://tex2e.github.io/blog/makefile/automatic-variables

2025/03/26(水) 15:48:44.68

>>797
基本的にサフィックスルールは何十年も前からobsolete扱いなのでやめた方が良い

2025/03/26(水) 20:50:04.73

ところでこの場合の makefile の話は GNU Make を前提にするということでええんか？

**797** (ﾜｯﾁｮｲ 4602-BGJw) · 2025/03/26(水) 22:53:57.57

皆さんいろいろと情報をどうもです
結局、以下のようなものと落ち着いてます
ちなみに使ってる環境のmakeはGNU Make 4.4で、GNU Makeの機能を多用してます

「$(OBJDIR)%.o: $(SRCDIR)%.c」と書ける理由は、pattern rulesという機能なのですかね
ここをforeachとかで書こうとしてましたが、これでいけると聞き、書いてみたら動いたのでもうそのままです

以外に汎用性が出そうだと感じてますが、改良点があればまたご意見ほしいです

PROGRAM = c_sample.exe

SRCDIR = ./src/
OBJDIR = ./obj/
INCDIR = ./include/

SRCS = $(wildcard ${SRCDIR}*.c)
OBJS = $(addprefix $(OBJDIR), $(notdir $(patsubst %.c, %.o, ${SRCS})))
INCS = $(wildcard ${INCDIR}*.h)

CC = gcc
CFLAGS += -g -Wall -I$(INCDIR)

all: $(PROGRAM)

$(PROGRAM): $(OBJS)
　　$(CC) $(CFLAGS) -o $(PROGRAM) $^

$(OBJDIR)%.o: $(SRCDIR)%.c $(INCS) Makefile
　　$(CC) $(CFLAGS) -c $< -o $(patsubst $(SRCDIR)%, $(OBJDIR)%, $@)

**デフォルトの名無しさん** (MX 0H1d-JaxA) · 2025/03/26(水) 23:25:47.70

>>803
>>804

ありがとうございます
助かりました

2025/03/27(木) 00:00:17.61

汎用するのならautotoolsを使った方が良いのでは?

2025/03/27(木) 01:07:35.19

拡張子に exe がついてるということはウィンドウズを想定してるんじゃないの？
cygwin とか msys2 とかだと autotools を入れるのは簡単だけどそうじゃないならめんどいかも。

2025/03/27(木) 02:03:57.32

普通cmakeでしょ
好きじゃないけど

2025/03/27(木) 08:24:51.71

>>807
分かったからもう消えろ
ここはCのスレではないしmakeのスレでもない

2025/03/27(木) 09:16:55.35

makeスレなくなったね

2025/03/27(木) 10:58:28.75

ないと思ったらUNIX板だったようだ

2025/03/27(木) 14:55:01.12

>>812
過疎ってきてるし
C++とmakeは連動すること多いから
話題はあってもいいんじゃねーかと
書き込んでみるテスト

2025/03/27(木) 18:38:06.75

ノーマルスーツを着ろシャア

2025/03/28(金) 12:58:29.90

>>815
あってもいいけどコンパイラの使い方までかな
makeは誘導した方が良いと思う

2025/04/06(日) 00:01:49.29

質問なのですが基底クラスでpublicとした仮想関数の可視性を派生クラスでprivateに狭めることができるのですが
なんでこんな仕様なの？
これは逆に言うと派生クラスでprivateとした一般メソッドに対し、
たまたま同じシグネチャの仮想関数を基底クラスで定義されたら基底クラス経由でprivateとしたメソッドを外部から呼び出せ
てしまいカプセル化の危機……！
そういう仕様になっているメリットとは一体……

2025/04/06(日) 07:42:00.02

前者は仮想関数を派生クラス経由で呼べないように出来る
というか派生のコンストラクタをprivateにして、friend指定したcreatorクラス経由でしか生成出来ないようにするとかそういうのに便利
あと後者は、試してないけど派生の同シグネチャの関数は基底経由で呼べないと思うよ、vtblに登録されてないから

2025/04/06(日) 08:51:38.89

継承に関しては早すぎる最適化の問題もあるから、そのまま使うんじゃなくてアダプタに切り離した方がいいと思う。

Boostあたりにアダプタ用のライブラリないかしらん。

2025/04/06(日) 09:09:40.72

>>818
コードで言えばこういう状況かな？
https://wandbox.org/permlink/gEndnLHWa7qEvNRP

基底にある仮想関数と同じシグネチャならオーバーライドするという規則は単純に言語設計の失敗。
だからこそ override 指定子が導入された。

override 指定子ではオーバーライドのつもりでオーバーライドになっていないときを検出できても
オーバーライドではないつもりでオーバーライドになってしまうことは検出できないのだが……
互換性を壊す変更を入れるわけにもいかずそのままズルズルと今まで失敗を引きずってきたという歴史的経緯。

2025/04/06(日) 09:14:57.63

ああそっか、シグネチャ同じなら強制的にオーバーライドになるんだっけスマン

2025/04/06(日) 09:27:02.17

意図せずオーバーライドになってしまうことがあるのは失敗だが、
意図して private でオーバーライドする分には「そういうインターフェイス」なのだからカプセル化の破綻ではないよ。

2025/04/06(日) 10:21:41.86

リスコフの置換原則を破るからあんまり良くはないと思うけどな
基底クラスとして振る舞わせる気がないならprivate継承すべきだ

2025/04/06(日) 10:25:35.73

>>821
なるほど……
virtualが省略可能なのが諸悪の根源かとｵﾓﾀがそっちか……

>>823
通常はBaseクラス→派生クラス、の順で設計するから「そういうインターフェイス」と考えてだいたい良いのかもしれませんけども
派生クラスまで設計した後にBaseクラスにメソッドを追加して、それがたまたま派生クラス独自に定義したprivateメソッドと
同じシグネチャになってしまった場合、Baseクラス経由で派生クラスのprivateメソッドを意図せず呼べてしまうという
現象が再燃する……

2025/04/06(日) 10:32:27.61

んまーBaseクラスにメソッドを追加しようとする時点で変更の影響範囲を派生クラスまで広げて調査すべき
というのは正論やがコンパイラで検出可能な不都合のチェックのを人にやらせるのはｲﾏｲﾁ……

2025/04/06(日) 11:31:20.83

大抵のコンパイラで普通警告出るやろ？

2025/04/06(日) 11:41:46.34

純粋仮装関数でも無ければ影響無いだろ
だいいち使わない関数なら配慮する必要も無い

2025/04/06(日) 11:42:28.71

全コンパイルは掛かるけどなw

2025/04/06(日) 11:43:04.77

たとえば GCC なら -Wsuggest-override を付けておけば override 指定子なしでオーバーライドしているときを警告する。
https://wandbox.org/permlink/h6PGzqrDAAkAVeJO

だけどこのオプションは -Wall にも -Wextra にも含まれてないから個別に指定しなきゃならなくて、普段は有効になってないのが普通かも。

**デフォルトの名無しさん** (JP 0Hd1-yI6P) · 2025/04/06(日) 11:54:04.73

前から思ってたけど -Wall と銘打ってるのに All じゃないとはこれいかに

**デフォルトの名無しさん** (JP 0Hd1-yI6P) · 2025/04/06(日) 11:54:05.20

前から思ってたけど -Wall と銘打ってるのに All じゃないとはこれいかに

**デフォルトの名無しさん** (JP 0Hd1-yI6P) · 2025/04/06(日) 11:54:58.77

（二重投稿ｽﾏﾝ）

2025/04/06(日) 12:20:48.70

コンストラクタ呼び出しで()の時にinitializer_listを呼んでしまったときの警告と
逆に{}の時にinitializer_list以外を呼んでしまったときの警告がほしい

2025/04/06(日) 12:33:44.13

override指定子って初めて知ったけども-Wallで警告出るのは俺はやだな
警告が大量に出るソースばかりと思うし
警告出すほどにoverride指定子を付けるべきなのかちょっと疑問

2025/04/06(日) 13:09:33.59

overrideなんて飾りです
privateも飾りです

2025/04/06(日) 15:06:13.11

#define class struct
#define private public
#define protected public
すれば大体はすり抜けられる

2025/04/06(日) 16:50:10.05

>>837
`private` などは用途が限定的なキーワードだからそういうことも出来るけど `class` はちょっと問題があるな。

template<class T> class foo {};

みたいなのが破綻する。

2025/04/07(月) 12:25:07.84

classとstructは別ものだからなぁ

2025/04/07(月) 12:42:21.06

C++ の言語仕様的分類では構造体というものはないのだが、 C との関係の都合で微妙な形で struct キーワードは残されてしまった。
これも歴史的経緯による変なところ。

2025/04/07(月) 14:49:45.64

むしろキーワードとしてのclassがいらなかった
型は全部struct、構文の曖昧さを除くためのプレースホルダは全部typenameで良かった

2025/04/07(月) 15:01:27.29

protectedは使った方が良いけどprivateは使いたくなるシーンがほとんど無い

2025/04/07(月) 15:02:24.36

>>841
Rust使え

2025/04/08(火) 02:19:24.63

rustだってどうせ20年もすれば後からあーすればよかったこーすればよかった言ってるよ

2025/04/08(火) 07:45:44.78

Rust はエディションごとに互換性が維持され、逆に言えばエディションをまたぐと互換性を損なっても良いというルール。
そして異なるエディションがひとつのプロジェクトに混在できる。
古いエディションから新しいエディションへの移行はかなり自動化されている。
最初から互換性を捨てることがありうる体制なので歴史的事情をいつまでも引きずることはない……と思うのだがこの体制でうまくいくかはやってみないとわからんね。
二十年くらいすれば結果が見えてくるだろう。

2025/04/08(火) 09:56:44.28

開発ツールごと遺跡になって発掘される毎に解析されるんだよ

2025/04/08(火) 19:53:49.89

似たような仕組みは歴史上何度も再発明されて全て爆死してるし
今の所うまく行ってるように見えてるのは、まだ大して使われてない証拠でしかないっておじさんは思っちゃうよ

2025/04/10(木) 00:16:06.10

現在公開されている世界最速grepツールであるripgrepがRustで組んであるってのがすごい

2025/04/10(木) 17:46:33.43

>>848
C や C++ でやってやれないことはないと思うが使えるプログラムがあるのにフルスクラッチで書きなおそうと思うことがそもそもあまり無いからね。
新しい言語が登場するという形で整理する機会が生じるのは健全な進歩だと思う。

2025/04/11(金) 08:30:12.43

rustで一部の高速なシステムコールが追加されたらそれを使えばC++だろうが何だろうが関係なくなる
でもどうせマルチスレッドのsimd使いなんだろうからシステム全体に過負荷になるからめんどくさい

2025/04/11(金) 08:37:04.65

↑何これ？w

2025/04/11(金) 13:45:57.41

>システムコールが追加されたら
？？

2025/04/11(金) 13:57:42.36

DOS「ファンクションコールと呼べ！」

2025/04/11(金) 14:31:46.86

それってOS付属のランタイムをrustで書いたらって事？

2025/04/11(金) 18:09:26.07

glibcのシステムコールラッパーみたいなものがRustにもあればってことなのかそれともsyscall命令で飛ぶカーネルのコードがRustで書かれてればってことなのか
分からんね

>>850は最近システムコールって言葉を知ったのかもしれない

2025/04/11(金) 18:48:50.71

なんか頭悪そうな人間がたくさん噛みついてきてるけど生産性ゼロだなとしか…
何が言いたいんだよ

お前らが単純にシステムコールを知らなかっただけだろう？
OSに対してサービスの要求するのがシステムコールだ
OSよって呼び方が違う

2025/04/11(金) 19:57:08.33

↑何を馬鹿にされてるかもわかってない

2025/04/11(金) 20:02:48.75

イマドキgrepぐらいAPIで用意しとけと

2025/04/11(金) 20:07:19.88

Rustって今こんなレベル低い人間も流れ込んでるのか
そのうちJava化する運命だな

2025/04/11(金) 20:07:35.60

>>856
そのシステムコールを提供するのはOS側であって「rustで一部の高速なシステムコールが追加されたら」ってのが意味不明だって話だぜ？

2025/04/11(金) 20:08:42.81

>>857
理解不足なのはそっち

2025/04/11(金) 20:09:54.47

>>860
当たり前だろ
馬鹿なのか？

2025/04/11(金) 20:14:09.35

システムコールはOSが提供するのは当たり前
それがRustの特性に合わせた高速化が行われていても使う側はなんでもよいと言う話がなんでわからないのか馬鹿なのかなと

2025/04/11(金) 20:15:15.52

>>862
「rustで一部の高速なシステムコールが追加されたら」について説明を

2025/04/11(金) 20:15:47.00

>>864
幼稚園児なのかな？

2025/04/11(金) 20:18:14.21

お前らrust "に" 一部の高速なシステムコールが～　と書いてあると勘違いしたんだろ
馬鹿すぎる

システムコールが追加されるのはOSだろ
馬鹿馬鹿しい

2025/04/11(金) 20:19:44.78

つまり>>848で書かれているツールの高速性は「Rustの言語仕様や機能に依存した話ではなくOS提供のシステムコールによるものだ」と言いたいのか
ふぅ～ん

2025/04/11(金) 20:20:27.06

>>867
幼稚園児並みの馬鹿発見

2025/04/11(金) 20:23:13.43

馬鹿発見

851 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 4694-PSZj)[sage] 投稿日：2025/04/11(金) 08:37:04.65 ID:5PthuDCs0 [1/2]
↑何これ？w

2025/04/11(金) 20:28:30.50

連投おつかれ
知ったかぶりは恥ずかしいよね

2025/04/11(金) 20:29:30.23

サブ回線使いだすほうが恥ずかしい

2025/04/11(金) 20:34:48.29

なんだよRust界隈のお客さんじゃなくていつもの大天才様くんかよ
おもんな

2025/04/11(金) 20:47:02.26

誰と勘違いしてるんだよ
普段はこのスレに書いてない
>>46が自分だ

2025/04/11(金) 20:52:01.51

ああ，自分の誤った主張を説明しようとするとボロが見えるから自分に反論してくる人にレッテル貼って誤魔化してるのか

2025/04/11(金) 20:55:02.66

それはどっちだよｗ

2025/04/11(金) 21:01:06.49

>>850
何を言っているのか全然わからん。
Rust開発者の主張は
「C/C++並に速くC/C++より安全」
だから、
「rustで一部の高速なシステムコールが追加されたらそれを使えばC++だろうが何だろうが関係なくなる」
というのが高速の話ならそりゃそうだろとしか。
Rustが違うと言っているのはそこじゃなくて、
「ビルド通ればダングリングポインタとかオーバーフローとか無いから安全だよ(safe rust なら)」
ということかと。

2025/04/11(金) 21:03:21.88

すぐさまサブ回線使いだすとか言う辺り、自分でもサブ回線使ってそうだよね
「rustで一部の高速なシステムコールが追加されたら」についての説明が出来ない時点でね

2025/04/11(金) 22:20:53.69

>>877
すぐ上のジジイは理解できてると言うのに…

2025/04/11(金) 22:23:05.46

何を言われているのかも分かってないようだｗ

2025/04/11(金) 22:24:47.66

いやいやｗ
未だに
＞　「rustで一部の高速なシステムコールが追加されたら」についての説明が出来ない時点でね
と言ってる時点で認知症だろ

2025/04/11(金) 22:29:25.47

ChatGPTにさっきのメッセージ食わせてみた

回答
たしかに、Rustで高速なシステムコールが追加されて、それを直接叩けるようになれば、言語による違いはある程度意味を失いますよね。
C++でもRustでも、結局はそのシステムコールにアクセスできるかどうかでパフォーマンスの上限が決まる。

ただおっしゃる通り、高速化しようとしてマルチスレッド＋SIMDをガチで使い始めると、リソースの使い方が雑になりがちで、
他プロセスにまで影響出たりするのが悩ましいところ。
特に、CPUキャッシュやメモリ帯域を食い尽くすと、システム全体が重くなって「なんかPC遅い…」ってなるやつですね。

2025/04/11(金) 22:34:55.84

恥の上塗りw

2025/04/11(金) 22:41:15.01

これぐらいの意味が取れないってどういうことなんだお前らは？

2025/04/11(金) 22:44:03.19

cmakeでbuildするC++プロジェクトのバイナリを配布したいんだが
この場合生成されたbinディレクトリを抜き出せばいいんでしょうか？
こういうことは初めてでよくわかりません

2025/04/11(金) 22:47:45.89

ChatGPTを使うにも知識と知恵がいるんだよ
バカは質問の仕方が下手
---
「Rustでシステムコールを追加する」という表現は文脈によっては誤解を招きやすく、通常の意味では少し不適切です

1. Rustで書かれたOSの中に、新たなシステムコールを実装する
→ 例：Rust製OS（例：Redox OSなど）にsyscallを加える。
→ この場合は正しい文脈。

2. Rustでカーネルモジュールを書いてシステムコールを追加する
→ 実現可能だがLinuxでは一般的ではなく、安全性に注意が必要。

3. RustでOSとやりとりするAPIを自作して、それを便宜的に「システムコール」と呼んだ
→ 厳密には誤用。OSレベルの syscall とは異なる。

2025/04/11(金) 22:54:08.95

>>885
自分では意味が取れなかったんだろ？ただの馬鹿自慢だろ？

2025/04/11(金) 22:56:17.51

ほんとこいつ頭悪いw
どうバカにされたかも理解できない

2025/04/11(金) 22:57:06.69

>>887
それは自分だろｗ
そこに書いてある内容の真偽すら判定できないんだろｗ

**デフォルトの名無しさん** (JP 0H66-GhsC) · 2025/04/11(金) 23:09:03.39

cpack使えばいいのか
自己解決