C++相談室 part165

■ このスレッドは過去ログ倉庫に格納されています
2023/10/31(火) 07:37:38.52ID:+ZyYyqMO0
!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
763デフォルトの名無しさん (ﾜｯﾁｮｲ 711b-yxlS)
垢版 |
2025/03/17(月) 14:43:44.88ID:EbB+xfjB0
関数のアドレス順とか
2025/03/17(月) 15:28:39.42ID:nF5lR4//p
コード書いた順だろw
2025/03/17(月) 16:50:25.99ID:qL9fWs880
>>760
私もそう思う。
いつからこうなのか探ってみたら1984年のリファレンスマニュアルではそもそも単項 + は存在せず、
https://web.archive.org/web/20171002220954/http://www.eah-jena.de/~kleine/history/languages/Stroustrup-CplusplusReferenceManual.pdf
1989年には単項 + が現れていてポインタも受け取れるようになってる。
https://www.softwarepreservation.org/projects/c_plus_plus/cfront/release_2.0/doc/ProductReferenceManual.pdf
この間にどんな議論があったのかよくわからん。

C の規格では今でも単項 + は算術型しか許してないし、それが自然だよな。
766デフォルトの名無しさん (ｱｳｱｳｴｰ Sa23-D2PX)
垢版 |
2025/03/18(火) 18:06:10.72ID:2EW8BzNca
>>760-762
各要素のサイズが一定じゃないから無理なんやろな
2025/03/21(金) 19:45:52.92ID:zuSmXANM0
>>755
またまた勉強になったお！
ありがとうございます！！
2025/03/21(金) 19:49:46.16ID:zuSmXANM0
関数のアドレスなら呼び出して
スタックに無理矢理アク(以下略)
2025/03/21(金) 22:32:50.41ID:pLF+KLC30
そういうむちゃくちゃが簡単にできるのがC/C++

そんなことしながら、チップを覚えるんだよなあ
自分、次はMIPS覚えないと
2025/03/22(土) 14:21:53.59ID:U6/Lg1xxa
どっかのタイミングでbpがスタックギリギリ飛ばすんじゃなくて
コンパイラが128bytesくらい飛ばす仕様になった気がするんだけど
あれは0埋めで(ホントはバグがあるのに)奇跡的にバグ回避するテクニックなのか
他に理由あるんか
2025/03/22(土) 18:01:17.10ID:nNEN9uWE0
>>770
128 ビット (16 バイト) じゃない？
SIMD とかの都合で 16 バイトアラインが必要な環境が出てきたからという事情だと聞いたことある。
2025/03/22(土) 20:51:53.87ID:kbZO019Z0
質問なのですがstd::unique_ptr<T>とかstd::shared_ptr<T>みたいなSTLで定義済みの
テンプレートクラスをfriendにすることは合法？
用途はシングルトンﾊﾟﾃｨｰﾝのオブジェクトのプログラム終了時の自動解放
2025/03/22(土) 21:29:46.22ID:nNEN9uWE0
>>772
T のデストラクタが private なのを std::unique_ptr<T> からのアクセスは許すってこと？
特に問題ないよ。

ところでテンプレートクラスじゃなくてクラステンプレートな！
2025/03/22(土) 22:33:09.97ID:kbZO019Z0
>>773
㌧クス、

>T のデストラクタが private なのを std::unique_ptr<T> からのアクセスは許すってこと？
>特に問題ないよ。
それがTのコンストラクタがprivateなﾊﾟﾃｨｰﾝなのです！
friendにしないとビルドが通らないかった（VS2022、VS2015）。
多分moveとかの最にstd::unique_ptr<T>がTのコンストラクタにアクセスするのだと思う。
2025/03/22(土) 22:39:33.53ID:kbZO019Z0
>ところでテンプレートクラスじゃなくてクラステンプレートな！
なるほど……orz

