C++相談室 part155

**デフォルトの名無しさん** · 2021/03/24(水) 12:07:15.39

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

テンプレここまで

**デフォルトの名無しさん** · 2021/05/01(土) 16:37:35.74

>>604
厳密に言えばリンカは関数名しか見ない。
C++はオーバーロードのためにシグネチャの違いを関数名に埋め込むマングリングを行う。

**デフォルトの名無しさん** · 2021/05/01(土) 17:09:26.40

>>602
C++で関数呼び出しを書いた場合、どの関数が呼び出されるかは
Best Matching Algorithm で選ばれているので実引数が charの場合は、
同じ場所の仮引数がcharである関数を優先的に選ぼうとする。
もし、同じ場所の仮引数がcharであるものが見つからなければ、
同じ場所の仮引数が int であるものを探して、見つかればそれを選択する。
このとき、実引数と仮引数の型の「距離」のような概念があり、
距離が近いものが選ばれる。複数の引数が有る場合で、二つの引数で
距離が近い関数がどっちもどっちになる場合には、「曖昧」であると、
され、エラーになる。

>その場合、受け取ったのがintかcharかプログラムはどうやって見分けるのですか？
ここであなたの言っている「見分ける」という意味が分かりにくいが、
オーバーロードされた関数は、C++レベルでは同じ名前に見えていてもが
アセンブラレベルでは別の関数名になっていて、別の関数として扱われていて、
別の関数が呼び出されているから「見分ける」以前問題になっている。

◆QZaw55cn4c · 2021/05/01(土) 17:16:10.99

>>591
コピコン以外は使わないです‥‥

**デフォルトの名無しさん** · 2021/05/01(土) 17:24:45.49

>>606
「リンカは関数名しか見ない」はおかしい。
リンカが見るのは、関数名を含むシグネチャをマングリングした結果のシンボル名。

**デフォルトの名無しさん** · 2021/05/01(土) 17:29:02.27

>>605
それは、実際そうだと思う。
char idx = xxx;
func( 'a' + idx );
と書いた場合、func(int)とfunc(char)のどちらが呼び出されるのかを
事前に予想するのは非常に難しい。
なぜなら、伝統的にCでは、char + char は、それぞれが int に昇格
されてから、int + int になって、結果も int になるとされていたから。

**デフォルトの名無しさん** · 2021/05/01(土) 18:00:18.46

ファイル出力で、1バイト出力と4バイト出力の違いは、単に人間が見るための
stdout出力とは訳が違って、後からファイルを入力する時にその部分のバイト数の違い
が大きな意味を持つので、オーバーロードの仕組みだけでコンパイラに自動振り分け
させるのは、分かりにくいバグを入れてしまう可能性がある。
なので、やはり、出力するのは1バイトなのか4バイトなのかを、明確に関数名で
区別できるようにした方が望ましいと思われる。

**デフォルトの名無しさん** · 2021/05/01(土) 18:45:41.91

>>609
そのマングリングした名前で関数を呼び出すことができるわけだし、関数名以外の何物でもないと思うが。
そもそもリンカはマングリングされているのかされていないのかも関知しないし。

**デフォルトの名無しさん** · 2021/05/01(土) 18:55:40.94

> 589 名前：デフォルトの名無しさん[sage] 投稿日：2021/05/01(土) 09:28:33.15 ID:18idEqJd [1/2]
> コピコン
> たまに見る
> 頭悪そう

>>595に何も言えねえ
頭悪そうｗ

**デフォルトの名無しさん** · 2021/05/01(土) 19:59:37.32

マングリング、ってなんかイヤらしいよね

**デフォルトの名無しさん** · 2021/05/01(土) 20:50:21.52

>>612
?h@@YAXH@Z みたいなのを関数名って言うのは違和感しかないわ

> そもそもリンカはマングリングされているのかされていないのかも関知しないし。
それを言うならリンカは関数かどうかすら関知してない

