C++相談室 part156 YouTube動画>1本 ->画像>1枚

前スレ
C++相談室 part155
http://2chb.net/r/tech/1616555235/

乙

乙でございます

乙python

前スレの>>989
> 可変個の参照の組 (vectorでいい) を関数 hoge に渡したいときって、hoge が vector< reference_wrapper<T> > を取るようにして
> hoge({ref(A), ref(B), ref(C)})
> みたいに呼ぶか、可変引数テンプレートを使って hoge の中でパースするかっていうのが普通のやり方かな？

なんですが、もしかして reference_wrapper って構築時に左辺値を渡したらそれの参照を保持してくれる？
だとしたら
hoge({A, B, C})
と呼べるしかなりスッキリしますね
hoge 内でいちいち get() しないといけないのはダルいですが……

継承や委譲との付き合い方がよく分からなくなった

あるクラスの機能を全部持っていてほしいが is-a 関係がないとかで継承関係にはないように思える場合ってどうすんの
例えば一辺の長さを表す変数やはみ出し判定メソッドを持つ「グリッド座標クラス」があったとして、今「オセロを解くクラス」を作りたいとき

オセロを解くこと is a グリッド座標では全くないし継承するのは頓珍漢に思える
一方で「オセロを解くクラス」がグリッド座標のインスタンスを委譲として持っていたとして、盤の大きさとかはみ出し判定メソッドにわざわざ「グリッド座標クラス」のインスタンスを通してアクセスするのも果たして正しいだろうか
例えば盤面 a と盤面 b を同時に持ったりもするだろうが、a.size() とか b.size() は同じものを表すのでこのようにアクセスするのは可読性を損なう
だから「オセロを解くクラス」は盤面の大きさとかはみ出し判定メソッドを自分のメンバとして持っていてほしいが、継承するべきようにも思えない

複数の盤面持つんならメンバで持つ一択だと思うけど
「解くクラス」に外部からはみ出し判定アクセスするのもおかしな話だけど
描画の都合とかで外部からアクセスするのが欠かせないなら、インデックス受け取って盤面の参照返すメンバ関数でも用意すればいい

あ、あるいは解くクラスが単に外部の盤面を参照する形でもいいかもね

>>7
> 複数の盤面持つんならメンバで持つ一択だと思うけど
「オセロを解く」といった時点で盤の大きさ等決まるんだから、自分のメンバとして基本的な機能持っててほしいと思うんですが、偏った考え方ですかね


> 「解くクラス」に外部からはみ出し判定アクセスするのもおかしな話だけど
そう思います

>>8
それはインスタンスとして盤面を持つという意味ではなくですか？

フロント部分とオセロを解くソルバー部分で持ち方変えるってのが普通

