C++相談室 part167

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

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

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

---

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

>>1
O2

通常、"xxx.h" の中に、static 修飾されたグローバル変数
(内部リンケージ)を書くのはおかしい。
しかし、はちみつ餃子によれば、
const int g_a = 5; //(1)
は、static を付けて無くても内部リンケージなんだそうだ。
しかるに、(1) は、"xxx.h" の中に書く習慣がある。
なんかもやもやする。

>>3
C++ Draft になんて書いてあるのかは知らないが、
内部リンケージと考えずに、COMDAT ANY Section だとすれば、
納得がいく。その場合、同じ定義を書くと、1つの section だけ
ガ残る。

内部リンケージとなる const int をヘッダに書いてると、定数式として使われる分には問題無いけど
左辺値としてアドレスを取るようなことをすると無駄な重複定義が生まれたり、
それをインライン関数内でやるとODR違反になったりして問題になることがある。

今なら constexpr int としておくことで暗黙に inline 変数となり暗黙の内部リンケージからも外れるので問題無くなっている。

>>5
でも、C++ の教本では constexpr キーワードが導入されるより
ずっと前から、const 修飾のグローバル変数をマクロの代わりに
使うことが推奨されていた。
マクロの代わりになると言うのであれば、"xxx.h" の中に
書いて良いはずだったはずなのに。

なんだかんだで整数程度はマクロで定義したほうが扱いやすいことが多かった。
正直言って C++03 時代に定数の定義のために const を推奨するのは理想論が過ぎると思う。
(そうしたいと思ってた人は多かったが言語機能が充分に噛み合ってなかった。)
実際に駄目だったからこんな基本的なところで改良が付け加えられてるわけだし。

>>77
>(そうしたいと思ってた人は多かったが言語機能が充分に噛み合ってなかった。)
しかし、C言語の算術定数の場合、整数、float、double が
定数自体の書き方で区別が出来るようになっているから、それほど
欲しいとは思わなかった。
それに、定数の型が char と int で全く動作が変わってしまうような
プログラムは、そもそも推奨されないというか、バグの元になる。
例えば、FILE *fp; に対して、

FlexibleWrite( fp, g_a );

で g_a の型が char なら、1 バイト、int なら 4 バイトの書き込みが行われる
という書き方は、好きな人もいるらしいが、不安定で見つけにくいバグの原因に
なりがちなので、推奨されない。

>>3
>通常、"xxx.h" の中に、static 修飾されたグローバル変数
>(内部リンケージ)を書くのはおかしい。
何で?

>>9
1. 「内部リンケージ」のグローバル変数は、その翻訳単位 A に
　のみにローカルな変数の事である。
2. xxx.h に書くグローバル変数は、複数の翻訳単位で
　共有されるものを書くのが基本。
　なぜなら、翻訳単位 A だけに必要な情報であるならば、
　A のソースファイル a.cpp に書けばいいから。

>>10
(xxx.h)
static int s_a = 5; //内部リンケージのグローバル変数！！！
としておいて、
(t1.cpp)
#include "xxx.h"
・・・
(t2.cpp)
#include "xxx.h"
・・・
(t3.cpp)
#include "xxx.h"
・・・
と書いたとすると、これは、
[続く]

>>11
[続き]
(t1.cpp)
static int s_a = 5;
・・・
(t2.cpp)
static int s_a = 5;
・・・
(t3.cpp)
static int s_a = 5;
・・・
と書いたのと同じ。
これだと、「5」を初期値に持つ4バイトの領域が、3つ分確保されてしま
うので、xxx.exe は、12バイトの領域が含まれてしまうことになる。
それならいっそう、static 属性を付けず、
(xxx.h)
extern int g_a; //定義なしの宣言
とし、t1.cpp、t2.cpp、t3.cpp のどれかひとつのファイルで、
int g_a = 5;
と書いた方が効率的。そうすれば、xxx.exe では、4バイトしか
消費しないで済むから。

selectany使いの俺、低見の見物

>>10
>2. xxx.h に書くグローバル変数は、複数の翻訳単位で
>　共有されるものを書くのが基本。
それが思い込みだよ

>>14
内部リンケージとなる名前をヘッダで宣言した時点で >>5 で挙げたように
重複定義やODR違反の可能性が生じてしまうから、それが適切となるケースは思い当たらないんだけど
一つでも有用な例を挙げられる？

>>10
それが「噛み合ってない」と述べた内訳のひとつ。
C++ の仕組みでは各翻訳単位でのコンパイルが完了してからリンクするというフェイズの分け方が解釈に強力に癒着していて変えられないので変数を定数式として使うためには定義である必要がある。
他の翻訳単位に定義がある変数が定数式になることはない。
この前提では内容が同じであってもそれぞれの翻訳単位で定義する必要が生じる。

>>12
が、それぞれの翻訳単位で定義しても変更されることがないことがなくアドレスを使うこともない変数は最適化でほぼ消えることをあてにして良い。
むしろ const な変数を外部リンケージにすると翻訳単位の中だけでは消せるはずのものを (他の翻訳単位で使う可能性があるから) 消せないということが起こって不利になる。

後から導入されたインライン変数は定義が複数あってもよく、しかも他の翻訳単位にある定義と統合されてひとつの実体を持つ (つまり全て同じアドレスを持つ) ことを保証するということで楽な運用を出来るようにした。
C++ のインライン関数の考え方をそのまま変数に延長しているのでわかりやすい。
ただ、オブジェクトの実体がどこかの翻訳単位に属して他の翻訳単位からはそれを参照するという (C から引き継いだ) 考え方はぶっ壊れてる。
テンプレートの導入の時点でもうぶっ壊れてるけど。

ところで、関数の戻り値のところに書く場合の constexpr は、
関数の内部のコンパイルの仕方まで変更してまうので、
const と書いた場合とは働きが明確に異なるけど、
グローバル変数の場合、型名の直前に書く場合は、
const と constexpr でどんな違いが有るんかいな？

constexprは計算式が書いてあればコンパイラが解いて計算結果を返す。constexprの即値を返す関数のみ計算が可能。
constは、単に値を変更できないことを表す。本来の意味は定数でもなんでもない。リードオンリーという意味。

>>18
なお、global 変数において、constexpr でなくても、
const int g_a = 初期値;
と書いてあれば、初期値部分に関数呼び出しや変数が書いて
無い限りは、定数になるまで計算されている。
この場合に限り、g_a マクロの様に振舞える。

>>17
const 付きの変数は初期化子が定数式のときは定数式として使える規則なのでそのときは constexpr との差はほとんどない。
そうでない場合 (初期化子が定数式でない場合) は const は単に書き換えられない変数というだけで定数式としては使えなくなる。
constexpr は初期化子が常に定数式であることを要求し、そうでない場合はエラー。
(より厳密な用語で言えば不適格。)

あとはシンタクス的な違いがちょっとある。
const int* p = &a;
と書いたときは p が指す先の型が const int で p 自体には const 性はない。
constexpr int* p = &a;
と書いた場合には p が指す先は int で、 constexpr は p 自体にかかっているという解釈になる。

>>19
C++ にグローバル変数なんて分類はないし、関数スコープでも const 付き変数の初期化子が定数式だったら定数式として使える。
再度強調しておくがマクロと同列に考えるのはやめてくれ。
字句的な規則と式評価の規則は全く別のレイヤなので結果的な動作が似て見えたとしてもメカニズムの話には持ち込むべきではない。

>>20
>C++ にグローバル変数なんて分類はないし
C++ の Draft では、余り使われて無い気がするが、
昔から習慣的に global variable と言われている
ものを C++ Draft 的に言うとどうなるとあなたは考える？
なお、関連するものとして、
namespace scope、global scope という言葉がある。

>>21
慣例も尊重はするけど伝わらなかったり曖昧だったりするなら話は変わってくる。
慣例はそんなに統一されてないんだよ……
この場合は推察は出来るからあまり強くは言わないけど気を付けてねくらいの感じ。

グローバル変数という言葉は余り使われていないというか、仕様の中ではスコープの分類とは違う意味で使われてる。
明瞭な用語の定義はないものの文脈的には思わぬところで変更されるような (つまり公開範囲やアクセス経路の設計に失敗している) 変数くらいの意味で使われてる。

翻訳単位の外に公開されているようなものに限ってグローバルと称している事例などもあるし、その定義ならクラススコープの public で static なデータメンバはグローバル変数と読んでもおかしくないことになる。

>>22
むしろ、namespace scope という言葉が逆に話を複雑にすることもある
名前なし namespace の scope と global scope が別の概念であったりもする。
複雑さは異常なくらいで、namespace、scope、life time の言葉も非常に
微妙なニュアンスや定義の差があったりするが、共通する部分も有り
そもそも C++ Draft が良い書き方なのかにも疑問が持たれている。

>B.cでg_aにアクセスする必要があるときにはA.hをincludeする
>絶対にB.cにextern const int g_a;と書いてはいけない

そんな作法無い