コード例：
class Foo {
　　friend std::unique_ptr<Foo>;
　　static std::unique_ptr<Foo> m_pObj;
private:
　　static Foo* createInstance() {
　　　　if (m_pObj == NULL) { m_pObj = std::unique_ptr<Foo>(new Foo()); } return m_pObj.get()j;
　　　　// ↑ std::make_unique<Foo>()したらビルドエラー（使うには多分std::make_unique<Foo>()もfriendが要る
　　　　 // 　　スレッドセーフ化は省略
　　}
　　// ...
};
2025/03/22(土) 23:40:24.86ID:nNEN9uWE0
>>775
new Foo() を Foo のメンバ関数の中でやる分には自分自身の中でやることなので friend 宣言は不要。
std::make_unique<Foo>() をすると std::make_unique の中で Foo のコンストラクタを呼ぼうとするから std::make_unique<Foo> をフレンド宣言する必要がある。
2025/03/22(土) 23:48:30.44ID:kbZO019Z0
>>776
>new Foo() を Foo のメンバ関数の中でやる分には自分自身の中でやることなので friend 宣言は不要。
と思うじゃん？
↓現実
>friendにしないとビルドが通らないかった（VS2022、VS2015）。(>>774

エラーメッセージは熟読していませんぬが、
多分クラステンプレートの実体化がクラスのメソッド全部についてまとめて行われる的なことが起きて、
Tのコンストラクタにアクセスするstd::unique_ptr<T>のメンバ関数（moveコンストラクタとか）が引っかかるのだと予想
2025/03/23(日) 00:18:05.56ID:Ft35v0Bz0
>>777
私は Visual Stuio 2022 (MSVC 17) にコンパイルさせてエラーが出ないことを確認した上で書いてる。
手元に Visual Studio を入れていないのでオンラインコンパイラだけど。
コードを呼び出す側なども補うとたぶんこんなのだよね？ 私が問題の理解を間違えている箇所はある？

#include <memory>

class Foo {
private:
static std::unique_ptr<Foo> m_pObj;
Foo(void) = default; // デフォルトコンストラクタはプライベート

public:
static Foo* createInstance() {
if (m_pObj == NULL) {
m_pObj = std::unique_ptr<Foo>(new Foo);
}
return m_pObj.get();
}
};

std::unique_ptr<Foo> Foo::m_pObj;

int main(void) {
auto bar = Foo::createInstance();
}
2025/03/23(日) 00:19:16.26ID:YXTjT4M+0
通ったが？
https://godbolt.org/z/xzTbKaM5f
2025/03/23(日) 00:20:25.80ID:YXTjT4M+0
あ、被った
内容は一緒
2025/03/23(日) 00:21:43.38ID:/EbbY7QB0
>>777
エラーメッセージは読まんといかんよ
分からんときは今ならLLMに読ませると良い
2025/03/23(日) 01:58:28.60ID:IgihfQRv0
>>778>>779
お騒がせしましたｻｰｾﾝ；；；orz ビルドが通らないというのは私めの勘違いだった模様。
コードはそれで良いです。
そのコード（最小サンプル）、および最小サンプルにする前のコード×VS2015でもfriend宣言部分をコメントアウトしてビルドが通った 。n_

フレンド宣言friend std::unique_ptr<Foo>; を付けるに至った履歴が無いので推測ですだが
デストラクタがprivateのままだったタイミングがあったのかも……
（m_pObjが生ポインタのタイプのSingletonはデストラクタがprivateでもビルドが通る（デストラクタを呼ぶ人が居ないため）
　→この状態でm_pObjをstd::unique_ptr<Foo>に変更してビルドエラー、アクセス許可が無いとコンパイラに言われて慌ててfriend追加、だった可能性、
2025/03/23(日) 09:31:51.75ID:CXYOr+7B0
繰り返しになるが熟読した方がいいぞ
無視していいメッセージかそうでないかも区別できるようになるから
2025/03/23(日) 09:32:31.18ID:Ft35v0Bz0
元の話題からはずれる余談だけれど、静的記憶域期間を持つブロックスコープの変数は最初に通過したときに初期化されるルールがある。 (条件によるので常にではない。)
https://timsong-cpp.github.io/cppwp/n3337/stmt.dcl#4
なのでシングルトンパターンはこう単純化して書くことも出来る。

#include <memory>

class Foo {
Foo() = default;
public:
static Foo* createInstance() {
static std::unique_ptr<Foo> m_pObj = std::unique_ptr<Foo>(new Foo);
return m_pObj.get();
}
};

int main(void) {
auto bar = Foo::createInstance();
}
2025/03/23(日) 10:12:01.75ID:i5B9IukZM
それunique_ptrにする意味ある？
shared_ptrなら意味わかるけど
2025/03/23(日) 10:45:14.55ID:Ft35v0Bz0
>>785
意味ないな。
2025/03/23(日) 10:56:08.84ID:IgihfQRv0
>>784
サンプルコードでは省略したけんども、Double-checked lockingの実験をしたかったﾉﾃﾞｽ！
■ Double-Checked Locking is Fixed In C++11
https://preshing.com/20130930/double-checked-locking-is-fixed-in-cpp11/

つなみに関数内staticオブジェクト初期化（初回実行時）のスレッド安全性がどうーなっているのかは
よく知りま栓（よって採用には消極的

>>785
Singletonなので誰からもshareされないし……
この場合むしろshared_ptrの方が牛刀な可能性もあるし……
なぜなら、std::shared_ptrの参照カウンタはその利用特性上
異なるスレッドから非同期にインクリメント/デクリメントされることを想定せざるおえず、
スレッド安全性担保がそこそこ重い同期オブジェクトで一方unique_ptrの所有権移動は非同期に行われることはなさげ
2025/03/23(日) 10:57:59.97ID:IgihfQRv0
すまんこTeamsのノリで途中送信すたorz
誤： スレッド安全性担保がそこそこ重い同期オブジェクトで一方unique_ptrの所有権移動は非同期に行われることはなさげ
正： スレッド安全性担保がそこそこ重い同期オブジェクトで行われている危険性がある。一方unique_ptrの所有権移動は非同期に行われることはなさげなので多分軽量
2025/03/23(日) 11:03:44.18ID:IgihfQRv0
だいたいstd::unique_ptrとstd::shard_ptrでは前者が1個のポインタと同じサイズなのに後者は2個分ある（ヒープにとられた参照カウンタへのポインタを持つため
sizeof(shared_ptr)=16
sizeof(unique_ptr)=8
というのもあり、std::unique_ptr<T>で済むところをstd::shared_ptr<T>推しするのはいかがなものか……
2025/03/23(日) 21:04:30.15ID:k0m2+uGk0
>>789
shared_ptrを使えと言ってるのでなくunique_ptrの意味が特にないと言ってる
別に使ってもいいけどお前それをわかってんの？ってこと？
ついでに言っておけばshared_ptrを使う場合ってのは参照カウントがゼロになったらシングルトンを破棄するみたいな凝った実装する場合に使う
2025/03/24(月) 00:16:57.44ID:zeyD/Mo00
unique_ptrじゃなくてナマポ使えって言ってんの？どこでdeleteする気なの？
2025/03/24(月) 00:22:30.84ID:wvKmLjta0
>>791
static Fooでいいだろってことだよ
自分で気づけなかったな
2025/03/24(月) 07:56:52.11ID:zeyD/Mo00
えぇ・・・？
2025/03/24(月) 08:43:05.04ID:s0JFvm8m0
>>792
マルチスレッドで問題あるんじゃなかったっけ？
資料どこにあるか忘れたけど。
2025/03/24(月) 08:50:28.31ID:s0JFvm8m0
>>794
ずいぶん前に問題無くなっているのね。
https://cpprefjp.github.io/lang/cpp11/static_initialization_thread_safely.html
2025/03/24(月) 09:19:49.44ID:8nOZWVbeM
>>795
もし解決されてないならunique_ptrでも問題出るでしょ
2025/03/24(月) 23:17:27.23ID:C5SHS/Z30
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)/$<
2025/03/24(月) 23:24:39.28ID:C5SHS/Z30
すいません、タブが崩れました

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

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

