C++相談室 part146

**デフォルトの名無しさん** · 2019/11/07(木) 11:35:36.76

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part145
http://mevius.5ch.net/test/read.cgi/tech/1568362404/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

**デフォルトの名無しさん** · 2019/12/13(金) 00:22:24.50

型演算をコンパイラに任せることが出来なくなって、すべてプログラミングしないといけなくなるのかな。

**デフォルトの名無しさん** · 2019/12/13(金) 06:47:47.05

>>824
むしろ（静的）型なんて俺には不要だぜ、ベイビーって奴の方がアホっぽいけどなw

>>825-826
静的型付け動的型付け
あたりでググってこい

**デフォルトの名無しさん** · 2019/12/13(金) 07:17:35.68

機械語は変数に型がない。
命令で型を使い分ける。
その大変さを考えると型欲しいってなるのかも。

**デフォルトの名無しさん** · 2019/12/13(金) 07:24:37.08

まさにBがCに進化するときの考え方だね

**デフォルトの名無しさん** · 2019/12/13(金) 09:49:21.00

>>825
ただし、実引数の型が違うのに仮引数の違いだけの同じ関数名の関数を複数
用意して使うと言う発想はスクリプト言語的な発想。
そのようにした場合、コンパイラが厳密にどの関数を使うかが人間には
分からない事が多いので安全性を損なう場合が多い。
スクリプト言語は RAD言語なのため、できるだけ短い関数名で対処しようと
するが、それが思わぬ間違いを含みがち。
C言語が好かれているのは、どういう処理がされるかが人間が完全予測できる
ことで、「大体の動作」は好まれない。

**デフォルトの名無しさん** · 2019/12/13(金) 09:53:03.46

>>826
型の違いでコードを自動変化させるという思想は、C++の中でも非常に最近に
なって STL (template) で流行りだしたもの。
もともとC言語に型が導入されたのは、プログラマのミスをコンパイラが発見して
エラーを出してくれるようにするためだった。C言語には関数の多態性(overload)
がない。なお、override と overload は別の概念なので、知らない人は検索して
欲しい。

**デフォルトの名無しさん** · 2019/12/13(金) 09:53:50.44

イネーブラ使えば良いのでは。

**デフォルトの名無しさん** · 2019/12/13(金) 10:00:20.89

コンセプトコイコイって感じなのかな。

**デフォルトの名無しさん** · 2019/12/13(金) 11:27:07.79

#pragma omp parallel forで
自動分割され、各スレッドに割り当てられた
ループの開始点と終了点を取得することできませんか?

**デフォルトの名無しさん** · 2019/12/13(金) 18:09:24.89

>C言語には関数の多態性(overload)がない

さらりと嘘をつくやつがおるな

**デフォルトの名無しさん** · 2019/12/13(金) 18:27:30.70

今UE4と組み込み以外でc++の仕事あります？

**デフォルトの名無しさん** · 2019/12/13(金) 18:33:53.16

オーバーロードあるか？
ディスパッチの方法はいろいろあると思うが

**デフォルトの名無しさん** · 2019/12/13(金) 18:55:58.62

>>836
USのマイクロソフトに行け

**デフォルトの名無しさん** · 2019/12/13(金) 19:01:03.38

>>830
> ただし、実引数の型が違うのに仮引数の違いだけの同じ関数名の関数を複数
> 用意して使うと言う発想はスクリプト言語的な発想。

え？スクリプト言語で「同じ関数名の関数を複数用意」できる言語なんて無いでしょ？
「同じ関数名の関数を複数用意」できるのは静的型付け言語の特徴だよ

**デフォルトの名無しさん** · 2019/12/13(金) 19:52:22.32

>>839
> え？スクリプト言語で「同じ関数名の関数を複数用意」できる言語なんて無いでしょ？
関数は無理だがメソッドでいいならPowerShell

**デフォルトの名無しさん** · 2019/12/13(金) 20:00:57.46

PowrShell は型付言語ですからね。
それぐらいでしょ？

**はちみつ餃子** ◆8X2XSCHEME · 2019/12/13(金) 20:54:52.57

用語としてメソッドと言ってるものでよければ Common Lisp もそうじゃね？

**デフォルトの名無しさん** · 2019/12/13(金) 21:07:31.92

>>841
うん、1つあれば
> え？スクリプト言語で「同じ関数名の関数を複数用意」できる言語なんて無いでしょ？
の反例になるからね

