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/02/18(火) 00:30:31.98

>グローバル変数とは、複数の関数から使用できる変数のことを言います。
>グローバル変数は、関数外で宣言された変数です。
>一方、関数の外側でも変数を宣言できます。これをグローバル変数と言います。
ぢつは自動変数以外はTLSもファイルスコープのやつも静的記憶期間の変数も全
部グローバル変数だったりして……

2025/02/18(火) 00:33:19.53

当然オブジェクトのメンバ変数も関数の外でクラスが定義されている限り、
自動オブジェクトであってもメンバ変数は例外なくグローバル変数である
という定義にしたら単純で誤解の余地も無い

2025/02/18(火) 00:44:49.13

しかしよく考えたら
>グローバル変数とは、複数の関数から使用できる変数のことを言います。
には他の関数に参照渡しされた自動変数も含まれるから、アドレスが関数外に流出して
メモリエリアシングの可能性がある変数はみなグローバル変数ということなのかも……

2025/02/24(月) 18:03:30.63

現在C++を勉強しています
規格書を読んで分からないところはChatGPTに質問すれば
大体解決してしまうのですが、こんな楽な勉強方法でいいんでしょうか？
昔、入門書読んでは挫折を繰り返してたのがバカバカしくなりました

2025/02/24(月) 18:13:54.21

>>692
それ何の心配？
そもそもプログラミングをAIにやらせること考えたら？

2025/02/24(月) 21:25:46.59

良い時代になったね

2025/02/25(火) 16:07:34.32

初心者は何が分からないのか分からない。
つまり的確な質問は出来ない。
要領を得ない質問から上手く察して回答するのは難しいよ。
(人間の指導者でも。)

学習の最序盤では入門書を読んで一方的に知識を詰め込む段階は要ると思う。
(それによって最低限に意味が伝わる質問が出来るようになる程度には。)
基礎を詰め込んだ後なら詳細を規格から探し回るよりは AI のサポートがあると便利ではあるかもね。

2025/02/26(水) 09:46:27.50

超賢い検索サイトだと思って付き合ったらいい
いきなり答え出ちゃったり、違うそうじゃないっていうのが出たり
楽しめるようなら楽しめる

2025/02/26(水) 20:06:27.25

初心者用のC++スレってここでいいですか？

2025/02/26(水) 22:17:10.74

>>697
特に初心者向けというわけではありませんが、初心者が駄目なわけでもありません。
C++ 関連の雑多な話題のスレという感じですね。

2025/02/27(木) 11:05:40.67

>>698
ありがとうございます
最近勉強を始めましたので分からないことがありましたらご教示いただければと思います

**青木康善** (ﾜｯﾁｮｲ 09f9-8/4C) · 2025/02/28(金) 21:57:23.23

DTMソフトのReasonのRack Extensionを作るのに、C++を覚えなきゃいけなくなりました。

独習C++とchat GPT頼りになんとか作りたいです。

環境変数の段階で躓いてます。

2025/02/28(金) 23:50:16.76

環境変数の話はC++の話ってより、Unix系の環境でのUIの話になるんだよね。
シェルスクリプトが中心にいるような世界だと、ああいうやりかたで設定するのが便利だったっていう。

正直、とりあえず無視して進んでもいい話だと思うよ。
優先度低いから、必要になってから学び直す感じで。

2025/03/01(土) 00:04:13.00

>>700
プラグイン的なものを作る場合はベースになるソフトの仕様に従わなければならない。
設計思想を理解するのは自分で一から設計する場合とは違った難しさがある。
入門書を読んだ程度で取り組むには ChatGPT の助けを借りても難しすぎるように私には思えるが……。

>>701
開発環境構築にあたって設定しなければならない (処理系や開発環境が参照する) 環境変数がよくわからんとかいう意味だと私は理解してた。
もしそういう意味なら必要になってからというんじゃなくて今必要なんだろ。
Java の経験はあるようなので環境変数の概念がわからんとかではないと思う。

**701** (ｽｯﾌﾟﾌﾟ Sdfa-5me9) · 2025/03/01(土) 01:37:40.11

ああ…その発想はなかった。
そういう意味なら全くの見当外れなレスだったから、忘れて。