こうです

申し訳ありませんでした
799Fish (ﾜｯﾁｮｲ 652f-MaZR)
垢版 |
2025/03/25(火) 02:35:59.65ID:3npSY7mr0
OpenCVについての質問です。VS2022を使用し、includeやopencv_world4100d.libの設定が終わり、検証のためにMatを宣言してimread、imshowのみを書いて検証しようとしたのですが、dllの設定がうまくいってなかったのかコンソールにdllのloadがfailedと大量に出力されます。OpenCVの入れ方を教えてほしいです…まだC++初心者で5チャンの投稿も初心者なので何か変だったらすみません…
800デフォルトの名無しさん (ｱｳｱｳｳｰ Saa5-WcQO)
垢版 |
2025/03/25(火) 04:37:37.58ID:ztarSHRBa
>>798
.o:
　　$(CC) $(CFLAGS) -c $(SRCDIR)/$<

>>799
環境変数
2025/03/25(火) 12:24:02.95ID:sbXkgTme0
>>799
exeと同じディレクトリにloadがfailedと言われるdll置いてみたら?
802デフォルトの名無しさん (ﾜｯﾁｮｲ 6e6c-JaxA)
垢版 |
2025/03/26(水) 11:17:13.88ID:ZFGsgZnF0
Makefileを作る時の$<と$?と$^の使い分けを教えて下さい
特に$<が何のためにあるのか分かりません。これだと2番目以降の材料が無視されてしまって動かない場合があるんじゃないかと心配になります。あと、makeは常に新しい材料のみコンパイルするという事は、すべてのケースで$?で良いのではと思ってしまいます。超初歩的な質問だと思いますがよろしくお願いします
2025/03/26(水) 13:48:44.59ID:GrIMF1MA0
C言語だとオブジェクトファイルの依存ファイルは，cファイルとそのcファイルが使うhファイルだけどコンパイルするのはあくまでcファイルだけ
だから依存関係の1つ目にcファイルを，2個目以降にhファイルを書いておけば$<でコンパイルできる

