C++相談室 part166

**sage** (ﾜｯﾁｮｲ 8732-NXaD) · 2025/04/26(土) 10:34:58.41

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

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

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

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

2025/04/26(土) 10:36:05.71

仲良く使ってね

2025/04/26(土) 11:57:58.29

STLでサイズがウンタラカンタラってなくなったんだね

2025/04/26(土) 13:02:57.57

あれはキチガイが勝手に貼り続けてただけでテンプレでもなんでもない

2025/04/29(火) 19:50:22.01

プログラムの書き方について学ぶためのサンプルコードですが、
CならLinuxGNUやBSDなど山ほどあるけど、C++の場合は定番としてどんなものがありますか？

2025/04/29(火) 20:44:07.29

Ｃ＋＋標準ライブラリチュートリアル＆リファレンス
っていう分厚い本読んどけば大体理解る

2025/04/29(火) 21:19:32.60

C++のOSSねえ
有名でコードの質がいい奴だとLLVMか？Clangも読めばコンパイラだから言語の勉強にはなるはず
規範的って意味だとBoostだけど、いきなり勧めるには技巧的で上級者向けすぎやな面白いけどね
あと有名所ならOpenCVだけどあれは汚いから真似してほしくない

2025/04/29(火) 23:01:06.57

Open CASCADE も汚いのでお勧めしないなぁ

2025/04/29(火) 23:56:21.35

ライブラリだと各OSに対応するためのコードだったり、ヘッダーオンリーにするためのテクニックだったりで、純粋なC++プログラムの勉強として見るとノイズが多いかもしれない
実は初心者向きの良い教材ってあんまり無いかも？
中級者以上ならBoostなどは勉強になるけど、簡単ではないし

2025/04/30(水) 00:21:11.63

いろいろとフリーダムすぎてなあそこがいいんだが

たとえば、ゲーム作りたかったら既存のゲームエンジン、とか、
やりたいカテゴリか近いところの、長続きしてるところの読んでみるといいかも

答えになってないが、(自分用であれ仕事であれ)使わされるのが一番早い

2025/04/30(水) 00:58:19.68

Windowsの電卓は平易で初心者向きかも
Google系も平易な印象だけど、Googleは独自ユーティリティを多用しがちなのが難点

2025/04/30(水) 09:16:57.03

C++ は言語として特定のスタイルを強制しないという方針を持っているからプロジェクトによって構成の仕方は全く違う。
適当な数個のプロジェクトを見ても数個のスタイルがわかるというだけでしょ。
どれが良いかとか言ってないでたくさん見るしか仕方ないんじゃないかな。

入門書とかいくつかの設計指南系の本くらいは読んでる？
理念抜きで結果として出来上がってるコードを見てもわけがわからんと思う。
本はたくさん読んだほうが良い。

それと C++ は今は三年ごとに規格の改定がある。
どの版を想定するかでもかなり違う。
特に大きなターニングポイントになってるのは C++11 と C++20 だと思う。
最新の GCC で特に指定しなければ C++17 として解釈されるのでこのあたりが現在の普通という感じなはず。

2025/04/30(水) 09:52:26.68

>>5
wxWidgets

2025/04/30(水) 12:58:39.49

Windows … というか Visual Studio だと今でもデフォルトは C++14 なんだよな
機能的には C++23 まで使えるのに

2025/05/04(日) 16:06:14.75

初心者スレないんですまん。

C++でvectorとsetで同じことやらすのってどうやるの？
cout << vec << endl;
cout << st << endl;
を共通で書きたいんだけど、
template?の書き方がわかんないの

2025/05/04(日) 18:28:39.39

>>15
きちんと諸々に配慮しようとすると面倒なんだけど本当にそれが出来ればよいだけならこんな感じで出来なくはない。
https://wandbox.org/permlink/2CaqGO3tiB7G9tCZ

15 (ﾜｯﾁｮｲ afaa-hOut) · 2025/05/05(月) 16:19:33.69