**デフォルトの名無しさん** · 2019/12/13(金) 21:09:15.79

>>843
そしたら、一つぐらいしか無いって俺は意見を訂正するだけなんだが、

お前も同じ関数名の関数を複数用意できるのはスクリプト言語では
PowerShellだけだって訂正するって話でいいの？

**デフォルトの名無しさん** · 2019/12/13(金) 21:13:12.55

それでいいんじゃないの

**デフォルトの名無しさん** · 2019/12/13(金) 21:23:18.13

質問です
template <typename T>
constexpr inline T value;
template <typename T>
constexpr inline T value = (T)0;
こうやって変数テンプレートの宣言と初期化を分離すると
VC、clang(Xcode付属)ではエラーになるんですがwandboxで試すとエラーになりません
本来どっちの動作が正しいんでしょうか？

**デフォルトの名無しさん** · 2019/12/13(金) 21:37:57.11

>>844
別にそれでいいよ
> え？スクリプト言語で「同じ関数名の関数を複数用意」できる言語なんて無いでしょ？
が無知からの発言と認めてもらえればいいだけだしw

**デフォルトの名無しさん** · 2019/12/13(金) 22:26:34.23

>>846
これも通ってしまった。
#include <iostream>

template <typename T>
constexpr T value = 1;

template <typename T>
constexpr T value = 2;

template <typename T>
constexpr T value = 3;

template <typename T>
constexpr T value = 4;

template <typename T>
constexpr T value = 5;

template <typename T>
constexpr T value = 6;

int main()
{
std::cout << value<int> << std::endl;
}

**デフォルトの名無しさん** · 2019/12/13(金) 22:27:26.74

実行結果。

Start
6
0
Finish

最後の定義が有効になってるように見える。

**デフォルトの名無しさん** · 2019/12/13(金) 22:28:16.14

Wandbox
C++
gcc HEAD 10.0.0 2019

**デフォルトの名無しさん** · 2019/12/13(金) 22:54:36.18

ありがとうございます、その結果を見るとgccがおかしいぽいですね・・・
宣言時に初期化は必須と考えて書いていこうと思います、ありがとうございました

**デフォルトの名無しさん** · 2019/12/13(金) 22:57:06.09

僕もちょっとわからないんだけど。

**デフォルトの名無しさん** · 2019/12/14(土) 00:21:27.14

>>836
デスクトップアプリ

**デフォルトの名無しさん** · 2019/12/14(土) 07:31:10.87

>>846
診断メッセージをよく見ろよ
> error C2737: 'value': 'constexpr' オブジェクトは初期化する必要があります。

そもそも分離できないんだよ
いいか、constexprは翻訳時定数だぞ
それを翻訳段階9まで未解決のままにできると思うか？

**デフォルトの名無しさん** · 2019/12/14(土) 08:56:55.09

>>854
なんでできるようにしないの？
そっちの方がおかしくね？

**デフォルトの名無しさん** · 2019/12/14(土) 09:02:00.44

なんでという理由も述べたはずだが

**デフォルトの名無しさん** · 2019/12/14(土) 09:53:01.66

>>856
だからそれを可能にするようにしてくれ

**デフォルトの名無しさん** · 2019/12/14(土) 10:02:03.90

ん？　俺は江添じゃねえぞ
奴なら標準会員だから言ってみるのもいいが

**デフォルトの名無しさん** · 2019/12/14(土) 10:02:27.48

- 標準会員
+ 標準化委員

**デフォルトの名無しさん** · 2019/12/14(土) 10:08:29.00

江添本ダメ絶対

**デフォルトの名無しさん** · 2019/12/14(土) 10:30:50.58

江添でもできない

**846** · 2019/12/14(土) 10:35:10.86

>>854
＞診断メッセージをよく見ろよ
見た上で言ってます（つまりgccまたはVC, clangのバグではないかということ

＞いいか、constexprは翻訳時定数だぞ
それ以前にテンプレートなんですが

**デフォルトの名無しさん** · 2019/12/14(土) 12:26:05.30

ローマ法王は根競べで決めるらしいですよ奥さん。

**デフォルトの名無しさん** · 2019/12/14(土) 12:26:49.81

誰でも閲覧できる規格ドラフト見ればすぐにわかることをこんな掃きだめで聞いても

**デフォルトの名無しさん** · 2019/12/14(土) 12:35:13.30

>>862
なんかとんがってんな

コンパイラのバグとまで言う根拠は何だ？
相場では規格票の条文だが

