C++相談室 part165
!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること
次スレは>>980が立てること
無理なら細かく安価指定
※前スレ
C++相談室 part164
https://mevius.5ch.net/test/read.cgi/tech/1683600652/
VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured >1 乙です
前スレ 例外はループ脱出に使うような物じゃない、との意見に賛成です。
自分は、例外は「起こり得るけどいちいちエラー処理を書いたらアホな話を」「処理呼び出し毎ではないレベルで」「エラー対処コーディングするもの」と思ってます。
具体例は、
リンクリストなどコレクション操作でメモリ不足が起きた場合、のエラー処理。
コレクションの追加や削除を頻繁に行うコードって、大体はもっと概念レベルが高い事をやってるので、1件の追加 レベルでエラー処理書いてたらアホな感じになる。
しかも、GUI プロセスを作ってて何か上手く動かないから特定のエラーだけを画面に表示したい、など、ことさら明確に対処したい場合です。プロセスが落ちればいいだけなら、main()の外側、の仕様がやってくれる。
古い本の情報だけど、SBリップマンによると、MS VC++と、sun、hp-ux の C++コンパイラで、例外を使う/使わないで速度性能調査したそうで、 4~6% の速度劣化があったとの事です。 スレ終了間際に現れる質問いいですかオジなんなの?w. Pythonで言うと
forのStopIterationは へっ? だし
int()のValueErrorですら微妙 >>3
ヘッダーの最後の行の #endif みたいなものだよ …(いくら5chとは言え、複数の人が集まる場所で、何かを教えて頂いてもお礼も言えず、面白い返しもできない人がいたとして。その人がプログラムに関してだけは素晴らしいコードを書ける、なんてことはあるのかな?と思う瞬間が人生の中であったり、なかったり) (今日の昼飯はセブンのサバ塩焼弁当にしとくか・・・) コードにはある程度そいつの人間性は反映されるな
スレチな話題ではあるけど (でもPythonは使ってもいいのかな?って時々思う) まちゅまちゅの3Dライブみた
前も思ったけどみこちとかなたそのダンス、めっちゃシンクロ率高い
リズムがぴったり一緒なんだよね
ダンスほんとにうまくなったよな (まちゅまちゅの3Dライブ?・・・ちょっと気になる) (((お前ら括弧ばっかり使ってlisperかよ?))) コピーとムーブの挙動、というか管理難しい。。難しくない? コピーやムーブはパターンに沿って管理できるからそんなに難しいとは感じないな。
ワイとしては参照の畳み込み (Reference collapsing) や変換の規則を毎回のように確認するんだけど全然頭に入ってこない。
参照はオブジェクトではないので逆に言えば値に対応する型が参照になることはないのだが、それはそれとして参照を含む型があり得るというのが今でも腑に落ちない。 参照しか知らんものだけど、ムーブて何か簡単に教えて
参照は実装上ただのポインタじゃん
ムーブはなにがどうなるん? >>24
考え方としては、shallow copyを二重開放リスクを避けて行うための仕組み。
右辺値という特別な一時変数のコピーで特別なコピー(ムーブコンストラクタ)を実行するようにして、クラス設計者が必要に応じてshallow copyを実装しやすくしている。 >>24
moveはRustで言う所有権の移動じゃないか >>24
aに戻り値などの一時オブジェクトbをコピーすると通常は
aでメモリを確保
bからメモリコピー
bのデストラクタでメモリを破棄
という動作になるけど、moveの場合
aにbでメモリをポインタで持ってくる
bのインスタンスでは破棄したことにする
とすれば無駄なメモリ確保とコピーが発生せず効率が良い 標準ライブラリでのムーブは所有権 (ownership) の概念を前提として構築されているし、
慣例としてもそのようにするものではあるんだが
言語としてはムーブコンストラクタ (またはムーブ代入演算子) を呼び出すというだけで
所有権の面倒をみる機能は何もない。
(辻褄が合うようにするのはプログラマの責任。)
何が起きているのかは所有権の概念と実装レベルで分けて考えたほうがいいと思う。
どう説明していいかわからんから関連する要素を箇条書きにしたらこんな感じかな。
・ それがコピーの文脈であるかムーブの文脈であるか区別は出来る
・ 一般的にムーブの文脈であった場合 (寿命が尽きる直前の一時オブジェクトの再利用が出来る場合) にコピーより効率が良い動作が出来る可能性がある
・ どのように効率がよくなるのかはそのクラス (のムーブコンストラクタやムーブ代入演算子) の定義次第
・ 典型的なムーブの実装はリソース本体を指すポインタの交換によって実現される
・ ユーザーが定義を与えなかった場合のデフォルトのムーブは全てのサブオブジェクトをムーブすることになっている で、このmove動作を定義するために、
一時オブジェクト(右辺値)に対する参照動作を関数定義できるようになっている ムーブされるとそのポインタは変わってしまうと思うけど、そういうケースはないの? 言っている意味がよく分からないが、純粋なポインタにはムーブという概念はないよ
ムーブを定義できるのはクラスに対してだけ
他の人も言っているようにムーブといっても実体は単なる関数呼び出しなので、その中でプログラマが自分の責任で必要なコードを書くことになる 質問した人じゃないけど説明ありがたいです
ムーブ難しいと思ってたけどもっと早く勉強して仕事で使うべきだった
(文法解析した要素をポインタいじって並べ変えるんだけど…
二重所有を防ぐのを手作業コーディングで責任を持たなければならないプログラムを作ってしまった) ただ、右辺値参照を使うと、通常の参照や代入と使い分けるためにconstやnoexceptを厳密に指定しないといけなくなりがちだから、
その辺の総合的な理解が必要になってくるのは注意点だね
constは一度付け始めるとライブラリ全部に伝染するからな・・・それを嫌って使わない派も結構いる(いた)よね 実際のコードだとポインタのムーブはunique_ptrとかにぶん投げで、自分で移動コード書くことはまずないな
自分でムーブ特殊関数の中身書くのはハンドル的なもののムーブを実現したいときくらい とにかく unique_ptr が便利すぎるから何でもかんでも全部 unique_ptr 使うようになってしまった
まあそれでいいのかもしれないが >>33
銀の弾丸ではない
手作業コーディングで責任を持たなければならないのは変わらない 所有権管理も結局はプログラマが書く (間違いを部分的にコンパイルエラーとして検出できることはある)、
所有権って具体的に何なんだってのはクラス定義に押し込めるという風に管理のレイヤを分けることが出来るってわけ。
クラス定義をした後は具体的に何をやってるのかを忘れて
所有権というものだと思い込むことが出来るという抽象化の仕組み。 >>37
アホか
普通に考えて、そのコード(クラス)の利用者が所有権について明示的に何かしなきゃいけなかったということだろ >>33
エスパーするけど多分その用途だとmoveは使えない。
データを共有している感じなので素直にshared ptrを使うのがいいかと。shared ptrで性能的にキツイならshared ptrを参照渡しするか。 >>40
ちょっと補足すると、戻り値をshared ptrの参照にするのはNGですな。そこは素直にRVOに期待するのが良いか。 VC++なんだけど32bitで_thiscallを関数ポインタ経由で呼ぶことってasm使わないと不可能?
メンバ関数を関数ポインタ変数とすることは出来てもそこから第一引数にインスタンス入れたりしてもコンパイル時エラーになる >>42
メンバ関数をポインタ経由で呼び出したいってことならstd::bindでできるはず VC++ のことは知らんけどメンバ関数ポインタは関数ポインタより大きい実装になってる処理系がある。
メンバ関数ポインタを関数ポインタに変換した時点で呼び出すのに必要な情報が失われているかもしれない。 基本的には言語の規定内でやるに越したことはないので無理な型変換をしないで済ませられるように出来るものならそうしたほうがいい。
どうしてもそうできない事情がある(と質問者が認識している)ならもうちょっと詳しい状況をコードで示して欲しい。 >>43
ありがとう、逆アセ見たら完璧にthiscallになってた
メンバ関数っていうかthiscall指定したものは32bitだとecxレジスタにthisポインタが隠されていてそれ以外はstdcallと同じ
なので下みたいに第一引数にインスタンスのポインタを入れる事でecxに代入される感じになりそうだなーと思ったら無理だった
ちなみに64bitの場合はどちらもfastcallで同じだから単純に第一引数にthisポインタが隠されてるだけ
auto pFunc = CDate::addDay; // CDate addDay(int value)
CDate tomorrow = pFunc(&instance, 1); てかググったら簡単なシミュレーション方法載せてるブログあった
_fastcallで宣言して第二引数のedxを捨て駒にする事で疑似_thiscallになる
つまりint(__fastcall * pFunc)(CDate*, void*, int)とすれば一応アセンブラ的な辻褄は合う事になる 質問なのですが型Tの参照を返す関数 const T& foo() の戻り値をautoのいくつかのバリエーションで受けてアドレスを見て見たのですが
auto x = foo();
auto& y = foo();
const auto z = foo();
const auto& zz = foo();
const volatile auto& zzz = foo();
cout << "&original=" << &g_vec << endl; // &original = 00B013D8 (このアドレスは一例)
cout << "&x=" << &x << endl; // &x = 010FF8AC // コピー(意図しないかも?)
cout << "&y=" << &y << endl; // &y = 00B013D8 // 参照(OK)
cout << "&z=" << &z << endl; // &z = 010FF888 // コピー(意図しないかも?)
cout << "&zz=" << &zz << endl; // &zz = 00B013D8 // 参照(OK)
cout << "&zzz=" << &zzz << endl; // &zzz = 1 // !!!!
という行末コメントに記載の結果になったお
Q1. 参照で受けたい場合は auto でなく auto& とせねばならない、で正しい?
Q2. 間違えてauto で受けても動いてしまい発見し難いケースが多いと思うのですが
意図しないパフォーマンス低下になるので防ぐ対策とか無い?
Q3. zzzのアドレスが1になるのは一体……
MSVC2019使用、言語の設定はC++14、 >>50
A1. 単に auto としたときに参照になることはない。
参照として受け取りたい場合は auto& にせねばならないというのは正しい。
A2. 参照かどうかで自動的に場合分けして欲しいなら decltype(auto) とすればいいが……
参照で受けるのが正しい状況なのかどうかは状況による。
テンプレート内など自動的な場合分けが必要な場合を除いては参照は参照として明示したほうがよくない?
(個人的感想です。)
A3. いくつか用意されている operator<< の基本的なオーバーロードの内で bool にマッチするから。
void* もあるのだけれど C++ では任意のポインタは void* へは暗黙の型変換されないのでマッチング候補にならない。
アドレスとして解釈して欲しいなら void* へ明示的に型変換しないといけない。 ごめん。 間違いがあった。
ポインタは void* へ暗黙に変換できる。
この変換はオーバーロード解決時の候補になりうる。
ただ、 bool への変換とは優先順位に差がある。 >>51>>52
㌧クス、
なるほど
わかりた
↓こうなったわ
decltype(auto) z = foo();
const auto& zz = foo();
const volatile auto& zzz = foo();
cout << "&original=" << (void*)&g_vec << endl; // &original=010213D8 (このアドレスは一例)
cout << "&z=" << (void*)&z << endl; // &z=010213D8 // 参照(OK)
cout << "&zz=" << (void*)&zz << endl; // &zz=010213D8 // 参照(OK)
cout << "&zzz=" << (void*)&zzz << endl; // &zzz=010213D8 // 参照(OK)
cout << std::boolalpha << "&zzz=" << &zzz << endl; // &zzz=true // boolean
boolへの変換は使うことは無いと思うが正体は調べてみるわ >テンプレート内など自動的な場合分けが必要な場合を除いては参照は参照として明示したほうがよくない?
非constなら考えるがこの場合foo()はconstオヌジェクトと参照を返してくるし、
これはもうdecltype(auto)一択で良いような気がが、 volatile を追加する変換は出来るが除く変換は出来ないから
volatile 付きのオーバーロードを用意していない operator<< では候補から消えて
bool だけが候補として残ってしまうってことになるみたいだな。
volatile が付いていない場合は
void* への変換のほうが bool への変換より優先順位が高いので
そっちが呼ばれる。 ラムダの参照キャプチャってconst参照に指定できないんだっけ?微妙に不便だな。 >>60
これじゃだめ?
#include <iostream>
using namespace std;
int main () {
const int a {0};
int b {0};
[&a, &b = const_cast <const int &> (b)] () {
++ a; // X
++ b; // X
} ();
return 0;
} C++20 RangesはMicrosoftの説明がわかりやすかった ふと今更思ったんだけど
ポインターpに対して演算子*が返す*pは、
値じゃなくて参照? #include <type_traits>
#include <iostream>
using namespace std;
int main () {
int value {0};
int *p {&value};
cout << is_reference <int>::value << '\n';
cout << is_reference <int &>::value << '\n';
cout << is_reference <decltype (value)>::value << '\n';
cout << is_reference <decltype (*p)>::value << '\n';
return 0;
} >>63
参照ってのが何を意味しているか分からんが
普通はポインターの示す場所の内容だ >>63
ポインター p に対して *p とした場合の型は参照ではない。
たぶん >>64 は *p が参照と言いたいつもりで書いているんだと思うけど
decltype に与えられる式の型が T 型の lvalue だった場合には T& が返されるルールなので
その式が参照でなくても参照が返されることがある。 あ、ごめん。 完全に間違った説明してたわ。 忘れて……。 恥ずかしい。 と思ってよく仕様を読んでみたらやっぱりこの (>>66) 考え方で正しいはず。
式が識別子式の時に限っては decltype は参照にならず式の型そのままで返すせいで decltype(value) は参照にならないが、
value と *p は型システム的にも値カテゴリ的にも同じだわ。 巷のスマートポインタはoperator*で参照型を返すので
生ポインタも同じかと思ってたよ 互換性の都合とかがあるから仕方ないね。
場合分けが大量にあって単純な一般原則の組み合わせにはなってないから仕様を読み解くのがしんどい…… ある構造体Aがあります
Aの比較関数が複数ありますcompA0,compA1,compA2,...
比較関数の関数ポインタがありますcompA
compA = &compA2;
別の構造体Bがあります
BはAを内包しています
struct B{ A a; ... };
この構造体Bを、Aの比較関数ポインタcompAで比較してソートするにはどう記述すればよいですか?
std::vector<B> bs;
bs.push_back(...);...
std::sort(bs.begin(),bs.end(),?);
できればラムダ式を使わずにできるとありがたいです >>72
ラムダ式使った方が良いと思うけど本当にラムダ式なしが良い? 使われると、ラムダ式の質問をすることになると思います・・・ >>72
もし C++20 を使えるなら (std::sort と違って) std::ranges::sort では比較関数とは別に
比較すべき要素を取り出す操作をプロジェクションとして与えることが出来るから
これ一発でいけてだいぶん楽できる。
std::ranges::sort(bs, compA, &B::a); >>74
思い出すのがしんどくなってきた
#include <iostream>
#include <vector>
#include <algorithm>
#include <functional>
using namespace std;
struct A {int value_;};
bool compA2 (const A &lhs, const A &rhs) {
return lhs.value_ < rhs.value_;
}
struct B {A a;};
int main () {
vector <B> bs;
bool (*compA) (const A &, const A &) {compA2};
sort (bs.begin(), bs.end(), bind (compA, bind (mem_fn (&B::a), placeholders::_1), bind (mem_fn (&B::a), placeholders::_2)));
sort (bs.begin(), bs.end(), [compA] (const auto &lhs, const auto &rhs) {return (*compA) (lhs.a, rhs.a);});
return 0;
} >>75
>>77
お二方、ありがとうございます
参考にして組んでみます その場で合成するのはさすがに見通しが悪すぎるので、
C++11 頃の C++ を仮定して私がやるならまずアダプタを作ると思う。
ちょっと雑ですまんがとりあえずこんな感じ。
class compB_adaptor {
private:
using comparator = std::function<bool(const A&, const A&)>;
comparator compA;
public:
compB_adaptor(comparator comp) : compA(comp) {}
bool operator()(const B& x, const B& y) {
return compA(x.a, y.a);
}
};
使うときには間にひとつ挟むだけで済む。
std::sort(bs.begin(), bs.end(), compB_adaptor(compA)); >>79
求めていたものそのものであったため、採用させていただきました
ありがとうございます int x;
std::cout << x;
でxが正ののときは「+」符号を付けさせるのってどうするんでしたっけ……
cout.form("%+d", x)とか以外で てきました㌧クス、
iosヘッダで探せば良かったのか、、、 C++23だとこれ
std::print("{:+}", x); PythonやC#のようなf"{x}"構文が作られる事はないんだろうか >>85
リフレクションが充実すればその上に実装できるので
直接的な言語機能として用意すると
辻褄合わせが後で面倒になるだろうし、
現時点で考えるのは時期尚早だと思う。 質問なのですが自作クラスFooのストリーム出力演算子に引数付きのマニピュレータを追加したいのですが
↓こんなやつ
Foo obj;
cout << custom_setw(10) << obj; // 整数のベクトル的なオブジェクトobjの要素を幅10文字で出力
custom_setw()で与えた10という数値をつつがなくFooのストリーム出力演算子
std::ostream& operator<<(std::ostream& os, const Foo& obj)
に渡すには一体どうすれば……orz グローバル変数渡しは最初に思いつくのですが、ostringstream os1, os2とFoo obj1, obj2に対して異なるスレッドで
os1 << custom_setw(30) << obj1; // スレッド1
os2 << custom_setw(20) << obj2; // スレッド2
とかやったら詰むし
std::setw()とか一体どうやってるんじゃ…… >>87-88
特定の型を出力するときにだけ作用する書式を設定するマニピュレータってこと?
std::setw がやってるのはストリームのメンバ関数 width を呼ぶのと同じ。
ストリームのオブジェクトが幅に関する情報を保存するデータメンバを持っていて、それを変更してる。
もちろんあなたが定義した独自の型 (この例では Foo) に結び付いた書式を保持するところなんて存在しないから単純にはできない。
私が思いつくのは
・ ストリームのほうも新しいものを定義する、つまり basic_ostream を継承して Foo 用の書式を格納するデータメンバを増やす
・ ストリームに対応付いたデータを格納するものを std::map かなんかで保持しておいて Foo を出力するときはそれを参照する
ということくらいかな。
スレッドが絡むと面倒くさいけど、しょうがないね。 既存のcoutとかstringstreamとかで使いたいなら、グローバルのstd::unordered_map<std::ios_base*, MyManipData>にでも置いとくしかないだろうね
ストリームオブジェクトの状態で持たせるクソ設計が悪いんだ レス㌧クス、
>ストリームのオブジェクトが幅に関する情報を保存するデータメンバを持っていて、それを変更してる。
なるほど……
これはユザーの立場からはメンバの追加ができない領域なので、Fooの側にメンバを持たせることにしますか……
class FooWrp {
const Foo& m_objRef;
int m_nWidth;
public:
FooWrp(const Foo& obj, int width) : m_objRef(obj), m_nWidh(width) { }
friend std::ostream& operator<<(std::ostream& os, const FooWrp& wrp) { ...(wrp.m_objRefの要素をwrp.m_nWidthに描かれている幅で出力する処理)... }
}; // 使い方
Foo obj;
cout << FooWrp(obj, 10);
ダッサwwwwwwwwwwwwwwwwwww
しかし、「たかが表示の整形」のために排他制御しつつmapを弄ったりTLSの利用を考えるのもアレなのでこれはこれで仕方が無いのか、orz ストリーム用の演算子なんか作らずに
オブジェクトの文字列表現を返す関数を用意したほうが汎用性高くない? Foo obj;
std::string s = obj.str(10); // 10億ギガ文字
cout << s;
出力を完遂できるんかこれ…… C++20 からは std::formatter を特殊化して書式指定を解釈するコードを入れておけば
std::format で独自の型を表示しようとしたときにその特殊化が使われる仕組みになってる。 オブジェクトの文字列表現が10億ギガ文字もあるの!?
FooWrpオブジェクトをうっかりログに出力しちゃったら大変だね!! 実験せずに質問するますが、
int a, b;
cin >> &x >> &y;
に対し、
Q1. 「100 a」を入力したら例外もタイムアウト待ちも発生せず、cin.fail()がtrueになるだけ?
Q2. 「100」とだけ入力してそのまんま(リダイレクト元のファイルハンドルか何かが
タイムアウトもエラーもクローズもしなければ)ならそれっきり返ってこない? EOFが抜けてたorz
Q2のケースにおいて「100 [EOF]」なら(多分)cin.fail()でとりあえずすぐ返ってくるのかそうか、