2025/03/01(土) 11:39:29.07

VSTの話かと思ったz

2025/03/01(土) 20:32:44.09

まだ、chatGPTに「こういうプラグイン作って」で済む時代ではないのか

2025/03/02(日) 16:59:51.21

グルーコードは頼んだら書いてくれそう
そういうのこそ、webから情報収集してもらって、AIに組んでもらいたい

2025/03/02(日) 20:49:33.30

「とりあえずHello World出すプラグイン書いて」とか「この情報どうやって取得すんの？」とかは今のAIでもやってくれるから
その手のコード書き捨てるのは格段に楽になった

2025/03/03(月) 01:18:59.95

マイナーなライブラリの使い方きいたらデタラメばっかだよ

2025/03/03(月) 01:53:36.51

https://i.imgur.com/WuNDS00.png
まぁな

2025/03/03(月) 09:52:35.09

>>708
結局ところ学習ソースはネットだからネットで情報の少ない分野がいい加減になるのはしゃーない

2025/03/03(月) 10:09:12.99

>>710
しゃなくはない
単なる現段階の技術的制約にすぎない
わからんものはわからんと言うべき
簡単に受け入れるな

2025/03/03(月) 10:23:10.28

自動小説製造機になに期待してんだか

2025/03/05(水) 18:11:47.24

AI が人間の知能を模倣しようとする試みである以上は人間に似た限界もある。
何もかもの専門家であることは出来ない。
無料で使える ChatGPT はその性質上、汎用 AI として調整されてるし使えるリソースは少なめなのでこれで AI を判断しないほうがいいよ。
プログラミング専用に訓練した AI は本当に賢い。

2025/03/05(水) 18:48:09.02

プログラミング専用ってどゆこと？

2025/03/05(水) 19:22:05.63

Clineとかじゃね？しらんけど

2025/03/05(水) 19:41:16.61

プログラミングの専門家ってなに？という疑問
言語仕様や構文、標準ライブラリに詳しい人またはAIのことかな？

でもそれって特定ビジネスドメインの専門家ではないよね？
たとえば高度な会計処理のプログラミングをAIにしてもらうことって可能なのかな？

アプリケーションを完成させるにはプログラミングだけでなくビジネスドメインの知識も必要になると思うけど

2025/03/05(水) 19:44:29.61

たとえば高位の税理士や会計士がプログラミング専門に訓練したAIに指示を出すことで会計ソフトを作ることはできるのだろうか？

2025/03/05(水) 19:45:37.93

AIについて語りたいならスレ違い。

2025/03/05(水) 19:51:32.43

具体的な話はしないよ。
ChatGPT を試した程度で AI を評価すべきじゃないという主旨。

2025/03/05(水) 19:51:57.29

たとえば、はちみつ餃子さんはC++のこと詳しいけどどんなアプリでも作れるってわけじゃないよね？
医学とか専門性の高いものはその分野の知識も当然必要になってくると思うし

そうするとプログラミングの専門家AIってなんだ？
ほんとにプログラム作れるのか？という疑問が湧いてくる

2025/03/05(水) 23:39:44.64

ハチミツさんはどんなプログラムでも作れるよ
時間さえあれば

2025/03/06(木) 00:09:24.53

ところで、「結局C++とRustってどっちが良いの？」でも質問したんだけど、
X(旧 twitter)で、C++ というキーワードが検索できないんだけど、
俺の環境だけなのか、一般的に他の人の環境でもそうなって
いるのかどっち？

2025/03/06(木) 07:44:57.51

unsigned intをkeyとするstd::mapである値以上ある値以下のkeyの要素を全て削除したいんだけどどうしたらいいかな？

2025/03/06(木) 09:03:07.49

>>723
std::erase_if

2025/03/06(木) 18:24:33.81

>>722
記号を含むワードは検索できない。
投稿する側が配慮して #cpp や #cplusplus といったタグをつける習慣はあるけどそれほど浸透してないので網羅的に探す方法はないと思う。
普通のワードでも検索はなんかおかしいし。
おすすめが賢いようなのでフォローやお気に入りを積極的にしていくと快適に情報を集められるかもしれない。
昔はおすすめ機能に「いらんことするな」という意見が多かったけど思ったより良くできてるね。