テンプレートなのは見ればわかるさ
だから何なのか説明をやめないでくれ

**デフォルトの名無しさん** · 2019/12/14(土) 12:50:37.99

>相場では規格票の条文

通産省の癖の抜けない老人はご退場いただきたい

**デフォルトの名無しさん** · 2019/12/14(土) 12:58:43.25

これODRの緩和と関係あるんですかね？

**デフォルトの名無しさん** · 2019/12/14(土) 13:34:08.27

>>772
>x86系CPUで普通のメモリへの読み書きで順番が入れ替わる可能性があるのは write => read だけ
別に。
コアAの読み書きをコアA自身が見る分にはそうかもわからんが
コアAの読み書きを異なるコアBから見たらwrite同士やread同士でも順番が入れ替わり得る
（アウトオブオーダー実行の影響で

安全に動かすには適切にメモリバリアで順序化する必要がある

**デフォルトの名無しさん** · 2019/12/14(土) 13:37:18.74

>>868
read ==> read
read ==> write
は入れ替わらない

**デフォルトの名無しさん** · 2019/12/14(土) 13:37:51.96

といってもロックレス何ちゃらぐらいの制御であればInterlockedCompareExchange()で済むから
スレッド間の通信なら普通メモリバリアとか直接触る必要は無いが

**デフォルトの名無しさん** · 2019/12/14(土) 13:38:24.93

>>869
迷信

**デフォルトの名無しさん** · 2019/12/14(土) 13:39:11.91

ソースは？

**デフォルトの名無しさん** · 2019/12/14(土) 13:39:40.59

リードキューやコマンドキューにコマンドが入るのはアウトオブオーダープロセスの事後であるため
そのような保証は無い

**デフォルトの名無しさん** · 2019/12/14(土) 13:41:05.07

それのソース

**デフォルトの名無しさん** · 2019/12/14(土) 13:44:15.66

https://github.com/herumi/misc/blob/master/cpp/fence.md

**デフォルトの名無しさん** · 2019/12/14(土) 14:15:12.84

x86系は
シングルコアのマルチスレッドアプリ
の多くがそのまま動くように出来てる

シングルコア時代が長かったから

**デフォルトの名無しさん** · 2019/12/14(土) 14:55:10.15

>>865
＞テンプレートなのは見ればわかるさ
＞だから何なのか
普通に考えて、実体化がまだなのに定義（初期化）を強制される妥当な理由はない、ということ

**デフォルトの名無しさん** · 2019/12/14(土) 14:57:30.67

確かにリンク先のインテルのマニュアルの
>8.2.3.2 Neither Loads Nor Stores Are Reordered with Like Operations
>Example 8-2. Stores Are Not Reordered with Older Loads
に
>Initially x = y = 0r1 = 1 and r2 = 1 is not allowed
と書いてあって>>875と同じことが書いてあるが疑わしい
マニュアルが間違っているのではないか、

ちな
>8byteのデータはアドレスが8の倍数のときにアライメントされている。
から安全に読み書きできるというのはi486みたいな古いプロセッサーだとかえって危険らしい
>8.1.1 Guaranteed Atomic Operations
を見たらﾜｶﾙ、

**デフォルトの名無しさん** · 2019/12/14(土) 15:04:35.33

つか上のインテルのマニュアルには「投機的実行時中のメモリアクセスではメモリアクセス例外は発生しない」
旨が2箇所ぐらいに書かれているが、
ということはつまりアセンブリコード上A→BまたはA→Cというメモリアクセスが条件によってどちら片方だけ実行されることを意図したコードであっても
A→B→Cというメモリアクセス順に成り得ることを意味し、他コアからもそう見えてしまうはずだが、
これをメモリアクセス順がreorderされていないうちに入れてしまうのはどうなのか、、、
マニュアル執筆者の国語の再教育が必要なのではないか

**デフォルトの名無しさん** · 2019/12/14(土) 15:10:49.52

>>877
おまえさん、もしかして
テンプレートの宣言と定義と
オブジェクトの宣言と定義を
ごっちゃにしてないか？

int test;
int test = 5;
これは宣言と定義じゃなく定義の重複だぞ

**デフォルトの名無しさん** · 2019/12/14(土) 15:13:40.23

お前なぁ
x86のこと大して詳しくないのにしゃしゃり出てくるからそういう情けないこと言うはめになるんだよ
x86でstd::atomicのmemory_orderを変えてバリア付きがどういうインストラクションになるか見てみな
storeのseq_cst以外は素のmovだから(コンパイラ依存だから絶対ではない)