とかかな
2025/03/26(水) 15:00:53.93ID:NpEBbPpga
>>802
っ https://tex2e.github.io/blog/makefile/automatic-variables
805デフォルトの名無しさん (ﾜｯﾁｮｲ 6232-bZOK)
垢版 |
2025/03/26(水) 15:48:44.68ID:OM1iPrvu0
>>797
基本的にサフィックスルールは何十年も前からobsolete扱いなのでやめた方が良い
2025/03/26(水) 20:50:04.73ID:cSMtN3B/0
ところでこの場合の makefile の話は GNU Make を前提にするということでええんか？
2025/03/26(水) 22:53:57.57ID:dm/+cX2j0
皆さんいろいろと情報をどうもです
結局、以下のようなものと落ち着いてます
ちなみに使ってる環境の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)%, $@)
808デフォルトの名無しさん (MX 0H1d-JaxA)
垢版 |
2025/03/26(水) 23:25:47.70ID:Z/+2BBNHH
>>803
>>804

ありがとうございます
助かりました
2025/03/27(木) 00:00:17.61ID:KC9fXGxH0
汎用するのならautotoolsを使った方が良いのでは?
2025/03/27(木) 01:07:35.19ID:gbE/Uiq80
拡張子に exe がついてるということはウィンドウズを想定してるんじゃないの？
cygwin とか msys2 とかだと autotools を入れるのは簡単だけどそうじゃないならめんどいかも。
2025/03/27(木) 02:03:57.32ID:eJjdVc1D0
普通cmakeでしょ
好きじゃないけど
812デフォルトの名無しさん (ﾜｯﾁｮｲ 6262-bZOK)
垢版 |
2025/03/27(木) 08:24:51.71ID:8EB6UmzB0
>>807
分かったからもう消えろ
ここはCのスレではないしmakeのスレでもない
2025/03/27(木) 09:16:55.35ID:KC9fXGxH0
makeスレなくなったね
2025/03/27(木) 10:58:28.75ID:KC9fXGxH0
ないと思ったらUNIX板だったようだ
2025/03/27(木) 14:55:01.12ID:OeqyroTj0
>>812
過疎ってきてるし
C++とmakeは連動すること多いから
話題はあってもいいんじゃねーかと
書き込んでみるテスト
2025/03/27(木) 18:38:06.75ID:bm95RmrL0
ノーマルスーツを着ろシャア
2025/03/28(金) 12:58:29.90ID:VPiwRdmLa
>>815
あってもいいけどコンパイラの使い方までかな
makeは誘導した方が良いと思う
2025/04/06(日) 00:01:49.29ID:xzDebXnC0
質問なのですが基底クラスでpublicとした仮想関数の可視性を派生クラスでprivateに狭めることができるのですが
なんでこんな仕様なの？
これは逆に言うと派生クラスでprivateとした一般メソッドに対し、
たまたま同じシグネチャの仮想関数を基底クラスで定義されたら基底クラス経由でprivateとしたメソッドを外部から呼び出せ
てしまいカプセル化の危機……！
そういう仕様になっているメリットとは一体……
2025/04/06(日) 07:42:00.02ID:xouJqKec0
前者は仮想関数を派生クラス経由で呼べないように出来る
というか派生のコンストラクタをprivateにして、friend指定したcreatorクラス経由でしか生成出来ないようにするとかそういうのに便利
あと後者は、試してないけど派生の同シグネチャの関数は基底経由で呼べないと思うよ、vtblに登録されてないから
2025/04/06(日) 08:51:38.89ID:2WEREMbe0
継承に関しては早すぎる最適化の問題もあるから、そのまま使うんじゃなくてアダプタに切り離した方がいいと思う。