そう、内包しようとしない方が自然かもしれない
(読んだ範囲で勝手に考えてるだけだけど)
例えばその解くクラスってのがAI的に自動で解くクラスなら、じゃあその対戦相手に同じ(だがインスタンスは別)AIや
プレイヤーが参戦したらどうなるんだ？と考えると
盤面は独立してるほうが自然な気はする(個人の見解です

>>6
オセロを解くアルゴリズムとオセロをプレイするモデル次第なのでなんとも。

まあ、オセロを解くんだったら多数のオセロ盤を持つだろうから、グリッドクラスを派生させてオセロ盤クラスを作るだろうな。
人間がオセロをプレイするのを素直にモデル化してもいいけど、ゲーム機のオセロゲームをプレイするようにモデル化したほうが、オセロを解く側のミスや負担が減る。

>>11
フロント部分って今の場合だと「オセロクラス」ってことですか？
つまり「オセロクラス」と「オセロを解くクラス」が、どちらがどちらを含むではなく、やり取りしあって動くべきだということですか？

>>13
派生って継承ってことですか？
つまり必ずしも is-a を満たさなくても機能を全部引き継ぐなら継承は是 (あるいはそうモデル化するのが良い) ということでしょうか

かんたんだろ
色々判定してくれるオセロ妖精すなわち神を作ればいい

＞is-a を満たさなくても機能を全部引き継ぐなら
どちらも自分で書いてるしグリッドクラスも継承を想定して作れるんだからそれでいいとおも
他人の書いた継承を想定してなさそうなのはやめといた方がいいけどね

てかis-a,has-aはあくまで迷ったときの指針に過ぎんし自分で継承が良さそうと感じたならそれで正解だよ

>>15
この場合、is-aは「グリッドとして同一視できる」を意味するから、オセロ盤をグリッドとして扱うことができるのなら継承もあり。

ただc++の継承は、継承元を総称として扱うという強い意味（継承元と派生クラス全体の強い結びつき）もあるのに注意。
オセロ盤とかその他のゲーム盤とかのクラスを（グリッドとして）使うということでもなければ、継承しないほうが設計の自由度を保てる。

>>18
> ただc++の継承は、継承元を総称として扱うという強い意味（継承元と派生クラス全体の強い結びつき）もあるのに注意。

まさに、そういった意味論的なところで悩んでいます
まあ実際にオセロソルバを作ろうとしているわけではないのですが、同じような局面に何度も出くわして、継承も委譲もどうも適切でないように思えて最終的に「グリッドクラス」の中身をコピペして「オセロソルバクラス」を作るようなこともしばしばしてしまいます

そんなん言い出したらメタプログラミングで取り入れるメンバを選択するための継承なんか全部アウトだぞ
STL内部でやってるようなのも全部

ていうか
>まあ実際にオセロソルバを作ろうとしているわけではないのですが
>まあ実際にオセロソルバを作ろうとしているわけではないのですが
>まあ実際にオセロソルバを作ろうとしているわけではないのですが

継承でできることを別の手段でもできるって言ってるだけでは説得力がない
そんなん言い出したらC++でできることをCで擬似コード書けるしな

特にコード量が増える「別の手段」を推奨するには
格段に強い理由がないと誰も動かせない

cpprefjp によると std::swap の実装って
void swap(T& a, T& b){
　auto tmp = move(a);
　a = move(b);
　b = move(tmp);
}
みたいな感じですよね？
よくされる「move された後のオブジェクトはどうなってる保証もないのでもう触るべきでない」みたいな説明に照らせば、上のコードは move した後のオブジェクトを再利用してるけど大丈夫なのかなって思ってしまいます
大丈夫なんでしょうか？
また、参照をmoveしたら当然参照元のオブジェクトが「どうなってる保証もない」と考えるべきなんでしょうか？

もう一個質問させてください
引数に参照をとる関数に一時オブジェクトを渡したいこともあるんですが、この場合は const参照か右辺値をとる関数としてオーバーロードするしかないですよね？

>MoveConstructibleかつMoveAssignable
こうなってるからヨシ！

>>22
move後の変数は、読み取った場合の値はどうなってるか保証できないが、
値を書き込むことは正常に出来る事が保証されていると聞いた。
破棄することや、初期化することも問題ない。

>>1
お疲れ様です

>>25
moveコンストラクタは呼ばれないの？
呼ばれるのなら保証するのは自分自身なのでは？

>>27
moveコンストラクタは、変数定義を
TYPE x = y;
の形式で書いた場合に y が右辺値の場合に呼び出されるだけ。
move代入は、
x = y;
の形式で書いた場合に y が右辺値の場合に呼び出されるだけ。
後者の場合、xがmove後であるかどうかは関係ない。

変数xの中身をmove後のxへの書き込み、xの破棄、x.init()などとしての
再初期化が「保証される」というのは、保証されるようにSTLライブラリなどが
作られているという意味で、コンパイラが保証するというわけではない。

T が値なら終了して、vector<T> なら再帰的に自分を呼ぶ関数を作りたいのですが、T が vector (あるいはコンテナ) かどうかで分岐する処理ってどうやって書くのが良いですか


あと近い話題で、+ 演算子をオーバーロードして vector + vector が結合された vector を返すようにするのってナシですかね？(string のように)
要素同士の和をとるのと紛らわしいですか？
cat(vector, vector) とかの方が良いかな

固定長文字列クラスってないんですかね

template<int N> void hoge(string s){
　……
　assert(N == s.size());
　array<int, N> a;
　……
}
なる関数を呼び出すときにテンプレートパラメータを省略したいんです
s が固定長なら s から N を推論してくれますよね

あるいは hoge の引数を costexpr に限る方法なんかがあれば、N は必ずコンパイル時に推論できるようになるの思うので、もしそういうものがあればそれでも大丈夫です

もしかして、C++11に対応したSTLで、BSD/MIT 系ライセンスのものは存在してませんか？
・apache-stlは、2008年くらいで開発が終了しているようです。
・msvc用のstlはapacheライセンスですが、vcruntime.hが存在しないと
　エラーになるようです。

apacheで良ければllvm

>>30-31
これマジキボンヌなので何卒よろしくお願いします

>>30
よくわからんが何で長さの相違を型の相違にしたいんだ？

文字列リテラルならこういう手があるけど
template <int N> void hoge(const char(&s)[N])
{
}

>>34
整数のテンプレート引数を使って、std::stringを継承した文字列クラステンプレートを作ればなんとかなりそう。試してないけど。
std::stringの継承はけっこうクセがあった気がするから、自分で調べてね。

>>30
＞テンプレートパラメータを省略したいんです
の理由がただお遊びレベルのような気がしてスルーしてたけど
固定長の文字列クラスは標準には無い、欲しけりゃ探すか自分で作れ、それか>>35

コンパイル時プログラミングのための機能を満載したライブラリ Sprout がある。
constexpr 対応した文字列クラスもある。
http://boleros.hateblo.jp/entry/20110926/1318115291

ボレロ村上が亡くなってもう一年以上たったんだなぁ……。
Sprout のメンテナンスを引き継ぐ大きな組織とかないのかね？
いっそ Boost に編入するとかでもよいような気がするが。

>>35
> 何で長さの相違を型の相違にしたいんだ？
すみません。どういう意味でしょうか
やりたいことは、関数に渡した定文字列の長さをコンパイル時定数として扱うことです


> 文字列リテラルならこういう手があるけど
ありがとうございます
これが現在やりたいことに最も近いです
2つの文字列リテラルの共通部分列の長さをコンパイル時定数として扱うみたいなこともできそうで、ワクワクしています


>>36-37
ありがとうございます
自作は想像だにしない失敗に繋がりそうなのでやめておきます


固定長文字列とか引数を constexpr に限るとかすごい便利な機能に思えるんですが、今後標準に入ることはあるんでしょうか
それとも僕の不理解で便利に見えるだけなんでしょうか

固定長文字列ってCOBOL以外にあるの？
FORTRANにも無いしCにも無い
現行言語には存在すらしない
昔から特殊技術で需要が少ない

malloc使わなかったらcも固定長でしょ
あとsql

>>39
文字列長ごとにメソッドが別になってプログラムサイズの肥大化に繋がる。

スタックに文字列を全部乗っけて（若干の）スピードアップを狙うこともあるけど、そのときでも「〇〇文字以下」みたいにサイズ制限するくらい。Delphiの文字列がそうだったと思う。

>>40
FORTRANにもあるしPascalにもあるぞ
需要じゃなくてお前の知識が少ないだけだろw

clangで、#includeや#include_nextした全てのインクルードファイルの
パスの一覧をテキストファイルに出力することは出来ますか？

>>44
-MD オプションかな。 これは gcc と clang で共通。

すみません
>>5の方法で可変個の参照の組を関数に渡そうとして行き詰まりました

hoge の定義を
template<class T> void hoge(vector< reference_wrapper<T> >);
として、hoge({a, b, c}) と呼んだら T が推論できないとエラーが出ました

a, b, c がfoo_t型だとして
単に型foo_tを明示して hoge<foo_t>({ a, b, c}) と呼んだら良いんｼﾞｬﾈｰﾉ；；；

質問ですがvirtualでないクラスFoo（つまりdynamic_cast適用不能）のオブジェクトをthrowしたら
catchできます？

>>47
ありがとうございます
ただ、なぜに推論できないのでしょうか

template<class T> void hoge(vector< reference_wrapper<T> >);
と
template<class T> void hoge(vector<T>);
が両方あってどっちか判断できないって話なら分かるんですが

reference_wrapper<T> をテンプレート型として認識できないからでしょ

>>50
ありがとうございます
コンテナの入れ子の中に T があっても推論してくれる例を知っていたので、いつでもできるのだと誤解していました

{ 1, 2, 3 }というだけではstd::vector<int>なのかstd::vector<double>なのか（ひょっとしたらstd::vector<long>とかかも？？）
わからないからという理由
自動型変換結果とのマッチングは追求しだすときりが無いので規格でどの範囲でやるか制限がかかっているたはず

>>48
C++はintだって投げられるし捕まえられるぞ

>>53
投げたブツの型の情報がどうやってcatchする場所に伝わっているのかｷﾎﾞﾝ

以心伝心

Emacs で LSP 使わず開発してる人いる？
おもしろ設定とか参考になるサイトあったら教えてほしい

flycheck しか入れてない

>>54
関数呼び出しと一緒やぞ
catch節に書いた仮引数でオーバーロードしてると思えばいい

>>57
ありえん
1つのthrowに対し、呼び出し元のcatchで呼び出すべき（オーバーロードされた）関数シンボルを一意に列挙できるなら
アンワインド時にオーバーロードのしくみで例外ハンドラの解決を行えるかもしれないが、これは論理的に成り立たない
なぜなら、例えばintを例外をスローする関数foo()がbar()とbaz()から呼ばれているとして、
bar()にcatch (int)が書かれているのにbaz()に描かれていないとした場合、
bar()経由の呼び出しにおいては（オーバーロードされた）関数シンボルのリストに func(int)が含まれるのに対し、
baz()経由の呼び出しにおいては（オーバーロードされた）関数シンボルのリストに func(int)が含まれない、
となって一意にならず、throwした瞬間にどっちなのか解決不能
やっぱcatch側が（何が来るかわからない状態で）待ち受けているとしか考えられない

ちょっち補足すると、
bar()でtry { foo(); } catch (int ex) { .... } したときに handler(int)を例外ハンドラのリストに動的に登録し、
baz()ではtry { foo(); } catch (int ex) { .... } が無いからhandler(int)を例外ハンドラのリストに動的に登録しないようにすれば、
foo()でthrowしたときに最新の例外ハンドラのリストを参照することによって解決はｷﾞﾘ可能だが、
スタックとは別に例外ハンドラのリストに動的に管理するみたいなことをしているのかとｶﾅｰﾘ疑問に、
（例外がfall throughする関数の中にはゼロコストの奴も含まれるので、スタック上で細工して例外ハンドラのリストを更新管理することは不可能

>>54
exception_ptr

exception_ptrの主な用途は、バックグランドスレッドからメインスレッドに、例外オブジェクトを持ち運ぶ、というものである。標準ライブラリにおいては、promiseとfutureの実装で使用される。
と書いてあってスレッド間をまたぐ用（promiseしたことを実行中に起きた例外を、promise完了を待っているやつに伝える）とき限定に見える

単純にcalleeからcaller側に飛ばす通常の例外ではどうなのや？？

intやdoubleやconst char*を型情報とともに収容可能なexception_ptrみたいな構造体が絡んでいるのだろうとは思いまするが

ｲﾏｲﾁ確証が無い

>>61
スレッドは関係ないぞ
同一スレッドでも監視ブロックを抜けrた後でrethrow_exceptionできるし

>>63
言わんとすることはわかりまするが
（そもそもpromise/futureのしくみも論理的には単なる継続なので単一スレッドでの実装もあり得るという意味でスレッドは関係無い
しかしrethrow_exception(ex)はrethrow_exception(ex)であってthrow exとは別の文やん？？
本当に単純にcalleeからcaller側に飛ばす通常の例外も同じしくみなのかどうか、、、

ｽﾏﾝ>>58、>>59は撤回
やっぱ関数のオーバーロードで呼び出すべきハンドラを解決している可能性がありえまつね
というのはスタックにはreturn addressが積まれているので、throw intするfoo()は、
throwする瞬間に自分がbar()経由で呼ばれたのかbaz()経由なのか判定可能
あとはreturn addressに対して呼び出すべきハンドラ（のシンボルのリスト）を与えるテーブルがあれば、
関数のオーバーロードで呼び出すべきハンドラを解決できる
極力実行コストを低くする手となるとこれかなあ……
長々とｽﾏﾝｶｯﾀ、継続調査しまつ

>>56
>Emacs で LSP 使わず開発

その発想がナンセンス

>>66
lsp-mode インストールしてファイル開いてみたら「これはなんのプロジェクトにも属してないファイルだ」とか言って何もしてくれなかったもん
テキストエディタだぞ
単一ファイルのソースも普通に編集できるべきだ

インストールさせるという選択肢である以上は
emacs側はそれをやるかどうかの選択をユーザに委ねていることになる
なのでNoという選択もありうる、とemacs側は考えている

選択肢が無く強制なら選択をさせずインストール現象もまた起こらない
インストールさせるということはYesかNoかをユーザが選ぶことができる仕組みになっているからだ
YesでもNoでもなく選択出来ないならインストールさせない仕組みになっているハズだ
ここでインストールできるということはユーザのYes/Noの意思が尊重されることに他ならない

選ぶ・選ばない・強制、などにおいて、選ぶことが出来る事象については何を選択してもいいし、emacs側もそれを容認している

>>45
有難う。

>>64
よくわからんが、こういうこと？
void caller()
{
exception_ptr ex;

ex = callee();

try
{
rethrow_exception(ex);
}
catch(double err)
{
cout << "What the hell does that mean?\n";
}
}

exception_ptr callee()
{
try
{
throw 0.1;
}
catch(...)
{
return current_exception();
}
}

クラスAがクラスBのインスタンスをメンバに持つとき (移譲っていうんだっけ？)、Bのコンストラクタってどーやって呼ぶんよ

>>71
メンバ初期化子リスト
https://ja.cppreference.com/w/cpp/language/initializer_list

C++20 からは std::string は constexpr 対応になっとるな。
実装が追いついとるかどうか知らんけど。

vectorもconstexpr

constexpr引数ってコンセプトとか使っても無理なん

なぁ…何気に…普通に…何の気なしに…以下の様なコードを書く…
textView1->get_source_buffer()->place_cursor(
textView1->get_source_buffer()->get_iter_at_line(minusList.front() - 1));
なんだけどさ…このplace_cursorの引数はiteratorなんだが…この一時的に作った無名の変数の寿命って…
どうなってるの？…ちなみに…place_cursorは&で受ける…やばいのかな？

place_cursorを実行している段階では…生きている…そうだ…次のステップに移行すると…消える…らしい
ほんまかいなと思いますが…一応…信じておきます…

またお前か

>>76
一時的なオブジェクトの寿命が完全式の終わりであることは保証されている。
https://timsong-cpp.github.io/cppwp/n3337/class.temporary#3

参照が一時オブジェクトに束縛されているときは更に寿命が延長されることもある。

勝手に消えるのは確かだが
いつ消えるかは確定出来ないんじゃないの？
次の行の実行中かも知れないし
もう少し生きてるかも知れない
関数抜けたら消えるだろうけど

その、意味があるとかないとかを、どうやって判断するかと聞いてるんじゃないかね

記述時に事細かに寿命を制御・確定できるような時制プログラミングを作ればいい
C++の場合だと新しい原理を作ればいい

> 参照が一時オブジェクトに束縛されている

一時オブジェクトが参照に束縛されている、だろ
ここではconstでない左辺値参照は含まない

>>83
> 一時オブジェクトが参照に束縛されている、だろ

いいえ。 束縛されるのは参照で束縛するのはオブジェクトです。

>>84
規格票での言葉遣いはこうなっているぞ
CA &&r = A{}; // OK, reference binds to temporary array object

>>85
実際はそこらへんいいかげんなんですよ。

いや、おかしいだろ
rand(); //ここで消えてしまう一時オブジェクトを
auto&& a = rand(); //引き止める（束縛する主体が参照で
客体が一時オブジェクトだぞ

typo
(束縛する)

>>85
このへんのセクション内部ではどちらの表現もある。
https://timsong-cpp.github.io/cppwp/n3337/over.ics.ref

"自由変数と束縛変数"
https://ja.wikipedia.org/wiki/%E8%87%AA%E7%94%B1%E5%A4%89%E6%95%B0%E3%81%A8%E6%9D%9F%E7%B8%9B%E5%A4%89%E6%95%B0

このへんの数学的用語では束縛されているのは変数で、 ML 系とか Scheme とかでも一貫してこの用法に従ってるんだけど、
めんどいから私は「××との間に束縛を持つ」みたいな言い回しでどちらが主語なのか曖昧にしたりしてる。

今回の場合は >>79 で示した通りオブジェクトの寿命に関する項目での表現では束縛されているのは参照だから
それにならっただけでどっちがどっちでもまあ重要じゃないよ。

>>89
１つめのリンクでは
結合する主体は参照を宣言するコンテキストだね
結合される客体がオブジェクトである点は変わってない

数学や他言語がどうたらには付き合ってやんね

ちゃんとC++の話のなかで例えるなら
実体定義と外部宣言はどちらが使われる側と使う側なのか
のような話だろ

そことは直接関係ないけど、cppreferenceの英語版って、英語として文法的におかしい
ことが有る気がする。主語が無くていきなり三人称単数現在のsが付いた動詞で
始まっている文章も、見出しの直後ならダメではないが、見出しの直後以外の
if節の後にあったりして、しかもそれがif節の中に繋がっていなくて、本来なら
主語を省略できない場合とか。
Microsoftの英語版はすらすら読めるけどcppreferenceの英語版は読めない。

int 配列の参照って
int (&a)[N]
であって
(int&) a[N]
じゃないよね？
後者は「参照の配列」を意味するようで変なのは分かるんだが、前者は前者でどこに&ついてんねんって感じなんだが

>>91
てにをはがおかしいのは日本国憲法に比べればかなりマシ。がまんしろ

>>92
>int (&a)[N]
それは、数学記号の様に読み取ることが出来る。
()は優先順位を変えているだけ。
優先順位に従って書いてみると、
a --> & --> [N] --> int
となる。これにより、
「a は、参照で、それは、[N] を指し、その要素は int である」
と読めて、もう少し自然な言語に直すと
「a は、参照で、それは、N要素の配列を指し、その配列の要素は int である」
となり、さらにわかり易くすると、
「a は、要素が int の配列を指している参照である」
となる。このように数学の式変形の様な工程を経ているだけの、単なる計算の様な
ものに過ぎない。

>>94
[補足]
a --> & --> [N] --> int
を英語で読んでみると、
「a is & to [N] to int」
となる。& を「reference」、[N]を「N要素のarray」に置き換えてみると、
「a is reference to "N要素の配列" to int」
となる。日本語に直せば、
「aは、int 型の N要素の配列への参照」
となる。

それはたとえば
int (a&)[N]
などを禁止する理由になってるだろうか

参照修飾子はすぐ右にある対象を修飾する

>>39の
> 2つの文字列リテラルの共通部分列の長さをコンパイル時定数として扱う
をやろうとして苦戦しています
再帰 constexpr 関数で計算しようと思ったんですが、引数として受け取った文字列リテラルの要素って定数と見なせないですよね？

そもそも無理か、勉強次第でできるかだけでも教えていただけたらありがたいです

>>96
(a&)
の部分は、()は優先順位を変えているだけなので、コンパイラは
a&
という部分式を認識しようとする。しかし、a& という部分式は
C++では文法的に存在して無いのでエラーとなる。
単にそれだけの事。

>>100
[さらに補足]
C++では、「宣言文」と地の文における「式」とは別扱いになっている。
なので、式における &a と宣言文における &a では、& の意味が異なる。
今回の場合は「宣言文」。
宣言文における &a は、a が参照型であることを意味する。
式における &a は、a のアドレスを取得する演算子である。

> x --> [N] --> int
> という順序の演算が並んでいると理解されている。

において「演算」と書いたのは、適切な言葉が見つからなかったため。
演算といっても、今回は宣言文ので、式における演算子とは意味が違う。
式に置いて x[y] は、常に *(x+y) と等価な演算子であるが、
宣言置いて x[N] は、演算子ではなく、x が N要素の配列型であることを
意味しているだけである。
また、最後の xxx --> int も演算子ではなく、型指定部と呼ばれ、
xxx の部分が int 型であるということを意味しているだけである。

しかし、コンパイラ内部では、
x --> [N] --> int
のように意味解釈がされていることだけは確かである。

>>101
> 「演算」と書いたのは、適切な言葉が見つからなかったため

抽象構文木？
長いしもうちょっと整理してから書いてや
独自記法もやめてな

>>102
抽象構文木とは限らない。

>>102
整理すると理解できないと思うぞ。
俺は個の痛手は良く馬鹿にされるが、IQは170くらいある。

IQが20違うともう対話が成立しないって聞いたことがある

「a&は禁止されてるから禁止」て言ってるだけじゃねえか
バカなのかコイツ

>>106
そうじゃない。a& という部分式が、記号として未定義と言っている。
禁止じゃなく、未定義。数学でも、
-a
は符号反転とか、負符合という意味で定義されているが、
a-
は定義されていないのと同様。
禁止ではなく、定義されない。だからエラーになる。

「パーサーが受理しない」なら言っていい

未定義って言ってんじゃん
パーサーなんて規格票で使わない用語を持ち出す必要ねえよ

>>108
それでは、なぜ受理(認識)しないのかという理由が曖昧。
理由は、そのトークン列が「未定義だから」。

>>110
還元できる構文規則がないからだよ
redexは非終端記号も含むから「トークン列」はそもそも誤り

>>111
専門用語をなるべく使わずに平易に説明してるつもりだった。

俺は、非終端記号、構文規則、redex、受理みたいな専門用語はなるべく使わずに、
生まれながらの頭の良ささえあれば理解できる様に書いたつもりだ。
だから、他に本などを読まなくても俺の説明をちゃんと読めば、数学的に高IQの人なら
理解できるはず。

>>105

> 独自記法もやめてな

脳天にどでかいブーメランぶっ刺さってんぞｗ

定義されてないから未定義なのか
定義できないから未定義なのか

未定義にしている理由なら、禁止してるから定義にないのは当然じゃん
定義にあるのは許可されたやつだけだから禁止されたものは書かれてない
定義に無いから禁止されてる
未定義＝禁止であって、未定義なのは禁止されてるから

なんで無いのかを聞いてるんだからどっかで禁止されたんだろ
で、答えが「未定義だから定義には無い」「禁止されたから禁止されている」何も言ってないじゃないか

なんでそのルールが無いのか、ルールそのものには書いてないじゃん

>>116
？？？
c++標準で未定義と定義されているのが「未定義」だろ。

>定義されてないから未定義なのか
>定義できないから未定義なのか
どちらもc++の「未定義」じゃない。
c++標準くらい読めよ。

関数呼び出し時の引数の評価順は未だに未規定(unspecified)ですね
でも未定義(undefined)ではない
最適化をしやすくするためとか

コイツが言ってんのは、構文解析の規則にないから未定義であり禁止、だろ
禁止されてんのは構文規則には入ってないです、未定義だからです、だから禁止です、ってな

そりゃ構文規則には受理する規則だけが書いてあるだけなんだから受理しない規則は書いてない
定義しない理由があったんならそりゃ禁止する理由だ
でなければ定義に書かれている

構文ルールに入って無いのはそのルールが未定義なのか禁止されてるだけなのかそもそも定義できないのか、それは分からないだろ
だから禁止されているかどうかの答えにはなってない

禁止されたから構文ルールには入ってねえんだよ

ある入力を受理するかどうか未定義ってどうやって書くんじゃ……
わざとあいまいなNFAにでもするのか…………
つかBNFはPDAなのでは……………………
PDNFAみたいなもんがこの世にはあるんか…………………………………………

初期化されてない自動変数やポインタを使うのはスリルあるね

>>120
構文規則には、その言語(C/C++など)で定義されたパターンを、非終端記号と終端記号を
組み合わせてBNFなどを使って書く(その構文規則をコンパイラ理論では「文法」と呼んでいる。)。
トークン列が、その構文規則のパターンに当てはまる場合、「認識された」という。
このとき、認識されないトークン列はエラーであり「受理されない」。
ようは、文法規則に当てはまってないトークン列が、「受理されない/未定義」。

>>116
C++の宣言文において、&x を x が参照型であることを意味する文法を最初に
定義するのは、人間。そういう言語にしたいからそうしただけ。
そしてその文法は、(必須ではないが)、BNFなどを使った構文規則として仕様公開される。
C++の構文規則には、x&というパターンは書いてない。
なので、積極的に「禁止」しなくても、トークン列にx&というものが現れても、
どの構文規則にも「マッチング」しないのでエラーが表示される。
それだけのこと。

仕様が提示する構文規則 (BNF) に合致しないというレベルの違反は診断対象規則 (diagnosable rules) に反するので処理系がユーザに通知する義務はある。

>>122
受理されなかった入力は非マッチなのであってエラーの一択なのでは……

>>123
x&とかxが型なら普通にパターンとして現れるのでは…………

「C++の構文規則にマッチする入力テキストの集合」が一意確定になることを疑う理由は無いから
入力テキストにわざわざ未定義などというクラスを設けるする必要は無いのでは……………………

>>126
構文規則の中に x&y は存在しているが、x&単独では存在していない。
だから、z = x&y; や z=(x&y) は受理されるが、z = x&; や z=(x&)
はエラーになる。

>>126
おっと、読み間違えた。
xが型の場合は受理されるよ。
xが名前トークンの場合は受理されない。

>>129
[補足]
・xが名前トークンでも意味論的にxが型名とみなせる場合にはxは型だと扱われる。
・xが変数名の場合には変数だとみなされる。
・xが変数名の場合には、x&yは文法の中の有る規則にマッチングするので
　受理されるが、xが変数名の場合にはx&という文法規則は存在してないので
　どんな文法規則にもマッチングできないのでエラーになる。

>>130
[さらに補足]
・xが(ユーザー定義の)型名の場合でも、それが現れる文脈次第で
　x&が受理され無い事がある。
　文脈によって受理されるパターンが違うので。

たぶんくそしょうもない質問いいですか

コンストラクタの初期化子リストで
まさに今初期化したばっかりの他のメンバを使うのはアリですか

class Foo{
Foo(Bar bar,Baz baz);
Bar bar_;
Baz baz_;
...
};

Foo::Foo(Bar bar,Baz baz)
:bar_(42)
,baz_(bar_) // ← これ
{...
自分の環境では動いてるようですが
規格に照らし合わせて合法なものなのでしょうか？

>>132
クラスのメンバ変数は定義に書かれた順に初期化されるから、その例についてはokなんじゃないかな

メンバ初期化子として書いた順ではなくクラス定義内のデータメンバ宣言順に従うというのが重要ポイントで、
勘違いを防ぐために宣言順とメンバ初期化子の順序は一致させるのが一般的な習慣になってる。
(一致させなくてもそれ自体は規格違反ではない。)

C++20 から入る指示付初期化 (Designated initialization) で順序を一致させるのが必須に
なっているのはこのへんの反省があったんだと思う。

各位　ありがとう

>>134
後半はへーって感じなので調べてみる

構造化束縛とか範囲for文が必ず新規にオブジェクトを宣言しないといけない仕様になってるのが何気に解せないのだが
既存のオブジェクトを使い回せた方が都合良いだろうに、なぜこういうことになったの？

構造化束縛の方はtieで行けるだろ

int a, b;
std::tie(a, b) = std::make_pair(1, 2);

参照じゃダメ？

c++11やり始めた頃、for(auto& e:〜やfor(const auto& e:〜と出来るのを知らず、酷いコードを大量に垂れ流してしまったよ

>>138
参照にしてもfor文のスコープ外で宣言できた方が都合が良いことがままある

ループの最後の値を使いたいという事？

>>140
言っても「稀に」程度だろうし、やりたければスコープ外で宣言した変数に代入すれば済む。
何を問題としているのかわからない。

お漏らし推奨

自作関数の引数を initializer_list にするのってなんか使い道あるんですか？
参照の組を渡せる？

MyVector v{1,2,3,4,5};
とかできる

ま、まいべくたーｗ

>>145
コンストラクタの引数にするくらいしかメリットないの？
前スレ掘ってたら、同じ型の参照の組なら initializer_list で関数に投げれるってのを見つけたんだがそれはどうやんの
initializer_listを引数にとる関数 hoge を
hoge({fuga, var, aaa})
って呼び出したら実体を渡してることになるよね？

MyVector(initializer_list<reference_wrapper<int>>) { }

>>148
それって vector< reference_wrapper<T> > とは違うんけ？

template <class T>をつけるならね

reference_wrapperはC++11からでC++03にはないから> >にする意味ないぞ

初期化のときに登場する｛｝が初期化子リストだと言うことがつい最近判明した
概念を区分して分離したのが一番大きいので、用途についてはあまり考えられていない

>>151
いや自分の可読性のためにそうしてるだけ
他の人にとってはそっちの方が見づらかったらすみません

それはそうと、関数に参照の組を渡すなら、initializer_list 云々というよりは reference_wrapper の組として渡すってことですね

もう一点、関数に initializer_list を渡すときって
・関数の引数の型が initializer_list である
よりも
・関数の引数のコンテナを initializer_list で初期化している
の方がしっくりくるんですが、前者で設計するメリットってありますか

overloadに弱くなる

>>153
長かったC++03時代でそういうクセが染みついちまった、ならわかる

気狂いいてワロ
(a, b, c) と ( a, b, c ) さえどちらが良いかなんて誰にも決められないのに、なぜ < <> > と <<>> なら後者の方が問答無用で良いと思い込んでるのだろうか
こういう、一概には言えないことを押し付けるタチの異常者が回答側に回ってるのイタ過ぎだろ

同和ンゴ

トークン分割の段階では >> というひとつのトークンとして切り出された上で
構文解析の側で辻褄を合わせるという変な解釈が不格好だから好きじゃないな。
構文が複雑になる分には仕方がないと割り切れるんだが、
異なるレイヤをまたいで辻褄合わせするのってなんか嫌じゃない？

でもまあ > > よりは >> のほうが見やすい気がするからそう書いてるんだけど、
割とモヤモヤしがち。

何で押しつけたことになるんだ？
被害妄想で攻撃的になるやつこそ病んでるぞ

スタイルは案件ごとにある
そこでいらぬ波風立てるやつは叩き出される
仕事は成果で語るものなのに勘違いして
つまらんことに気を取られるやつは使い物にならん

>>149
おそらく初期化子リスト版の方が高速に動作する
まぁ、今時のコンパイラの最適化は変態レベルに進化してるから結局同じようなコードに落ち着くかもしれないけど

>>154
initializer_list をとることにしておけばコンテナの種類を決めておく必要がないから得ってことですか？

>>159
> スタイルは案件ごとにある
元質問はスタイルが指定された案件では全くないので、自分が頓珍漢なこと言ってたって認めるわけね

> そこでいらぬ波風立てるやつは叩き出される
> つまらんことに気を取られるやつは使い物にならん
狂おしいまでに己のことだな

>>162
元質問には特定の案件か否かはどちらとも書いていないね
さらに俺は特定の案件の話だともそうでないとも言ってない

次から次へと勝手に決めつける軽率なやつが
他人に向かって頓珍漢とか天に唾するってやつだぜ

恥ずかしくなってネタっぽくしてるが隠しきれてない同和ンゴ

cout と cerr に同じもん流し込みたいときって
cout << hoge;
cerr << hoge;
ってやるしかない？
一行というか一文で書けたら楽だが

>>165
すなおに以下のようなマクロにしとけばどうかな
#define HOGE(x) std::cout << x; std::cerr << x;
例えば以下のように使う
HOGE(hoge << endl);

random_device{}();
の中括弧って何なん
デフォルトコンストラクタで構築するってこと？
なんで丸括弧じゃないん

別に中()でも問題なくない？

ラムダ式のキャプチャ構文の個別コピーとか個別参照がなんで存在するのかイミフなんだが
引数で良いじゃん

キャプチャにもコストは掛かるから必要なものだけ最小限キャプチャしたい時に必要なんだよ
なぜ引数でいいと思うのかはイミフ

既存の関数ポインタや関数オブジェクトと整合性を取るには、寿命やスコープの異なる変数を使うための仕組み(キャプチャ)が必要だったからでしょ

とあるラムダ式を読みづらいと感じるならそこでは使わないほうがいい
煽っているわけではなくて、ラムダ式の存在意義は可読性の改善なので、ラムダ式を読みづらいのは本末転倒だからね

>>170
キャプチャデフォルトにしても使わなかったやつはキャプチャされないから
あえて個別にするのは何か理由があるときだね

>>170
キャプチャできるオブジェクトってみんな引数としても渡せるじゃん
参照、const参照、コピーも自由自在だし
コストって言うけど、参照キャプチャと参照渡し、コピーキャプチャとコピー渡しってコスト違うの？

一応断っておくと[&]と[=]の存在意義は分かる
オブジェクトを個別にキャプチャするのがイミフってだけ
「こういうときに使う。引数渡しではできない」という例があったら教えていただきたいです

ラムダ式がキャプチャするタイミングと呼び出すタイミングは違ってもいい

呼び出し時にキャプチャ元の存在は保証されない自己責任

>>174
これを引数渡しではどう書く？

random_device dev;
int ary[256];
generate(begin(ary), end(ary), [&]{ return dev(); });

>>175
なるほど
コピーしたいけど呼び出しの度には嫌だ、というときに役立つのか
神機能だな

>>177
もう解決しました

>>176
コピーならHOSYOUされる

>>178
つか新しい関数を作る機能

>>169
カリー化

普通のｷｬﾌﾟﾁｬ（コピー）ではなくて
異常なｷｬﾌﾟﾁｬ（参照のｷｬﾌﾟﾁｬ）なら呼び出し時にキャプチャ元（参照されているオブジェクト）
の存在はＨＯＳＹＯＵされないから注意しないとＫＩＫＥＮだが
なんでそんな機能があるのかというとオブジェクトをカリー化（？）する場合にあったら便利だねえ、ぐらいの勢いの話
普通のｷｬﾌﾟﾁｬだけでもポインタをｷｬﾌﾟﾁｬしたら同じことができる

もっとも、自動変数として作られたオブジェクトxをｷｬﾌﾟﾁｬする場合、
xを参照のキャプチャする代わりに&xを普通のキャプチャしてしまうと
（「＆」演算子が使われたことにより）微
妙に最適化に響きかねない問題というのは微妙にあるが微妙なので普通は気にするほどではないはず……

元のデータをFUCKYUできないような書き方はAUTO

キモい言葉遣いヤメレ

ヒドロキシクルルキン
イベルメクチン

ヒドロキシクロロキン
イベルメクチン

C++において関数は第一級オブジェクト
なのに C++ が関数型プログラミングを全く想定していない仕様に思えるのはなぜ

関数型のパラダイムもうまく取り込んでほしい

>>187 古いから。
>>188 提案するのは自由だから、がんばって。

>>187
c++の関数は第一級オブジェクトじゃないだろ。
高階プログラムはテンプレートという別の仕組みでサポートしている。

関数型プログラミングは別に古くないはず……
ＧＥＮＪＩＴＳＵ世界が状態を持ち破壊的代入を伴うから
まだチューリングマシン的な計算モデルの方が対応がとりやすい（気がする）だけ
C/C++が関数型プログラミング一本鎗にならないのはそれが根本原因

・弱体化された関数型の機能
・構造化プログラミング
・GOTO文
これがCだよ

で、多分70年代当時は関数型プログラミングはおそらく過去の遺物になってた
でないとこの頃のlispの失速が説明つかない

当時生まれてないけど
あのマシン性能が貧相な時代によくLISPなんて流行ってたな

むしろマシンリソースが少ない時代だからこそ流行したといえる
LISPマシンはすなわちスタックマシンだ
複雑な語句パーサーとツリー構造の構築がなくても、ストリームから
はいってきたキーワードを順繰りに解釈してスタックにつんでいき
かっこが閉じたらスタックからひっぱればちゃんと動くものがつくれる

>>190
禿は「第一級オブジェクト」をテンポラリでないオブジェクトと言っているようだが

権威者がこれこれと言ってたからこれこれであるという話の持って行き方は
今日の世界では小学生レベルの人間しかしない

中世ヨーロッパでは過去の偉人の言葉をいかにうまく引くかが議論の上手下手を左右したらしいが

その世界の教祖のような人でも一切、言葉を引いてはいけないのか
小学生で年収1000越えそうな人ってジュジュちゃんとかいるけど
自分の年収を棚に上げてわかったようなことをｗ

>>194
それForthじゃね？

>>196
ここで必要なのは範例ではなく定義。
何が正しいのかを議論したいわけじゃなくてどの定義を使う「ことにする」という擦り合わせ。
C++ における定義を決めるなら設計者の言を元にするのは妥当だろ。

それはそれとして >>195 はなんかおかしいこと言っていると思うし、
なんか勘違いしてそうな気がするが。

関数型プログラミングが古いと主張する香具師は
MVCとかなMと表示等が分離した設計モデルでありかつ
Mがマルチスレッド（UIスレッドとは別）なケースのプログラミングを
ラムダ式を使わずにして見られれば宜しい
すっきり収拾をつけるにはコールバック関数として関数オブジェクトを渡すか、
コールバック関数をvoid*引数の関数にするという前近代的な設計にするかしかなく、
classを使って手で書く関数オブジェクトはラムダ式を見たコンパイラが生成するコードと大差ないから
前者は関数型プログラミングに他ならない
という印象、
※ 個人の感想です

それはそれとして>>192も相当おかしいことを言っていると思うし以下略

>>197
年収が人間の価値だと思う人って今でもいるんだね

関数型の実戦で使えるエッセンスは10年前から各種人気の言語で取り込まれ、
具にも付かない思想倒れな部分は取り込まれなかった。それだけ。

>>196
上下を左右するとな。
今日一番心に残った表現だ。

Scheme だとプログラムの流れ (関数を呼出したり戻ってきたり) を継続の起動の連鎖として
定義づけているが、継続の概念の元になったのは並列計算の研究から生まれたアクター。
アクターにメッセージを送るのと関数呼出しが実装上は同じになってしまったという気づきから継続の概念へと整理されていった。

関数型とオブジェクト指向は整理の仕方が違うだけで
(といっても人間が使う以上はどのようなメタファで整理されているかも大事でもあるんだけど)
より抽象的なレベルで見ると同じことをやっている。
そんで並列計算は (理論上は) どっちでも織り込み済みなのでパラダイムによって
どちらのほうが並列計算しやすいということもない。

差があるとしたら単に言語の設計の出来栄えとかライブラリの整備とかのレベルの話なんで、
パラダイムにまで踏み込んで考えるような話じゃないよ。

高所得者「年収が人間の価値だと思う人って今でもいるんだね」
低所得者「年収が人間の価値だと思う人って今でもいるんだね」

>>203
C++に取り込まれた、実践で使える関数型のエッセンスってどんなん

bind

深さが任意の入れ子の vector を一次元 vector に展開したいんですが、良いやり方ありますか
再帰すれば良いと思うんですがどういう条件で分岐すれば良いかわかりません

入れ子を一階層だけ展開する処理を書いて
入れ子がなくなるまで末尾再起するというのはどうだろうか

>>210
今見てる階層の一個下がvectorか値かっていうのはどう判定したら良いですかね？

>>209
これ

flatten - 1.57.0
https://www.boost.org/doc/libs/1_57_0/libs/fusion/doc/html/fusion/algorithm/transformation/functions/flatten.html

大抵の言語でその手の挙動はflattenと呼ばれてる

Yet Another Common Lisp Problems
http://www.nct9.ne.jp/m_hiroi/clisp/yaclp03.html#ans51

>>197
肝心なのは「誰が言ったか」ではなくて、「（言った）意味、中身」。

さもないと「権威に訴える論証」にひっかかるから気をつけな。
わかってやっているなら詐欺師だし。

>>210
ちょっとググった感じだと、vector<T> が vector かどうか判定する is_vector ってないんですね
あと is_array は std::array を array と見なさないみたいな情報もあって、メタ関数は罠というか勘違いが多そうで怖いですね

現状、自分で is_vector を実装するしかないんですかね？
ごく基本的な処理に思えるので、シンプルな解法というかイディオムみたいのがあれば教えていただきたいです


>>212
ありがとうございます。が、今は自分で書くならどうなるかというところに興味があります
boost の flatten のコードはいろんな場合に対応するべく難解になっていそうですが、どうにもならなかったら参照してみます

>>215
正直、まず>209の「深さが任意の入れ子の vector」をどう定義してるのか見せてもらわないと話が見えてこない気がする。
要素型が固定なら要素型のほうで判定すれば is_vector は要らないだろうし、
variant とか使ってる場合もやっぱり is_vector の出番は無いだろうし。

>>216
vector< vector< ... vector<T> > ... > で、T は correction (vector, array 等) じゃない、というのを想定しています
仮定が足りませんでしょうか

>>214
偉そうにキリるなら「第一級オブジェクト」の公式な定義をまず出せ

>>215
作るったって大した話じゃねえべ

template <template<class...> class T> struct is_vector : false_type { };
template <> struct is_vector<vector> : true_type { };

template <template<class...> class T> constexpr bool is_vector_v = is_vector<T>::value;

>>217
numpy の reshape / flatten / ravel みたいなの想定してる？

>>217
それじゃ深さ固定じゃね？・・・深さの違ういくつかのケースを扱うっていうことか。
T を受け取るオーバーロードとそれ以外を受け取るオーバーロード書けばおしまいな気がする。

（要素ごとに深さが異なることもあるのを想定してた。）

>>219
ありがとうございます
よく知らない構文も混ざってるので、勉強します


>>220
はい
flatten をしたいです


>>221
template<class T> T flatten(vector<T>)
と
template<class T> T flatten(T)
ってことじゃないですよね？


>>222
>>217ってそれ含みませんっけ？

そもそも厳密な書き方じゃないので、含むか含まないかわかりませんね
今は含まないということにします

>>218
そもそもc++には「第一級オブジェクト」なんて定義されてないだろ。
c++標準に"first-class object" なんて記載あったかね。

一般的な解釈はwikipediaでも勉強しろよ。

>>225
ここはC++スレだ
一般的な解釈なんて頓珍漢なこと言ってんな
そっちへ逃げたければ１人で逃げろ
俺は付き合ってやんね

>>226
だったら「第一級オブジェクト」なんて頓珍漢なこと言ってんな
そっちへ逃げたければ１人で逃げろ
俺は付き合ってやんね

>>227
流れくらい読めよ
第一級オブジェクトと言ったのは>>187だぞ
おまえ他人に頓珍漢なんて言う資格ねえぞ

一昨日の曖昧イキリで今さらヒートアップしてんじゃねー

>187、>190 、>195 、>197、>214
の流れくらい読めよ
禿の権威にかこつけて「第一級オブジェクト」を主張しているのは>>195 >>197だぞ。俺はそれに>>214で反論しているだけで「第一級オブジェクト」は肯定していない。

おまえ他人に頓珍漢なんて言う資格ねえぞ

>>230
おまえの定義では斜め上な返事のことを反論というのか

関数は第一級オブジェクトか否かで揉めてるところへ
禿の定義を参考に持ち出したところへ
権威主義がどうたらと人格批判を始めたのが反論とは笑止千万
だから頓珍漢と言ってやったら相手の言葉をオウム返しし初めやがって
いくら寂しいからってプログラム技術板で全然技術的でない絡み方してんなよ

流れ一切読んでないけどFirst-class citizenのことを言いたかったのかなｗ

こいつ「天に唾する」クンでしょ
>>219もコピペでドヤってるし

>>233
失礼な奴だな
オリジナルだよ
コピペじゃねえよ
他で同じもん作ったやつがいたの？
知るかそんなん

>>231
日本語でok

>>235
無教養なやつだな、まあいいけど
犬を相手に話したことが通じてなくても別に構わんのと同じだ

あの程度のコードをコピペだと思ってしまうあたり
自分では書けないやつなんだろうな
だとしたらプログラム技術板では最下層のゴミだ

効きまくりでクソワロ

5hは初めてか？肩の力抜けよ。

「第一級オブジェクト」についてはこんな感じだな。間違っていたら解説してくれ。
・c++では「第一級オブジェクト」は定義されていない
・c++では関数はオブジェクトじゃないし、オブジェクトとして扱うこともできないので、c++の関数をwikipediaにあるような解釈で「第一級オブジェクト」と言うことはできない
・関数を操作対象として（メタ）プログラムする仕組み（テンプレートとか関数オブジェクト・ラムダ式）があるので、高階プログラム自体は可能

第一級オブジェクト、よくイキりのWEBプログラム屋が使う印象の単語
C++界隈ではあんまり聞かん単語だな、使わないことはないが

std::functionで「第一級オブジェクト」とやらに出来ることは何でも出来るからそれで充分であって
そっから先はただの宗教戦争だろ

第一級市民オブジェクト

フランス革命で殺されたかも？

>>241
> std::functionで「第一級オブジェクト」とやらに出来ることは何でも出来る

俺も完全にこれの話だと思ってた

ただ純粋関数型言語のようには書きたくても書けないよね、というのが>>187-188の話だと

>>238
は？　尻尾巻いて逃げた負け犬の分際で何か言ったか？

つーか
> 「天に唾する」クン
なのは図星なのかよって思うとまたワロタ

>>246
そんなとこ見てねえよ

コピペ呼ばわりから逃げたいのか？
吐いた唾は飲ませんぞ、自分で書けない低脳が

>>241
まあ、c++は歴史が長いから、他人には禁止したい余計な機能はあるよなぁ。

以前、ユーザー側からどうやってもdeleteできないスマートポインタを作ろうとしたけど、どうしても::deleteをブロックできなくて挫折した。……まあ、::delete使うやつはいないだろうけど。
あと、オブジェクトのライフサイクル制限を目的としてヒープに置けない（スタックだけに置ける）クラスを作ろうとしたけど、メンバ変数に置くのをブロックできなくて挫折した。

そういうしょうもない機能作ることに時間をかけるくらいならバカを雇わない方がよっぽど生産的だわ

しょうもないかねえ
俺は技術的に色んなことを想像したぞ

しょうもないわ。
注目するのはなぜdeleteしようとしてんの？ってとこでしょ。
それを無理に禁止してもそいつはもっとめちゃくちゃなことするぞ。

しょうもないことにしたいやつは考えること自体を拒否するから
相手すんの馬鹿らしいわ

自分も昔似たようなこと考えたことはあったけど
operator->()を実装する限り、直接呼び出しでナマポ取られちゃうのを防ぐ方法がないんだよな
しょうもないことは否定しない

すぐには実用的な用途は思いつかないからしょうもないかどうかは判断できないけどパズルみたいなもんで趣味としてやるならいいんじゃね？

自分で使う分には全然問題ないんだけどな。他人が絡むとマーフィーの法則が恐ろしい。
パラノイアなのは否定しない。

旅行バッグに荷物をきっちりと詰めてから荷物の入れ忘れに気づく徒労感を楽しみたい人だけやればいい

ピンプってる場合だってクラックはやればできる
そういうのまで完璧にガードするのか否かで考え方変わってくるからな

標準にだって「禁止」や「非推奨」はあるね

autoでなにか受けるときに、参照を使う方がユニバーサル参照を使うより良い場合ってある？

const参照であればいい場合もあると思う。

>>260
ﾎﾜｧｲ？

規格票を検索してもuniversal referenceというフレーズはヒットしない

もともと名前がなかったので、通称としてuniversal referenceとかforward referenceとか呼ばれるようになったんよ

>>262 forwarding reference でどうぞ。

std::vector<A>を、std::vector<B>を使ってソートしたい場合
どうするのがスマートでしょうか？
例えばAが生徒の名前、Bがその生徒の得点だとして・・・
struct C{A a; B b;}を定義してvector<C>を作ってそれの比較演算子を作って・・・というのは思いつきますが
もっといいやり方ってありますかね？

名前、得点の他に何か、たとえば出席番号や出席日数などがあるなら
名前と得点だけのstruct C { A a; B b; }; を作るのは得策じゃなさそうだな
全てのデータが載ったマスターデータを作っておいて、
そのレコードへのポインタでvectorなり何なり作ってソートしては？

vector<C>みたいなものを作りたくないならAとBのvectorの要素間の対応関係はどうやって守るつもりなの？
片方だけソートしたら壊れちゃうぞ
元データは触らずにindexのvectorを別に用意して、[](int x, int y){return b[a] < b[y];} でソートする手もあるけど

>>260
割となんでか気になるので、よかったら教えてください

多次元配列の in-place な添字の入れ替え (transpose) って上手いやり方知られてますか？
多次元配列の各要素は一次元に配置されてると仮定して良いです (行優先でも列優先でも良いです)

>>266-267
ありがとうございます
とりあえず要素そのものじゃなくポインタかインデックスでやれば良いことに気づけました

>>267 >片方だけソートしたら
両方ソートするイメージでした

>>269
縦横の二重ループで一つずつswapするしかないんじゃないかなー
gslやgmtlはそうなってた

>>271
行列で言うと、上三角あるいは下三角の各要素を巡回して対応する要素と swap するみたいなことですよね？

多次元の場合も同じようにできますかね？
例えば3次元配列だったら、直方体を斜めに切って上三角錐か下三角錐の各要素を巡回するって理解で合ってますでしょうか

CMakeについてもこのスレでいいの？

ちょっと違うね
スレないんなら立てたら？

スレ検索したらmakeスレなんて無いんだな
確かにここ10年位makefileなんて書いたことないけど…

VSCodeで書く時は便利なんで・・・

過去に
make 使ったら負け
ってスレがあった

まあ今どきMakefileなんて人間様が書くもんじゃないし

>>278
え？

え？

立ててみた。活用してね。

ビルド自動化ツールCMake Part.1
http://2chb.net/r/tech/1623496111/

cmakeってすごいよね
Makefile作れるだけかと思ってたらVisual Studioのソリューションファイルなんかも生成できて驚いた

>>282
CMakeはGitHub Actionsと組み合わせると、ビルドとテストが自動化できて最強なんだよ。
コマンドラインで出来るめんどくさい仕事は自動化してほしいよね。

AutomakeもそううだがCMakeはなんでそんなことができるのか原理がわからん……

mesonとかautotoolsとかのビルドツール共用でも良かったかな

ていうかそもそもVisual Studioのslnファイルの仕様とか公式に公開されていましたっけ

>>286
中身見てごらん。テキストファイルだよ。

せっかくスレ作ったのにこちらで話してる

>中身見てごらん。テキストファイルだよ。
ﾋｴｯ…、、、ブラックスワン理論…！

バージョン変わるとすぐ壊れるがな。
dockerで環境揃えてmake使った方がよっぽど安定するわ。

>>286
全部のタグを説明するリファレンスのようなものがあるかどうかは知らんけど、ある程度はドキュメント書かれているよ。

>>286
マイクロソフトってそう言うドキュメントは結構まめに公開してるよ
https://docs.microsoft.com/en-us/visualstudio/extensibility/internals/solution-dot-sln-file?view=vs-2019

M$にベンダーロックインされる。

sln作らなくても最近のVisualStudioは直接cmakeプロジェクト読めるぞ

新しいプロジェクトするならmesonを試したいなー

GYPには期待したんだがもう先がないな。

メンバの構築 (コンストラクタの呼び出し) を後で行いたい
なんでこれしきのことができないんだろうか

「ポインタ使え」はナシね
これしきのことにポインタて笑って感じなんで

C++では、デバッグモードと本番モードの切り替えってどうやるのが普通ですか？
今は、実行時に渡す環境変数で切り替えてます

ビルド時にバイナリ自体を分けるのが多いような

>>297
他の言語の多くは参照型がデフォなんだから、同じことをC++でやりたいのなら他の言語の参照型に相当するポインタを使うのは当たり前じゃん。
どうせポインタよく分からないとかスマポも知らずにポインタめんどくさいとか思ってるからポインタ使いたくないんでしょう？このスレで笑われるのは君の方だよ

まあスマポが他の言語みたいにスマートでもなんでもないゴミみたいな記述法だからなw

>>298
デバッグモードというのは具体的に何をするモードのことを言ってるの？
一般的に C++ 関連の用語として言うときのデバッグとリリースの違いはコンパイル時のプロジェクトを分けて
実行バイナリ自体が異なるものになるくのが普通だし、
Visual Studio とかを使ってたらリリース版とデバッグ版はそのように分かれるようになってる。

そういう運用の仕方についての質問ではなく、たとえば
「いざというときに現場でデバッグに使えるモードを仕込んでいるけど
　そのモードへの隠しスイッチはどうあるべき？」
みたいな切り替え方をどうすべきかだけの質問なのかな？

もしそうなら環境変数でもコマンドラインオプションでも自然だと思う。

>>301
言語の成り立ちや目的が違うからな
そう思う人は他の言語を使えば良い

「スマート」がなんで「記述法」にかかるんだろう。記述法にそんなもんあるのか？

C++標準としては「NDEBUGマクロで切り替えろ」じゃないの

>>297 std::optional で。ポインタ使うのの何が嫌なのかわからないけど。

>>298 それで切り替えできてるならいいじゃないの。人の数だけある「普通」とかどうでもよくない？

>>300
ポインタは参照型じゃなぁぁぁぁい！ｗ

>>308
だから「相当する」という語が付いてるんだろ？

>>299,305,307
ありがとうございます

C++に関係したフォーラムや掲示板で、一番人が多いとこってどこですか？
海外のサイトでも可です

このスレで質問することも多いのですが、アルゴリズムに絡んだ質問だったりするとなかなか回答頂けないので

多次元配列の a[2][3][4] って記法、各次元の長さが x, y, z だとすると *(a + 2*y*z + 3*z + 4) を計算してるの？
意味的に一緒かというよりは、実際そういう実装になってるのか知りたいです

かけ算の数が小さくなる工夫みたいのってされてるんですか？

>>312
CPUに合わせた最適化はされてるよ。例えばx86 CPUではメモリーアドレッシングという計算が得意。まあ、コンパイラが吐くアセンブリを見るといいよ。

>>311
質問なら Stackoverflow とか Teratail とか。

>>313
ありがとうございます
> 多次元配列の a[2][3][4] って記法、各次元の長さが x, y, z だとすると *(a + 2*y*z + 3*z + 4) を計算してるの？
というのは大体どんな処理系でもそうで、
> かけ算の数が小さくなる工夫みたいのってされてるんですか？
ここは処理系による高速化がされてるということですね

つまり、大抵は
> 2*y*z + 3*z + 4
に相当する部分を自分で (書いた関数とかマクロで) 計算して a に加えるよりは、a[2][3][4] とアクセスする方が速いんですかね？
>>272の、多次元配列の添字の入れ替えを in-place でやりたいという話で、こういう疑問に行き当たりました

>>315
それを自分で判断できない知識レベルならコンパイラに任せたほうが確実に良いよ。

「早すぎる最適化は諸悪の根源」とか「実測せよ」というよく知られた格言がある。
仮にちょっとした書き方で高速になるのだとしてもそれによって全体が読みにくいコードになってたら
改善するのが大変になって結果的にあまりよくないコードになってしまいがち。
処理速度が足りないのなら足を引っ張っているのはどこなのか
完成したプログラムを測定してから問題個所を改良すべきというのが先人の教え。

>>315
どうやれば高速化するかは、実際のコードで実測とアセンブリみないと解析できない。掛け算の代わりに足し算で計算できる場合はそうした方が早いかもしれない。
x86 アセンブリの場合、MOD eax, [ecx+ebx*2]のように一語でアドレス参照できる場合がある。
高速化手法には、他にもSIMDもあるし、マルチスレッドもある。

>>297
C++11だとnewでメモリだけ最初に確保しといて、も一回 new で
そのメモリ指してコンストラクタ走らせるってやり方？
ポインタ遮蔽するような template書けば良さそうだけど。

>>308
イコールとはいいませんが、ニアリーイコール、同じようなものですよ‥‥

>>318
わざわざ自分で書かなくてもvectorがちょうどそんな動作してるよね

>>317
ありがとうございます

in-place だと
○ 作業用メモリが必要ない
○ 全要素の半分だけ一回ずつ訪れれば良い
☓ 要素アクセスは自分で書いた関数なりマクロなりで行う必要がある

out-place だと
☓ 作業用メモリが必要
☓ 作業用領域にコピーして元の配列に戻すので各要素を二回ずつ訪れる必要がある
○ 要素アクセスは高速

て感じなので、やってみてどっちが良いか決めます

俺がC++をこよなく愛する理由のひとつがとにかく長年の積み重ねのおかげで
コンパイラが激烈に賢いことだ
他の、たとえばJavaやらそれから派生したKotlinなんかでコード書いてて
「こんぐらいはコンパイラが最適化してくれるっしょ」とかルーズに書いて
実際に展開されたバイトコード見て絶望したことは数えきれない

Java の場合は JVM の側で最適化したりするからバイトコードはそんなに頑張らないらしいよ。

makefile (GNU Make) の使い方の質問はどのスレで聞いたらよいんですかね？

>>297
普通に破門
おまえはポインタを使うなではなくC++を使うな
二度とこの世界に戻ってくるな

CMakeのスレ使えば？

>>297
誰もメリット感じないから実装しないんだろ。
ポインタに対するメリットは？

みなstd::unique_ptrを思いついているが質問の仕方が気に食わないのでわざと回答しない

「これしきのことにポインタ」とか言ってるくらいだから>>297にとってポインタのハードルがものすごく高いんだろう。

ｗ

そうは言っても、コンストラクタでしかプロパティ設定できない不親切なクラスを仕方なく使う羽目になることは結構あるでしょ

RAII分かってるならそもそもコンストラクタ呼び出した後に2phaseでメンバ構築やろうなんて思わないから、質問の意図がわかんねーんだよな

>>290
++

>>311
stackoverflow

> このスレで質問することも多いのですが、アルゴリズムに絡んだ質問だったりするとなかなか回答頂けないので

知ってるがお前の態度が気に入らない
というケースならいくつか思い当たるな

>>312
>多次元配列の a[2][3][4] って記法、各次元の長さが x, y, z だとすると
> *(a + 2*y*z + 3*z + 4) を

*(a + 4 + (3 + 2*y)*z)
くらいのことはやってるよ

>>315
そういう話ならいちいち掛け算してるかとかその回数がとかよりも
メモリキャッシュに乗ってるかどうかの効率の方が多きい

前後の命令の依存関係によっては多少高コストの演算でもパイプラインに隠れて全体としては
それほど時間がかからないということも有りうる。
命令ひとつの実行コストだけでは評価できないから結局のところやってみてから計測するのが
手っ取り早いって話になる。

>>312
現代の普通のコンパイラであれば当然最適化が行われる

コンパイル時に決定可能な部分はコンパイル時に決定するし、
ループ内で変化がない部分はループの外で計算する
のが普通

a[i][j][k] で一番ループの内側がkであれば
a[i][j]まではループの外で行うし
a[1][2][k] のような固定値であればa[1][2]まではコンパイル時に計算する

メモリアクセス順は非常にパフォーマンス的には重要で
a[i][j][k] を3重ループでアクセスする場合
ループの外側からi,j,kとするべき

言語上のいわゆる配列は最適化されやすいので普通は気にしなくていいが、
vectorやMatなど、外部定義の [] は基本的には遅いと思っていい

コストが小さいとはいっても確実にコストは発生する
速度が非常に重要な場合では
SIMD化、キャッシュ化、ループアンロールなどで最適化すべき
その場合も、データ構造、アクセス順、アルゴリズムなど上位層の最適化が終わってから

vectorの[]だって配列へのアクセスしかしてないけどな。
インライン展開されるし範囲チェックもしてない

素人質問ですみません
クラスのメンバ関数は常に外で実装しますか？それとも、短いものはクラス宣言内に書きますか？
混在させて良いものかと迷っています(クラス宣言内に書くとinline指定になる事は知っています

>>341
どっちでもいいようになっているんだからどっちにするかは個別の判断による。
具体的条件を示してくれたらどちらが好ましいかの意見は言えるよ。

template<class T, size_t N> using myarray = std::array<T, 2*N>;
としたときに、関数 hoge を
template<class T, size_t N> void hoge(myarray<T, N>);
と
template<class T, size_t N> void hoge(array<T, N>);
でオーバーロードすることってできますか？

>>338
高コストという文言の意味がよくわからんが
レイテンシが大きい命令はパイプラインを乱すぞ

>>343
２番目のオーバーロード関数はarrayにstd::を付け忘れてるのか？
だとすると無理だと思うな

std::array<int, 1> a;
hoge(a);
と呼び出したとき、N==2となるべきかN==1となるべきかの根拠がないから

やってみてないけど
つーか、おまえさんはやってみたのか？

>>345
> ２番目のオーバーロード関数はarrayにstd::を付け忘れてるのか？
すみません。そうです

まだ試してないです
無理そうだなって思うんですが、昔「オーバーロード関数は機械にとってはそれぞれ別名関数だ」って話を聞いて、じゃあもしかしたら行けるかもと思った次第です

すぐ試せることを自分で試さずに5chで聞くの良くないよ

>>341
templateのクラス書いてると、長くても中に入れちゃうから、でかいのバーンって
そのままヘッダに入れても抵抗はないけど、templateでない場合でかい関数は普通に外に書くな。

>>341
外

templateやstaticのように実装をヘッダファイルに書く場合も
ヘッダファイルの中でプロトタイプと実装に分ける
さらに実装は別ファイルにしてヘッダファイル内で#includeする

宣言だけからなるアウトラインを残したいから

>>343,345-347
試して無理でした
言い方合ってるかわかりませんが、>>343のやり方ではオーバーロードと関数テンプレートの差がないからでしょうか

コンパイラに myarray を array と別の型だと思ってもらって、hoge をオーバーロードするテクってありますでしょうか

>>350
継承でいけるんじゃね

>>350
using で作った別名と元の型を区別する方法があるかという意味でなら方法は無い。
using は「別名」を作っているだけであくまでも同じ存在。

オーバーロードできるように型を分ける方法があるかという意味でなら >>351 が提案しているように継承を使うのが簡単な方法。
template<class T, std::size_t N> class myarray : public std::array<T, 2*N> {};
みたいに書いて継承しつつ特になにも付け加えなければ事実上の別名でありつつ異なる型でもある。

template<class T, std::size_t N> class myarray : public std::array<T, 2*N> { using std::array::aray; };
コンストラクタも継承しとかないと使いにくくて困るぞ

std::array<T, 2*N>::arrayか
この件のみ動作確認しないポリシーなんでやりづれえ

>>349
迷惑なやつだな

>>351,353-354
なるほど
ありがとうございます

> この件のみ動作確認しないポリシー
てどういういみでしたっけ？

コンストラクタさえ継承しとけば、元のクラスとほぼ同じ使用感で使えるんですかね？
試しきれないので未知の困難に直面しそうで結構不安です

>>355
何が？

>>356
多分、自分で確認もせず書き込むようなやつには同じく動作確認なんかしてやらねーよ、ってことだろ

どうでもいいけど変数テンプレートの四則演算って推論の邪魔するような

>さらに実装は別ファイルにしてヘッダファイル内で#includeする
これはやりすぎだろ
#include先に何書いてるかわからんから結局読まなきゃならん
空行とコメントで上下に分ける方がマシ

それは非テンプレートなクラスでも一緒だと思うけど

>>361
その論法はヘッダファイルそのものを否定する考えだな

結局読まなきゃならないのは一緒だよ、当たり前
それでも、何か所にも同じのを書くのが嫌だから#includeなんじゃないの？
俺は一か所からのみ#includeするのを否定してる

何か所にも同じのを書くのが嫌なら
テンプレートでない関数をプロトタイプと実装に分けただけで難癖つけるのか？

まぁヘッダのインクルードの仕方はそれぞれだからなぁ
自作ヘッダ内では一切インクルードしない(それの前に必要なヘッダをすでにインクルードしてる前提)ってのもある

ただその戦略なら、テンプレートがインスタンス化される直前にその実装が書かれたやつインクルードすればいいだけなんだが

多分同じ奴だと思うが、数スレ前から多次元配列を自力でどうこうしようとしてる奴、悪いこと言わんから外部ライブラリ使うとけ
今の時代、行列とかテンソルの計算は並の人間が書いた C/C++ じゃ絶対に Python (NumPy) その他に敵わんと思う

まあ C/C++ の多次元配列ライブラリも群雄割拠で何が何だか全く分からないんだが
STL に多次元配列が中々入らない理由もこれかな

つーか入ったところで大したもんにはなり得ないか
行列の分解とか掛け算を STL が担うのはあり得んしな

>>365
難癖もクソも普通にC/C++の欠点でしょ
フロッピーディスクの時代の遺物よ

>>369
別におまえさんにC/C++を使ってくれなんて頼んでない
嫌いなら出てってもらって構わない

>>370
誰が嫌いなんて言った？
欠点を差し引いてもメリットがあるから使ってるんだし、欠点は欠点として認めないと進歩しないよ

質問です
#define A L"xyz"
#define B L"www"
を結合するとき
#define C AB
じゃだめなんですか？
#define D A(B)
ですか？
それとも
#define E A"www"
ですか？

#define C A B
じゃね

>>371
欠点は欠点として認めるって具体的にどうしてるんだ？
プロトタイプを一切しない、のような公害か？

>>374
いや昔の貧弱な環境でもビルドできるように、って制約が無きゃもうちょっと違う形だったんじゃないの
今みたいにヘッダが肥大化しがちで各ソースごとに同じ解析しなきゃならないのは不自然ではある
IDEやコンパイラが賢いおかげでそこまでビルド時間酷くはならんようだけど

>>367
行列とかに関しては特に、C++のみで限界までチューニングしたってSIMD使ったコードにはまず勝てない(さらに言えばGPGPU使った方が、大きい行列ではもっと速い
それらを汎用化して使いやすくするのは可能だろうけど、そんなハード依存が激しいものを標準に入れるのか、それともハード依存は無いがめっちゃ半端なものを作るかの二択になるからでしょ

>>372
#define C A##B

>>375
具体的にどうしてるんだ？　と聞いてるんだが
答えたくないならいいよ

IDも知らんのかこいつは

日本語でおｋ

>>375
はい
そう申しております

>>379
375「俺は371じゃないから質問に答えろと言われても知らない」

横レスにしても頓珍漢すぎるだろ
今、横レスとして読み直したが俺にアンカー振られている意味がわからない

>>369に噛み付いてるんだから欠点じゃないと言いたいんだろ？
頓珍漢はお前だ(>>374でも相当おかしな事言ってるが

>>380
すまん直後の書き込み読んでなかった

>>383
また例のオウム返し野郎か
何がおかしいのか説明できないやつがハッタリかますんじゃねえ

>>365
俺の>361,364の一体どこをどう読めばそんな解釈ができるのか教えてくれよ
俺が否定してるのはこれ↓
>さらに実装は別ファイルにしてヘッダファイル内で#includeする
これは全然「テンプレートでない関数をプロトタイプと実装に分けただけ」じゃないよ
（藁人形論法ってやつか？これ）

ポインタはchar * const p = q; とでも書かないとpがconstにならないが
char& c = *q; と書いたらそんなリスクを回避できる
革命的前進

>>376
ﾊｱ？
#define C(A, B) A##B
にしないと駄目なんじゃ……

もっともK&Rの頃のCなら
#define C A/**/B
と書くことはできたっぽい

>>372のAとBを連結するなら>>373でいいだろ。括弧でくくった方がいいかもしれんが。
##は用途が違う。

実装も書いてあるヘッダファイルって src に置くの？ include に置くの？

boost のライブラリって、一度入ったら時代遅れになっても取り除かれないんですか？
それとも boost の全貌を把握してる委員会みたいのがあって、ちゃんと選別みたいなことをしてるんですか？

今どきムーブセマンティックに対応してないデカいコンテナクラスを見つけて、そういう疑問を持ちました

>>385
俺は
> 何か所にも同じのを書くのが嫌なら
> テンプレートでない関数をプロトタイプと実装に分けただけで難癖つけるのか？
と言ったんだ

二行目だけ切り取ってきて人のこと藁人形とは藁わせてくれるやつだな

>>385
純粋に気になるんだけど、例えば俺が>>366で書いたようにテンプレートの実体化が起きる前に関数、メンバ関数の実装を分けてインクルードすることは出来るけど
実体化が起きる翻訳単位では必ず実装が必要になるよね？(テンプレートの分離コンパイルは出来ないという問題から)

クラステンプレートのポインタや参照しか使わない翻訳単位では、例えばiosfwdみたいに前方宣言しか書いてないヘッダを使うことで、ビルド時間減らせるかもしれんけど

そういう意味ではクラステンプレートの定義書いてるヘッダで、メンバ関数の実装を書いたヘッダをインクルードするのは別におかしくはないと思うんだが

>>389
src に .hpp が置いてあるプロジェクト観たことあるけど
かっこ悪いと思った

include に置いてあるファイルに実装めっちゃ書いてあってももちろん嫌じゃないですか？

いやも何も、テンプレートは明示的実体化して使えるテンプレートパラメータを制限でもしない限り、ヘッダに実装するしかないんだよ
可読性の問題を気にしてるなら拡張子変えればいい
ヘッダだからって.hや.hppじゃなきゃいけないなんて決まりは無いしinclude(フォルダかグループか知らんけど)直下に置かなきゃいかんわけでもない
そのくらい自分で工夫しろ

.obj で分割するメリットって .exe が巨大化しないためってのもあるけど
テンプレ使うと各 .obj 全部に同じバイナリーが増殖しない？

多分だけど、今時の環境だと一度他の翻訳単位で実体化されたものは再利用するんじゃなかったかな

リンク前に判るの？
リンク時に同じ名前で同じ引数ならまとめるの？
怖くない？

lexical phase 9だな

>>391
論旨変わってないだろ、何が切り取りだか
で、お前のその変な疑問がどこから出たのか聞いてるんだけど

>>392
「そういう意味」がどういう意味なのかよくわからない
.hに宣言しか書いてないからコンパイル時間が減るんであって、
.hで定義をincludeしたら減らないよ？

>>400
テンプレートの話やろ？
翻訳単位のどこかに定義(実装)が必ず要るんだぞ
あるソース(翻訳単位)においては不完全型でいいんなら、そこで使うヘッダは前方宣言だけでいい(クラス定義は要らん)って書いたじゃん
クラス定義が要るんならそれは実体化を伴うんだからメンバ関数の実装ヘッダに書いてなきゃリンカエラー出るぞ

>>400
だから１行目を読め
読みたくないなら逃げるのはおまえさんの勝手だが
逃げた事実は消えないぞ

>>390
だめなboostライブラリというのは、そりゃ山ほどある
メンテナという概念は一応あろうが

>>398
YES実際恐ろしい
"a.cpp"に
class Foo { void some_method() const { return 3.0; } };

"b.cpp"に
class Foo { void some_method() const { return 4.5; } };
int main() { Foo x; printf("%f\n", x.some_method()); }

とか書いてリンクして実行したら3.0と表示されることがある
ビルド中に警告とかは無し（於VC++ 2010

というわけでクラス定義は極力ヘッダファイルに書くのが正しいい
二つのFooクラスの定義を同時にincludeしたら確実にビルドエラーになってﾜｶﾙ

どうしても.cppファイル側にクラスの定義を書くときは無名namespaceで囲うべきや
（名前付きnamespaceは名前の重複についてクラス定義ほど検査が厳しくないのであまり解決策にならない

今ｼﾞｯｹｿしたがVC++ 2019でも同じだぬ、
"a.cpp"
#include <stdio.h>
class Foo { public: double some_method() const { return 3.0; } };
double get_Foo() { Foo y; return y.some_method(); }

"b.cpp"
#include <stdio.h>
extern double get_Foo();
class Foo { public: double some_method() const { return 4.5; } };
int main() { printf("%f\n", get_Foo()); Foo x; printf("%f\n", x.some_method()); }

実行結果:
3.000000
3.000000

4.5どこ行った；；；

初歩的なことかもしれませんが質問させてください。
以下の3ファイルがあるとして、src.cpp をコンパイルしようとすると失敗します。
hoge の myclass に対する特殊化を file2.hpp でしてるだけだから OK だと思ったのですが、無理でした。
一方で、file1.hpp の中身を file2.hpp の下の方にコピペしたらコンパイルできます。
この、hoge の特殊化を file2.hpp でしてるという考え方はどう間違ってるのでしょうか。


// file1.hpp
template<class T> void hoge(T);
template<class T> void fuga(T x){
　hoge(x);
}

// file2.hpp
#include"file1.hpp"
#include"myclass.hpp"
template<class T, int N> void hoge(myclass<T, N> x){
　...
}

// src.cpp
#include"file2.hpp"
int main(){
　myclass<int, 10> x;
　fuga(x);
}

>>406
無理でしたとは？コンパイルエラー？エラーメッセージは？

それ多分特殊化じゃなくてオーバーロード？(違ってたらすまん
hogeの<T>を受け取る奴で実体化した後にmyclass受け取る奴が出てくることになる

myclass版の前方宣言をfile1.hpp(fugaより前)に書くか、fugaの実装をfile2.hppのインクルードより後にすればいける、と思う

>>406
それは >>408 が指摘する通りオーバーロードになってる。
オーバーロードの解決方法は複雑なんで私もちょっと自信はないんだけど、
オーバーロードの候補の内で実引数の型と完全に同一 (または実引数の型に cv 修飾したもの) のものがあれば、
それの優先度はテンプレート引数のマッチより高いので曖昧さは生じずに解決できるのが正しい。

そんで >>408 がいう

> hogeの<T>を受け取る奴で実体化した後にmyclass受け取る奴が出てくることになる

というのはたぶん関係ないと思う。
Two phase name lookup のルールが適用されるはずだから fuga 内での hoge の呼出しは
その時点では解決を試みられず、 main 内での fuga の呼出しが有った時に
fuga の実体化が起こってそのときに hoge も実体化されるので
宣言の順序にかかわらずどちらの hoge も候補になるはず。

なので include がどうこうというのとは関係なく
file2.hpp のほうの hoge が問題なく呼び出されるべきで、 >>406 に間違いはないと思う。

手元に入れてないから動作確認できないんだけど古い MSVC は Two phase lookup の実装が
おかしかったとか聞くからそのへんで何か問題が起こってるんじゃないか？
GCC や Clang だとかなり古いバージョンでも特に問題なくコンパイルできてる。

>>405
リンクする順番変えたら 4.5 になったり 3.0 になったりするかもしれないししないかもしれない

>>396
古典的なツールチェインでは同一のものがそれぞれの翻訳単位に作られる。
その上でリンク時に同じものは同じに統合される。

それが嫌だという場合にはテンプレートには明示的実体化という仕組みがあって、
暗黙的な実体化を抑制する仕組み (extern template) とセットで使うことで
テンプレートの実体をひとつの翻訳単位にまとめることは出来る。

当然だが個別に指定するのはめんどいし、
いまどきの処理系は賢いので、あまり使われてないと思う。

>>406,>>408
うろ覚えだったのでスマンコ
というか自分がその手の順序依存を経験したのはVC2008-2015あたりまでだった気がする
最近のだとC++標準への準拠の設定(コンパイルオプション/Zc:twoPhaseとか)も影響するはず

間違えた、>>406,>>409
2017あたりまで標準への準拠のオプション(名前不明)は指定しないと有効にならなかった気がする、2019では既定

/permissive-
やった(VS2017
2015以前なら>>408のような対策するしかないと思う

>>407
失礼しました
短縮して書くと
undefined reference to 'void hoge<myclass<int, 10>>(myclass<int, 10>)'
というメッセージが出ます

コンパイラは g++ 11.1.0 です


用語の使い方が正しいか自信がありませんが、
file1.hpp 内で hoge の宣言と hoge を呼ぶためのユーティリティ関数 fuga の実装をしておいて、後から必要に応じて具体的な型について hoge の実装を書ける、という方がすわりが良いのですが、こういう考え方は間違っていますか
fuga は型によらず hoge を呼ぶための関数なのでその実装を後に回したくない、という思いもあります

C言語の double _Complex と C++ の std::complex<double> って実部虚部の並び方とか一緒ですよね？
ヘッダファイル aaa.h で宣言されてる double _Complex * をとる関数に std::complex<double> * を渡したいのですが、やり方がわかりません。


#define 〇〇 std::complex<double>
#include<aaa.h>
みたいにできると想像してるのですが、合っているでしょうか？

>>416
_Complexはただのdouble型変数なのでstd::complex<double>と互換性なし

>>417
メモリレイアウトから違うのですか？
では、double _Complex * をとる関数に std::complex<double> * を渡すことはできないということですか？

はい

エ！？
_Complex って std::complex の後にできたんじゃありませんでしたか
なぜ、実部と虚部がメモリ上に連続で置かれているという設計にしなかったのでしょうか……

作りが似ている、ということと
互換性が保証されている、ということは同じじゃないぞ

保証があるか否かは規格票で確認することで主観が入る余地はない
俺が見た範囲では保証するとは書いてなかった

_Comolex変数の実部と虚部をそれぞれcreal(), cimag()で取得してstd::complex<double>変数にセットするしかない

_ComplexがC99でstd::complex<T>がC++03

>>415
>>406に嘘書いてないか？

std::complex<double> *hoge;
double _Complex *p = (double _Complex *)&hoge[0];

>>424
すみません
どこか矛盾しますでしょうか
手元でコンパイルしてみて、そうなりました

>>408は試してみた？

>>427
はい
>>408様の仰る「fuga の実装を後に書く」というのが、>>406に書いた「下の方にコピペしたら」というのです
そして、それらのことを踏まえて、>>415に書いたような疑問を持ちました

ところで嘘というのはどういうものでしょうか
なにか矛盾しますでしょうか

hogeの実装(関数の中身)を実際は書いてなかったとか、何か事実と違うことがあるんじゃないかと思った
だけ

>>415に書いてある理由なら、同じコンパイラであればどこか妥協するしかない気が
fugaの前方宣言だけはfile1に残して、実装を別のヘッダにして後からインクルードするとかは？(>>408で言ったのはそういうことなんだけど

>>421-422
今調べたら、C側は実部虚部というメモリレイアウトを保証していて、std::complex 側は C の複素数と同じメモリレイアウトを保証してるようですね

>>423
すみませんCの方が早かったんですね

>>425
ありがとうございます
暗黙のキャストがなぜ許されないのかはまだよく分かっていませんが、キャスト自体は可能なようで、double _Complex (あるいはそのポインタ) をとる C 言語関数に std::complex<double> (あるいはそのポインタ) を適切にキャストして渡すのは問題ないようになってると理解しました

>>430
その件について
ISO/IEC 9899でC++という文言に言及するか
ISO/IEC 14882でCという文言に言及しているか？
430に書かれている限りでは「似ている」だけだが

それからC++03は2003年にC++98のバグ修正をしただけだから
C99より古いぞ

良スレ気体age

>>431
いや、すみません。逆に「似ている」とはどういう意味でしょうか

例えば std::complex については
http://eel.is/c++draft/complex.numbers
の記述からしてメモリレイアウトは実部虚部と決まってるわけですが、これはソースとは見なせないんでしたっけ？

>>431
> それからC++03は2003年にC++98のバグ修正をしただけだから
> C99より古いぞ
ですから、
>>430
> Cの方が早かった
のでは？


あと>>433は「std::complex は C の複素数型と同じことを保証する」という記述は含みませんね
ただ、この場合メモリレイアウトが同じであることの他に要請するべきことってありますっけ？

>>431,434
> ですから、
> >>430
> > Cの方が早かった
> のでは？

すみません
間違えました
ごっちゃになってました
これは取り消します

https://stackoverflow.com/questions/55563217/do-complex-types-in-c99-behave-like-stdcomplex-in-c
ここを読むとメモリレイアウトは同一みたいなんだよね。むりやりキャストしても問題なさそうな気がするけど

本質的なデータはdouble2つ組だし、順序も普通は実部→虚部だろうし、わざわざパディングや別の変なメンバ混ぜることも考えにくいし
たまたまレイアウト一致する可能性は現実的に高いだろうけど
規格が保証してるかどうかはまた別の話かな

もう C は C89 で止めれ
C++ は　C89 だけ受け付け可能であれば、あとは好きに変えてもらってもかまわない

C/C++の複素数の構造体・クラス間の変換関数を規格として用意してもらうしかない

インテルコンパイラの最適化オプションO2とO3で計算結果が変わって、問題を起こしている箇所を見つけようと思ってるんですが、
$ icpc -O3 src.cpp -lhoge
とコンパイルしてる場合、当然 src.cpp に問題があるのであって別でビルドされたライブラリ hoge は無関係と思って良いですよね？

ゲェーッ -O3 はダメだけど -fast は期待通りに動きました
あまりにも意味不明なのでこれに手を出すのはやめておきます
失礼しました

やべー未定義動作踏んでそう

あるよなぁ。
FortifyやCodeSonarといった静的解析ツールで検出できたらいいが、どこまでできるんだろう。

複素数とか高々数値メンバが2つとかそれぐらいの話なのに
なんでビットコピーできないと発狂するのかｲﾐﾌ

備え付けの手段で実数部と虚数部毎に代入するとか
構築とかしたらええんじゃ

>>437
>>436によるとサイズも並びも一致することを規格が暗に示してるようなんだ。1つ目の回答を見てくれ

まだ「暗に」とか言ってんのこのキチガイ
コイツのせいで不必要に大事になった感はあるよね

>>446
お前のコードで誰にも迷惑かからないなら、もう規格云々はいいから自分の思い込みたいように好きにやれば良いよ

T* をとるオーバーロードコンストラクタに const T* x を渡したら、argument do not much だからとエラーになりました。
が、(T*)x を渡したらOKでした。
(T*)をつけてようがつけてなかろうが、x というポインタの const 性は変わりませんよね？
（つまり x を変える挙動があったらプログラムは終了しますよね？）
なぜ引数の型のマッチには (T*) が必要なのでしょうか。

できればキャストしたくないので、こうすれば避けれるとかこう思えば安全というのがあったら教えていただきたいです

>>449
const性変わるんじゃない？

const T* xなんだから xはの先にある*xは変えてはいけないという指示をコードかいた人は出していて
そのT*をとるコンストラクタはその中で変更する可能性を言ってるんだから
T*にキャストして渡したらコンストラクタの中で変更され可能性が出るよ

>>449
ああ、だから>なぜ引数の型のマッチには (T*) が必要なのでしょうか。
というと
本来ならconst指定されてて変更してはいけない変数を、変更するけどいいのね？というコンパイラからの確認的なもの

>>450
> const性変わるんじゃない？
ありがとうございます。
誤解してました。
（というか、そこ変えれるなら何でもありな気が……）


>>451
実は、他人の作ったライブラリとの橋渡しでこういう問題が出ました。
知る限りではそのライブラリは引数のポインタの指してる先を変えないのですが、どうやらキャストはするしかないようですね。
この件で (T*) とは別に const_cast<T*> なるやり方の存在も知って、Cスタイルのキャストよりはこちらの方が良いという説明がいろんなところでされてるのですが、正直全く同じものに見えます。
なぜ const_cast の方がマシなのでしょうか？

うん、マシだね
特にその問題では

>>452
Cスタイルキャストは状況に応じてよしなにキャストしてくれるんだが
これがたまに意図しないキャストになる場合があるから、意味を明確にするためにC++のなんちゃらキャストをする
よほどのことがないと変なキャストにはならないとは思うけど一応

const_castはint*→char*のように指す先の型は変更できない
だから、そのような変更をしようとしたらエラーになるし
そのような変更を意図していないことも示せる

>>452
誤解してるようだけど、constってのは基本的にはバグ抑止のためのもので
文法上のルールに過ぎないのよ
実行時にチェックが走ったりするわけではない
で、意図的に破ることも一応出来る。意図的に破るときはそれが見てわかるようにconst_cast使おうね、
Cスタイルのキャストは何でも通しちゃうから避けようねってだけ

>>454-455
なるほど。ありがとうございます
今は const_cast で渡すことにします

>>441
この件諦めきれなくて少し調べてみたら、
-O3 はダメだが
-O3 -static -ipo は正常に動く
ことが分かった
更に、icpcでなくg++なら最適化レベルによらず正常に動くことが分かった

この場合陥っていがちな失敗なんてないですかね
ググってもなかなか体系的な知識に出会えなくて、、、

諦め切れないくらい気になるなら -S で .asm コード見るべき

こんなところでC++が中途半端に出来るだけが自慢の専門卒みたいな連中に尋ねるよりも
大学の先生かチューターの院生に尋ねた方がいいだろう
進みたい研究室があればそこに行って訊くと良い

>>458
たぶん初期化漏れとかの未定義動作
-Wallでコンパイルすれば何かわかるんじゃね

>>459-461
すんませんあざす
asmコードとか未知の領域ですけど勉強になりそうですね

-Wallは一応常につけてて、ワーニング全部潰すようにはしてます
全部のオブジェクトにvolatile付けたり外したりしてみようかな

適当に弄って適当に動いたように観えて
適当に解決したって言い張るやつは成長しない

短かったり切り出せるようなコードだったらcompiler explorerとかもあるよ

const ではないオブジェクトについて const 付きにキャストしている場合には
const を剥がしてから書き込みをすることは OK だが、
元々 const なオブジェクトから const を剥がして書き込むのは未定義で、
実際に最適化で壊れることはある。
ちなみに const なオブジェクトから const を剥がしても読むのみなら OK。

LLVM 9.0 で const 領域への書き込みを最適化で削除するする方針になってる。
https://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#noteworthy-optimizations

>>460
院生ねえ。。。修士の新人は手放しできないんだけどな
レッテルで色眼鏡つかう奴って
情報処理特種とかでもひれ伏すのか？
学生みたいなコード書くアホ知ってるけどｗ

インテルコンパイラ様ともなれば
プラグマで関数単位で最適化レベルを変えられるんじゃないの
動くパティーンが分かっているのなら二分探索で問題の箇所を見つけるこ
とができうる

C++の参照で渡した構造体を
中で別の構造体に実態コピーしたい時ってどうしたらいいんでしょう

void CTest::SetData(Kouzoutai &kozo)
{
if(kozo.judge == 1){
_KozoTmp = kozo;
}else{
//色々する
}
}

とすると、_KozoTmpってkozoと同じアドレスになっちゃって、
_KozoTmp.judge = 10とかしちゃうともとのkozo.judgeも変わっちゃいますよね
ポインタだったら
_KozoTmp = *kozo;
とかやればいいんでしょうけど
参照で渡した時ってどう書けばいいんでしょう

それで普通にコピーされるだろ
なんでされないと思うの？

参照にした時って、ポインタみたいにアドレスコピーにならないの?

あのさ、_KozoTmpは何だ？Kouzoutai型だろ？Kouzoutai*でもKouzoutai&でもないだろ？
なんでアドレスなんか持てると思うの？

あ、そうなんだ
ありがとうございます
kozoを参照で渡したから
_KotoTmpも無理矢理アドレスになるかと思ってました

>>468
参照というのはいうなれば別名。
SetData の実引数と kozo は「同じもの」と考えて構わない。 (少なくともその場合は)

copy コンストラクタ と move コンストラクタ ってみんなちゃんと書いてる？
デフォにまかせてる？

ものによる
ポインタやハンドルがあれば書いたり=delete;したり
実体だけなら大抵デフォ

=defaultが多い

コピーコンストラクタがあったらムーブ自動生成されないんでしょ？

俺、タイプ量の少なさは美しさの１つだと思ってるから
=default;は本当に必要なときだけ書く

doxygenでドキュメント作成してるけどソースが見づらくてコメント無い方がいいのではと思ってしまう