**デフォルトの名無しさん** · 2019/12/14(土) 15:20:09.00

そりゃー間違ったマニュアルにしたがって実装したら間違った実装になり得る（ｷﾘ

ていうかアウトオブオーダー実行の影響がマルチコアCPUにおいても透過的だと認めやっても良いが、
>>879の投機的実行の件はどうなんじゃ？
あるコアが投機的実行中に他のコアをストップさせるのでは何のための投機的実行かわからん…

**デフォルトの名無しさん** · 2019/12/14(土) 15:21:14.95

>>877
× 普通に考えて
〇俺の頭の中で

× 妥当な理由はない
〇妥当な理由は思い当たらない

テンプレートなら初期化は不要という主張なら、
constexpr 変数の宣言と定義を分離できないことは納得してるのかな？
そうだとして、それをテンプレートの時だけ可能とすることに意義があると思うの？

特別ルールを設ければコンパイラ実装やプログラムの読み取りにコストがかかるから、
明確が意義がなければ特別ルールは無いのが妥当だと思うよ。

**デフォルトの名無しさん** · 2019/12/14(土) 15:24:42.79

>>880, >>883
マウント取るのが最優先でまともな回答できない（するつもりも無い）んなら黙っててくれ

＞これは宣言と定義じゃなく定義の重複だぞ
externつけたら？

＞それをテンプレートの時だけ可能とすることに意義があると思うの？
テンプレート実引数に使われる型が不完全型であっても、実体化まで評価を遅らせられる

さて、
＞× 普通に考えて
＞〇俺の頭の中で

＞× 妥当な理由はない
＞〇妥当な理由は思い当たらない
こんなゴミみたいな煽り入れてきたからには逃げるなよ

**デフォルトの名無しさん** · 2019/12/14(土) 15:32:39.86

>>884
おまえさんの元の質問はこうだったな
template <typename T> constexpr inline T value;
template <typename T> constexpr inline T value = (T)0;

どこにexternなんて書いてある？
マウントがどうたら気にするあまり後出しなんかしてるのはそっちだぞ
こっちはそんなこと微塵も考えちゃいねえよ失敬な
最初の口調に戻れよ

**デフォルトの名無しさん** · 2019/12/14(土) 15:36:57.55

間違えた
Ｘテンプレート実引数に使われる型が不完全型であっても、実体化まで評価を遅らせられる
○初期化に使われる定数式の評価を遅らせられる

言い換えれば、宣言と定義を分離できないならconstな変数テンプレートの宣言時には
それに使う定数式内のすべての型が完全型であることを強制されてしまう
＝std::is_integral_v = std::is_integral<T>::valueでいえば
is_integral構造体の方が取り回しがいい、ということ
なんのために変数テンプレートが導入されたのか・・・・

**デフォルトの名無しさん** · 2019/12/14(土) 15:37:56.58

>>885
自分が失敬だからこうなってるとは考えられないんだな
何様だよ、そもそも質問に答えてないだろうが

**デフォルトの名無しさん** · 2019/12/14(土) 15:43:43.09

>>887
template <typename T> constexpr inline T value;
template <typename T> constexpr inline T value = (T)0;
を例示しての質問に対して
int test;
int test = 5;
という答えをしているぞ
valueがtestになったのは悪かったが
余計な飾りをとって問題の核心を指摘したんだよ

**デフォルトの名無しさん** · 2019/12/14(土) 15:48:43.77

家事があるんでしばらく離席する

**デフォルトの名無しさん** · 2019/12/14(土) 15:58:10.05

規格でそうなってる（テンプレートゆえの特例は無い）のが”わかってるなら”
最初からそう言ってくれれば済むんじゃないの？
>>854を読み直せよ、テンプレートのことが完全にすっぽぬけた上に失礼な回答だろ

＞コンパイラのバグとまで言う根拠は何だ？
とまで、って・・・・普通にありえるだろ、動作が違うんだから（未定義とかいう屁理屈は無しで）

で、>>883は逃げたの？

**デフォルトの名無しさん** · 2019/12/14(土) 16:55:24.17

>>886
やっぱり constexpr 変数の宣言と定義を分離して何がしたいのか、
何ができるようになるのか、が見えてこない。ごめんね。