**デフォルトの名無しさん** · 2021/05/01(土) 21:00:22.23

>>612
むちゃくちゃだなぁ。わざわざ用語をごっちゃにして何がうれしいの？
シンボルが関数を指すのか変数その他を指すのかもリンカは関知しないんじゃないの？
たとえば ld のマニュアルに function name なんて一度も出てこないし。
https://linux.die.net/man/1/ld
> ld combines a number of object and archive files, relocates their data and ties up symbol references. ...

**デフォルトの名無しさん** · 2021/05/01(土) 21:25:44.91

私は「関数名」派
C++のコンパイラは元々はC++からCに翻訳してたわけだし

**デフォルトの名無しさん** · 2021/05/01(土) 21:27:05.03

まあどっちでもいいけど

**デフォルトの名無しさん** · 2021/05/02(日) 00:16:29.81

>>616
だなあ。
C++のコードにおいて、関数名と呼ぶ場合、それはマングリング込みとかのシグネチャではなく
あくまでもソースコード上にある関数の名前だからなあ。

>>618
これはあんまりどっちでも良くない。
つか、>>612の言い分を認めるとオーバーロード/オーバーライドってもんがなんだか分からなくなるｗ
同じ関数名で関数の実装を選べるってのがオーバーロード/オーバーライドだから。

**デフォルトの名無しさん** · 2021/05/02(日) 01:13:49.22

オーバーライドの意味も知らない子は無理して回答しなくていいよ

**デフォルトの名無しさん** · 2021/05/02(日) 01:21:37.53

C++初心者はクラス継承の学習にこだわりテンプレートの学習が後回しになるので、テンプレートが最適解になることが多いと悟るのが遅くなる

**デフォルトの名無しさん** · 2021/05/02(日) 01:23:19.71

オーバルライトは新しいからね。

**デフォルトの名無しさん** · 2021/05/02(日) 01:39:37.43

>>619
Cに翻訳された段階だと変数名まで含んだ名前が関数名
当然リンカの段階ではC++の関数名は残って無い
C++以外のドメインでどれが関数名かを議論すること自体意味がない

**デフォルトの名無しさん** · 2021/05/02(日) 01:40:39.79

>>610
されていたって...
今もそうだよ

**デフォルトの名無しさん** · 2021/05/02(日) 06:37:18.08

>>619
overrideキーワードは派生クラスで仮想関数を上書きするときに使う
overloadキーワードはcfront 1.0世代のC++で関数を多重定義する予告として使われていた

**デフォルトの名無しさん** · 2021/05/02(日) 08:57:49.73

基底クラスBで定義された int foo(double x) が派生クラスD1、D2でオーバーライドされた場合、
同じ「foo」という関数名に対して
　Bのクラス名が入ったマングルされたシンボル _$F_B__foo_INT_1_DBL
　D1のクラス名が入ったマングルされたシンボル _$F_D1_foo_INT_1_DBL
　D2のクラス名が入ったマングルされたシンボル _$F_D2__foo_INT_1_DBL
みたいな3種類のシンボルがリンカに渡されることになり（マングリング規則は適当
、{ オーバーライドされた関数名 }と{ オーバーライドされたシンボル }の
1対1対応は崩れるのだから
　関数名≠関数のシンボル
を示す例としてオーバーライドはオーバーロードと同じく妥当であることは変わりが無い

、と思うが知らん

**デフォルトの名無しさん** · 2021/05/02(日) 09:20:39.13

>>621
継承とテンプレートが対立するかのように考えてる時点で
テンプレートどころかクラスや継承もまともに理解できてないやつの発言にしか見えない

**デフォルトの名無しさん** · 2021/05/02(日) 10:53:26.72

>>626
丁寧な御説明ありがとう。
それで正しいですよ。

**デフォルトの名無しさん** · 2021/05/02(日) 12:10:24.45