2025/03/06(木) 19:34:30.93

最近Rustに押されてるのは検索性の悪さと無関係じゃないと思う

2025/03/06(木) 19:58:40.82

Go とか BASIC とか Scheme なんかも日常的な語彙すぎて検索性は悪いが、検索自体が出来ないってことはないから組み合わせるワード次第でなんとかなるもんな。
日本語の文章という制約を入れればそれなりに絞れるし。

**青木康善** (ﾜｯﾁｮｲ 694e-rQ/Z) · 2025/03/07(金) 14:22:29.06

皆さん、アドバイス大感謝します。しかし、Javaはある程度分かるんですが、C++はなかなか手古摺ります。

2025/03/07(金) 14:57:48.23

そもそもtwitterを検索に使おうって言う発想が貧困アタオカ

2025/03/07(金) 19:27:12.87

通常のwebより、SNSのほうが新鮮でおいしいって若者は思ったりするらしいんだが

それなら5chもいいぞ、名無しでいけるだけあって、愚問こいちゃっても後腐れは少ない

2025/03/07(金) 20:36:20.40

>>729
そうやって解決策を示さずに初心者を排除していると老害と言われるよ。

2025/03/08(土) 14:23:59.19

自分が初心者だった頃を思い出せば
新参者に優しくなれるだろ？

2025/03/09(日) 20:55:57.38

初心者だった頃は、好き放題にぶっ叩かれてたな