宣言だけ見える constexpr 変数への参照やポインタだけはとれるようになるけど、
それだともう constexpr である必要なくて const 変数でよさそうで、それならふつうに
宣言と定義は分けられるし。

ちなみにテンプレート実体化までテンプレート引数依存箇所の評価はされないから、
宣言と定義を分ける話を「評価を遅らせられる」と言い表しているのも何か間違ってそう。
「記述を遅らせられる」の間違い？

**デフォルトの名無しさん** · 2019/12/14(土) 17:16:54.80

だめだこいつ
絶望的に人に者を尋ねる態度がわかってない
「言ってくれれば済む」とか図々しすぎ
技術的な議論がしたいがこいつ相手では
不必要にイラついちまって無理だわ
俺そんなに人間できてない

**デフォルトの名無しさん** · 2019/12/14(土) 17:24:00.92

>>891
すまん、
＞テンプレート実体化までテンプレート引数依存箇所の評価はされない
これ検証してみたらたしかにそうだった
手元のコードで完全型を要求されたから、初期化時に不完全型を使えないと思い込んでた
（おそらくconstexprな変数テンプレートの実体化が、必要な型の実体化より先に来てたっぽい
多分構造体か何かでワンクッション置けば解決できると思う）
これなら確かに分けられなくて問題無いね

>>892
＞いいか、constexprは翻訳時定数だぞ
＞それを翻訳段階9まで未解決のままにできると思うか？
＞なんかとんがってんな
＞後出しなんかしてるのはそっちだ
＞余計な飾りをとって問題の核心を指摘したんだよ
さらには
＞最初の口調に戻れよ
の上で
＞技術的な議論がしたいがこいつ相手では
＞不必要にイラついちまって無理だわ
よくそんなセリフが言えたもんだ
自己評価高すぎじゃない？ｗｗｗｗ

**デフォルトの名無しさん** · 2019/12/14(土) 17:52:18.36

意見が合うとか合わないとか以前の問題
根底的なメンタリティに欠陥がある相手とは話にならない

**デフォルトの名無しさん** · 2019/12/14(土) 17:58:45.99

FYI

>>846
Bug 68012: g++ incorrectly accepts forward declaration of constexpr variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68012

>>848
One definition rule
https://timsong-cpp.github.io/cppwp/n4659/basic.def.odr#1
> No translation unit shall contain more than one definition of any variable, function, class type, enumeration type, or template.

**デフォルトの名無しさん** · 2019/12/14(土) 18:08:23.02

>>895
わざわざありがとう、やっぱgccのバグだったのね

**デフォルトの名無しさん** · 2019/12/14(土) 19:50:50.54

GCCに踊らされてスレを浪費した

**デフォルトの名無しさん** · 2019/12/14(土) 20:04:04.94

>>837
オーバーロード=多態性じゃないんで…
オーバーライドのことなら当然cで実現できる

**デフォルトの名無しさん** · 2019/12/14(土) 21:11:37.22

>>898
どうやって？
いや、ディスパッチの方法はいろいろあると思うが

**デフォルトの名無しさん** · 2019/12/14(土) 21:15:53.72

禿もそんなことを言いながら
virtualの導入には当初反対から出発したんだよな

**デフォルトの名無しさん** · 2019/12/14(土) 21:26:53.87

>>899
その話題QZ相手にやったばかりなんで自分で調べて

**デフォルトの名無しさん** · 2019/12/15(日) 09:10:03.56

君が忘れた腕時計見つめながら。

**デフォルトの名無しさん** · 2019/12/15(日) 10:29:35.56

>>898
overload は、同じ関数名で仮引数の型が違う関数を作れるという多態性のことですよ。

**デフォルトの名無しさん** · 2019/12/15(日) 10:52:20.53

ツリーのイテレータがあるとして、イテレータが返すのはノードじゃなくて、ノードの持つ値ですよね？
すると、イテレータは立体機動出来ないといけなくなるけど、begin().begin()とか変ですよね？
begin().parent()とか。

**デフォルトの名無しさん** · 2019/12/15(日) 10:59:28.89

イテレータが返すじゃなくて、イテレータの逆参照が返すかな。

**デフォルトの名無しさん** · 2019/12/15(日) 11:08:51.65

コレクションとしては子孫ノード全部を列挙できればよくて、ツリー構造に沿った操作が行いたいなら
それに加えて直接の子ノードのみを列挙するイテレータが用意できればいいだろう。

**デフォルトの名無しさん** · 2019/12/15(日) 11:17:54.16