Boostあたりにアダプタ用のライブラリないかしらん。
2025/04/06(日) 09:09:40.72ID:CSMreA7R0
>>818
コードで言えばこういう状況かな？
https://wandbox.org/permlink/gEndnLHWa7qEvNRP

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

override 指定子ではオーバーライドのつもりでオーバーライドになっていないときを検出できても
オーバーライドではないつもりでオーバーライドになってしまうことは検出できないのだが……
互換性を壊す変更を入れるわけにもいかずそのままズルズルと今まで失敗を引きずってきたという歴史的経緯。
2025/04/06(日) 09:14:57.63ID:U2fAIE9I0
ああそっか、シグネチャ同じなら強制的にオーバーライドになるんだっけスマン
2025/04/06(日) 09:27:02.17ID:CSMreA7R0
意図せずオーバーライドになってしまうことがあるのは失敗だが、
意図して private でオーバーライドする分には「そういうインターフェイス」なのだからカプセル化の破綻ではないよ。
2025/04/06(日) 10:21:41.86ID:gleSakN+0
リスコフの置換原則を破るからあんまり良くはないと思うけどな
基底クラスとして振る舞わせる気がないならprivate継承すべきだ
2025/04/06(日) 10:25:35.73ID:xzDebXnC0
>>821
なるほど……
virtualが省略可能なのが諸悪の根源かとｵﾓﾀがそっちか……

