[過去ﾛｸﾞ] C++相談室 part137 (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
841(1): (ﾌﾞｰｲﾓ MM7b-uZyL) 2018/09/29(土)22:03 ID:oWn9MzvpM(2/2) AAS
>>840
moveするのが分かってるんなら最初からvectorごとヒープに作って unique_ptr で持てばいいでしょ
中途半端にガワだけスタックに置く意味がない
842: (ﾜｯﾁｮｲ 1704-ClIk) 2018/09/29(土)23:45 ID:OLOWa9QF0(1) AAS
move後の元オブジェクトを破壊っていうか破棄しようって提案もあったよ。ちょっと早くなるのだとさ。
843(1): (ﾜｯﾁｮｲ 9f23-brPT) 2018/09/30(日)00:04 ID:kBo12DYt0(1) AAS
>>841
ポインターならそもそも copy のコスト安いから move 要らないじゃん
844(2): (ﾜｯﾁｮｲ 5780-q1nr) 2018/09/30(日)00:20 ID:aYXyCrkn0(1) AAS
それだったら最初から普通にﾎﾟｲﾝﾀでかけよ
845: (ﾜｯﾁｮｲ ff80-LozN) 2018/09/30(日)00:57 ID:GfZkWSkk0(1) AAS
この3冊が、神の書！
Linux プログラミング・インタフェース、Michael Kerrisk、2012
C++11/14 コア言語、江添 亮、2015
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006
846(3): (ｱｳｱｳｳｰ Sadb-uZyL) 2018/09/30(日)01:40 ID:CKZYWlYLa(1/3) AAS
>>843
だからmoveいらないって話でしょ
C++のムーブセマンティクスがああなったのは中途半端にスタックを使うスタイルが定着してしまっていて今更ポインタ使えというのは無理があるからで、
本来は所有権の管理さえ適切に行えるようになってさえいればムーブなんか要らんよ
847: (ｵｯﾍﾟｹ Sr4b-N9wp) 2018/09/30(日)06:43 ID:C9oWPEnUr(1) AAS
C++ Coding Standards って新品で買えないけど代わりになる書籍ありますか？
848(4): (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)06:48 ID:d4gXl3Bi0(1/10) AAS
>>846
ポインタ使え思想はすでにC#とかなクラスが参照型な言語で実現されているが
オブジェクトの解放にガベージコレクタが要る言語になった
これはガベージコレクタ無し・所有権の無条件移動だけだと、次のようなケースで早速話が破綻するから仕方が無い
void bar(int n) {
std::unique_ptr<Foo> a(new Foo());
for (int i = 0; i < n; i++) {
省6
849(3): (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)06:53 ID:d4gXl3Bi0(2/10) AAS
それにポインタ使え思想だと次のようなケースでBaz::m_c[i]のBar:m_b[j]の:Foo::m_aのアクセスに藻前らどんだけ間接参照するんですかと、
class Foo {
SomeClass m_a;
};
class Bar {
Foo m_b[100];
};
省3
850: (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)07:13 ID:d4gXl3Bi0(3/10) AAS
ちな>>849はm_bやm_cが配列であるため、配列アクセス時の添え字が定数なｼﾁｭでもない限り、JITでも間接参照回数を3以下にはできん
851(1): (ﾌﾞｰｲﾓ MM7b-uZyL) 2018/09/30(日)09:10 ID:3yGUdTqFM(1/2) AAS
>>848
よくわからんな
848の問題はそれmoveでも一緒だよね
単にデフォルトの挙動がmoveかborrowかだけの話で、unique_ptrがたまたま前者なだけ
スマポ使えば間接参照はどうしても増えるけど、実際>>849のようなケースで特定の要素だけ所有権捨てたりしないでしょ
所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、その場合に限ってスマポを使えばよい
コーナーケースのために全てを複雑にする必要はない
852(1): (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)09:21 ID:d4gXl3Bi0(4/10) AAS
>>851
>所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、
有り得ない仮定すぐる…
>>848なケースにおいて、オブジェクトaの生成時点というのは、
ライブラリー制作者がfunc1()を設計してビルドまで完了した後やがな…
853(1): (ﾌﾞｰｲﾓ MM7b-uZyL) 2018/09/30(日)09:39 ID:3yGUdTqFM(2/2) AAS
>>852
自分でも分かってて揚げ足取ろうとしてるんだろうけど、コーディング時に、プログラマがオブジェクトを生成することを意図したコードを記述した時点で、な
854(4): (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)09:46 ID:d4gXl3Bi0(5/10) AAS
>>853
いやｽﾏﾝ言い方がまずかったそういう意味ではない
確かに
>所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、
というのは真だが、ライブラリのインターフェースに解放が必要なオブジェクトのmoveなど認めたら有り得ないコストが生じるという話
func1()の制作者が所有権を寄越すことを強制した（そういうインターフェース仕様にしてしまった）場合、
func1()を使う人はfunc1()に所有権を渡さねばならない。この結果、
省5
855(1): (ｱｳｱｳｳｰ Sadb-uZyL) 2018/09/30(日)09:52 ID:CKZYWlYLa(2/3) AAS
>>854
だからそれmoveでも同じことだよね？
ユニバーサル参照のことを言ってるんだとしたら、あれただの型推論だぞ
856(1): (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)10:03 ID:d4gXl3Bi0(6/10) AAS
>>855
解放が不要なオブジェクトのmoveは話がちげう
この場合、単に生ポインタ（オブジェクトのアドレス）をfunc1()に渡すのと変わらん
これはライブラリのインターフェースに現れてもコスト的には問題は無い
元レスのアンカー先>>846は>>854のコストが避けられない主張
857: (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)10:07 ID:d4gXl3Bi0(7/10) AAS
いやすまん解放が不要なオブジェクトでも、所有権を移動した場合は>>854の1のコストは避けられないorz
ここは訂正
858(2): (ｱｳｱｳｳｰ Sadb-uZyL) 2018/09/30(日)10:11 ID:CKZYWlYLa(3/3) AAS
>>856
スマポのmoveも本体のmoveも一段間接参照が入る以外は何も変わらないって言ってるんだけど、そんなに難しい話かなあ
859: (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)10:45 ID:d4gXl3Bi0(8/10) AAS
>>858
>>848、>>849は、現行C++におけるスマポのmoveと本体のmoveの優劣は問題にしていない
848を現行C++のコード風に書いたから誤解を招いたのかもしれないが、比較はあくまで現行C++と846思想の比較であって、
846の次の思想を実行に移したら>>854のコストが避けられませんよという話
1. スタックを使うスタイルはやめるべき（全部スマポであるべき）
2. 所有権の管理さえ適切に行えるようになってさえいれば（現行C++のムーブセマンティクスみたいな）ムーブなんか要らん
1は現行C++との比較において、間接参照回数に響く
省1
860: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ bf6f-aemA) 2018/09/30(日)10:52 ID:56zUhffF0(1) AAS
>>858
本体のムーブも、ムーブ出来るように書いたらカスタムなスマートポインタみたいになるから、
間接参照が入っちゃうので、なおさら同じではあると思う。
でもまあ、ムーブは抽象化の方法であって、
最終的に実行されることが同じだからなくても良いってのは暴論よね。
861(1): (ｵｯﾍﾟｹ Sr4b-hm9e) 2018/09/30(日)11:10 ID:f0zM7Hcdr(1/4) AAS
アンダースコアとドットをこの順で必ず含む string があったとして、アンダースコアからドットまでの部分文字列を切り出す処理って一行で書ける？
substr と find_first_of と find_last_of を組み合わせる方法を考えたんだが、
アンダースコアの前を削る;
ドットの後を削る;
という2行に渡るやり方しか思い付かない
862: (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)11:15 ID:d4gXl3Bi0(9/10) AAS
ちな
>スマポのmoveも本体のmoveも一段間接参照が入る以外は何も変わらないって
これは現行C++においても違う違いがﾜｶﾙ男ならﾜｶﾙ
func1()からfunc2()にfunc1()の自動変数aをmoveするとして、かつfunc2()はインライン展開されるとすると、
func2()におけるaのメンバへのアクセスはfunc1()呼び出し時点でのスタックポインタ相対で一発でやれる
一方、aがスマポだったりすると、aのメンバへのアクセスの前に、func1()呼び出しの都度1回はスタックポインタ相対でaのアドレスを得なければならない
863: (ﾌﾞｰｲﾓ MM7b-uZyL) 2018/09/30(日)11:27 ID:fM5IaZg4M(1) AAS
オブジェクト本体のメモリのコピーにかかるコストを考慮すればどっちもどっち
864(2): (ﾜｯﾁｮｲ 9fa2-aemA) 2018/09/30(日)11:54 ID:u5/6mv7u0(1) AAS
>>861
substr じゃなくて、コンストラクタ使えばいいんじゃね
string t(s.begin() + s.find_first_of('_') + 1, s.begin() + s.find_last_of('.'));
865: (ｵｯﾍﾟｹ Sr4b-hm9e) 2018/09/30(日)12:29 ID:f0zM7Hcdr(2/4) AAS
>>864
なるほど、ためになります
866(1): (ｵｯﾍﾟｹ Sr4b-hm9e) 2018/09/30(日)12:35 ID:f0zM7Hcdr(3/4) AAS
>>864
ふと気になったのですが、このコンストラクタの挙動って他の名前の関数で実装されてないんでしょうか？
867(1): さまよえる蟻人間◆T6xkBnTXz7B0 (ｽﾌﾟﾌﾟ Sdbf-RRKt) 2018/09/30(日)12:48 ID:Eso9UeUod(1) AAS
>>866
assign
868: (ｵｯﾍﾟｹ Sr4b-hm9e) 2018/09/30(日)13:18 ID:f0zM7Hcdr(4/4) AAS
>>867
何から何までありがとうございます
869: (ﾜｯﾁｮｲ bf9f-e6iu) 2018/09/30(日)14:15 ID:QSRvujde0(1) AAS
「rustにもあるし俺らも入れなきゃ」くらいの感覚で
今までのシステムとの統合性の難しさなんかほぼ考えないで入れちゃった機能だから。
c++らしいといえばらしい感覚だけど。
870: (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/09/30(日)14:22 ID:d4gXl3Bi0(10/10) AAS
std::basic_string::find()もイテレータを返すように他のコレクションとの統合性を尊重して欲しいよな
871: (ﾜｯﾁｮｲ 77c7-aemA) 2018/09/30(日)22:56 ID:SdlFi6Ao0(1) AAS
findを実行した対象とは別のstringの同じ位置に何かしたいとき
イテレータで返されるとちょっとだけ面倒
まあ大した問題でもないんだけど
872(1): (ﾜｯﾁｮｲ bf8a-ClIk) 2018/10/01(月)17:20 ID:mKeAnbBU0(1) AAS
moveセマンテックが必要になった理由を理解してないのが多くて驚くばかりだな
破壊して良い中間オブジェクトとそうじゃないのとを区別するために必要なのだよ
ポインタ使えばmove必要ないとかそういう問題じゃない
873: (ﾜｯﾁｮｲ 9f02-aemA) 2018/10/01(月)17:40 ID:qsdLJDx40(1/6) AAS
元はといえば禿が左辺値参照でもconstつければ右辺値を指せるという曲がった話を始めたのが
評判悪くてC++11でやっとやっとやっとやっとメスが入ったのが本当の理由
874(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ bf6f-aemA) 2018/10/01(月)18:05 ID:hbafP85H0(1) AAS
>>872
色んな話題が出てるので混乱してるが、ムーブ不要論を出してる側の *元々の* 主張は >>846 の通り
「ちゃんとした所有権の管理 (たぶん Rust みたいなやつのこと？) が有りさえすれば」
であって、でもそれは C++ ではもはや無理でしょということもわかった上だと思う。
875: (ﾜｯﾁｮｲ f7c3-2BxS) 2018/10/01(月)18:05 ID:Gge6W+rt0(1/5) AAS
Cにも欲しいわ
Cは参照ないから右辺値指示ポインタで
876: (ﾜｯﾁｮｲ 9f02-aemA) 2018/10/01(月)18:09 ID:qsdLJDx40(2/6) AAS
それを言うなら、右辺値の概念を撤廃すべきでしょ
どんな値もポインタで指すことができ、
ポインタで指すことでregister指定を解除されるという変更
877: (ﾜｯﾁｮｲ 1704-ClIk) 2018/10/01(月)18:12 ID:UY4lJdAP0(1) AAS
テンポラリーオブジェクトなくすと、一回必ず厳密に生成してから仕様になるので、手間増えると思う。
878(1): (ﾜｯﾁｮｲ f7c3-2BxS) 2018/10/01(月)18:40 ID:Gge6W+rt0(2/5) AAS
右辺値がないと int i = 0; すら書けなくなるんだが
879(1): (ﾜｯﾁｮｲ 9f02-aemA) 2018/10/01(月)18:50 ID:qsdLJDx40(3/6) AAS
なんで？
int j;
j ^= j;
int i = j;
左辺値でも問題ないじゃん
880: (ｵｲｺﾗﾐﾈｵ MM4f-IJfJ) 2018/10/01(月)18:54 ID:xwh6ZD/vM(1/2) AAS
>>879
苦しいねーw
881(1): (ﾜｯﾁｮｲ 77e3-c2ki) 2018/10/01(月)19:00 ID:Yquio+NL0(1/2) AAS
0 以外はどうすんの。
882: (ﾜｯﾁｮｲ f7c3-2BxS) 2018/10/01(月)19:02 ID:Gge6W+rt0(3/5) AAS
> j ^= j;
はい未初期化値を使ったから未定義動作で鼻から悪魔
883(1): (ﾜｯﾁｮｲ 77e3-c2ki) 2018/10/01(月)19:04 ID:Yquio+NL0(2/2) AAS
char buf[1];
int i = (int)(buf[10] - buf[0]);
で、i = 10 に初期化される。
884: (ｵｲｺﾗﾐﾈｵ MM4f-IJfJ) 2018/10/01(月)19:05 ID:xwh6ZD/vM(2/2) AAS
NaNのときはxorは未定義か、そこまで考えなかったな
885(1): (ﾜｯﾁｮｲ 9f7c-c2ki) 2018/10/01(月)19:06 ID:uXaVofwo0(1) AAS
>>883
間違った。正しくは：
char buf[1];
int i = (int)(&buf[10] - &buf[0]); // i = 10 と等価。
886: (ﾜｯﾁｮｲ bf9f-e6iu) 2018/10/01(月)19:11 ID:rJND5eoS0(1/2) AAS
そもそも=の無理やりなオーバーロードや引数に対する暗黙的なattainが問題なんだろう。
しかし元々のcのシンタックスを引き継ぎつつ、上記の問題を解決するのは不可能。
887: (ﾜｯﾁｮｲ f7c3-2BxS) 2018/10/01(月)19:14 ID:Gge6W+rt0(4/5) AAS
>>885
10
0
&buf[10]
&buf[0]
&buf[10] - &buf[0]
(int)(&buf[10] - &buf[0])
省2
888: (ﾜｯﾁｮｲ 9f02-aemA) 2018/10/01(月)19:19 ID:qsdLJDx40(4/6) AAS
>>881
別に？
int *j;
j = &10;
int i = *j;
てだけじゃん
10が左辺値だったらって話ね
省4
889(1): (ﾜｯﾁｮｲ f7c3-2BxS) 2018/10/01(月)19:23 ID:Gge6W+rt0(5/5) AAS
10が左辺値ならこれ認めるの？
10 = 42;
890(1): (ﾜｯﾁｮｲ 574e-2bq/) 2018/10/01(月)21:57 ID:92NEoPQV0(1) AAS
お前らがC++で作ったことあるものリスト化して
891: (ﾜｯﾁｮｲ 9f02-aemA) 2018/10/01(月)22:37 ID:qsdLJDx40(5/6) AAS
>>889
全然かまわん
int a = 10;
int b = 10;
a = 42;
こう言っているに過ぎない
892: (ﾜｯﾁｮｲ 9f02-aemA) 2018/10/01(月)22:42 ID:qsdLJDx40(6/6) AAS
>>878
そろそろ答えてもらおうか
なぜ右辺値がないと int i = 0; が書けないのか
893: (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/10/01(月)23:15 ID:2m3Ms8fl0(1/3) AAS
>>874
ていうか所有権などという中途半端な概念にオブジェクトの解放を担わせるのは危険か無意味かのどっちかにしかならない
最後までオブジェクトを使いたい人と、そのオブジェクトを所有する人を
コードに所有権を明示するスタイルで一致させられるケースは少ない
希ガス
894(2): (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/10/01(月)23:21 ID:2m3Ms8fl0(2/3) AAS
しかしながら右辺値参照を使うとコードを書く人がオブジェクトの所有権を意識せざるを得ない
これを抽象化といわれるとかなり違和感
※ 個人の感想です
895(1): (ﾜｯﾁｮｲ bf9f-e6iu) 2018/10/01(月)23:31 ID:rJND5eoS0(2/2) AAS
結局ネストしたオブジェクトってのはどう扱おうと楽な扱いなんてできんってことなんだわ。
同期と効率と安全性を全て容易にするってのは不可能なんじゃないかね。
896: (ﾜｯﾁｮｲ 9fbd-G9Ql) 2018/10/01(月)23:41 ID:2m3Ms8fl0(3/3) AAS
>>895
>結局ネストしたオブジェクトってのはどう扱おうと楽な扱いなんてできんってことなんだわ。
いや？
オブジェクトの所有権は最初のcallerががっちり掴んでオブジェクトを使うcallee以下は生ポでおk
全てが調和する
897: (ﾜｯﾁｮｲ 5780-q1nr) 2018/10/01(月)23:46 ID:zfKNS/F/0(1) AAS
AA省
898: (ﾜｯﾁｮｲ 17b3-kFNE) 2018/10/01(月)23:49 ID:aHxMqUX30(1) AAS
>>894
右辺値参照周りを抽象化とか言ってるアホははちみつだけだろ
899: (ｱｳｱｳｳｰ Sadb-mlbx) 2018/10/02(火)00:39 ID:YrRJAaFSa(1/3) AAS
外部ﾘﾝｸ:ideone.com
上のコードで教えて欲しい。
templateでデフォルト引数で関数を指定する場合、わざわざテンプレートパラメーターFuncにdecltype(...)しなきゃいけないのは何故？
900(1): (ﾜｯﾁｮｲ 17b3-aemA) 2018/10/02(火)01:21 ID:HQVsIoxF0(1) AAS
外部ﾘﾝｸ:ideone.com
testは関数名だから型じゃない
901: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ bf6f-aemA) 2018/10/02(火)02:10 ID:wuORmtyC0(1/4) AAS
>>894
ムーブだのなんだの言ってても、
C++ の言語機能として直接的に有るのは rvalue 参照を区別して受け取れるってだけで、
所有権の管理をキッチリやってくれるわけではない C++ の限界なんだよね。
だけど、なるべくクラス・関数の実装の中に区別を押し込めて隠す道具のひとつにはなるって話。
でも、中途半端にやるなら隠さないで見せた方がマシという論はわかる。
902(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ bf6f-aemA) 2018/10/02(火)05:46 ID:wuORmtyC0(2/4) AAS
受取る関数の側を上手く作っておけば
それを使う側では所有権の移動とかそんなに気にしなくない？
rvalue だったら勝手にちょっと効率的になる (こともある) ねってだけで。
使うときに気にしなくて良いように押し込められるならやっぱり抽象化の道具って言えると思うよ。
903(1): (ｱｳｱｳｳｰ Sadb-mlbx) 2018/10/02(火)06:04 ID:YrRJAaFSa(2/3) AAS
>>900
ありがとう。
template<typename Func = int (int)>
を
template<typename Func>
にするとエラーになるのは何故？
904: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ bf6f-aemA) 2018/10/02(火)06:50 ID:wuORmtyC0(3/4) AAS
>>903
デフォルト引数からはテンプレート引数を推定できない制限がある。
905: (ｱｳｱｳｳｰ Sadb-mlbx) 2018/10/02(火)07:00 ID:YrRJAaFSa(3/3) AAS
なるほどです。
906: (ﾜｯﾁｮｲ 9702-aemA) 2018/10/02(火)07:46 ID:kk/2dA0Y0(1/6) AAS
時々、イラつかされる制限だ
907: (ﾗｸｯﾍﾟ MM0b-2bq/) 2018/10/02(火)08:15 ID:Tcj3k2lbM(1/4) AAS
>>890
C++が得意なことを教えてください
908: (ﾌﾞｰｲﾓ MM7b-uZyL) 2018/10/02(火)10:26 ID:giBEQZ0BM(1) AAS
>>902
いや呼び出す側に意識させるのが右辺値参照の目的だろ
意識しなくていいようなケースならconst参照で十分
909: (ﾜｯﾁｮｲ 9702-aemA) 2018/10/02(火)10:31 ID:kk/2dA0Y0(2/6) AAS
冗談は顔だけにしろよ
たとえばstd::threadの右辺値参照なんぞ意識してるか？
910: (ﾜｯﾁｮｲ 17b3-kFNE) 2018/10/02(火)13:13 ID:8CvSI5wK0(1) AAS
一行目に何の意味があるのかわからん
911(1): (JP 0H4f-ZVm4) 2018/10/02(火)15:51 ID:Xh7D/bbnH(1) AAS
割と昔からあるプログラムを見てるんですけど一つのメソッド内で
for(int i = 0; ……）{……}
for(i = 0;……）{……}
って書き方してるのをちらほら見ます
要は宣言してるんだから使い回せるだろみたいな理屈なんでしょうがビルドしようとすると当然未定義だとエラーが出ます
昔のC++だとこれがオッケーだったりしたんでしょうか？
912(1): (ﾜｯﾁｮｲ 9702-aemA) 2018/10/02(火)15:56 ID:kk/2dA0Y0(3/6) AAS
そうだよ
913: (ﾗｸｯﾍﾟ MM0b-2bq/) 2018/10/02(火)16:33 ID:Tcj3k2lbM(2/4) AAS
c++で初心者が作れるものを教えてください
914(1): (ﾜｯﾁｮｲ 9702-aemA) 2018/10/02(火)16:37 ID:kk/2dA0Y0(4/6) AAS
rogueとか作って見てはどうよ
SetConsoleCursorPositionとGetKeyStateがあれば何とかなるだろ
915(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ bf6f-aemA) 2018/10/02(火)16:39 ID:wuORmtyC0(4/4) AAS
>>911
むしろ古い仕様だと後者の i を宣言しようとすると、
ひとつのスコープ内で同じ名前の変数を定義しようとした扱いになってエラーになったりした。
916(1): (ﾜｯﾁｮｲ 9702-aemA) 2018/10/02(火)17:18 ID:kk/2dA0Y0(5/6) AAS
今のコンパイラでも当時の仕様に合わせるオプションはある
917: (ﾗｸｯﾍﾟ MM0b-2bq/) 2018/10/02(火)18:04 ID:Tcj3k2lbM(3/4) AAS
>>914
ありがとう
918: (ﾗｸｯﾍﾟ MM0b-2bq/) 2018/10/02(火)19:05 ID:Tcj3k2lbM(4/4) AAS
C++.でバッチ処理やbashのsedの様な機能はありますか？
919(1): (ﾜｯﾁｮｲ 9702-aemA) 2018/10/02(火)19:11 ID:kk/2dA0Y0(6/6) AAS
システムコマンドを実行したいのならsystem関数
正規表現ならstd::regexクラス
ファイル名に関する様々なことはstd::filesystem::pathクラス
920: (ﾜｯﾁｮｲ 574e-2bq/) 2018/10/02(火)20:37 ID:YnEH1wx10(1) AAS
>>919
ありがとうございます
とても便利です
921(1): (ｵｯﾍﾟｹ Sr4b-N9wp) 2018/10/03(水)01:07 ID:S2BN/gu+r(1/3) AAS
std::array を自作関数の引数に渡したいときって、サイズはハードコードしないとダメなの？
上下前次1-新書関写板覧索設栞歴
あと 81 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.043s