何が子ノードのみを列挙するイテレータを返すかがよくわからない。
ノードの値がイテレータを返すことはできないので、ノードが子ノードを指すイテレータを返すとすると、イテレータの逆参照はノードを返すことになる。
これは意味論的にちょっと違うかなって。
コレクションにおいて位置はイテレータで示されるので、立体的な位置を持つツリーでは、イテレータ自身が立体機動出来て、巡回能力を持つイテレータは、reverse_iteratorのように外部に用意されれば良いのかなと思ったんだけど。
たとえば、レベルオーダーや深さ優先の巡回イテレータがあるとすると、普通に考えるとスタックやキューが内部に必要にある。
というわけでコピーのコストがあるので、これを標準には出来ないんじゃないかなって。

**デフォルトの名無しさん** · 2019/12/15(日) 11:22:50.93

子ノードを指すイテレータの逆参照が子ノードを返すとすると、*node.begin()は子ノードを返す。
**node.begin()は最初の子ノードの値を返すことになるんだけども。
イテレータの逆参照がノードを返す場合、初期化子リストが素直に実装出来てイイんだけども、イテレータの逆参照が値を返さないのが腑に落ちない感じ。

**デフォルトの名無しさん** · 2019/12/15(日) 11:23:28.40

>>903
こらこらoverloadは多態じゃない多重定義だ
多態はpolymorphism間違えるな

**デフォルトの名無しさん** · 2019/12/15(日) 11:27:25.99

イテレータは演算子の実装を求められてるわけではなく、その演算子を呼び出した時の効果を求められてるだけなので、++(int)はスタックをコピーしない方法を考えた。

**デフォルトの名無しさん** · 2019/12/15(日) 11:30:57.88

そこは値じゃなくてノードを返すイテレータでいいんじゃね？
必要ならイテレータ自体を拡張してもいいだろうけど、この場合はあまり応用できそうもないし。

**デフォルトの名無しさん** · 2019/12/15(日) 11:31:53.05

そうなのかな？

**デフォルトの名無しさん** · 2019/12/15(日) 11:37:55.15

まずイテレータで何を抽象化したいかを明確にしなよ
ノードを意識させたいのか？

**デフォルトの名無しさん** · 2019/12/15(日) 11:38:38.78

STL風ツリーって検索しても絶対出てこないし、CIAが絡んでるような気がしてきた。

**デフォルトの名無しさん** · 2019/12/15(日) 11:39:36.48

そこがわかんないんだよねえ。
禿4とか読んでると、イテレータは位置を意味してるように思うんだけど。

**デフォルトの名無しさん** · 2019/12/15(日) 11:45:00.74

ツリー構造
範囲が広すぎて
汎用化すると使い勝手が悪くなるからしない
ってだけかと

**デフォルトの名無しさん** · 2019/12/15(日) 11:56:45.76

recursive_directory_iteratorとかね

**デフォルトの名無しさん** · 2019/12/15(日) 12:06:14.82

なんでdirectory？
treeでいいじゃん

**デフォルトの名無しさん** · 2019/12/15(日) 12:22:05.91

いや立体がどうたら言ってるから
じゃあrecursive_directory_iteratorを使うユーザーのコードは
いちいち多重ループだの再帰だのといった処理になるのかって
思ってさ

**デフォルトの名無しさん** · 2019/12/15(日) 12:24:23.41

ツリーは、あるノードの親が知りたいときもあるはず。

**デフォルトの名無しさん** · 2019/12/15(日) 13:07:24.45

ごちゃごちゃ考える前にイテレータの本分を決めなよ
begin()からend()まで++で走らせた時にどうなってほしいの？
話はそれからだ

**デフォルトの名無しさん** · 2019/12/15(日) 13:09:44.18

一般にtreeの探索順序はアルゴリズムと深く結びついてるし、
そこ凝りだすと沼だぞ。

**デフォルトの名無しさん** · 2019/12/15(日) 13:09:51.26

関数ポインタをシリアライズしてファイルとして保存し、
ファイルからその関数ポインタを利用できる形に復元する方法ってあるのでしょうか？

**デフォルトの名無しさん** · 2019/12/15(日) 13:13:54.57

関数だろうが変数だろうがポインタはただの整数値でしょ

**デフォルトの名無しさん** · 2019/12/15(日) 13:18:39.25

>>923 環境や「利用」の仕方を具体的に限定すればやりようはあるかもね。