>>823
通常はBaseクラス→派生クラス、の順で設計するから「そういうインターフェイス」と考えてだいたい良いのかもしれませんけども
派生クラスまで設計した後にBaseクラスにメソッドを追加して、それがたまたま派生クラス独自に定義したprivateメソッドと
同じシグネチャになってしまった場合、Baseクラス経由で派生クラスのprivateメソッドを意図せず呼べてしまうという
現象が再燃する……
2025/04/06(日) 10:32:27.61ID:xzDebXnC0
んまーBaseクラスにメソッドを追加しようとする時点で変更の影響範囲を派生クラスまで広げて調査すべき
というのは正論やがコンパイラで検出可能な不都合のチェックのを人にやらせるのはｲﾏｲﾁ……
2025/04/06(日) 11:31:20.83ID:xouJqKec0
大抵のコンパイラで普通警告出るやろ？
2025/04/06(日) 11:41:46.34ID:Qy9uUb820
純粋仮装関数でも無ければ影響無いだろ
だいいち使わない関数なら配慮する必要も無い
2025/04/06(日) 11:42:28.71ID:Qy9uUb820
全コンパイルは掛かるけどなw
2025/04/06(日) 11:43:04.77ID:CSMreA7R0
たとえば GCC なら -Wsuggest-override を付けておけば override 指定子なしでオーバーライドしているときを警告する。
https://wandbox.org/permlink/h6PGzqrDAAkAVeJO

だけどこのオプションは -Wall にも -Wextra にも含まれてないから個別に指定しなきゃならなくて、普段は有効になってないのが普通かも。
831デフォルトの名無しさん (JP 0Hd1-yI6P)
垢版 |
2025/04/06(日) 11:54:04.73ID:4eCwmFCZH
前から思ってたけど -Wall と銘打ってるのに All じゃないとはこれいかに
832デフォルトの名無しさん (JP 0Hd1-yI6P)
垢版 |
2025/04/06(日) 11:54:05.20ID:4eCwmFCZH
前から思ってたけど -Wall と銘打ってるのに All じゃないとはこれいかに
833デフォルトの名無しさん (JP 0Hd1-yI6P)
垢版 |
2025/04/06(日) 11:54:58.77ID:4eCwmFCZH
（二重投稿ｽﾏﾝ）
2025/04/06(日) 12:20:48.70ID:JUJG8trR0
コンストラクタ呼び出しで()の時にinitializer_listを呼んでしまったときの警告と
逆に{}の時にinitializer_list以外を呼んでしまったときの警告がほしい
2025/04/06(日) 12:33:44.13ID:KBEItHDk0
override指定子って初めて知ったけども-Wallで警告出るのは俺はやだな
警告が大量に出るソースばかりと思うし
警告出すほどにoverride指定子を付けるべきなのかちょっと疑問
2025/04/06(日) 13:09:33.59ID:Qy9uUb820
overrideなんて飾りです
privateも飾りです
837デフォルトの名無しさん (ﾜｯﾁｮｲ a574-CpEl)
垢版 |
2025/04/06(日) 15:06:13.11ID:BtyKUyO50
#define class struct
#define private public
#define protected public
すれば大体はすり抜けられる
2025/04/06(日) 16:50:10.05ID:CSMreA7R0
>>837
`private` などは用途が限定的なキーワードだからそういうことも出来るけど `class` はちょっと問題があるな。

template<class T> class foo {};

