[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
796: (ﾌﾞｰｲﾓ MM62-xG3a) 03/24(月)09:19 ID:8nOZWVbeM(1) AAS
>>795
もし解決されてないならunique_ptrでも問題出るでしょ
797(1): (ﾜｯﾁｮｲ 4602-BGJw) 03/24(月)23:17 ID:C5SHS/Z30(1/2) AAS
Makefileについて教えてください。
ベースディレクトリにMakefileがあり、サブディレクトリは以下の構造としたいです
・src\内にhello.c func1.c func2.cが、include\内にfuncs.hがある
・*.oはobj\内に作る
・最終成果物は.\sample.exeとして作る
ソースファイル、ヘッダファイルの増減時にSRCS、INCSを修正すれば済むようにと、
以下のようなMakefileを作っているのですが、makeすると
省20
798(1): 797 (ﾜｯﾁｮｲ 4602-BGJw) 03/24(月)23:24 ID:C5SHS/Z30(2/2) AAS
すいません、タブが崩れました
下の方ですが、全角スペースで記載してますが
$(PROGRAM): $(OBJDIR)/$(OBJS) $(INCDIR)/$(INCS)
$(CC) $(CFLAGS) -o $(PROGRAM) $^
.c.o:
$(CC) $(CFLAGS) -c $(SRCDIR)/$<
こうです
省1
799(2): Fish (ﾜｯﾁｮｲ 652f-MaZR) 03/25(火)02:35 ID:3npSY7mr0(1) AAS
OpenCVについての質問です。VS2022を使用し、includeやopencv_world4100d.libの設定が終わり、検証のためにMatを宣言してimread、imshowのみを書いて検証しようとしたのですが、dllの設定がうまくいってなかったのかコンソールにdllのloadがfailedと大量に出力されます。OpenCVの入れ方を教えてほしいです…まだC++初心者で5チャンの投稿も初心者なので何か変だったらすみません…
800: (ｱｳｱｳｳｰ Saa5-WcQO) 03/25(火)04:37 ID:ztarSHRBa(1) AAS
>>798
.o:
$(CC) $(CFLAGS) -c $(SRCDIR)/$<
>>799
環境変数
801: (ﾜｯﾁｮｲ 9901-Awih) 03/25(火)12:24 ID:sbXkgTme0(1) AAS
>>799
exeと同じディレクトリにloadがfailedと言われるdll置いてみたら?
802(1): (ﾜｯﾁｮｲ 6e6c-JaxA) 03/26(水)11:17 ID:ZFGsgZnF0(1) AAS
Makefileを作る時の$<と$?と$^の使い分けを教えて下さい
特に$<が何のためにあるのか分かりません。これだと2番目以降の材料が無視されてしまって動かない場合があるんじゃないかと心配になります。あと、makeは常に新しい材料のみコンパイルするという事は、すべてのケースで$?で良いのではと思ってしまいます。超初歩的な質問だと思いますがよろしくお願いします
803(1): (ﾜｯﾁｮｲ 6518-hacg) 03/26(水)13:48 ID:GrIMF1MA0(1) AAS
C言語だとオブジェクトファイルの依存ファイルは，cファイルとそのcファイルが使うhファイルだけどコンパイルするのはあくまでcファイルだけ
だから依存関係の1つ目にcファイルを，2個目以降にhファイルを書いておけば$<でコンパイルできる
とかかな
804(1): (ｱｳｱｳｳｰ Saa5-WcQO) 03/26(水)15:00 ID:NpEBbPpga(1) AAS
>>802
っ 外部ﾘﾝｸ:tex2e.github.io
805: (ﾜｯﾁｮｲ 6232-bZOK) 03/26(水)15:48 ID:OM1iPrvu0(1) AAS
>>797
基本的にサフィックスルールは何十年も前からobsolete扱いなのでやめた方が良い
806: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 09fa-p0tU) 03/26(水)20:50 ID:cSMtN3B/0(1) AAS
ところでこの場合の makefile の話は GNU Make を前提にするということでええんか？
807(1): 797 (ﾜｯﾁｮｲ 4602-BGJw) 03/26(水)22:53 ID:dm/+cX2j0(1) AAS
皆さんいろいろと情報をどうもです
結局、以下のようなものと落ち着いてます
ちなみに使ってる環境のmakeはGNU Make 4.4で、GNU Makeの機能を多用してます
「$(OBJDIR)%.o: $(SRCDIR)%.c」と書ける理由は、pattern rulesという機能なのですかね
ここをforeachとかで書こうとしてましたが、これでいけると聞き、書いてみたら動いたのでもうそのままです
以外に汎用性が出そうだと感じてますが、改良点があればまたご意見ほしいです
PROGRAM = c_sample.exe
省13
808: (MX 0H1d-JaxA) 03/26(水)23:25 ID:Z/+2BBNHH(1) AAS
>>803
>>804
ありがとうございます
助かりました
809: (ﾜｯﾁｮｲ 9901-Awih) 03/27(木)00:00 ID:KC9fXGxH0(1/3) AAS
汎用するのならautotoolsを使った方が良いのでは?
810: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ ed32-p0tU) 03/27(木)01:07 ID:gbE/Uiq80(1) AAS
拡張子に exe がついてるということはウィンドウズを想定してるんじゃないの？
cygwin とか msys2 とかだと autotools を入れるのは簡単だけどそうじゃないならめんどいかも。
811: (ﾜｯﾁｮｲ 06b2-xG3a) 03/27(木)02:03 ID:eJjdVc1D0(1) AAS
普通cmakeでしょ
好きじゃないけど
812(1): (ﾜｯﾁｮｲ 6262-bZOK) 03/27(木)08:24 ID:8EB6UmzB0(1) AAS
>>807
分かったからもう消えろ
ここはCのスレではないしmakeのスレでもない
813: (ﾜｯﾁｮｲ 9901-Awih) 03/27(木)09:16 ID:KC9fXGxH0(2/3) AAS
makeスレなくなったね
814: (ﾜｯﾁｮｲ 9901-Awih) 03/27(木)10:58 ID:KC9fXGxH0(3/3) AAS
ないと思ったらUNIX板だったようだ
815(1): (ﾜｯﾁｮｲ 4202-rYal) [!donguri] 03/27(木)14:55 ID:OeqyroTj0(1) AAS
>>812
過疎ってきてるし
C++とmakeは連動すること多いから
話題はあってもいいんじゃねーかと
書き込んでみるテスト
816: (ﾜｯﾁｮｲ 4279-Br5P) 03/27(木)18:38 ID:bm95RmrL0(1) AAS
ノーマルスーツを着ろシャア
817: (ｱｳｱｳｳｰ Saa5-WcQO) 03/28(金)12:58 ID:VPiwRdmLa(1) AAS
>>815
あってもいいけどコンパイラの使い方までかな
makeは誘導した方が良いと思う
818(1): (ﾜｯﾁｮｲ 6ea1-pnyl) 04/06(日)00:01 ID:xzDebXnC0(1/3) AAS
質問なのですが基底クラスでpublicとした仮想関数の可視性を派生クラスでprivateに狭めることができるのですが
なんでこんな仕様なの？
これは逆に言うと派生クラスでprivateとした一般メソッドに対し、
たまたま同じシグネチャの仮想関数を基底クラスで定義されたら基底クラス経由でprivateとしたメソッドを外部から呼び出せ
てしまいカプセル化の危機……！
そういう仕様になっているメリットとは一体……
819: (ﾜｯﾁｮｲ 4587-wZYf) 04/06(日)07:42 ID:xouJqKec0(1/2) AAS
前者は仮想関数を派生クラス経由で呼べないように出来る
というか派生のコンストラクタをprivateにして、friend指定したcreatorクラス経由でしか生成出来ないようにするとかそういうのに便利
あと後者は、試してないけど派生の同シグネチャの関数は基底経由で呼べないと思うよ、vtblに登録されてないから
820: (ﾜｯﾁｮｲ 45f5-pnlG) 04/06(日)08:51 ID:2WEREMbe0(1) AAS
継承に関しては早すぎる最適化の問題もあるから、そのまま使うんじゃなくてアダプタに切り離した方がいいと思う。
Boostあたりにアダプタ用のライブラリないかしらん。
821(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ cd32-nY3F) 04/06(日)09:09 ID:CSMreA7R0(1/4) AAS
>>818
コードで言えばこういう状況かな？
外部ﾘﾝｸ:wandbox.org
基底にある仮想関数と同じシグネチャならオーバーライドするという規則は単純に言語設計の失敗。
だからこそ override 指定子が導入された。
override 指定子ではオーバーライドのつもりでオーバーライドになっていないときを検出できても
オーバーライドではないつもりでオーバーライドになってしまうことは検出できないのだが……
省1
822: (ﾜｯﾁｮｲ 45ba-wZYf) 04/06(日)09:14 ID:U2fAIE9I0(1) AAS
ああそっか、シグネチャ同じなら強制的にオーバーライドになるんだっけスマン
823(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ cd32-nY3F) 04/06(日)09:27 ID:CSMreA7R0(2/4) AAS
意図せずオーバーライドになってしまうことがあるのは失敗だが、
意図して private でオーバーライドする分には「そういうインターフェイス」なのだからカプセル化の破綻ではないよ。
824: (ﾜｯﾁｮｲ cd7c-a/1F) 04/06(日)10:21 ID:gleSakN+0(1) AAS
リスコフの置換原則を破るからあんまり良くはないと思うけどな
基底クラスとして振る舞わせる気がないならprivate継承すべきだ
825: (ﾜｯﾁｮｲ 6ea1-pnyl) [sa] 04/06(日)10:25 ID:xzDebXnC0(2/3) AAS
>>821
なるほど……
virtualが省略可能なのが諸悪の根源かとｵﾓﾀがそっちか……
>>823
通常はBaseクラス→派生クラス、の順で設計するから「そういうインターフェイス」と考えてだいたい良いのかもしれませんけども
派生クラスまで設計した後にBaseクラスにメソッドを追加して、それがたまたま派生クラス独自に定義したprivateメソッドと
同じシグネチャになってしまった場合、Baseクラス経由で派生クラスのprivateメソッドを意図せず呼べてしまうという
省1
826: (ﾜｯﾁｮｲ 6ea1-pnyl) 04/06(日)10:32 ID:xzDebXnC0(3/3) AAS
んまーBaseクラスにメソッドを追加しようとする時点で変更の影響範囲を派生クラスまで広げて調査すべき
というのは正論やがコンパイラで検出可能な不都合のチェックのを人にやらせるのはｲﾏｲﾁ……
827: (ﾜｯﾁｮｲ 457b-wZYf) 04/06(日)11:31 ID:xouJqKec0(2/2) AAS
大抵のコンパイラで普通警告出るやろ？
828: (ﾜｯﾁｮｲ bd5f-gX4K) 04/06(日)11:41 ID:Qy9uUb820(1/3) AAS
純粋仮装関数でも無ければ影響無いだろ
だいいち使わない関数なら配慮する必要も無い
829: (ﾜｯﾁｮｲ bd5f-gX4K) 04/06(日)11:42 ID:Qy9uUb820(2/3) AAS
全コンパイルは掛かるけどなw
830: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ cd32-nY3F) 04/06(日)11:43 ID:CSMreA7R0(3/4) AAS
たとえば GCC なら -Wsuggest-override を付けておけば override 指定子なしでオーバーライドしているときを警告する。
外部ﾘﾝｸ:wandbox.org
だけどこのオプションは -Wall にも -Wextra にも含まれてないから個別に指定しなきゃならなくて、普段は有効になってないのが普通かも。
831: (JP 0Hd1-yI6P) 04/06(日)11:54 ID:4eCwmFCZH(1/3) AAS
前から思ってたけど -Wall と銘打ってるのに All じゃないとはこれいかに
832: (JP 0Hd1-yI6P) 04/06(日)11:54 ID:4eCwmFCZH(2/3) AAS
前から思ってたけど -Wall と銘打ってるのに All じゃないとはこれいかに
833: (JP 0Hd1-yI6P) 04/06(日)11:54 ID:4eCwmFCZH(3/3) AAS
（二重投稿ｽﾏﾝ）
834: (ﾜｯﾁｮｲ 6e10-ZtHn) 04/06(日)12:20 ID:JUJG8trR0(1) AAS
コンストラクタ呼び出しで()の時にinitializer_listを呼んでしまったときの警告と
逆に{}の時にinitializer_list以外を呼んでしまったときの警告がほしい
835: (ﾜｯﾁｮｲ f901-x8Qa) 04/06(日)12:33 ID:KBEItHDk0(1) AAS
override指定子って初めて知ったけども-Wallで警告出るのは俺はやだな
警告が大量に出るソースばかりと思うし
警告出すほどにoverride指定子を付けるべきなのかちょっと疑問
836: (ﾜｯﾁｮｲ bd5f-gX4K) 04/06(日)13:09 ID:Qy9uUb820(3/3) AAS
overrideなんて飾りです
privateも飾りです
837(1): (ﾜｯﾁｮｲ a574-CpEl) 04/06(日)15:06 ID:BtyKUyO50(1) AAS
#define class struct
#define private public
#define protected public
すれば大体はすり抜けられる
838: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ cd32-xzp7) 04/06(日)16:50 ID:CSMreA7R0(4/4) AAS
>>837
`private` などは用途が限定的なキーワードだからそういうことも出来るけど `class` はちょっと問題があるな。
template<class T> class foo {};
みたいなのが破綻する。
839: (ｻｻｸｯﾃﾛﾙ Spd1-gX4K) 04/07(月)12:25 ID:yN1PvO54p(1) AAS
classとstructは別ものだからなぁ
840: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 696c-Uo71) 04/07(月)12:42 ID:ioyUXCRU0(1) AAS
C++ の言語仕様的分類では構造体というものはないのだが、 C との関係の都合で微妙な形で struct キーワードは残されてしまった。
これも歴史的経緯による変なところ。
841(1): (ﾜｯﾁｮｲ 6e10-ZtHn) 04/07(月)14:49 ID:KdsoKBW+0(1) AAS
むしろキーワードとしてのclassがいらなかった
型は全部struct、構文の曖昧さを除くためのプレースホルダは全部typenameで良かった
842: (ｱｳｱｳｳｰ Sa05-nY3F) 04/07(月)15:01 ID:w0rhHNCza(1/2) AAS
protectedは使った方が良いけどprivateは使いたくなるシーンがほとんど無い
843: (ｱｳｱｳｳｰ Sa05-nY3F) 04/07(月)15:02 ID:w0rhHNCza(2/2) AAS
>>841
Rust使え
844: (ﾜｯﾁｮｲ 6e10-ZtHn) 04/08(火)02:19 ID:o1kEMolW0(1) AAS
rustだってどうせ20年もすれば後からあーすればよかったこーすればよかった言ってるよ
845: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ cd32-Uo71) 04/08(火)07:45 ID:veBTnWpR0(1) AAS
Rust はエディションごとに互換性が維持され、逆に言えばエディションをまたぐと互換性を損なっても良いというルール。
そして異なるエディションがひとつのプロジェクトに混在できる。
古いエディションから新しいエディションへの移行はかなり自動化されている。
最初から互換性を捨てることがありうる体制なので歴史的事情をいつまでも引きずることはない……と思うのだがこの体制でうまくいくかはやってみないとわからんね。
二十年くらいすれば結果が見えてくるだろう。
846: (ｻｻｸｯﾃﾛﾙ Spd1-gX4K) 04/08(火)09:56 ID:HZL/zZFGp(1) AAS
開発ツールごと遺跡になって発掘される毎に解析されるんだよ
847: (ﾜｯﾁｮｲ cd7c-a/1F) 04/08(火)19:53 ID:S61wTbWN0(1) AAS
似たような仕組みは歴史上何度も再発明されて全て爆死してるし
今の所うまく行ってるように見えてるのは、まだ大して使われてない証拠でしかないっておじさんは思っちゃうよ
848(2): (ﾜｯﾁｮｲ bd5f-VGeA) 04/10(木)00:16 ID:nvkavsn60(1) AAS
現在公開されている世界最速grepツールであるripgrepがRustで組んであるってのがすごい
849: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ cd32-9E30) 04/10(木)17:46 ID:SlMXr4vG0(1) AAS
>>848
C や C++ でやってやれないことはないと思うが使えるプログラムがあるのにフルスクラッチで書きなおそうと思うことがそもそもあまり無いからね。
新しい言語が登場するという形で整理する機会が生じるのは健全な進歩だと思う。
850(6): (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)08:30 ID:9LNHX+AUM(1) AAS
rustで一部の高速なシステムコールが追加されたらそれを使えばC++だろうが何だろうが関係なくなる
でもどうせマルチスレッドのsimd使いなんだろうからシステム全体に過負荷になるからめんどくさい
851: (ﾜｯﾁｮｲ 4694-PSZj) 04/11(金)08:37 ID:5PthuDCs0(1/5) AAS
↑何これ？w
852: (ﾜｯﾁｮｲ 829f-1egp) 04/11(金)13:45 ID:8HYvuWNF0(1/2) AAS
>システムコールが追加されたら
？？
853: (ﾗｸｯﾍﾟﾍﾟ MM66-XbuE) 04/11(金)13:57 ID:gEQ2gSNrM(1) AAS
DOS「ファンクションコールと呼べ！」
854: (ｻｻｸｯﾃﾛﾛ Spd1-gX4K) 04/11(金)14:31 ID:2mKx2F8Up(1) AAS
それってOS付属のランタイムをrustで書いたらって事？
855: (ﾜｯﾁｮｲ 829f-1egp) 04/11(金)18:09 ID:8HYvuWNF0(2/2) AAS
glibcのシステムコールラッパーみたいなものがRustにもあればってことなのかそれともsyscall命令で飛ぶカーネルのコードがRustで書かれてればってことなのか
分からんね
>>850は最近システムコールって言葉を知ったのかもしれない
856(1): (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)18:48 ID:qqgfnt32M(1/17) AAS
なんか頭悪そうな人間がたくさん噛みついてきてるけど生産性ゼロだなとしか…
何が言いたいんだよ
お前らが単純にシステムコールを知らなかっただけだろう？
OSに対してサービスの要求するのがシステムコールだ
OSよって呼び方が違う
857(1): (ﾜｯﾁｮｲ 4694-PSZj) 04/11(金)19:57 ID:5PthuDCs0(2/5) AAS
↑何を馬鹿にされてるかもわかってない
858: (ﾜｯﾁｮｲ 42e6-XbuE) 04/11(金)20:02 ID:S6J8cW8H0(1) AAS
イマドキgrepぐらいAPIで用意しとけと
859: (ﾜｯﾁｮｲ cd7c-a/1F) 04/11(金)20:07 ID:Yq7fRKgz0(1/2) AAS
Rustって今こんなレベル低い人間も流れ込んでるのか
そのうちJava化する運命だな
860(1): (ﾜｯﾁｮｲ 02ad-S7Iq) 04/11(金)20:07 ID:9wDK2WuU0(1/5) AAS
>>856
そのシステムコールを提供するのはOS側であって「rustで一部の高速なシステムコールが追加されたら」ってのが意味不明だって話だぜ？
861: (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)20:08 ID:qqgfnt32M(2/17) AAS
>>857
理解不足なのはそっち
862(1): (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)20:09 ID:qqgfnt32M(3/17) AAS
>>860
当たり前だろ
馬鹿なのか？
863(1): (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)20:14 ID:qqgfnt32M(4/17) AAS
システムコールはOSが提供するのは当たり前
それがRustの特性に合わせた高速化が行われていても使う側はなんでもよいと言う話がなんでわからないのか馬鹿なのかなと
864(1): (ﾜｯﾁｮｲ 02ad-S7Iq) 04/11(金)20:15 ID:9wDK2WuU0(2/5) AAS
>>862
「rustで一部の高速なシステムコールが追加されたら」について説明を
865: (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)20:15 ID:qqgfnt32M(5/17) AAS
>>864
幼稚園児なのかな？
866: (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)20:18 ID:qqgfnt32M(6/17) AAS
お前らrust "に" 一部の高速なシステムコールが～ と書いてあると勘違いしたんだろ
馬鹿すぎる
システムコールが追加されるのはOSだろ
馬鹿馬鹿しい
867(1): (ﾜｯﾁｮｲ 02ad-S7Iq) 04/11(金)20:19 ID:9wDK2WuU0(3/5) AAS
つまり>>848で書かれているツールの高速性は「Rustの言語仕様や機能に依存した話ではなくOS提供のシステムコールによるものだ」と言いたいのか
ふぅ〜ん
868: (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)20:20 ID:qqgfnt32M(7/17) AAS
>>867
幼稚園児並みの馬鹿発見
869: (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)20:23 ID:qqgfnt32M(8/17) AAS
馬鹿発見
851 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 4694-PSZj)[sage] 投稿日：2025/04/11(金) 08:37:04.65 ID:5PthuDCs0 [1/2]
↑何これ？w
870: (ﾌﾞｰｲﾓ MM22-PSZj) 04/11(金)20:28 ID:G/OJx5+6M(1) AAS
連投おつかれ
知ったかぶりは恥ずかしいよね
871: (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)20:29 ID:qqgfnt32M(9/17) AAS
サブ回線使いだすほうが恥ずかしい
872(1): (ﾜｯﾁｮｲ cd7c-a/1F) 04/11(金)20:34 ID:Yq7fRKgz0(2/2) AAS
なんだよRust界隈のお客さんじゃなくていつもの大天才様くんかよ
おもんな
873: (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)20:47 ID:qqgfnt32M(10/17) AAS
誰と勘違いしてるんだよ
普段はこのスレに書いてない
>>46が自分だ
874: (ﾜｯﾁｮｲ 45f2-1egp) 04/11(金)20:52 ID:edOe0r2X0(1) AAS
ああ，自分の誤った主張を説明しようとするとボロが見えるから自分に反論してくる人にレッテル貼って誤魔化してるのか
875: (ｵｲｺﾗﾐﾈｵ MM95-exh5) 04/11(金)20:55 ID:qqgfnt32M(11/17) AAS
それはどっちだよｗ
876(1): (ﾜｯﾁｮｲ 4d3e-Vpyu) 04/11(金)21:01 ID:yx7ZxPSb0(1) AAS
>>850
何を言っているのか全然わからん。
Rust開発者の主張は
「C/C++並に速くC/C++より安全」
だから、
「rustで一部の高速なシステムコールが追加されたらそれを使えばC++だろうが何だろうが関係なくなる」
というのが高速の話ならそりゃそうだろとしか。
省3
上下前次1-新書関写板覧索設栞歴
あと 126 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.025s