同じようにするまいとは思うものの、他人を制止するのは(ry

2025/03/09(日) 21:48:59.36

初心者だったころはそもそもSNSもインターネッツもなくパソコン通信の黎明期で
周囲には俺以外C言語でプログラムしようという人間もいなかったから気楽だった

2025/03/13(木) 18:20:47.77

十年くらいC++触ってなくて、最近また触る機会があったんだが
なんだこの[]()ってのは…ラムダ式なんて初めて見たよ

2025/03/13(木) 19:23:59.55

そういう古参さんは、頭に+つけるってのを聞くとちょっと喜ぶと思うｗ

2025/03/13(木) 19:42:32.11

>>735
十年前にはもうあったよ！

2025/03/14(金) 07:38:33.30

すっぽすっぽ先生がC

2025/03/14(金) 07:40:07.31

すっぽすっぽ先生がC with Classesを作ってから最初の規格C++98まで19年
C++98からC++11まで13年
そしてC++11から今14年

2025/03/14(金) 10:03:43.97

十年くらい前に最新の書式を導入する情報もリスクを被る勇気も無いわな

2025/03/14(金) 10:23:25.48

>>736
なんスカそれ?

2025/03/14(金) 11:05:51.17

>>741
ラムダ式の前に + を付けると関数ポインタに型変換できるという小ネタの話だと思う。

2025/03/14(金) 15:50:51.90

キャプチャ付lambdaでさらに脳汁

2025/03/14(金) 17:15:25.44

迷走してますなぁw

2025/03/14(金) 21:47:11.78

>>742
初めて知った

2025/03/15(土) 09:10:45.56

>>745
実際にはラムダ式 (クロージャ型) に対しての特別な機能があるわけじゃなくて、単項 + にクロージャオブジェクトを渡そうとするとオーバーロード解決ルールの途中で適用可能な暗黙の変換が適用された結果としてそうなる

**デフォルトの名無しさん** (ｽﾌｯ Sd9a-JU6R) · 2025/03/15(土) 17:45:50.20

[](){}();

2025/03/15(土) 22:57:27.79

停止性問題を一般のケースについて解く機械的手続きで有限時間で必ずおわるもの（アルゴリズム）は存在しないが
人間は納期までにプログラムえおデバッグできる……できる……たぶん……

2025/03/16(日) 09:48:31.74

出来なかったら誰かがどういう形かで責任を取る。
それが社会ってもんだ。

2025/03/16(日) 11:01:20.74

有限時間内に終わる機械的計算手続きとして存在するかという観点で考えたとき
デバックの不可能なプログラムは存在しないという例の命題は偽な可能性、
もっともこの正確な引用は「バグのないプログラムは存在しないがデバックの不可能なプログラムもまた存在しない」であって全体として矛盾した主張であることは前から指摘されてあるが

2025/03/16(日) 11:04:22.68

訂正orz、
誤：　有限時間内に終わる機械的計算手続きとして存在するかという観点で考えたとき
正：　任意のプログラムのデバッグと言う手続きが有限時間内に終わる機械的計算手続きとして存在するかという観点で考えたとき

2025/03/17(月) 06:41:01.39

ラムダ式に+の話は始めて知った
勉強になった

2025/03/17(月) 09:17:27.77

>>746
それちょっとだけ解説きぼんぶっちゃけなんとなくで使ってて気持ち悪かった

2025/03/17(月) 09:55:35.41

オーバーロード解決のルールは大雑把には
　・候補の中で実引数と完璧に型が一致するものがあればそれが選ばれる。
　・完璧な一致がないが暗黙の型変換を適用したら一致するという候補があればそれが選ばれる。
ということになってる。
実際には変換の中にも優先順位がごちゃごちゃあってかなり複雑なんだけど……。

で、組み込みの単項 + が受け取りうる型は何かというと算術型、スコープなし列挙型、またはポインタ型の三つ。
https://timsong-cpp.github.io/cppwp/n3337/expr.unary#op-7

キャプチャなしのクロージャ型は関数ポインタへの変換関数を持っている。つまり暗黙の型変換が可能。
https://timsong-cpp.github.io/cppwp/n3337/expr.prim.lambda#6

クロージャからポインタへ暗黙の型変換をすれば単項 + に一致するからそれが選ばれる。
そういうメカニズムだと私は理解してるんだけど間違いがあったら誰か指摘してね。

2025/03/17(月) 09:58:44.63

単項 + の話題がウケたみたいなのでオマケで * の話もしようかな。
単項 * にクロージャを渡した場合は関数の参照になる。
つまり *[](){} としたら型は void(&)() ってことね。

式中に参照が現れたら参照が指す先の型に変換されて、関数指示子が現れたら関数ポインタに変換されるので多くの状況では最終的に関数ポインタになっちゃうんだけど。

2025/03/17(月) 10:46:49.46

要するに副作用って事か
環境によってとかオプティマイズ如何で違った動きになる事は無いのかなぁ

2025/03/17(月) 11:12:41.81

ならんだろw

2025/03/17(月) 11:24:02.10

昔、ARM系の環境で配列とポインタがまるっきり違う扱いになって困ったって事があったんだよなぁ

2025/03/17(月) 11:44:46.70

>>756
これは言語仕様の話なので言語仕様に沿わないことがあるなら単にコンパイラのバグってだけだ。

2025/03/17(月) 13:02:56.94

「関数の配列」なんてものが存在しないC++で、関数ポインタに合法的な加減算することなんてないはずなのに、その仲間である単項+が効いちゃうのは気持ち悪くはある

2025/03/17(月) 13:42:24.96

関数ポインタをインクリメントしたら次の関数になるとかだったら便利よね

2025/03/17(月) 13:56:11.11

次ってどこだよ

2025/03/17(月) 14:43:44.88

関数のアドレス順とか

2025/03/17(月) 15:28:39.42

コード書いた順だろw

2025/03/17(月) 16:50:25.99

>>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 の規格では今でも単項 + は算術型しか許してないし、それが自然だよな。

2025/03/18(火) 18:06:10.72

>>760-762
各要素のサイズが一定じゃないから無理なんやろな

2025/03/21(金) 19:45:52.92

>>755
またまた勉強になったお！
ありがとうございます！！

2025/03/21(金) 19:49:46.16

関数のアドレスなら呼び出して
スタックに無理矢理アク(以下略)

2025/03/21(金) 22:32:50.41

そういうむちゃくちゃが簡単にできるのがC/C++

そんなことしながら、チップを覚えるんだよなあ
自分、次はMIPS覚えないと

2025/03/22(土) 14:21:53.59

どっかのタイミングでbpがスタックギリギリ飛ばすんじゃなくて
コンパイラが128bytesくらい飛ばす仕様になった気がするんだけど
あれは0埋めで(ホントはバグがあるのに)奇跡的にバグ回避するテクニックなのか
他に理由あるんか

2025/03/22(土) 18:01:17.10

>>770
128 ビット (16 バイト) じゃない？
SIMD とかの都合で 16 バイトアラインが必要な環境が出てきたからという事情だと聞いたことある。

2025/03/22(土) 20:51:53.87

質問なのですがstd::unique_ptr<T>とかstd::shared_ptr<T>みたいなSTLで定義済みの
テンプレートクラスをfriendにすることは合法？
用途はシングルトンﾊﾟﾃｨｰﾝのオブジェクトのプログラム終了時の自動解放

2025/03/22(土) 21:29:46.22

>>772
T のデストラクタが private なのを std::unique_ptr<T> からのアクセスは許すってこと？
特に問題ないよ。

ところでテンプレートクラスじゃなくてクラステンプレートな！

2025/03/22(土) 22:33:09.97

>>773
㌧クス、

>T のデストラクタが private なのを std::unique_ptr<T> からのアクセスは許すってこと？
>特に問題ないよ。
それがTのコンストラクタがprivateなﾊﾟﾃｨｰﾝなのです！
friendにしないとビルドが通らないかった（VS2022、VS2015）。
多分moveとかの最にstd::unique_ptr<T>がTのコンストラクタにアクセスするのだと思う。

2025/03/22(土) 22:39:33.53

>ところでテンプレートクラスじゃなくてクラステンプレートな！
なるほど……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.86

>>775
new Foo() を Foo のメンバ関数の中でやる分には自分自身の中でやることなので friend 宣言は不要。
std::make_unique<Foo>() をすると std::make_unique の中で Foo のコンストラクタを呼ぼうとするから std::make_unique<Foo> をフレンド宣言する必要がある。

2025/03/22(土) 23:48:30.44

>>776
>new Foo() を Foo のメンバ関数の中でやる分には自分自身の中でやることなので friend 宣言は不要。
と思うじゃん？
↓現実
>friendにしないとビルドが通らないかった（VS2022、VS2015）。(>>774

エラーメッセージは熟読していませんぬが、
多分クラステンプレートの実体化がクラスのメソッド全部についてまとめて行われる的なことが起きて、
Tのコンストラクタにアクセスするstd::unique_ptr<T>のメンバ関数（moveコンストラクタとか）が引っかかるのだと予想

2025/03/23(日) 00:18:05.56

>>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.26

通ったが？
https://godbolt.org/z/xzTbKaM5f

2025/03/23(日) 00:20:25.80

あ、被った
内容は一緒

2025/03/23(日) 00:21:43.38

>>777
エラーメッセージは読まんといかんよ
分からんときは今ならLLMに読ませると良い

2025/03/23(日) 01:58:28.60

>>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.75

繰り返しになるが熟読した方がいいぞ
無視していいメッセージかそうでないかも区別できるようになるから

2025/03/23(日) 09:32:31.18

元の話題からはずれる余談だけれど、静的記憶域期間を持つブロックスコープの変数は最初に通過したときに初期化されるルールがある。 (条件によるので常にではない。)
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.75

それunique_ptrにする意味ある？
shared_ptrなら意味わかるけど

2025/03/23(日) 10:45:14.55

>>785
意味ないな。

2025/03/23(日) 10:56:08.84

>>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.97

すまんこTeamsのノリで途中送信すたorz
誤：スレッド安全性担保がそこそこ重い同期オブジェクトで一方unique_ptrの所有権移動は非同期に行われることはなさげ
正：スレッド安全性担保がそこそこ重い同期オブジェクトで行われている危険性がある。一方unique_ptrの所有権移動は非同期に行われることはなさげなので多分軽量

2025/03/23(日) 11:03:44.18

だいたいstd::unique_ptrとstd::shard_ptrでは前者が1個のポインタと同じサイズなのに後者は2個分ある（ヒープにとられた参照カウンタへのポインタを持つため
sizeof(shared_ptr)=16
sizeof(unique_ptr)=8
というのもあり、std::unique_ptr<T>で済むところをstd::shared_ptr<T>推しするのはいかがなものか……