>>24
それは、前スレの以下の投稿の事だね。
(ちなみに、私の発言ではない)
「
988 デフォルトの名無しさん (ﾜｯﾁｮｲ 8101-ma3r)
2026/01/29(木) 14:11:34.91ID:7sXa6UKh0
>>986
g_aの宣言はA.hで行う
extern const int g_a; とするか extern int g_a;とするかの選択が強制される

B.cでg_aにアクセスする必要があるときにはA.hをincludeする
絶対にB.cにextern const int g_a;と書いてはいけない

これは作法の範疇だよ
作法を破れば何でもできるさ
」

なんつーか、関係ない話だけどさ

最初に疑問を投げた人が、おそらく回答したであろう人のレスに「なお、」って付け加えるのって凄く変に思うんだよな

>>23
global scope は global namespace scope の別名で、 namespace scope の一種。 (包含関係)
https://timsong-cpp.github.io/cppwp/n3337/basic.scope#namespace-3
多少の特別扱いはあるけど別の概念というわけではないよ。

仕様書が分かり難いのは C++ が分かり難いからで、 C++ が C++ である限りどう表現したって分かりやすくはならない。
そんなのは参考書で補えというのが委員会の立場。
というか普通は単なるユーザが仕様書をガッツリとは読まなないのが普通だし、わかりやすいことよりも曖昧さがないことが仕様書としてあるべき姿でしょ。

最後にどなたかまとめてくれると嬉しい

>>27
>global scope は global namespace scope の別名で、 namespace scope の一種。 (包含関係)
これは正しいが、
「名前なし namespace の scope」と「global scope」は別の概念
ということはまた正しい。

>>27
>わかりやすいことよりも曖昧さがないことが仕様書としてあるべき姿でしょ。
定評のある C++ の本を書いている人が、C++ の Draft が仕様書として曖昧さが
無い、とは思ってないようだったが。
少なくとも、彼が自分で呼んでも不明瞭な事が一杯有った、ので、
詳しそうな人に沢山の質問をしたと書いていた。
つまり、仕様書を読んだだけでは理解できないようになっている
可能性が高い。

定数定義はenum使う派いる？

>>30
曖昧さが無いようにという指針が実現できていないのは事実だよ。
曖昧さに関する欠陥報告はたくさん出てる。

ただそれは批判したところでどうにもならん。
正確な記述のために努力してなお曖昧なのでこれ以上にできることがあるわけではない。

>>31
enum が妥当な場合、選択肢として複数の整数がありうるような場合ならもちろん enum を使うけど……
特定の数値のためにひとつひとつ異なる列挙型を作るという意味ならやらないな。
C++ の列挙子は個々の列挙型なので (underlying type とある程度の互換性はあるものの) 型を本来あるべきものに出来ない。
統合開発環境で型を表示させたときに意味のない列挙型が出てくるとはかなり嫌な感じがする。

>>32
かなり高度で評判の良い C++ の教本を書いている人の間でも、
C++ Draft の書き方には問題があるんじゃないか、という説もある

>>35
主張は何？ 何が言いたいのかわからない。

>>36
C++ Draft が分かりづらいのは、曖昧さの除去に役立ってない

>>37
現状をそう解釈したとして、その上でどうすべきと考えているのかを明瞭にして。

>>38
どうすべきかは彼らの問題だ。
C++委員会を手伝うことはしたくない。
彼らの事の進め方が、私の思想とは全く異なるから。

ある委員会がありました。その人達が決めた仕様が全体的に
おかしく、分かりにくく、評判も時と共にどんどん悪くなっていきました。
「それを直すことは人類に役立つから直すべき」
などと考える人がいますが、そうすると、委員会が得をしてえらそうに振舞う
だけで、画期的な良い提案をした人には何のメリットもありません。

ガイキチはほっとこ

仕様で盛り上がるなんていつぞやのrustスレ

>>40
委員会が諸悪の根元で、自分たちの利益のために改悪してるとても言いたげだな。
委員会を運営するために金を出してるスポンサーが誰で、何のためにやってるかわかってんのか？

>>43
>委員会を運営するために金を出してるスポンサーが誰で、何のためにやってるかわかってんのか？
教えて。

>>43
>自分たちの利益のために改悪してるとても言いたげだな。
そういうことでは全く無い。
物事を行うシステムの問題を言っている。

ずいぶんふわっとした内容なことで

C言語だと単にconst int foo = 10; と書いたら外部リンケージになるため
複数の箇所からインクルードされるヘッダファイルbar.hにそれを書く場合は
extern const int foo;
とせねばリンカーか何かに起こられる。（もちろん=10は.c の方に const int foo = 10; と定義を書かねばならない
従って、C++とから
extern "C" {
#inclue "bar.h"
}
としたときにbar.hにexternの無いconst int宣言が含まれることは事実上無いからでextern "C" の曖昧さの問題は事実上無いﾊｽﾞ……

それよかむしろ関数の宣言のexternを省略したやつをextern "C" { } で囲った場合どうーなちゃうの？！
と言うのが疑問ではある（Visual Studioだと経験上問題なさげ……

>>47
>それよかむしろ関数の宣言のexternを省略したやつをextern "C" { } で囲った場合どうーなちゃうの？！
「関数プロトタイプ宣言」の場合、
extern 書いても書かなくても同じはずだが。

まだやってんのか
初学者ならともかく暫く書いていたら
自然と身に付くことやろw

>>39
ならc++を捨てて自分で言語を開発すればいいんじゃない？Rustみたいに。
思想も名誉も自分のものだよ。