このクソ議論見ても関数オーバーロードの仕様は失敗してるってのがよくわかる。

**デフォルトの名無しさん** · 2021/05/02(日) 12:12:19.26

…などと意味不明の供述をしており、

**デフォルトの名無しさん** · 2021/05/02(日) 12:47:09.45

悪い子: この仕様はクソだ！
普通の子: この仕様は〇〇だから良くないね
良い子: この仕様は〇〇だから良くないね、△△とすれば良いのに

**デフォルトの名無しさん** · 2021/05/02(日) 13:06:19.55

>>626
それは単に別のクラスで同じ名前のメンバ関数はシンボルが違うってだけの話だろ
オーバーライドは全く関係ない
そもそもオーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない
オーバーロードと並べて語る意味が全くわからない

**デフォルトの名無しさん** · 2021/05/02(日) 13:16:03.71

ダンバインよりビルバインのほうが好き

**デフォルトの名無しさん** · 2021/05/02(日) 13:18:20.36

（話に付いてこれてない香具師が居るな

**デフォルトの名無しさん** · 2021/05/02(日) 13:20:32.85

>そもそもオーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない
では聞くがvtblに乗っける関数へのポインタのアドレスは誰が最終的に決めるんじゃ

ちな1つのクラスのメソッドの定義が必ずしも同一の翻訳単位内とは限らないから、
相対インデックス指定の出番は無い＝コンパイル時解決は不可能

**デフォルトの名無しさん** · 2021/05/02(日) 13:26:01.49

＞では聞くがvtblに乗っける関数へのポインタのアドレスは誰が最終的に決めるんじゃ
実行時に実行バイナリが決めるに決まってるだろ
リンカがリンク時に静的に決めるとでも思ってるの？すげえなそのリンカ

**デフォルトの名無しさん** · 2021/05/02(日) 13:27:21.13

>>633
それはオーラロード

**デフォルトの名無しさん** · 2021/05/02(日) 13:46:56.51

よく知らんけど、多くの場合vtblを作るのはコンパイル時であって、リンク時でも実行時でもないのでは？

**デフォルトの名無しさん** · 2021/05/02(日) 13:50:36.00

>>635
vtbl内のアドレスを最終的に決めるのはリンカなんだろうけど、それは
「オーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない」と両立するので
反論ぽく挙げてる意味がわからない。

**デフォルトの名無しさん** · 2021/05/02(日) 13:51:49.77

ビルバインはもっと禍々しいデザインになる予定だったが、競合アニメだったマクロス・シリーズの影響で変形ギミックが追加され色も派手になった

**デフォルトの名無しさん** · 2021/05/02(日) 13:53:08.50

>>637
分かってくれてありがとうw

**デフォルトの名無しさん** · 2021/05/02(日) 13:53:56.96

おまいら中身のある会話しろよ
ひまなの？

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/02(日) 15:30:38.46

せやで。

**デフォルトの名無しさん** · 2021/05/02(日) 18:29:19.65

>>627
実際にプログラムを改修したりする場面では継承とテンプレートどちらでやるか
悩むってのはよくある話。
テンプレートだと元のクラスをいじらなくちゃならないからためらいがち。
その点継承だと元のコードいじらなくて(あるいは最小限の修正で)済むからな。
継承してテンプレートってのもなしじゃないがｗ継承するくらいなら、テンプレートまで
やんないｗ

**デフォルトの名無しさん** · 2021/05/02(日) 18:44:15.42

継承とテンプレートって全然違うけど
悩む場面が想定出来ない

**デフォルトの名無しさん** · 2021/05/02(日) 19:07:17.74

もう継承はしなければしないだけ偉いっていう気持ちになって久しい
つーかOOPに飽きてるというか見限ってる
C++を使ってるのは単に自由度が高くてパフォーマンスが良いから

**デフォルトの名無しさん** · 2021/05/02(日) 19:55:42.70

OOPに飽きてる俺すげー