>>16
ありがとうございます。

std::endlの代わりに' '(空白)を使うことはできませんかね
図々しくごめんなさい

2025/05/05(月) 17:57:32.37

>>17
まさに「諸々に配慮」と述べた部分がそれでね……。
ここで定義した operator<< と元からある operator<< の両方が char を受け取ることが可能なので
どちらを呼び出すべきか曖昧なオーバーロード (ambiguous overload) になってしまっている。

ちゃんとやる場合はここで定義する operator<< が受け取れるのはコンテナに限定しなければならない。

型に制約を付ける真っ当な方法が入ったのは C++20 からなのでそれ以前の C++ でやろうとすると回りくどいんだよ。
C++11 でなるべく簡素に書くとしたらこんな感じかな。
https://wandbox.org/permlink/Hli0dW7vNwSICQmp

2025/05/06(火) 12:29:11.51

>template <class T>
>auto operator<<(std::ostream& os, const T& container_object)
> -> typename std::enable_if<!!sizeof(begin(std::declval<T>()) != end(std::declval<T>())), std::ostream&>::type {
横から何じゃこりゃw

2025/05/06(火) 12:35:30.96

declval は要らんな。
もっとキッチリしたほうがいいのか簡素にしようか迷ってちょっと変な感じになってる……。

2025/05/06(火) 13:03:38.40

>>20
いやいや非難ではなく
俺が知っているC++じゃないw
- operatorの前のautoは何ぞ?
- !!演算子?

2025/05/06(火) 13:42:19.73

>>21
関数名の前に auto を書くと仮引数の後ろに返却値の型を書けるようになる。
つまり -> から { までのところに書いてるのが返却値の型。

従来の書き方では関数の仮引数を返却値の型を決定する文脈では使えないというルールがある。
たとえば
template<class T> decltype(e) foo(const T& e) {return e;}
というようなことは出来ない。ここで e を参照することは出来ない。

後置では返却値の型を書くところで仮引数を使ってかまわない。
template<class T> auto bar(const T& e) -> decltype(e) {return e;}
ってのはアリ。

この場合の auto は返却値の型を後置するというマークってことね。
後置にする必要がなくても後置で一貫させてるプロジェクトもたぶん結構ある。
auto がこのような用途で使えるようになったのは C++11 からなのでもう結構浸透してると思うんだけど、全く見たことないの？

!! は ! をふたつ並べてるだけ。 bool にキャストする代わりに使うイディオムなんだけど見づらいからやめたほうがよいという人も多い。

2025/05/06(火) 14:29:32.39

>>22
解説を有難うございます
返り値を後置する記法のアドバンテージが分かりました
>>18は返り値を後置にしてるけどもこれは必須ではないということね
!!も分かりました（g++-12はなしで通ります）

2025/05/06(火) 16:07:03.30

>>23
> !!も分かりました（g++-12はなしで通ります）

非型テンプレートパラメータで size_t (sizeof の結果) から bool への変換 (縮小変換) は認められていないはず……
……と思ったらこれには例外があってコンパイル時計算の文脈で実際には情報が欠落しないなら OK。
つまり整数の 0 か 1 のときに限り (型の大きさとしては小さくなる変換であっても) bool に変換が可能。

2025/05/06(火) 17:28:20.12

非0ならtrueやないんか

2025/05/06(火) 18:05:53.77

>>25
せやで。こういうときは変換されない。

template<bool num>
class foo {};

int main(void) {
foo<2> bar;
}

通常の暗黙の変換で許されていても非型テンプレートパラメタでは縮小変換はされないので↓みたいなのも駄目。

template<unsigned char num>
class foo {};

int main(void) {
foo<1000> bar;
}

15 (ﾜｯﾁｮｲ afaa-hOut) · 2025/05/06(火) 18:35:49.00

>>18
重ね重ねありがとうございます。
なんとか理解してみます。

C++20だとどうなります？
一応、C++の新機能ってぺージ見たんですけど、よくんからなくて

2025/05/06(火) 18:36:01.85

enable_ifは便利だけど使ったら負け感が半端無い

2025/05/06(火) 19:26:25.22

この場合は enable_if は本来の意味で使ってないしな。

2025/05/06(火) 20:07:39.20

>>27
こんな感じかな。
https://wandbox.org/permlink/IgEx8yRTGMZ2qr6U

C++20 からはイテレータの概念も再編されて range という概念で扱うのが好ましいということになり、コンテナは range の一種だったことになった。
コンテナの中のここからここまでという範囲を表すものを中心にした考え方で、コンテナ自身も range だし、コンテナの除き窓のような view も range 。
Rust とか Go で言うスライスみたいなもん。

で、テンプレート引数として受け取った T が std::ranges::range の制約を満たすものなんやでという制約を入れることによってそうじゃないものはマッチしないように出来るし、
他の operator<< の候補にマッチするものがあるのならそっちが選ばれるようになる。

15 (ﾜｯﾁｮｲ afaa-hOut) · 2025/05/06(火) 21:47:53.45

>>30
ありがとうございます。
rangeはときどき見てたんですけど、ぱっと見あんまり必要性がわからなかったんですけど、こういう理由があったんですね。

これから時間があるときは、rangeを意識して書きたいと思います。

ありがとうございました

2025/05/07(水) 09:06:41.19

>>29
ostreamあんま詳しくないので本来の意味じゃないってのが良くわからんかった
コンテナでなければ弾くようにしてるんだと思うけどsizeofで括ってるのは式自体が評価されないようにするため？

2025/05/07(水) 09:38:53.26

>>32
そう。
実態としては sizeof の中の式が成立するかどうかだけが判定基準になってる。
sizeof が 0 を返すことはあり得ないわけだし sizeof の中の式が成立しないなら enable_if で判定する以前に弾かれるわけなので enable_if は判定の役に立ってない。
式を書く場所があるならなんでもよかったんだけど最終的には ostream& になってもらわないといけないので enable_if が楽だったというだけ。

2025/05/07(水) 09:53:44.11

あーなるほど、意味がわかった
ありがとう

2025/05/07(水) 22:31:24.20

vectorって、
宣言時に、要素数と初期値を設定できないっけ？
気持ちとしては、、
↓
vector<int> my_data(3) = { 6, 8, 44 };

2025/05/07(水) 22:42:31.19

>>35
できない。
そうしたい理由としては指定した個数分の要素が間違いなく与えられているようにってこと？

2025/05/07(水) 22:57:31.27

>>35
arrayはそれに近いな
array<int, 3> my_data = {6, 8, 44};

2025/05/07(水) 23:14:20.16

>>35
与えている要素の個数に間違いがないことを確実にしたいというのが目的だとしたらこういう関数を定義するのはどうだろう。
https://wandbox.org/permlink/QBu2dsYRUkrMmLzC

2025/05/07(水) 23:14:51.64

>>36
まあ、普通の配列なら、
int my_data[3]= { 6, 8, 44 };
ってできるので。

できても問題は無さそうだけど…

2025/05/07(水) 23:25:35.43

>>39
文法の一貫性としてということ？
配列をそう定義したときの [3] は型の一部であってコンストラクタに渡す値ではないから……。
配列をそう書けるのが例外的、変則的な措置だと考えるべきだと思う。

**デフォルトの名無しさん** (JP 0Hee-L4A6) · 2025/05/08(木) 00:57:15.98

>>20
decvalは要る。お前さんは数値計算知らん。
型拡張で重要になるぞ。

**デフォルトの名無しさん** (JP 0Hee-L4A6) · 2025/05/08(木) 01:50:59.67

はちみつさんはC++仕様策定委員なの？
委員会でそんな発言されたら困るよ。
今さらtraitsみたいなトリック
使いたくないよ。

2025/05/08(木) 02:01:35.71

>>41
何を言ってるんだ？ >>18 で declval を使ったのが無意味だという話をしてるんだぞ。

2025/05/08(木) 03:34:36.76

>>38
これでできましたね。
(... && is_convertible_v<U, T>)ってなんでしょうか？

（可変個引数Uが存在してって意味？）

2025/05/08(木) 08:59:22.62

>>44
それは特に裏の意味はないよ。
全ての U が T に変換可能 (convertible) であるという制約を入れてる。

**デフォルトの名無しさん** (JP 0Hee-L4A6) · 2025/05/08(木) 11:19:39.64

>>43
そうでしたか。すみませんでした。

2025/05/08(木) 19:02:02.59

>>45
そうでしたか
難しいですね…

2025/05/08(木) 20:09:36.08

>>47
難しい (分かり難い) と感じる部分を具体的に説明できる？

2025/05/09(金) 02:43:45.34

templeteでフォボナっちみたいのって、
実際に何に使うのかね…？

template<int n>
struct fibonacci
{
static constexpr int value = fibonacci<n-1>::value + fibonacci<n-2>::value;
};

2025/05/09(金) 07:07:00.89

もう見抜けない、最先端のAIディープフェイク動画は心臓の鼓動まで再現、判別が困難に
2025-05-08
https://karapaia.com/archives/507859.html

2025/05/09(金) 09:22:27.26

>>49
暗号関係などで用途はあると思うけど今なら関数 (costexpr) で定義したほうがいいな。

2025/05/09(金) 11:24:03.52

>>49
定数の計算を全部コンパイル時にやっちまおうぜというのが流行った時期があった
それでtemplateの目的外使用が過ぎたためにconstexprができた

2025/05/09(金) 15:56:00.48

ボレロさんが生きてた頃に比べるとつまんなくなったなconstexprさん

2025/05/09(金) 16:41:56.66

>>51
はちみつ餃子さんは何系のプログラマーでしょうか？

組み込み系？

2025/05/09(金) 16:43:37.53

>>52
ところで、
なんでコンパイラ側で、constを自動でconstexpに最適化しないんですかね…？

2025/05/09(金) 16:47:27.64

constexpr に特有のトリックは constexpr の制限故に生まれたのだから緩和されれば気合いの入った取り組みも要らんようになる。
真っ当な進歩なので文句は言えんがつまらんというのはわかる。

2025/05/09(金) 16:53:00.47

>>55
する。
const をつけて定義する変数の初期化子が定数式であるときその変数も定数になるというルールがある。
つまり初期化子が定数式なら const 変数と constexpr 変数は同一の効果をもつ。

2025/05/09(金) 20:05:51.01

>>57
そうでしたか
まあ、そうですよね…

2025/05/09(金) 20:07:04.42

>>53
陶芸家プログラマーか…

いろんな人がいるもんですね…

2025/05/09(金) 21:48:50.36

あの熱意で平均寿命まで生きていれば・・・

2025/05/10(土) 12:01:09.18

定数まわりはググったり ChatGPT に質問したりしても理解しにくいんじゃないかな。
「定数」という言葉が違う意味で使われていてそれらがひとつの解説に混在したりするのが意味不明になる原因だと思う。
・なんか決め打ちの値という意味
・変更できない変数の意味
・C++ 規格用語としての定数の意味

2025/05/10(土) 12:14:05.67

constant number
fixed number
magic number

**デルフォトの名無し** (ﾜｯﾁｮｲ f34b-k+y7) · 2025/05/11(日) 19:59:16.83

RustのCargo的なツールってC++にありますか...?

ビルド、依存関係管理等が全部できるオールインワンなやつです。

2025/05/11(日) 20:12:58.46

>>63
しいていえば Conan が近いと思うがビルド自体は指定したビルドツールに下請けさせる構造になってる。
プロジェクトのビルドをする仕組みが多用なので既存のプロジェクトを Conan の管理化に入れるといった状況を考えると C++ 的にはこうなるのは仕方がない……。
C/C++ では OS (ディストリビューション) のパッケージマネージャでライブラリを管理するのが普通だったので言語の側で統括的に扱うツールという文化が欠けてる。

**デルフォトの名無し** (ﾜｯﾁｮｲ f34b-k+y7) · 2025/05/11(日) 20:18:54.81

>>64
そうなんですね...
今RustやってるんですけどC++も触ってみたいなと思って良さげなのないかなと探してるところなんです...
おすすめのビルドツールは何がありますか？

2025/05/11(日) 20:21:24.40

OS提供のヘッダーファイルと連携しないといけないからね
rustだってOSのAPIとして使われるようになったら今の形のままでは済まされないはず

2025/05/11(日) 20:25:47.11

>>66

OS提供のヘッダーファイル？
どんなのがあるんですかね...

2025/05/11(日) 20:34:00.81

>>67
Windows SDKとかUNIX系なら/usr/includeにあるやつとかMacだと/Library/Developerとか
ひとつの環境に複数バージョン同時に入ってたりパスの規則もベンダーごとにばらばらだったり独自の拡張構文が使われてたりで処理系側のツールで吸収しきれるものではなく
自然>>64も言ってるOS側の管理に委ねるという方向に

2025/05/11(日) 20:42:23.09

>>68

えぇ...そうなんですか...
C++にはcargoみたいな便利ツールはない...
OS管理...(´・ω・)

2025/05/11(日) 20:58:44.05

別に便利ツール自体がないわけではなく、ライブラリはOS側のパッケージマネージャやcanonやバージョン管理ツールの機能等で揃えて
ビルドはcmakeというメタビルドツールで各OSの持つビルドツール向けの入力ファイルを生成したりということはする
統一感には欠けるしばらばらのものを組み合わせてるから躓く可能性もずっと高いけども

2025/05/11(日) 21:11:16.07

>>70
バラバラなのはちょっとまずいですね...
なんか良さげなのないもんですかね...

2025/05/11(日) 21:16:18.20

あくまで個人の意見だけど、パッケージマネージャーは conan より vcpkg の方が好き
conan はそれ自体が Python のパッケージなので、「リポジトリのルートに Python の仮想環境 (venv) を作る → 仮想環境にConan をインストールする → C++ のライブラリを管理する」の流れになるのがね…って気持ちになるかも

どちらにせよ conan や vcpkg は外部ライブラリの管理だけに使うもので、ビルドは cmake を使う

C++だとライブラリ間に依存関係があるものは少ないから、 Git のサブモジュールを使うとか、 clone したソースファイルをそのままプロジェクトに入れるとかする方法もある (綺麗ではないけど)
PythonのpipやRustのCargoがやってるような、バージョンを考慮した依存の解決はしなくて済むことが多い

2025/05/11(日) 21:17:42.17

色々と事情はあるけどファイル数個で収まる程度 (初心者が書く程度) のプログラムならビルドツールがどうこう考える必要もないよ。コンパイラドライバを呼び出せばそれで終わり。
ファイルが増えたりサポートする実行環境が増えて手に負えなくなったときに続きを考えたら良い。

2025/05/11(日) 21:17:53.90

リンク先の画像見てのようなミームがあるけど、残念ながらC++は割と本当にこの通りなんだよね…
Rustがめっちゃ楽なのはよく分かる

https://www.reddit.com/r/ProgrammerHumor/comments/1hnfuvk/whyidliketoavoidusingcpp/

2025/05/11(日) 22:02:05.72

自分の手元でさえビルドできればそれでいいなら統合開発環境に任せてしまう手も。何も考えなくても1クリックで最適にビルドしてくれるよ

2025/05/11(日) 22:18:31.15

c++やるなら苦労経験した方がええやろ

2025/05/12(月) 11:10:35.53

>>74
まるでCargoでbuildが絶対失敗しないかの様な言い草ですね

2025/05/12(月) 11:11:51.96

>>75
C++が初めてならそれで良いと思う