>>48
前スレで
>つまり、extern "C" の直後を中括弧で囲ってないものは、extern 宣言であるが、
>extern "C" の直後を中括弧で囲っていて、中に extern で修飾してないものは、
>(原則として)「狭義の定義」である。
と書いたあった、
すわなちextern "C" { } のブロック内に
externを省略した（extern で修飾してない）関数宣言がある場合、
>(原則として)「狭義の定義」である。
に該当しそう(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

>>48
前スレで
>つまり、extern "C" の直後を中括弧で囲ってないものは、extern 宣言であるが、
>extern "C" の直後を中括弧で囲っていて、中に extern で修飾してないものは、
>(原則として)「狭義の定義」である。
と書いたあった、
すわなちextern "C" { } のブロック内に
externを省略した（extern で修飾してない）関数宣言がある場合、
>(原則として)「狭義の定義」である。
に該当しそう(((( ；ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

大事なことなので2回言いました
大事なことなので2回言いました

関数の場合と変数の場合で意味が違ったりするという一貫性の無さも C++ の持ち味

>>51
それは変数の場合。
関数の(プロトタイプ)宣言の場合は、問題にならない。
なぜなら、static 修飾した同名の関数と混在して宣言するなどの
特殊なことをしない限りは、
extern void func();
と
void func();
は、同じ扱いになるから。

バカが揃うと一気にスレが進むんだよね
たまにこういうタイミングがある
しかも抑えが効かないのかきまって長文

心しますｻｰｾﾝｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

このスレだとだいたいｵｲｺﾗﾐﾈｵかごめ；；の人やな

いやそこらのﾐｼﾞﾝｺより目立ってしまってｽﾏﾝｺ（ｷﾘ

いや、相談の範疇ならスレタイ通りだろ。
変な主張始めたらスレ違いカエレだけど。

いまさら人に聞けない
酒席とかでネタにするために、経緯を押さえたい話

C#のTAPと、C++のコルーチン。偶然、ほぼ同時期に学ぶことになって、うん、だいたい一緒。って思ってる
これって結局、投票とかで、C#の書き方でいいよもう、ってなったってこと?
それとも、両方に共通の祖先とか居る?

>>61
C# でそのへんに関与してた人が知見を持って C++ にも提案した。
結果的には色々と違いも大きいので実際には単純ではないけどキーマンが共通しているというのは特に大きい要因だと思う。

>>62
ずいぶん詳しいんだね

>>63
私が回答を付けるときはだいたい資料を確認してるよ。
詳しいというより手間をかけてる。

規格を追ってる人のブログを普段からざっと目を通すくらいのことはしてるけど。

わりと昔からちょいちょいこのスレは見てるが、はちみつはわりとちゃんとした知識で解答しとる印象ある
趣味人でプロとしてはC++のコーディングはしてないと言ってるが、ホンマかいな？と思うぐらいにはちゃんとしてる

はちみつの中の人は江添だからな


というボケを考えたがさすがにキャラが違いすぎか

>>65
まあ、
日曜プログラマーレベルだな

江添さんの本で勉強しました。ここにいるの？

もう人間がプログラミング言語の仕様なんか意識する時代じゃないって言ってたよ

そうだけど気が早いｗ 移行期の間は勉強しとくと役に立つ

>>65
そりゃガチの素人は関係のある資料を探すことも解釈することも出来ないから……
私はそれが出来る程度にはちゃんとした言語仕様の知識がある自信はあるけど
言語仕様をそれなりに知ってるという程度でプログラミングが十全に出来るというわけではないだろう。

私がちゃんとしているように見えるならそれは知識が優れているからではなく、
ちゃんと調査してちゃんと言語化するのを丁寧にやってるからだと思う。

>>66
キャラもそうだが、以前から私の言葉を見ているなら世代的に私が江添氏より古いことはわかると思う。
私が最初に江添氏を知ったとき、彼は C++ のことなんか全然知らなかったよ。

たとえ規約書を完全に読みこなし、完全無欠に言語を操れるとしても、
俺らの駄文愚問に向き合って lex&parse して、推定・回答までしてくれるとは限らない
自分で学べ、さもなくは去れみたいなカルチャのC++ならなおのこと

はちみつたんのような御仁を、我々中級者は大事にすべき

初級者は…ありがたみがわからんか…。

きもいわ

他の言語スレと比べてみるとよく分かる
有識者のいないスレは閑散としてるからね
C++スレは恵まれてるよ

八光さんのhageは自分で剃ってるのかどうかは気になる
お薬のせい？

スレ潰しの荒らしはスルーしようぜ

有識者っていうか質問者の代わりにしっぽ振って調べに行く手動クローラみたいな感じよ
体のいい初心者にはいいように使われて実務者からはバカにされてる

「相談室」スレなんだから、初心者の質問に答えるのは妥当じゃないかな。

>>77
「調べに行く」はちょっと違うと思う
「たしかこうだったよな」という見込みはあって、それでも一応確認して正確な情報を提供してくれてる
こんなに頼りになる人そうそういないぞ

実務者ってMFCでUI作ってる人みたいなの？

Linuxでも、WineでWin32やMFCのアプリは動くけど、使っている
フレームワークや技術が新しくなればなるほど、動きにくくなる

>>80
それくらいしかバカに出来る対象がいないんだろうけど
そういうことしててもお前の腕は上がらんよ

MFCでUI造ってると指摘すると馬鹿にしたことになるのか？

デバドラのコンパネなので、MFCでUI造れ。と言われたら、粛々と作る。それが実務者

デバドラのコンパネなので

理由になってない
ことがわからないんだよなこのジジイは

以前はデバイスドライバーのインストーラーで100MB超えてたりすると嫌だなーって感じた
たぶん、.NETでユーティリティとか作ってたんじゃないかと思う

いまはデバイスドライバーで100MBとかあっても気にならない
作りやすいツールキットでUI作ってくれていいよ

>>86
C#は、「自己完結型」にすると、*.exe のファイル中、または、同じ
ディレクトリの中に *.dll を同梱することになり、ユーザーに
配布するファイルのバイト数が、100MB を超えるらしいね。

DLLって本来はアプリ側が巨大にならないようにOSが提供する名目だったのに
依存性爆発のDLL同梱しないといけない馬鹿アプリが大量生産されて
どうしてこうなった

いつもMFCのことはバカにしてるけど
MFCを使って開発してる人のことを
バカにしてる訳じゃ無いんだ
判ってくれ

>>88
DLLやランタイム同梱は歓迎だけどなー
昔は、vcruntime12入れてくれとか、.net3.5入れてくれとかあって面倒だった
依存関係まるごと全部入りでZIPを展開するだけで動かせるのは正義だよ

それって同一システム内に重複したDLLが散らばっているってこと?

そもそも、.NET の DLL って何種類くらいのバージョン(?)
があるんかいね？ .Net Core とか .Net なんたら とか沢山
有って、その中で Version 数値も色々有るんだろうけども

>>92
例えば、
.NET
.NET Framework
.NET Core
.NET 5
.NET Standard
のようなものや
Mono
が有るらしいね。

おれﾈｲﾃｨﾌﾞはライブラリのみで使ってるわ

>>91
そういうことだろね
俺もシステムフォルダに入れるより重複してでもアプリ直下にいれるのが好き
それ使ってるアプリ削除するときにゴースト化しなくて済むし

VSは、C/C++でも、CRT や MFC の DLL 版をリンクした場合、
*.exe の中に、どのバージョンの DLL が必要化の情報が
入っているらしい。MSVCR80.dll や MSVCP140.dll、msvcr100.dll
みたいな。だから、間違って動的リンクされる心配は無いらしい。
ただ、その DLL が見つからないと起動できない。

今の Windows のインストーラ (MSI) は依存関係のあるコンポーネントが入って無ければ入れるような形にすることは出来る。
古い世代の人間はインストーラを全然信用しないから ZIP 版を落してきて適当なところに置くみたいなことをしちゃうんだよ。
「レジストリが汚れる」みたいなことを言ってる人がまだいる。
Windows の管理化に入ってるコンポーネントと入ってないコンポーネントが入り乱れてよくわからん環境が出来上がる。
かといって各アプリケーションのインストーラが本当にきちんと定義されてるかというとあまり信用できないのも本当なんだよな……

msvcr/ucrt/mfc/atlは、システムが管理しているものは、WUの対象になるから、
まさかのセキュリティホールを突かれるリスクだの、ランタイムを責任もって更新する手間だのの分がラクになる

もうd5

MSVCR80.dll、MSVCR100.dll、MSVCP140.dll などを全部入れても
大した容量ではないはずなのに、OS には最初からは入ってない
のは、なんでなんだろうね？

>>88
その発想の延長上にdockerがあり、いまやごく当たり前

>>100
同じ名前でも微修正された異なるものがある。
それらも含めてとなるとそこそこの分量になるし、修正が必要だったもの (問題があったもの) を残すのは良くないだろう。
過去のバージョンを際限なくメンテナンスというわけにもいかない。

本来なら最新版に合わせてアプリケーションを修正して欲しいに違いないが、古いバージョンのランタイムに依存し続ける選択をするならそれはアプリケーションかユーザーの責任でやれ (Windows は面倒を見ない) ということだと私は理解してる。

Microsoft Visual C++ Redistributable latest supported downloads
https://learn.microsoft.com/cpp/windows/latest-supported-vc-redist

>>101
>>98を否定する考え方だな
管理不可能なセキュリティーホールを散らばらせることになる

Docker の役割は環境を定義することが本筋。
依存関係の解決に使うのも用途のひとつとして間違っているとは言い切れない。
だけど Docker コンテナに古いバージョンの依存関係を閉じ込めたままでずっと使い続けているのだとしたら間違った運用だと思う。
メンテナンスしなくて良いわけではない。

依存関係がどうこう言うくらいならなるべく全部を静的リンクしたほうが良くない？ という思想が現代的潮流かも。

確率されたシステムをよりセキュアに保つ方法を
ユーザのインストールの利便性と天秤に掛けて前者を捨てている
Docker流行ってるのは軽率だと思うよ

ちょっとバージョンが違うと、もう動かない、ってのが多発すると、防衛的に、そうなっちゃうのもわかるけど

そのためにテストってあるんじゃない?
と、テストをいまだ自信をもって書けない俺が思う

今は動的ライブラリのメリットほとんどないよな
ストレージの節約は今や誤差レベル
バグフィクスが意味あるのは極一部でほぼ幻想、バイナリ互換を保つのは地獄
意味あるのはプラグインの機能拡張ぐらいか

CUDAみたいなギガサイズのライブラリもあるんですよ

フロッピーディスクでも使ってんの？

>>109
バージョン合わせるのめんどくさいね
CUDAとnvidiaドライバー

あのCUDAとか、LLVMとかのクソデカさは、C++のtemplate のフリーダムさのせいだと信じてる
すっごい重複があるんだろうと

もしRustになったら、コンパクトになるように書き方が強制されるので、ずいぶん小さくなりそう
それでまた、C++が馬鹿にされるんだ

ああ、いやだいやだ もちろんC++派です

>>108
個人的には、開発中は DLL 版でビルドしている。
リリースする時だけは、static リンク版にするつもり。
Debug の *.exe のサイズが小さくなって良い気がするから。
複雑だけど。

正しく書けていればそれでよいんだけど未定義を踏んでたりするのがコンパイルオプションの違いで顕現することもあるから開発中でもたまにはリリース用のビルドをしてテストを通したほうが良いよ。
工程の最後の方で問題が発見されるとしんどい。

構造体や配列の初期値が0を期待したコードは書くべきではない(C++でも)

この唐突な言いっぱなし何なの？w
staticなストレージなら規格で決まってる
OSのローダーの動作としても決まっている
そんなとこ疑うのはむしろ素人

そなの？　
int data[10]{0};
char *str{nullptr};
とか入れてるけど。

プロジェクト単位でちゃんと決めたらよろし

組込み系とかだとスタートアップルーチンを書く立場になりうるから言語仕様の保証を受けられない (というか自分が保証する側) ということも無いとは言えないが、保証されているときに保証を信じられないと言い始めると何も出来なくなる。

① 期待できるときには期待すべき。
② 期待できるときかどうか判断する能力がないなら判断できるように学ぶべき。学んだ上で人は間違えるものであるからレビューやテストの体制を整えるべき。
③ それができない人員と組織であるときは一律に期待しないルールを課すのが仕方ないときはあるかもしれない。

struct Hoge; // 前方参照
struct Hage {
Hoge hoge;
};
struct Hoge {
int hage;
};
↑これは期待通りコンパイル出来るのですが
struct Hoge; // 前方参照
struct Hage {
Hoge hoge;
};
typedef struct _Hoge {
int hage;
} Hoge;
↑これだとエラーになります
struct _Hoge; // 前方参照
struct Hage {
struct _Hoge hoge;
};
typedef struct _Hoge {
int hage;
} Hoge;
↑こうすればコンパイルは通るのですが
typedefはそのまま残して2番目の書き方でコンパイル通すにはどう書くのが正しい？

>>120
3つとも通らないよ
コンパイラは何?

struct Hoge; // 前方参照
struct Hage {
Hoge *hoge;
};
struct Hoge {
int hage;
};

>>120
細々とした規則はあるけど、覚えて置くと楽な規則は「クラスの定義はそれによって大きさが確定する」ってことだ。
逆に言えば大きさを確定できないようなクラス定義を書くことはできないように規則が定められている。

その最初の例で言えば struct Hoge; で Hoge がクラスであることはわかるようになったが大きさを決めるのに必要な情報がない。
なので
struct Hage {
Hoge hoge;
};
としたときに Hage の大きさもわからない。
そういう書き方は許されないようになっている。

二番目の例も三番目の例も同じ。

>>120
そして型名と型名のエイリアスは違うものなので二番目の例は前方宣言と異なる定義をしたと見做される。
C++ では C に有った構造体タグの概念が消滅したのでそういう typedef の使い方は無意味。

この場合にどうして前方宣言を使いたいのかわからない。
普通にこう書けるのに。

struct Hoge {
int hage;
};
struct Hage {
Hoge hoge;
};

訂正です
struct Hoge; // 前方参照
struct Hage {
Hoge *hoge;
};
struct Hoge {
int hage;
};
↑これは期待通りコンパイル出来るのですが
struct Hoge; // 前方参照
struct Hage {
Hoge *hoge;
};
typedef struct _Hoge {
int hage;
} Hoge;
↑これだとエラーになります
struct _Hoge; // 前方参照
struct Hage {
struct _Hoge *hoge;
};
typedef struct _Hoge {
int hage;
} Hoge;
↑こうすればコンパイルは通るのですが
typedefはそのまま残して2番目の書き方でコンパイル通すにはどう書くのが正しい？
>そして型名と型名のエイリアスは違うものなので二番目の例は前方宣言と異なる定義をしたと見做される。
>C++ では C に有った構造体タグの概念が消滅したのでそういう typedef の使い方は無意味。
別物なら仕方無いですね
>この場合にどうして前方宣言を使いたいのかわからない。
これは再現する必要最小限のコードにしたからそうなっただけで
前方宣言にしないといけなり理由が別にありますね

>>125
どうしても Hoge とは別に _Hoge が必要なら _Hoge のほうを別名にすればいいんじゃね？

struct Hoge; // 前方宣言
struct Hage {
Hoge *hoge;
};
typedef struct Hoge {
int hage;
} _Hoge;

あるいは typedef に強い意味があって _Hoge に意味がないなら

struct Hoge; // 前方宣言
struct Hage {
Hoge *hoge;
};
typedef struct Hoge {
int hage;
} Hoge;

とか。
C との互換性のためだけの無意味な文法だけど。

何が譲れない制約なのかがいまいちわからん

>>125
意図が分からないまま発言ですが
2番目の例、1行目の「struct Hoge;」が後方と不一致だから「typedef struct _Hoge Hoge;」に直すのはどうですか

こんなのこそAIにやらせたらいいんじゃないの？とかやってみもせず提案する(鼻ホジ)
コード貼りつけて「コンパイル通るようにして」

クラスや構造体の前方宣言は
1. FooとBarがそれぞれBarとFooを参照する、みたいな相互参照する場合
2 Barを参照するFooを定義するヘッダファイルでBarのヘッダファイルをインクルードしたくないという
　気まぐれな要望を満たす場合
というのが動機の97%を占める（脳内調べ

>>131
ヘッダを C と C++ とで共用できるようにある程度は記法を近づけておかないといけないという現実的な理由だよ。

>>125
蛇足だけど、
「_（アンダースコア）で始まり、大文字が続く名前」
は予約済みだからユーザー定義では使えないよ。

>>128
それでイケた気がする
struct _Hoge; // 前方参照
typedef struct _Hoge Hoge;
struct Hage {
Hoge *hoge;
};
typedef struct _Hoge {
int hage;
} Hoge;

>>130
>2.Barを参照するFooを定義するヘッダファイルでBarのヘッダファイルをインクルードしたくない
まさにそれです！

>>133
struct __Hoge; という名前なら予約域回避出来るんですかね

どうせなら後ろに付けては 全部読んでないけど

>>136
二つ以上連続するアンダースコアが含まれる (←つまり先頭以外の場合も) ような名前も予約されてる。

>>137
そうしますありがとう

>>135
モジュールの導入で依存関係の階層化が改善されているけど逆に言えばそれ以前は全然駄目だった。
どうせ駄目なので小細工は徒労だと思う。

CやC++で意図的にアンスコ始まりの名前をつけてる奴の異教徒な匂いはすごい
そのおかげでRustのように未使用変数名をアンスコから始めないと警告が出る言語は馴染めない

>>130
>気まぐれな要望を満たす場合
include しても、言語的に class CXxx; という不完全定義が
存在していなければ、無理。

インクルードガードのマクロを __HOGEFUGA_H__ みたいにしているライブラリめっちゃ多いけどあれ全部未定義動作踏んでることになるのかな

当たらなければどうということはない

>>143
未定義だよ。

ただ、 C++ の予約名は「標準ライブラリが」予約していることになってる。
https://timsong-cpp.github.io/cppwp/n3337/reserved.names#1
実装上の都合とかで標準ライブラリがそういう名前を使うかもしれないからユーザが使うと衝突してワヤになるかもしれんぞというのが予約名の意味。
だから標準ライブラリやそれに付随するような OS 関連のヘッダなどで予約名を使うのは OK 。 (そのための予約)

もし問題があるとしても大抵の場合に名前の衝突を引き起こす形で顕在化してコンパイル時にわかるので未定義と言っても実態としては比較的には害は小さい。

私自身は適当に生成した乱数でインクルードガード用の長い名前を作ったりしてる。
三十文字くらいのデタラメな名前なら衝突しないだろう。

インクルードガードはふたつかみっつ昔ぐらいはアンスコで始まるマクロで書くパターンはものすごく多かった
まだそのころはアンスコスタートの識別子は予約語っていうのは決まってなかった、ないし決まってても周知されてなかったからな

アンスコというより短いマクロ名は禁止にしてるわ
prefixを必ずつけるルール
templateのテンプレートパラメータを大文字1文字にするやついるけどあれも禁止

ちなインクルードガードはもうpragma onceしか使ってないわ
古いコンパイラは無視、そもそもテストしないし

ARM にアンダースコアに関する言及を見つけた。
ちゃんとルールとして書いてあったけどその頃の主な用途は関数名のエンコード (マングル) だったみたいだ。
用途はともかく予約するというルールは 1990 年頃にはおおよそ成立していた模様。

>>140
ほんそれ
静的解析にかけたら盛んに文句言われるからやめた方がええ
クラスや構造体を前方宣言したらそのクラスや構造体の使用箇所全部で言われる……

しかしBarを参照するFooを定義するヘッダファイルでBarのヘッダファイルをインクルードしないことによって
テンプレートを駆使して超高速化を果たしたBarのソースコードをFooとBarを含むライブラリの利用者に対して
隠蔽するという要望は
気まぐれとはいえある……

んまーそういう場合もBarのwrapperクラスBarWrpを定義したらだいたい前方宣言無しで済むが
ていうか前方宣言でないと駄目なケースがあったような気がするが思い出せんぬｽﾏﾝｺ……

>>149
そなた、ここにもいたんか。extern "C"を使えば共存できるんだな。

>>143
現実的には大丈夫。
__XXXのような名前は、現代では、コンパイラがSyntax Sugerを
展開する時などに使いたいからユーザーによる使用を禁止している
だけであり、__XXXX_H__ みたいな、誰でも広く使っていた
ような名前はコンパイラは生成しない努力はされているハズ。
どういうことかというと、__XXX_1AB5E32 見たいなのは駄目という
こと。このようなものは、コンパイラが内部で使う可能性が有るから。

だれか試した人いる？Linuxしか対応してないみたいだけど

AMDがCPUで処理するプログラムをGPU向けに移植するためのライブラリ「hipThreads」を発表 - GIGAZINE
2026年02月20日 15時43分
https://gigazine.net/news/20260220-amd-hipthreads/
AMDがCPUで処理することを前提に書かれたC++コードをAMD製GPUで実行できるように移植できるC++スタイル並列処理ライブラリ「hipThreads」を発表しました。

サンプル見たら std::thread を hip::thread に書き換えるだけでいいみたいだ　すごいね！
まあCPU前提のコードをGPUで実行したら遅くなりそうだけども、、、

OpenMPみたいにどうーコンパイルされるか意識しながら書いたら
良いのでは（適当

どれくらい速くなるのか知りたいね

CUDA使ったことあるならわかるけどCPU向けのロジックで実行しても思ったほど性能でないのは目に見えてる
GPU使いたい人は性能が欲しいわけ
CPUとの共通化なんて二の次

まずはCPUでテストしたいしね ゆくゆくはGPUだのFPGAだのにオフロードするとして

あと、ヒネってないC++なら、AIに頼みやすかったりとかするんでは
数学に強いAIとか居るし

CPUではループするような場面を
GPUやFPGAは全部展開して並列して一気に計算終わらすイメージ
そこまで考慮してコンパイルしてくれるなら良いけど
あらかじめ意識して描いておかないといけないのなら
最初からGPUやFPGA用に描いた方が速いという人もそれなりに居るだろう

既存のプログラムが楽にちょっと良くなる (可能性がある) というのが肝心なんだろ。
GPU に任せてたいして高速にならなかったとしても GPU に任せた分だけ CPU が空くのが有り難いということもあるかもしれんし。

ドワンゴがFPGA創るって話あった気がするけど
あれどうなったん

>>162
公式な発表をざっと検索したけどここ十年くらいは動きが無いっぽいので自然消滅したか部分的に色々なプロジェクトに吸収されるとかで落ち着いたくらいの感じじゃないのかな。
公式発表がない以上は中の人じゃないと状況はわからん。

cudaでスレッドの足並み揃わなくなる
再帰呼び出しとかやると劇的に遅くなる

>>164
cudasynchronyzeとか、
ちゃんと考えないから

そうかGPUで今迄CPUで実行してたコードを動かすと速くなるのか!ピコーンひらめいた!!
もうCPU消してGPUだけ残してそれをCPUにしたらいいんじゃね？

中学生レベルのウイット能力

CPUは汎用だからな
GPUにはそれができない

>>168
汎用とか知ったかかましてますなぁ？
汎用計算はとっくにGPUで可能
むしろGPGPUなんて当たり前すぎて死語になってる
単純に今のGPUはCPUにホストされる前提のデバイスだからCPUなしには成り立たない

>>166
g/GPU/FPGA/s
改変してるが
>そうかFPGAで今迄CPUで実行してたコードを動かすと速くなるのか!ピコーンひらめいた!!
>もうCPU消してFPGAだけ残してそれをCPUにしたらいいんじゃね？
これはネラーより頭の良い人達がIPで何十年も前に実現してる

>>169
計算しか取り柄の無いってわからんの？
CPUって計算以外もこなすからPCやスマホで役に立つ

>>171
汎用の説明になってないし
むしろ現代の標準的なコンピューターシステムに特化した機能を持っているのがCPU
言葉間違えましたで謝れば終わるのに愚かなやつ

iGPUのほうがこういう仕組みと相性良さそうに思えるがそうでもないのかな

GPUの「Pixel Shader」というものを調べていたことが有るけど、
元々はテクスチャの各点(Texel)のカラー値を計算で求めるための
ものだったようだけど、それを汎用計算用に使うテクニックが
生み出されていた。
また、GPUはコア数が多いが、必ずしも各コアが独立して計算
できるわけではなく、まず、コードはあるブロックに属する
全コアで共通になっていて、if 文のようなものは、
条件に合っているコアだけが実行し、合ってないコアは、
何もせずに停止、といような仕組みになっているらしかった。
だから、if 文が有ると、例えばコアの半分くらいは実行を停止
しているような状態になるらしい。
再帰関数なども掛けるとのことだったが、どういう風に実行されるのは、
個人的にはまだちゃんと理解してない。

グラフィックにしろGPGPUにしろ大抵はメモリ帯域がネックになる
DDR5-6400でも51.2 GB/s x 2ch≒102GB/sとかで、
128bit GDDR6のRTX3050でも220GB/sとかだから基本iGPUは敵わない
コンピュートバウンドだとしてもそれはそれでdGPUに敵わない

dGPUのVRAMを超えるサイズのLLMを動かすケースとかは知らんけど
「iGPUとメインメモリを使ったGPGPU」は基本手間の割に性能は出ない印象

CUDAの方のthrustみたいなもんだろ。saxpyみたいなのなら変更無しでそのまま高速化できるだろうけど

20年以上前にハイエンドGPUでしか最高画質FHDで遊べなかったハーフライフ2が現世代のiGPUなら最高画質4Kで快適に動くようになってる

メモリ帯域で言うと今のDDR5x2chの102GB/sに対して
2007年のGeForce 8800GTXが86GB/s、8800Ultraが103GB/sだから、
その頃のハイエンドくらいの性能は出るってことか。
（FLOPSは400GFLOPS未満くらいで、Alder Lake(12世代)のCorei最下位でクリアしてる）

今のiGPUすげーとも思うけど、どっちかというと20万円以下で
19年未来のiGPUと勝負できた当時のハイエンドすげーとも思う。

ハーフライフ2は2004年リリースだけど新世代GPUが登場した時などにミニアップデートされ続けている
iGPUの性能向上だけではなく、22年間の保守でハーフライフ2そのものも軽量化・最適化されてきた結果だろう
最新のアップデートは2025年7月24日
AI需要によるメモリ高騰で新世代GPUが当分出ないようならアップデートも当分ないんじゃないかな

iGPUって、CPU内臓のGPUの事全般を言っているのかな？
AMD製のCPU内臓のGPUも、Intel製CPU内臓のGPUも、世代を問わず
全部まとめて iGPU ってことで合ってるの？

消火器と消化器と小火器はぜんぜんちがう別のもの

命令の実行の仕組みが全く別物なんだし
GPUがCPUの完全上位互換にはなれないんだからな

>>174
shaderはそもそも行列演算の塊だから「色の計算」以外に使えて当然だし
使えるものは使わないともったいない(決して「間違った使い方」ではない)
ループは苦手だと思う

ものすごく簡単に言うなら GPU は同じ計算を異なるデータに対して大量に並列処理するような用途のために設計されてる。
グラフィクスを効果的に表現するためにはそれが必要だったからだ。
しかし日常的に必要な計算はある処理を終えてから次の処理をするという順序関係があるのが普通だし、そういう処理では GPU は使い物にならない。
CPU を主体にしつつ並列計算が効果的なところでは GPU に任せるという構成が普通ということになる。

普通は GPU に任せるにしてもそもそもどこを GPU に割り当てると効果的なのかを検討するところから面倒なんだよ。
少し効果があるかもしれないという程度のために手間をかけるのも面倒だしな。
>>154 は「スレッドを使ってる箇所は (効果的というほどでないかもしれないが) ちょっとでも GPU で出来へんか？」という手軽な導入がキモなんだろ。
効果があることがわかったならガッツリとチューニングするのはそれからでもいい。

cudaでいいから
c++の複雑さは持ち込まないのが吉

汎用処理をGPUにやらせるより、CPUの超省電力コアのほうがまし

SoCが流行り

SoCが今頃流行りだした地方があるのにびっくり

行列計算は行a_i_j (j=1..N)と列b_i_j (i=1..N)の積和の繰り返しで
多分これを同じブロックに属する複数のコアで並列計算するんだけんども
a_1_1、a_1_2が異なる値かb_1_1、b_2_1が異なる値だったりしたら
積の演算の中で桁上がりがtrueのコアとfalseのコアが混在して
if文の条件が合うコアと合わないコアが混在して計算を完遂できないのでは
とそこはかとなく疑問が（ｷﾘ

GPUでの計算は例えばこんな風に進行するらし
https://at-sushi.com/pukiwiki/index.php?Thought%20GPGPU%20%A4%C7%B5%D5%B9%D4%CE%F3%A4%CE%B7%D7%BB%BB
個々のコアはチューリングマシンていやーチューリングマシンなので汎用やが
こういう風に計算を組み立てないと1つのブロックで動作を完遂するのが1コアとかになって並列性が生かせんぬ
ていうかコアのshared memoryやキャッシュメモリは少なく（数MBぐらい
ホストCPUとGPUボード上のVRAM間のデータ転送もタダではないので
GPUをデータ転送計画と計算手順を示す前から汎用とみなすことは机上の空論……

GPUの「Pixel Shader」の場合に限定した話だと、あるブロックに属する32個のコアが、1つのコードを共有し、
if ( a[i] > 5 ) { (処理); }
というコードを32個のコアが、それぞれのコア番号「i」に対して実行しようとする。
a[0] は、10 だから実行、a[1] は、3 だから非実行、・・・
のように、それぞれのコアで、実行するか実行しないかが分かれる。
それで、実行するコアがその部分を実行している間は、実行しないコアは、完全にその場で停止している。
そして、(処理); の部分の実行が完了すると、全てのコアの IP(命令ポインタ、PC) が if ブロックの
次の行へと進むようになっている。
そのようにして、「IP」は全てのコアで共通して進められるが、上記の

>>191
そのようにして「IP」は全てのコアで共通して進められるが、上記のように、
あるコアは実行し、あるコアは実行しない、というような事になっている。
これは、通常の x86/x64 のような汎用 CPU の、マルチコア(マルチスレッド)とは全く
異なる処理方法である。

>>192
厳密に言うと、if の条件式を満たさないために「実行しないコア」も、その場で停止している訳ではなく、
if ブロックにおいて「IP」 は、実行するコアと全く同様に 1命令ずつ進んでいくのだろう。
しかし、そのコアにおいては「命令を実行するフラグ」が「0」になっているので、命令の場所に IP
が来ても、無視して処理しない、ということになっているのだと推定される。
x86/x64 の SIMD 命令のパックド命令において、BIT フラグが 1 になっている要素だけを add したり、
mul したりする命令と良く似ている。

>>190
Thought GPGPU で逆行列の計算
「GPUでの計算は例えばこんな風に進行する」とはちょっと話が違うんじゃないか

行列計算用の専用の枠があって
そこに数値突っ込めば、ハードウエアで行列計算して返してくれるっていうのの集合体でしょ
ハードウエア計算なんだからどうやったってソフトウエアと同じ汎用性は持ちえない

>>194
なんでこのページを貼り付けたのか謎すぎるよな
別にGPUの動きなんて何も説明してない

CMakeでVisual Studioのソリューションも生成できてすごいと思ってたんだけど
CMakeLists.txtにset(CMAKE_CXX_STANDARD 17) とか set(CMAKE_CXX_FLAGS_RELEASE "/MT") 書いてもソリューション設定に反映されないじゃん
include_directories(include/win32) とか add_definitions(-D_UNICODE) 反映される設定もある
なんなのこれ？　ポンコツ？

NvidiaとAMDでも実装方法違うからな
似てるけど一概にこうとは言えない

>>197
しばらくはModulesをgrepするようにしたほうがいい
最近CMake使ってないけど、俺の時はそうした 大した量でもないので
どうしてこうなってんだろ? と思うようなことがわかったりわからなかったり

ポンコツなのは、まあそうかなと内心思う これは使えるポンコツだ

CMake は autotools よりマシではあるだろ。
綺麗に整理しようとしても場当たり的な処理も必要な現実があるから、現実のほうを変えられない以上はどうにもならない。
現実の道具はだいたい汚いもんだ。

>>195
GPU の Pixel Shader は、C言語に似た言語でプログラミングできるから、汎用性はある。

CMakeで .sln 作って MSBuild コマンドでビルドしてたんだけど Makefile に戻ることにするよ

CMakeは汚すぎるのでMesonに乗り換えた方がいいよ

mesonはmsbuild向けにはおすすめしない
複数configuration持てないから
xmakeのほうがよい

ビルドツールが乱立し始めたので
改めてautotoolsが良いと
俺は思ってるんだけどなぁ

老人にはそれでいいんじゃない

>>205
autotools は難しい印象がある。

autotoolsは情報がウェブ上に多数あるので良いよ
スケルトンプロジェクトを生成するシェルスクリプト書いとくと捗る

githubでいろんなプロジェクト見るけどautotools使ってるやつなんか長らく見たことないわ
ここの住民は化石かなんかか

対象アーキテクチャが広いなら Autotools しか選択肢がない。
逆に言えば Linux と mac と Windows くらいだけサポートできれば上等だろうみたいに割り切るなら autotools は無駄に複雑なだけでとりたてて利点はないな。

M4言語なんて謎言語素敵すぎやん?

C++erならbjam使えよ()

autotoolsのために今どきPerlなんか入れたくない
複雑ならSConsで単純ならimakeでxmkmfすれば良いんだ

PerlはGit for Windowと一緒にインストールされるやつを使えばok

BJ Stroustrup 氏って、長年、ウォールストリートかどっかの金融マンしていてそれが収入源なんだって。
だから言っている事が数学的に頓珍漢なことが有るのか。
納得。

>>215
「ストラウストラップ氏は、長年金融大手の**モルガン・スタンレー（Morgan Stanley）**に勤務しています。
役職: マネジング・ディレクター（Managing Director）およびテクノロジー部門のフェロー。
ウォール街の大手金融機関のシニアエグゼクティブ」

autotools は、Unix の非互換性を採るための、ほぼ Unix 特化のツールというイメージだな。
$ ./configure
# make
みたいなお約束になっていて、基本からして 前提。
Unix 互換OS だと各種インタプリタがインストール済みであることを仮定できるからそうなってるし、
ほぼ #include するヘッダファイルのマクロや関数郡の存在チェックや互換性チェックを主な目的に
しているような印象が有る。
しかも、出来上がったツールのコマンドラインオプションで動的に修正せずに、
configure スクリプトのコマンドラインを帰ることで、
makefile 自体を書き換えて、コンパイル段階で、別のバイナリを作れるようにC言語のマクロを変更する
ような仕組みになっている。
これは、C コンパイラがあらゆる環境でインストール済みであることを前提にした仕組みであり、
Unix 環境の前提に強く依存している。

>>217
誤: 関数郡
正: 関数群

また変なのが住みついたなあ
お前もコテハンつけろよ

autotoolsなんか21世紀に採用するようなもんじゃないだろ

>>220
21世紀に採用するもんじゃないようなアーキテクチャがたくさんあってそういう環境でも使えなきゃならないから Autotools なんだよ。
現実は非情である。

UNIXを覚え始めた頃にだいたいトラウマなるパターンで
覚えると便利なもんだよ

ごめん
CMakeLists.txtにset(CMAKE_CXX_FLAGS_RELEASE "/MT") を書いても .sln に反映されない原因が分かった

C++ ではなく C で書かれたものが 1つだけ混ざってたんだ
当たり前だけど、Cプロジェクトの場合は CMAKE_C_FLAGS_RELEASE を使わなきゃいけなかった💦

>>211
sendmail.cfのやつか？
それならルール理解すれば簡単

>>215
そうなんだ
Stroustrupは天才だよな

最初templateの文法見たとき冗長すぎるだろと思ったけど、ここまで言語が発展したんでそこだけみれば慧眼の持ち主と思ってる

「発展」ェー

うっかりチューリング完全になっちゃったﾃﾍ

>>194
>>196
そのリンクは創造で貼ったわｻｰｾﾝ；；；；；
GPGPUでググったら創造の斜め上の面倒くささやったわ（できあいのライブラリは使わないものとする
https://speakerdeck.com/primenumber/puroguramuwogao-su-hua-suruhua-ii-gpgpubian
行列の積ですら何も考えずに書いたらCPUより遅いという
しかしかんばれば6000倍の高速化というのは魅力……

ラプラス変換とか理解できる頭じゃないとな

Xでは嫌がらせでC++で検索できないが、FaceBook だと「C, C++ Projects and tasks」というグループに
メンバーが56.6万人いる。Rust は、最大のグループの「Rust Developers」でも、1.1万人しかいない。

嫌がらせですか

むしろ C++ と名付けたやつが嫌がらせだろ。

昔やってたゲームに「****」って曲があったんだけどタイトルのせいで全然検索に引っかからないの思い出した

いいこちゃんばっかりで、わざと検索できなくしていることが理解できないんだね。

C++が名付けられた時点でWeb検索なんて無かっただろ
MS-DOSはファイル名に+が使えなかったのでアンチDOSな意図はあったかもしれないが、結果拡張子は乱立したな

C++ の方がわざとやっているのではなく、X の方が検索できないのをわざと放置しているんだよ。
直そうと思えば直せるのに直してない。

そっちか。>>233-234に引きずられたようだすまんな

C/C++についてならPHPが出た頃に一気に検索精度落ちた気がする

>>239
Googleの場合、検索窓に「C」「C++」とかも一緒に入れていると PHP と混同せずに検索できるよね。

そもそもX(旧Twitter)の検索は昔からいまひとつだったのが
ここ最近のアプデでガチでまるで使えない状態になってるのだ

Xで何を期待してc++で検索するん？
その発想が謎すぎる

>>242
どのように使われてるかの調査。

あの肥溜めで何の調査？

>>244
匿名性掲示板よりかなりちゃんとしてる。ほとんど誹謗中傷も無いし。

草

相談室もいまやAI（）のほうが使い勝手いいからなあ
すぐに返ってくるし、コードも書いてくれる
もちろん間違っている場合も多いが、それはここも変わらん

いままではGoogleで検索してStackoverflowや個人開発者のブログを読んで回って解決策やサンプルコード探してたのに
いまはGoogle検索の先頭にAIの回答やサンプルコードが出てくるんだよね
すごい時代になったもんだ

度忘れを検索する程度なら、だいたい当ててくるんだよな
「あーそれそれ、それでいいわ」程度のことなら、あのおまけのAIでいける

俺の愚問に毎度大量に電気喰ってるような気がしないでもないがｗ

AIは参考にする為にこのスレ見てるかも

ロクな育ち方しなそうで草

今のところc++をAIに書かせたことないけどメモリオーダーとか理解して安全なロックフリー実装とかできんのかな
他言語でもマイクロオプティマイズに関してはAIは弱い印象
余裕でAIにダメ出ししてるわ

並列プログラミングの微妙なニュアンスを言葉にして伝えるぐらいならコード書いたほうが早くね…？
AIにはデバッグのほうを手伝ってもらえば

>>253
それは並列に限らずどの領域でも言えるだろ
少なくともおれよりAIの方がコーディングスピードは上だから任せられるなら任せたい
あと網羅性の点でもAIの目聡さは評価できる
おれならテストしてようやく気づくような例外ケースも最初から考慮にいれていることが多い

生ポを使うなって指示したらだめなんか

楽しいプログラミングがAIに奪われ、苦しいデバッグが人間に押し付けられている現実
AI導入で品質維持のコストは増える
AI企業経営者は、裸の王様に透明な服を売りつける仕立て屋の能力が高い

意味不明
なぜ人がやるより品質維持のコストが増える？
素人がバイブコーディングする話とプロがAI使う話をごっちゃにしてるだろ

せめて売りつける相手は女王様にしてほしぃ

>>257
プロと素人の違いは給料の有無でしかないから、プロがいるとコストが大きくなってしまう現実

AIを使うと頭が悪くなる？「脳の疲弊」を防いでより賢くなるための正しい付き合い方 | Forbes JAPAN 公式サイト（フォーブス ジャパン）
https://forbesjapan.com/articles/detail/94246

>>259
意味不明連発だな

> AI導入で品質維持のコストは増える

これの言い訳になってない
その非論理的な思考方法ではソフトウェア開発無理だぞ

AI「書き書き〜。これが私の考えたコードです！次は何を実装します？」
ボク「ここはおかしいやろ。こうしないと不味い。」
AI「その指摘、まさに正論です！鋭いですね。」
ボク（うるせー黙れわかってたなら最初からやっとけ電気の無駄遣いすんなカス）

【衝撃】AIはまだ生産性を上げていない？エコノミスト誌が暴く「AI革命」の不都合な真実｜奥山真司の地政学「アメリカ通信」 - YouTube
https://www.youtube.com/watch?v=JKuzhoRqbBw

まだ移行期だからな なんだかんだあるさ

当面の課題は…RAMの高騰だわｗ

人間「○○するコードを書いたのでデバッグよろ、改善点などあれば挙げて」
AI「かしこまりました」

みたいな関係じゃないとだめだなんだけど、AIに学習させるために手取り足取り教える羽目になっている
金払ってAIに教育してるお人よしなバカが真っ先にリストラされる

そんなわけない
AI使ってないやつはそもそも論外
AIを使いたおして再現性のある開発手法を確立したやつが勝者

AI、戦争止めて来い

AIは、メモリー解放に関して危険なコードを書くことが多いようだ。
Win32 の場合、他のEXEのリソースを閲覧するために LoadLibraryEx() で HANDLE hModule を取得し、
リソースの構造体取得した場合、ID に整数IDと文字列 ID を共通化した LPCSTR 型のような変数が使われていることが有る。
それは、FreeLibrary() を呼び出すまでだけ有効な筈だが、FreeLibrary() を読んだ後も参照してしまうコードを
出してきたことが有る。
以前も、Shell API のパスの IDL で、先頭ではなく中間的な部分だけを配列変数に入れてしまい、
その変数のアドレスに対して解放関数を呼び出しているコードを書いてきた。
そのコードでは中間的な部分のアドレスも必要であはったが、開放するのは先頭アドレスでなくてはならない。
だから面倒でも両方のアドレスを記録しておく必要があったのだが、AI は、先頭アドレスを記憶せず、
中間的なドレスだけを記録してしまった。そして、最後に中間的なアドレスの方をメモリー解放関数に渡していた。

>>268
誤: そのコードでは中間的な部分のアドレスも必要であはったが、開放するのは先頭アドレスでなくてはならない。
正: そのコードでは中間的な部分のアドレスも必要ではあったが、解放するのは先頭アドレスでなくてはならない。

>>268
前半部分についてもう少し詳しく書いておくと、
既存のリソースのIDを全て列挙するために、Win32 のリソース関連の Enum 系の関数を使い、コールバック関数の中で、
リソースID を、std::vector<XXX> のグローバル変数に push_back() していた。
列挙が済んだら時点で FreeLibrary() を実行。
その後に、そのリソースID を、グローバル変数の std::vector<XXX> から取得して利用する、
といようなコードになっていた。

>>270
[さらに補足]
>リソースの構造体取得した場合、ID に整数IDと文字列 ID を共通化した LPCSTR 型のような変数が使われていることが有る。
>それは、FreeLibrary() を呼び出すまでだけ有効な筈だが、FreeLibrary() を読んだ後も参照してしまうコードを
>出してきたことが有る。
とあることのために、(自分のアプリでは無い)EXEの中のある種類のリソースを入れ替えたかったのだが、
そのEXEの中の既存のリソースを全て削除してから追加する作業をする必要があった。
Update や削除している最中には、当然予想されることとして、IDが文字列IDだった場合、「文字列ID」は破壊されてしまう
可能性がある。
削除したリソースの ID だけでなく、他の文字列 ID に対してもアドレス自体が変わってしまう可能性があるため、
他の文字列IDも含めて、全体的に文字列 ID(文字列へのアドレス)が無効になってしまう可能性も考えられる。
仕様書に書いてあるかどうかは不明だが、ある種の常識としてその危険性が想定される。
AI は、そういうことも配慮が難しいようだ。

>>271
>とあることのために、(自分のアプリでは無い)EXEの中のある種類のリソースを入れ替えたかったのだが、
誤解を招きそうなので断っておくが、「自分のアプリでは無い」と書いたが、実際には、リソース修正用の自作アプリ
そのものではなかったが、リソースを入れ替えたかった EXE も、自分が作ったアプリ。
他の人の作った EXE のリソースを改竄しようとしたわけではない。
「リソースを変更するために作った実行中の EXE ではない」という意味で「自分のアプリでは無い」と書いてしまった。
「自分」とは「リソースを変更す作業を行うために作ったアプリのEXE」の事で書いてしまった。
また、入れ替えたかったリソースは画像関連のものであり、アプリの実行を買えるようなものではない。

>>267
戦争とは人同士の頃し合いである→せや！

後のスカイ・ネットである

ドレス

>AI は、そういうことも配慮が難しいようだ。
AIはそういうことは配慮しない

＞AIを使いたおして再現性のある開発手法を確立したやつが勝者

違うな
AIを使いたおして再現性のある開発手法を確立したやつを雇っていたやつが勝者

出力量がヒトと桁違いなのでいかにこれを上手に利用するかというゲームになっている

低性能ドローンの大群による飽和攻撃を迎撃すべく高性能な精密兵器を使う非対称戦によく似てて面白いね

DDOSの反撃には使えそう

cudaはC/C++使ってんだから
コンパクトで高性能を追求するなら
こっちなんだろうけど
でも現場ではPythonなんだよな

Pythonで計算論理を記述するけど、実計算はC/C++なんでしょ 全然しらんけど

pythonがチヤホヤされてるのでどれどれと試したけど、
マルチスレッド処理が遅くてガッカリした記憶しかないわ
やたらpythonをほめる人の気が知れない

Numpy、Pandas、PyTorchぐらいは使ってからPythonを語りな
あとJupyter notebookとかさ
使ったことないのはエンジニアとしてダサすぎる

Pythonは好きだけど、それは「楽に読める・書ける」という点であって、単体の性能ではそりゃ大幅に見劣りするのは当然じゃないかと。

>>282
用途を間違うのがださい

ライブラリを使う人とライブラリを作る人で見え方がまったく違うのはしかたない

性能劣っていいならBASICがいいんだが

それでいいのなら、それで構わない。

言語の良し悪しもあるけどエコシステムが充実していることも必要だよ。
ライブラリを組み合わせるグルー言語としての性質を利用するならライブラリを導入しやすいパッケージマネージャやバンドラがまともじゃないと話にならない。
言語として BASIC が良いなら Visual Basic .NET あたりが良かろう。

Pythonの流行した当時はUNIX互換環境でまともに使えるインタプリタ言語なんてPerlとshくらいしかなかったし
構造的に書けるだけである程度インパクトがあった
それを20年以上引きずってるだけ

Pythonの流行しだしたときに（日本だけ?）勢いがあったのはrubyだったと思う

Pythonでスクリプト組んだは良いが速度に満足できずC++11以降で書き直すことになる

>>292
c++に書き直せるレベルのしょぼいものしか作ってないって白状してるようなもの

>>293
Cやアセンブラに書き直せるレベルならOKってこと？

リフレクションやダックタイピングを駆使しないとpythonを使いこなしてることにはならない(ｷﾘｯ
みたいな宗派でしょ

PythonおせーからC++とは普通ならんわな
最初のチョイス間違ってる

可能なら先に見積もるのが望ましいけど常にはっきりわかるというわけでもないだろう。
検証のためにプロトタイプを Python で作ることも無いとは言えないんじゃね？
Python を使ったことがないからプロトタイプ用にどれくらい適しているかは知らんけど。

perlが糞すぎて辟易してたからPython出始めの頃は感動したもんだ

とりあえずCythonなにそれうまいのまで読んだ

>>296
↑
いつも、こういうバカが出てくるな

Pythonの問題を具体的に言えないバカ

>>297
↑
こういう、使ってないやつにはわからんだろうが、
なんでPythonが今でも使われてるか？　って話。

pythonが使われているのは良くも悪くもガバガバなのと、過去のライブラリ蓄積のおかげじゃない？
個人的にはNimの方が優れていると思うけど、惰性にはなかなか勝てない。

Perlはバッファデータが文字化けしてても処理続行してくれるけど、Pythonはすぐに例外スローするので文字コード処理は不便

>>299
発音がむずくて知られてないかも説

>>303
逆だよ
例外スローすることで知らん間にバグが混入するのを防止出来る

おまいらpythonはC++で書かれてるんだぞ

GUIアプリはいまだC++で作ってるけど
CUIはもうPythonで作るようになったワイ

CUIって単語もう使わんよね
ジジイ味を感じる

>>308
普通に使うよ
情報価値の乏しい個人の感想はプログラマー板でどうぞ

今時CLIっていうのが普通だよ
昨今のコーディングAIツールもそういう名称になってるだろ？
まさか使ってないの？
そもそも英語圏でCUIという言葉がもともとマイナー
Googleトレンドでも見てみろよ
老いて情報収集してないからそういう昔覚えた言葉にロックインされたままになってる
教えてもらったんだから感謝しな

＞今時CLIっていうのが普通だよ
言わないぞ
スレ違いなのでこの話題はおしまい

CUI と CLI は違うものだよ。

>>305
テキトーに読み捨ててほしいんだと思う
たぶん「まともに」使ってない&そんなもんでいいんだよ派
俺もそう

まあ一般的なプログラマ認識として CUI と CLI はほぼ同じもんっていう認識だわなぁ
あえて厳密にいうなら大昔の Borland の Turbo Vision でつくったようなツール(もうガチでわしらみたいな老人しか知らんか・・・)
みたいなのが CUI で、コマンドラインで標準入出力だけで動作するツールが CLI てなところかね

tvをCUIというかはちょっと微妙…ｗ (速攻釣られとくｗ

TUI という言葉が生まれてしまったのも状況をややこしくしてるが CUI はデザインに関係なくテキスト画面を使ったインターフェイス全般を包括する用語と解釈すべきで、 CLI も TUI も CUI の一種ではあるだろう。

Windows だと実行ファイルの中のフラグで CUI か GUI かを指定する仕組みだからそれで CUI が指定されているもの (または Windows 以外でもそれに相当するような動作をするもの) を CUI と私は認識してる。

webアプリはcuiなんよね

TurboVisionはCUA(Common User Access)なのでは

curses や vi は CLI ではなくCUI だね

カーセズでアプリ作りたかったなぁ。遠い目

C++の文脈でCLIと言われるとC++/CLIが先に思い浮かんでしまう

ほんそれ

>>312
どう違うの？

コマンドラインはEnterキー入力で命令を送る仕組みでありテキスト対話型AIサービスも含まれる

apt, aptitude

>>310
でもサブプロセスとして呼び出してGUIとパイプで入出力を行う場合コマンドラインインターフェイスではなくない？
コンソールから起動しコンソールから入力する場合はCLIでいいけど

その場合はUIですらないんだからCUIも不当
単なるバックグラウンドプロセスとかサービスとかデーモンとか

コンストラクタで引数をメンバ変数にmoveする場合

Myclass(std::string str)
:member(std::move(str)) {}

としておけばMyclass(std::string&&)は必要ないって理解で正しい？

>>328
strのmove渡しを強制する必要なければそれでいい

>>329
ありがとうございます。シグネチャ合わないのかと思っていました。

>>328
const 参照と右辺値参照のオーバーロードでいいじゃないかな

参照渡し or 値渡し？
https://yohhoy.hatenadiary.jp/entry/20120524/p1

>>331
私も最初そうだと思っていたら、chatGPTに値渡しmoveで両方カバーできると言われたんです。

AIの回答が正しいか自分で調べず匿名掲示板に投げて他人に調べさせる人、今後も増えそうだね

【危険】AI活用で絶対やってはいけない6つのNG行為！信頼を失う「ワークスロップ」の恐怖。組織での予防がこれからのAI展開のカギ - YouTube
https://www.youtube.com/watch?v=SdO9w5i0_nU

>>328
コピー省略を適用しない素朴な解釈だと参照渡しにしたほうが効率的になる。
https://wandbox.org/permlink/9EZ9rpRBtMucnuQw

しかし C++17 以降ではコピー省略が一部の場合に必須になり、この場合はそれに該当するのでどちらでも同じになる。
https://wandbox.org/permlink/D0akhuHAh6pXHTxE

参照渡しってCPUとかOSによって誤作動の要因にならんの？
はっきり値渡ししたほうがよくないの？

ヒープで作った巨大な構造体を値渡しするとスタックサイズが

安心欲しいならC++は使わんでよろしい

>>335
ありがとうございます。論より証拠ですね。さすがはちみつさん。C++17以降ならchatGPTの指摘が正しいわけですね

プリミティブなオブジェクトは値渡しで、それ以外はconst参照がいいってどっかで。

>>333
じきにAI ＞＞ 匿名掲示板になって誰も聞かなくなるから大丈夫。stack overflowすら過疎る時代

元々Pythonから入ったけど、今度のプロジェクト(趣味)はもっと単純だからC++でやってみようと思って始めてみら
最初は混乱したけど、慣れると関数の引数と戻り値、型を意識するんで逆にわかりやすいね。

Pythonは名称がわかりやすいから入門で概念が全然わからないうちは良いが何やってるかわからなくなるけど、.hとか別にあると設計と照合しやすい

>>339
ChatGPT にそこまで尋ねたなら、どうせならメカニズムまで質問すればいいだろ。
質問さえすればコピー省略についてだって説明してくれたはずだ。
正しいか正しくないかだけ判定させても応用が効かん。
理屈を理解する努力はすべき。 (結果的に理解できるかどうかは知らんけど。)

C++17 以降で一部のコピー省略が必須になったが、それ以前でも許されてはいたので最適化をあてに出来るならあてにするのが間違っているわけではない。

いまどきはPythonでも静的に型付けするコードを書く方が多数派じゃない？　言語仕様として強制できる点がメリットという見方はありうるが。
.h を.cppと別に管理する必要があるのは単に時代遅れなだけだよ。だから、モジュールとかが導入されたわけで。
パフォーマンスには圧倒的な差があるからそれだけでC++を使う意味はあるけど、比較のポイントはだいぶズレているような。単にPythonを使いこなせていなかっただけの人に見える。

インターフェイス部分と実装部分に分離するという思想は良いでしょ。
分離の方法としてヘッダを使うのは破綻してるけど。

>>345
でもJavaのimportとかも、メンドクサイで。

Rust使え

Delphiとか同じファイル内でインターフェイスと実装の記述が分かれているけどちょっとめんどくせえと思った
でもPythonで別れていないのを見てなげえよって思った

1ファイルを上下分割する形だと、エディタ側に支援がないとくそめんどくさいんだよな(DelphiのIDEには一発で行き来できる操作はもちろんある)
一般的には2ファイルのほうがどのエディタでも普通に編集できて良いと思う

文字列検索で重複ヒットする安易な命名こそが問題派です

>>344

Pythonでも静的に型付けするコードを書くとは？

>>351
今のpythonは型のヒントを書く記法があって、処理系単体だと意味はないがmypyなどの外部ツールで静的に型チェックできる
どれぐらい使われてるかはびみょー、プロジェクトによる

実行時に違う型入ってても何も起きないね

コーディングAIなるものが出てきたな
何やるにもハイスペックPCが必要になってついていけない

スマホアプリでも、高スペック持ちなら猿でも作れる時代
いまだスマホすら持ってない俺様は洋ナシ

じき、CLI程度でよければ、軽量AIに頼める時代がくるだろ

欲しい機能をぐぐったら、だいたいドンピシャなサンプルが出てくる、みたいな感じだろ
すでに設計まで経験してる人なら、軽量AIを使いこなせる、みたいな未来を想像してる

🍐pearというより🥶poor

loopy

std::equal_range()って比較の所要時間が短い場合はかえって線形検索よりも遅くならない？

Nが小さければ線形探索で十分ってのは常識でしょ

自己解決した
シーケンシャルアクセスが前提のstd::listをstd::equal_range()で使おうとしたのが良くなかった
std::equal_range()の誤用を避けるために、setやmultisetのメンバー関数equal_range()をvectorにも追加しつつstd::equal_range()を非推奨にしたほうがいいのではと思った

なんだその中途半端な理解は
それはstd::listのデータ構造の問題であって、仮にメンバー関数にしても何も解決しない

どういう意味？

誤用？じゃあ正しい使い方は何？

std::equal_rangeをlist用に特殊化するほうがいいのでは

C++20で追加されたstd::random_access_iteratorのサンプルコードのような方法でコンパイル時に警告表示できれば良さそうだけど
https://cpprefjp.github.io/reference/iterator/random_access_iterator.html