ってかw

**デフォルトの名無しさん** · 2021/05/02(日) 20:02:15.30

普段どの程度の規模のどういうコード書いててその結論に至ったかで評価が変わるな

**デフォルトの名無しさん** · 2021/05/02(日) 20:06:12.37

>>644
改修にテンプレートがどう役立つのか想像つきにくいけど
そのコードが前提としてる特定の型以外でも受け入れられるようにするとか？
(それで継承とテンプレートどっちが優れてるという話にはならない気がするが

**デフォルトの名無しさん** · 2021/05/02(日) 22:27:50.57

>>649
> そのコードが前提としてる特定の型以外でも受け入れられるようにするとか？
まあ、一番単純なパターンだとそれだね。

まあ、自分は>>621ではないので、
> (それで継承とテンプレートどっちが優れてるという話にはならない気がするが
その真意はわからんけど、自分の経験でも対処療法的に継承でやっつけちゃうより
やっぱりテンプレート化しときゃ良かった、と思ったときは多々あったｗ
(「神は細部に宿る」んだわ、ほんとｗ)

**デフォルトの名無しさん** · 2021/05/02(日) 22:42:08.00

低レイヤーコードの置き換えを前提にモデル化できるってのがオブジェクト指向の一つの売りだが
まああんまりそこの置き換えってしないわけだわな。
言うほど有効な場面は多くないってのはそれはそう。
素直に関数かけやって場面のが圧倒的に多い。

**デフォルトの名無しさん** · 2021/05/03(月) 03:06:36.21

>>651
オブジェクト指向や継承の概念を使いまくっても、メンバ関数の形で
関数は書きまくるよ。

**デフォルトの名無しさん** · 2021/05/03(月) 03:09:53.91

>>651
>低レイヤーコードの置き換えを前提にモデル化できるってのがオブジェクト指向の一つの売りだが
>まああんまりそこの置き換えってしないわけだわな。
>言うほど有効な場面は多くないってのはそれはそう。
めちゃくちゃ低レイヤーな部分の書き換えは余り起こらないけれど、
クラスは階層的に継承して行くから、中間的な部分は結構修正が入る。
また、やはり仮想関数(ポリモーフィズム)の作法は便利。

**デフォルトの名無しさん** · 2021/05/03(月) 03:15:32.93

>>653
というか、基本クラスの Animal 的なクラスの修正はそんなに頻繁には入らなくて、
Dog, Cat, Lion, Bird, Fish みたいな部分の修正がプログラミングの主戦場になる。
例えばゲーム作りの場合、Animalクラスの中にwalk(), eat(), battle(), sleep(),
jump(), set_velocity(), set_position() などを仮想関数で用意しておいて、
Animalを継承したDog, Cat, Lion, Bird, fishみたいなクラスがそれぞれ
どのように歩いて、どのように食べて、どのように戦って、どのように寝て、
どのようにジャンプするかをプログラムするというのはとても便利。
クラスや継承、仮想関数の概念が無ければその様に便利にプログラムする
ことは簡単にはいかない。

**デフォルトの名無しさん** · 2021/05/03(月) 03:37:22.90

シンプルにポリモをやるための継承はいいんだけど
それ以外をやるための道具として流用し始めると途端におかしくなるって経験上思ってる

**デフォルトの名無しさん** · 2021/05/03(月) 06:47:59.32

>>654
そういうゲームみたいなシチュエーションがそんなにあるわけじゃないって話だよ。
よっぽどプログラマ間で共有できる抽象概念がない限り逆にわかりにくくなることのが多い。

**デフォルトの名無しさん** · 2021/05/03(月) 06:56:42.03

派生関係がなくても関数名を一致(つまりオーバーロード)させるだけで動いてくれるテンプレートのほうが楽なことが多い。
実際、最近C++に追加されている機能は大部分が派生関係のないテンプレートクラス。
一方、派生して使うiostream系クラスは機能追加される気配がまるでない。

**デフォルトの名無しさん** · 2021/05/03(月) 09:29:12.51

というか、単に間違ったクラス化や間違った継承してた奴が多かったんじゃないの

>>657
クラステンプレートでも結構継承使ってるぞ

**デフォルトの名無しさん** · 2021/05/03(月) 10:18:11.42

皆様おはようございます
ちょっと質問させてください

テンプレートクラスを宣言定義する時に、ヘッダーに定義を書かないとエラーを吐いてしまいます
テンプレートクラスのヘッダーファイルを、他のヘッダーファイルにインクルードして使う場合、なるべくテンプレートクラスのヘッダーに必要なファイルをインクルードをしたくないので、テンプレートクラスをヘッダーソースに分けて記述できれば嬉しいのですが……

//テンプレートのヘッダー
template<class T>
class Hoge{
public:
Hoge();
};
//テンプレートのソース
template<class T>
Hoge<class T>::Hoge(){
cout<<“hego !”<<endl;
}

//テンプレートを使うクラス(別なヘッダーファイル)
class UseHoge{
public:
UseHoge(){
Hoge hoge;
}
};

これをメインで記述すると未解決の外部エラーになってしまいます
テンプレートをUseHogeのヘッダーソースに分けて記述すればエラーは出ないのですが出来るなら独立させたいです……
何かいい方法がありますでしょうか？

**デフォルトの名無しさん** · 2021/05/03(月) 10:27:08.26

Hogeを使う型で具体化する話？

**デフォルトの名無しさん** · 2021/05/03(月) 10:32:39.67

基本的にテンプレートの実装をソースに書くことは出来ないよ
与える型を決め打ち(明示的実体化)すれば出来るけど、当然汎用性は大幅に下がる

**デフォルトの名無しさん** · 2021/05/03(月) 11:41:17.40

Hogeをvectorやunique_ptrの様に、インクルードすればどこでも使えるようなテンプレートクラスにしたいのですが、そういう場合はHogeの定義もヘッダーに記述して、そのヘッダーを適宜インクルードするような形になるんでしょうか？

**デフォルトの名無しさん** · 2021/05/03(月) 11:46:53.45

それを出来るようにするためのexportという機能が昔の標準規格に定義されてたんだが
難しすぎてほとんどのコンパイラが実装できなかったので消えた

**デフォルトの名無しさん** · 2021/05/03(月) 11:56:42.04

>>662
vectorやunique_ptrも全部ヘッダに実装書いてるんだよ
見た目の問題だけなら、宣言と実装を分けることはできるけど(実装もヘッダのどこかに書けば

**デフォルトの名無しさん** · 2021/05/03(月) 11:59:02.11

>>663
ありがとうございます
難しい感じなんですね

インクルードでコンパイル時間が余分にかかるかも……と思っていたのですがそれが一番近い方法なのでしょうね
コンパイル時点でTの大きさがわからないから明治化しない限りはリンカ？でのエラーになるのでしょうか？

**デフォルトの名無しさん** · 2021/05/03(月) 12:02:09.68

>>664
すれ違いになりました
ありがとうございます
ベクター等もそうなっているんですね
一度覗いてみたときにマクロの大文字が並んでて頭痛がして以来じっくりみたことが無かったので……(大汗)

**デフォルトの名無しさん** · 2021/05/03(月) 13:46:09.28

>>656
ただ、MFCを見ても分かるように、例えば、左ボタンをクリックした時には、
が OnLButtonDown()というメンバー関数が呼び出される様になっていて、
それは、CWndで基礎が定義されていて、CWndを継承したクラスも同じ関数名で
同じイベントを処理する様になっている。
これを純粋なCだけで書くのは分かりにくいだろう。

**デフォルトの名無しさん** · 2021/05/03(月) 14:09:33.89

>>667
ちなみに、MFCはちょっと複雑になっていて、C++本来のポリモーフィズムは、
設計上は virtual 属性をつけた仮想関数で実装するようになっているのだが、
CWnd::OnLButtonDown()CWnd::OnChar()やCWnd::OnKeyDown()などに
関しては、非仮想関数で実装されていて、メッセージマップなる独自の仕組みで
MFCのフレームワークが独自に継承クラスのものを呼び出すような仕組みに
なっていて、「Message Routing」などと呼ばれている。
MFCでC++本来の仮想関数で実装されているものとしては、CWnd::PreTranslateMessage()
がある。

なお、C++を使っていて便利なところは、
void CMyWnd::OnLButtonDown()
{
　if (条件) {　　
　　(処理);　// CMyWnd の独自の処理
　}
　else {
　　CWnd::OnLButtonDown();　// 継承する前のデフォルトの処理
　}
}
のように、条件によって継承する前のデフォルトの処理も分かり易く呼び出せるところ。
これをplain な Cで統一した書き方で分かり易く書くのは不可能。

**デフォルトの名無しさん** · 2021/05/03(月) 14:22:00.89

WTLって知ってる？
MFCとほぼ同じ機能を派生クラスではなくテンプレートクラスで実現しているんだが、ソースが綺麗

**デフォルトの名無しさん** · 2021/05/03(月) 14:28:53.28

何言ってんだWTLも継承使ってるしユーザーもWTLから継承するだろうがアホか
典型的なポリモーフィズムではないけど、それがそのままデメリットにもなってる(ウインドウのインスタンス管理をまとめられない

**デフォルトの名無しさん** · 2021/05/03(月) 14:39:14.18

継承といっても1世代だけじゃん
多重継承も使ってるから感じにくいけど

**デフォルトの名無しさん** · 2021/05/03(月) 15:08:41.96

本気で言ってんのか？

**デフォルトの名無しさん** · 2021/05/03(月) 15:17:14.89

テンプレートは実体化された時に存在の有無を判定されるので、最低限のオーバーロードで済ませる

**はちみつ餃子** ◆8X2XSCHEME · 2021/05/03(月) 16:27:31.54

そういえばどこかの超人プログラマ集団がいる組織では必要になったら設計を気にせずどんどん
機能を増やしていって、どうにもならなくなったらさっさと捨てて作り直す文化があるというのを聞いたことが有る。
剛腕があれば綺麗な設計なんて必要がないし、無能ならば綺麗な設計は出来ない。

つまり大体の場合にあんまり綺麗な設計にならないってことになる。
それでもなんとかするしか仕方ない。

**デフォルトの名無しさん** · 2021/05/03(月) 17:27:36.73

>>674
完全に捨てるというのは、多分、大きなプロジェクトでは無理で
リファクタリングするんだと思われるが、その際に基本クラスの
設計や継承の仕方が変わる、ということなんだと思われる。
例えば Windowsエミュレータの Wineや、clangのソースなどを
いくらソースが汚くなったからといって完全に書き換えるというのは
どんなに超人豪腕プログラマ集団でも効率が良い方法とは
思えない。なぜなら、例えばWineのソースは150MB位あるから。

**デフォルトの名無しさん** · 2021/05/03(月) 17:32:03.66

>>674
アジャイル開発の説明によれば、ソースがきれいかどうかについては、
そのコードに機能追加や改良を続けられているのであれば、それで良し、
と考えるとあった。本当に問題が有るのは改良を続けられなくなってきた
時で、その時はその時で、リファクタリングしてソースを整理すると良いと。
常に綺麗にし続けるというのは努力はしても良いが、基本的には不可能に
近くて、むしろ、ソースを綺麗にすることが目的になってしまっては、
無駄に時間が掛かりすぎてかえって時間のロスになってしまうことがあるから。

**デフォルトの名無しさん** · 2021/05/03(月) 18:09:40.04

ソースコードからひたすらcall treeを書きまくって独立した関数やクラスに切り分けていって
依存関係を整理していく仕事が今日もまたはじまるお、

**デフォルトの名無しさん** · 2021/05/03(月) 19:25:57.69

>>674
将来の破棄を前提とするなら、そのための準備が必要でしょうな。エージェントとかを使ってモジュール間の結合度を落とすとか、モジュール間で公開するIFを限定的にしてモジュール単体を捨てやすくするとか。
そのへんの話題はなかったのかしらん？

**デフォルトの名無しさん** · 2021/05/04(火) 12:15:45.91

>>675
でも、そのポリシーは「完全に捨てる」ことを
しないと機能しないよ。
結局、前に書いてある「あの関数」とか「例のクラス」とかが
縛ってしまうからね。
リファクタリングするだけじゃ、結局程度の問題でしかない

**デフォルトの名無しさん** · 2021/05/04(火) 13:02:15.57

>>679
どれは違う。
数学で代入したり、共通部分を括りだして M という変数に代入して
分かり易くしたり、展開したり、足し算して一つにまとめたり、
同類項をまとめたり、因数分解したりするなどして、式を簡単化
するのと同じようなことをプログラミングに置いて行えば、
前のソースを残しつつ、コードをわかり易くできる。

**デフォルトの名無しさん** · 2021/05/05(水) 00:03:02.26

export機能は確かに立ち消えになったが、現状のC++において
テンプレートの定義をcppに書くことは、明示的実体化をしたら一応はできる
どうするのかと制限事項とかはここを見たらﾜｶﾙ↓
■ テンプレート関数の宣言と実装を分離する方法 ( 補足 )
https://qiita.com/MasayaMizuhara/items/b1e3a53f62df88205eb7

一方、>>664で言っている
>見た目の問題だけなら、宣言と実装を分けることはできる
というのは（多分）こっち↓
■ テンプレート関数の宣言と実装を分離する方法
https://qiita.com/MasayaMizuhara/items/37f8c2a5462a4f7f8ea0

**デフォルトの名無しさん** · 2021/05/05(水) 00:14:15.46

>>680
言うは易しの典型例ktkr、
実際には依存しなくていいものが依存しまくりで
同値類が何かとか読むだけでばさっぱりわからなくなっている状況が多く、
>>677のような汗みどろ血みどろの作業になるんである

すんなり逝くのはGUIの場合みたいな切り分けのゴールが意味的に明白なケースぐらい
これはフォームの絵面を見てUI要素の塊別にinner classにでもしてやっていけば
ソースコードの行数Nに対してO(N*log(N))ぐらいで何とか整理がつく、

**デフォルトの名無しさん** · 2021/05/05(水) 12:46:37.29

ネットつうのはド素人が平気でシッタカかますとこだから
いちいち釣られててもしゃーない
ここ最近の流れだと>>677さんだけガチ勢だと思う
doxygenはワイらのお友達

**デフォルトの名無しさん** · 2021/05/06(木) 11:30:21.66

C++で3値ブールってどうやって表現してますか
char？

**デフォルトの名無しさん** · 2021/05/06(木) 11:36:37.33

3値ブールをenum型で定義すればintサイズ

**デフォルトの名無しさん** · 2021/05/06(木) 12:00:53.01

>>684
// #include <compare>
class strong_ordering;
class partial_ordering;
class weak_ordering;
および、これらのクラスの随伴関数operator<=>

**デフォルトの名無しさん** · 2021/05/06(木) 13:22:29.39

>>684
unsined char

**デフォルトの名無しさん** · 2021/05/06(木) 13:52:22.50

スペルマ違い

**デフォルトの名無しさん** · 2021/05/06(木) 17:31:19.46

BOOST_FOREACHで自作クラスをイテレートするのダル
なぜC++11の範囲for文で完全にカバーする努力をしなかったのかますます謎だ

**デフォルトの名無しさん** · 2021/05/06(木) 18:32:04.97

vector<int> v;
vを初期化
for(int& x: v){
　int y = move(x);
}
これって文法的には問題ないっていうかコンパイルエラーなりませんよね？
参照をmoveするってどういう意味なんですか？

**デフォルトの名無しさん** · 2021/05/06(木) 19:58:59.64

引数の型から返り値の型が明らかに決まるとき、返り値の型をわざわざテンプレート引数として書くのがめんどいんですが、省略するテクありますか

**デフォルトの名無しさん** · 2021/05/06(木) 20:33:45.29

>>691
引数の型で明らかに決まるんなら、戻り値の型を引数の型引数から導出される型として表現できるはずでしょ

**デフォルトの名無しさん** · 2021/05/06(木) 21:37:43.27

>>689
boost foreachができたのは15年以上前だから仕方ない。今更使う必要もないと思うぞ

**デフォルトの名無しさん** · 2021/05/06(木) 21:50:31.70

>>690
xを、このあと殺すだけだから
ぶっちょんぶっちょんに犯しまくっていいよってこと
それがconstのない右辺値参照にキャストするってこと

**デフォルトの名無しさん** · 2021/05/06(木) 22:05:14.28

>>691
autoとか？

**デフォルトの名無しさん** · 2021/05/06(木) 23:11:22.73

>>692
どうやって書くの？
template<class T1, class T2, class T3> T3 func(T1 a, T2 b){
T3 c;
return c;
}
みたいなやつのT3をテンプレート引数じゃなくしたいってことなんですが

**デフォルトの名無しさん** · 2021/05/06(木) 23:21:31.82

>>696
int64_t ret = func<int, size_t, int64_t>(100, 200);

**デフォルトの名無しさん** · 2021/05/06(木) 23:22:49.21

>>694
v とか x は y = move(x) の後で使い回しても良いんですよね？
つまり、vector v の要素の参照 x を move しても、v の要素も x も影響を受けなくて、y の構築のされ方が違うだけということで良いんですかね？

超初歩的なこと聞いてすみません

**デフォルトの名無しさん** · 2021/05/06(木) 23:28:09.10

>>697
？？？
> func<int, size_t, int64_t>
の int64_t をテンプレート引数じゃなくしたいってことです
実行時に返り値の型が分かるような関数を作るテクはあるかと言い換えても良いです
無理なら無理で良いです

**デフォルトの名無しさん** · 2021/05/06(木) 23:29:49.59

>>693
>>537,542みたいなときはある

**デフォルトの名無しさん** · 2021/05/06(木) 23:31:52.81

>>698
右辺値参照はあくまで、一時オブジェクトですよと示すだけなのでそのコードでは問題ない
けどyがint yじゃなくてvectorなどの、
「一時オブジェクトを受け取った場合、メモリ確保やコピーのコストを減らすために中身のポインタだけすげ替える」
クラスだった場合、その後のvの中身は使えなくなる
moveはただのT &&へのキャストだよ

**デフォルトの名無しさん** · 2021/05/06(木) 23:33:25.48

>>700
うーん、そのためだけに使うってのはちょっとなあ

**デフォルトの名無しさん** · 2021/05/06(木) 23:33:54.75

>>699
>>695に出てるじゃん
T3無しで自分で書いてみた？

**デフォルトの名無しさん** · 2021/05/06(木) 23:44:41.27

>>692,695,697,703
返り値の型がautoな関数って普通に作れるんですね
すみませんでした
ありがとうございました

**デフォルトの名無しさん** · 2021/05/07(金) 04:09:07.13

初歩的な質問かつスレチ気味ですみません
vscodeを用いて簡単なコードを書きました
ビルドとデバッグを試みました
ビルドは出来ましたかデバッグにエラーが出て、No such file or directryとあります
パスを指定する際に日本語が含まれていることでエラーが出たのかと思うのですが正しいですか？