みたいなのが破綻する。
2025/04/07(月) 12:25:07.84ID:yN1PvO54p
classとstructは別ものだからなぁ
2025/04/07(月) 12:42:21.06ID:ioyUXCRU0
C++ の言語仕様的分類では構造体というものはないのだが、 C との関係の都合で微妙な形で struct キーワードは残されてしまった。
これも歴史的経緯による変なところ。
2025/04/07(月) 14:49:45.64ID:KdsoKBW+0
むしろキーワードとしてのclassがいらなかった
型は全部struct、構文の曖昧さを除くためのプレースホルダは全部typenameで良かった
2025/04/07(月) 15:01:27.29ID:w0rhHNCza
protectedは使った方が良いけどprivateは使いたくなるシーンがほとんど無い
2025/04/07(月) 15:02:24.36ID:w0rhHNCza
>>841
Rust使え
2025/04/08(火) 02:19:24.63ID:o1kEMolW0
rustだってどうせ20年もすれば後からあーすればよかったこーすればよかった言ってるよ
2025/04/08(火) 07:45:44.78ID:veBTnWpR0
Rust はエディションごとに互換性が維持され、逆に言えばエディションをまたぐと互換性を損なっても良いというルール。
そして異なるエディションがひとつのプロジェクトに混在できる。
古いエディションから新しいエディションへの移行はかなり自動化されている。
最初から互換性を捨てることがありうる体制なので歴史的事情をいつまでも引きずることはない……と思うのだがこの体制でうまくいくかはやってみないとわからんね。
二十年くらいすれば結果が見えてくるだろう。
2025/04/08(火) 09:56:44.28ID:HZL/zZFGp
開発ツールごと遺跡になって発掘される毎に解析されるんだよ
2025/04/08(火) 19:53:49.89ID:S61wTbWN0
似たような仕組みは歴史上何度も再発明されて全て爆死してるし
今の所うまく行ってるように見えてるのは、まだ大して使われてない証拠でしかないっておじさんは思っちゃうよ
2025/04/10(木) 00:16:06.10ID:nvkavsn60
現在公開されている世界最速grepツールであるripgrepがRustで組んであるってのがすごい
2025/04/10(木) 17:46:33.43ID:SlMXr4vG0
>>848
C や C++ でやってやれないことはないと思うが使えるプログラムがあるのにフルスクラッチで書きなおそうと思うことがそもそもあまり無いからね。
新しい言語が登場するという形で整理する機会が生じるのは健全な進歩だと思う。
2025/04/11(金) 08:30:12.43ID:9LNHX+AUM
rustで一部の高速なシステムコールが追加されたらそれを使えばC++だろうが何だろうが関係なくなる
でもどうせマルチスレッドのsimd使いなんだろうからシステム全体に過負荷になるからめんどくさい
2025/04/11(金) 08:37:04.65ID:5PthuDCs0
↑何これ？w
2025/04/11(金) 13:45:57.41ID:8HYvuWNF0
>システムコールが追加されたら
？？
2025/04/11(金) 13:57:42.36ID:gEQ2gSNrM
DOS「ファンクションコールと呼べ！」
2025/04/11(金) 14:31:46.86ID:2mKx2F8Up
それってOS付属のランタイムをrustで書いたらって事？
2025/04/11(金) 18:09:26.07ID:8HYvuWNF0
glibcのシステムコールラッパーみたいなものがRustにもあればってことなのかそれともsyscall命令で飛ぶカーネルのコードがRustで書かれてればってことなのか
分からんね

>>850は最近システムコールって言葉を知ったのかもしれない
2025/04/11(金) 18:48:50.71ID:qqgfnt32M
なんか頭悪そうな人間がたくさん噛みついてきてるけど生産性ゼロだなとしか…
何が言いたいんだよ

お前らが単純にシステムコールを知らなかっただけだろう？
OSに対してサービスの要求するのがシステムコールだ
OSよって呼び方が違う
2025/04/11(金) 19:57:08.33ID:5PthuDCs0
↑何を馬鹿にされてるかもわかってない
2025/04/11(金) 20:02:48.75ID:S6J8cW8H0
イマドキgrepぐらいAPIで用意しとけと
2025/04/11(金) 20:07:19.88ID:Yq7fRKgz0
Rustって今こんなレベル低い人間も流れ込んでるのか
そのうちJava化する運命だな
2025/04/11(金) 20:07:35.60ID:9wDK2WuU0
>>856
そのシステムコールを提供するのはOS側であって「rustで一部の高速なシステムコールが追加されたら」ってのが意味不明だって話だぜ？
2025/04/11(金) 20:08:42.81ID:qqgfnt32M
>>857
理解不足なのはそっち
2025/04/11(金) 20:09:54.47ID:qqgfnt32M
>>860
当たり前だろ
馬鹿なのか？
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況