>>600
サンプル貼ってよ
サンプル貼ってよ
std::swapも右辺値参照も全然上手く行きそうになかっのたで
宣言をポインタにして
private:
std::vector<short> *_stdSansyo;
void sansyo::setSansyo(std::vector<short>& sansyo)
{
_stdSansyo = &sansyo;
sansyo[6] = 100;
_stdSansyo->data()[5] = 50;
}
関数をこんなふうに書き換えたら、ちゃんと参照だけで動いたのでもういいや
けど右辺値参照とstd::swapの例も出してくれたらこれから色々いたスカリマス
宣言をポインタにして
private:
std::vector<short> *_stdSansyo;
void sansyo::setSansyo(std::vector<short>& sansyo)
{
_stdSansyo = &sansyo;
sansyo[6] = 100;
_stdSansyo->data()[5] = 50;
}
関数をこんなふうに書き換えたら、ちゃんと参照だけで動いたのでもういいや
けど右辺値参照とstd::swapの例も出してくれたらこれから色々いたスカリマス
>>599
参照渡し自体はできてるはず。
ただ参照渡ししたvectorをクラスのメンバに代入して、代入されたクラスメンバの方を更新しているからvectorを渡した元の方にはまったく影響が無いというだけ。
参照渡し自体はできてるはず。
ただ参照渡ししたvectorをクラスのメンバに代入して、代入されたクラスメンバの方を更新しているからvectorを渡した元の方にはまったく影響が無いというだけ。
sansyo::_stdSanshoをどうしても参照にしたいならこうするしか、
class sansho {
private:
std::vector<short> _stdSansyo;
public:
sansho(std::vector<short>& src) : _stdSansyo(src) { }
void setSansyo(std::vector<short>& sansyo);
};
void sansyo::setSansyo(std::vector<short>& sansyo) {
_stdSansyo[5] = 500;
}
int main() {
std::vector<short> moto;
sansyo cSansyo(moto); //ここで参照渡し
for (int i = 0; i < 10; i++) {
short tmp = i * 2;
moto.push_back(tmp);
}
cSansyo.setSansyo(moto); // moto[5]に500が入りまくり
for (int i = 0; i < 10; i++) {
std::cout << "値=" << moto[i] << "\n"; //値が変わった！（予定
}
};
class sansho {
private:
std::vector<short> _stdSansyo;
public:
sansho(std::vector<short>& src) : _stdSansyo(src) { }
void setSansyo(std::vector<short>& sansyo);
};
void sansyo::setSansyo(std::vector<short>& sansyo) {
_stdSansyo[5] = 500;
}
int main() {
std::vector<short> moto;
sansyo cSansyo(moto); //ここで参照渡し
for (int i = 0; i < 10; i++) {
short tmp = i * 2;
moto.push_back(tmp);
}
cSansyo.setSansyo(moto); // moto[5]に500が入りまくり
for (int i = 0; i < 10; i++) {
std::cout << "値=" << moto[i] << "\n"; //値が変わった！（予定
}
};
>>598
だったら何だとぬかす気だ？
> 存在しないものを見てニヤニヤしてる変態こわい
> 文章を字面通りにしか解釈できない人？
要するに話になんない奴ってことだろ
言ったことにも裏の意味にもコメントされたくない
じゃあ相手しねえでやるから黙ってろゴミ
だったら何だとぬかす気だ？
> 存在しないものを見てニヤニヤしてる変態こわい
> 文章を字面通りにしか解釈できない人？
要するに話になんない奴ってことだろ
言ったことにも裏の意味にもコメントされたくない
じゃあ相手しねえでやるから黙ってろゴミ
訂正orz
誤： private: std::vector<short> _stdSansyo;
正： private: std::vector<short>& _stdSansyo;
もしcSansyo.setSansyo(moto)の呼び出し時に参照を渡したいんじゃああ！
という向きにはsansyo::_stdSansyoはstd::vector<short>* _stdSanshoにして
ポインタを持つようにすべき
誤： private: std::vector<short> _stdSansyo;
正： private: std::vector<short>& _stdSansyo;
もしcSansyo.setSansyo(moto)の呼び出し時に参照を渡したいんじゃああ！
という向きにはsansyo::_stdSansyoはstd::vector<short>* _stdSanshoにして
ポインタを持つようにすべき
ちゅかもっと大きな一般原則としてつぎのどっちかにすべき
(1) std::vector<short>の実体の所有権をmain()（で定義いているmoto）に固定してcSanshoクラスにmotoのアドレスを記憶させない
(2) std::vector<short>の実体の所有権をcSanshoクラスのインスタンス（_stdSansyo;）に固定してmain()でmotoを定義するのをやめる
※ 個人の感想です
つまり出題が悪い。出し直し
(1) std::vector<short>の実体の所有権をmain()（で定義いているmoto）に固定してcSanshoクラスにmotoのアドレスを記憶させない
(2) std::vector<short>の実体の所有権をcSanshoクラスのインスタンス（_stdSansyo;）に固定してmain()でmotoを定義するのをやめる
※ 個人の感想です
つまり出題が悪い。出し直し
検証不能な事物を錦の御旗にするような人間が
ソフトウェアのテスト推しなのは
大いなる矛盾である氏ね
ソフトウェアのテスト推しなのは
大いなる矛盾である氏ね
>>611
あの流れで
> 文章を字面通りにしか解釈できない人？
なんてぬかすやつは複数ID自演厨と見なされて当然だ
疑われたくなければ口の利き方に気をつけな
疑いは晴れてない
この後の発言にも気をつけるんだな
あの流れで
> 文章を字面通りにしか解釈できない人？
なんてぬかすやつは複数ID自演厨と見なされて当然だ
疑われたくなければ口の利き方に気をつけな
疑いは晴れてない
この後の発言にも気をつけるんだな
参照をフィールドに保持するのは、一部のパーサーくらいでは？
しかも、状態を関数に切り分けないとデバッグが辛いので、仕方なくそうするだけで、バッド何とかの類だし。
しかも、状態を関数に切り分けないとデバッグが辛いので、仕方なくそうするだけで、バッド何とかの類だし。
むかし5chで誰かが、プログラムを書くときは必ずテストしてるはずなんだって言ってましたが。
それを単体テストとして書いておけばずっと使えて便利だよと。
その書き込みを見て世界中の人がテストフレームワークを書き始めたんですよ。
それを単体テストとして書いておけばずっと使えて便利だよと。
その書き込みを見て世界中の人がテストフレームワークを書き始めたんですよ。
バッドエンディングですね。
グローバル変数使うなとは言わないけどコメントもないのはキツい
grep掛けて検索しても訳分からん
ポインタで飛び火してるときなんてもう…
grep掛けて検索しても訳分からん
ポインタで飛び火してるときなんてもう…
演算子オーバーロードの厄介さはキーワード検索で拾いにくいこと。
反復子もそうだが。ま、言い出したらきりないが。
反復子もそうだが。ま、言い出したらきりないが。
>>561を書いたのは私なんだけどなぁ...
面倒くさそうな人がいるし、一般論だけ言って立ち去ろって思っただけ
面倒くさそうな人がいるし、一般論だけ言って立ち去ろって思っただけ
ちなみに、>>561以降は何も述べてない。
私は一般論を語っただけだから、他の人が私と似た考えでツッコミを入れただけに過ぎない。
殺虫剤のパラドックス？それがどうした？
私はテストコードを書いて不具合を激的に抑えているが？
殺虫剤のパラドックスを説明したところで、不具合を限りなくゼロに近づける試みが無駄であることの証明にはならない。
私は一般論を語っただけだから、他の人が私と似た考えでツッコミを入れただけに過ぎない。
殺虫剤のパラドックス？それがどうした？
私はテストコードを書いて不具合を激的に抑えているが？
殺虫剤のパラドックスを説明したところで、不具合を限りなくゼロに近づける試みが無駄であることの証明にはならない。
>>622-623
自我の芽生え、おめでとう！
では、かえるの歌を歌います。
【...JASRAC権利関係の為、自主検閲...】
♪パパーン
(全員でクラッカーを鳴らす)
自我の芽生え、おめでとう！
では、かえるの歌を歌います。
【...JASRAC権利関係の為、自主検閲...】
♪パパーン
(全員でクラッカーを鳴らす)
殺虫剤のパラドックスなんてものは存在しない。
ただの退行テスト不足だ。
ただの退行テスト不足だ。
殺虫剤のパラドックスって言いたかっただけやろw
そもそもテストで発覚したバグを修正したら同じテストで摘出できないのは当たり前
摘出できたら単なる修正漏れだしw
JSTQBの関係者か信奉者が言い出したんだろうけどあまり意味のない用語だと思う
そもそもテストで発覚したバグを修正したら同じテストで摘出できないのは当たり前
摘出できたら単なる修正漏れだしw
JSTQBの関係者か信奉者が言い出したんだろうけどあまり意味のない用語だと思う
蒸し返さなくていいから……
虫返さないですと！？
スルーの法則
コンストラクタでなら参照型のメンバ変数に保存できる。ほとんどの人はやらないけど。
>>633
できるのと実際に実装するのは別の話だわな。
所有権の無いオブジェクトの参照を保存するなんて狂気の沙汰だ。
できるのと実際に実装するのは別の話だわな。
所有権の無いオブジェクトの参照を保存するなんて狂気の沙汰だ。
アイキャンユーキャン。
shared_ptr(またはスマポ)至上主義の変なやつ以前から居るんだよな
相手にするな
相手にするな
ナマポ使ったほうが良い場面なんて皆無でしょう
出たwナマポ完全否定奴w
参照型のメンバ変数は参照オブジェクトの生存期間を保証できないからweak_ptrで保存しておいて使う時だけshared_ptrを取得するのがC++的な解決なんじゃないの。
スマポにしたら所有権の問題を考えなくてよい
というわけではないからスマポ使えというのは妥当ではない
逆に所有権に矛盾が無ければインスタンスは生成元が与えた参照を持って良い
ていうかスコープを抜けたら自動的に解放される系のクラスを書いたら
エラー処理上エラー通知先としての生成元オブジェクトの参照保持はほとんど不可避
というわけではないからスマポ使えというのは妥当ではない
逆に所有権に矛盾が無ければインスタンスは生成元が与えた参照を持って良い
ていうかスコープを抜けたら自動的に解放される系のクラスを書いたら
エラー処理上エラー通知先としての生成元オブジェクトの参照保持はほとんど不可避
コピー禁止のshared_ptr欲しい
すべてスマポで書くスタイルも悪くないと思うけど、メイヤーズ神もツリー構造で子が親のポインタを持つときはナマポで十分と書いている
木のノードは子へのポインタじゃなくて子のノードIDを持て😡
自分よりポインタの方が寿命が長いことが保証されているなら確かに生ポで問題ないが
それが成り立つ状況ってなかなかないよな。
それが成り立つ状況ってなかなかないよな。
参照先の実体がまだ生存しているかどうか知るにはweak_ptr::expired()を使うしかないのが現状でしょ。
Chromiumはstd::unique_ptrを全面的に使ってるけど、ポインタを使う設計そのものが古いような気がする。
まあcコードを全く使わないってのならいいんでないの。
ただc++のポータビリティーは君が思ってるより低いけどね。
ただc++のポータビリティーは君が思ってるより低いけどね。
露骨すぎるマウント取りたがりダッセーｗｗｗ
マウントじゃなくてポインタでは？
C++に特化したAPIなんてどこのOSでも提供されないから、結局、Cの配列と互換性のあるstd::vectorやstd::arrayを使わざるを得なくなる。
木は木全体を収める領域ごと一気に解放する場合もあるから別に
>Cの配列と互換性のある
doubt
doubt
ダウトとデビューって似てるよね
親が子のポインタを所有する木は、親を消すとネストして子孫のデストラクタを呼ぶので、スタックが枯渇します。
したがって、子から順番に消さなくてはなりません。
したがって、子から順番に消さなくてはなりません。
その様はまるで摩天楼がドミノ倒しのように連鎖倒壊するようでもあり、DOMINOというピザにもなっています・
なんと後味の悪い話
意味が分からない
探索はループでもできるんで、たとえば数万個の要素を持つツリーを子から消せというのは真理なのかも
消すのは独立して実行できるので別スレッドに送れば実質コスト0
>>662
DFAとPDAではやれることの範囲の違いがちげう
つかこの場合は安易にスマポとかコンテナを使うから破棄ごときにトラバースの手間がかかるんである
DFAとPDAではやれることの範囲の違いがちげう
つかこの場合は安易にスマポとかコンテナを使うから破棄ごときにトラバースの手間がかかるんである
それもそうであるな
ちゅか垂直探索なら木をメモリに持っておく必要が無い
水平探索ならメモリ上に世代1、世代2、....と木を育てていく（らしい）が
兄弟ノードを全部見終えたのでいざ従妹ノードに移ろうとするときに
親ノードへの参照は欲しい木がするがするとshared_ptrなら即循環参照になり、
子の情報で親（子孫がいっぱいぶら下がっている）を生成できるわけもないから、
ウィークポインタの出番でもない
水平探索ならメモリ上に世代1、世代2、....と木を育てていく（らしい）が
兄弟ノードを全部見終えたのでいざ従妹ノードに移ろうとするときに
親ノードへの参照は欲しい木がするがするとshared_ptrなら即循環参照になり、
子の情報で親（子孫がいっぱいぶら下がっている）を生成できるわけもないから、
ウィークポインタの出番でもない
子から消さなかったばかりに。
2000人を乗せた航空機が洋上で消えた。
ってなるかも？
2000人を乗せた航空機が洋上で消えた。
ってなるかも？
A380でさえ853席だが2000人なんてどうやって載せるんだろう
く、空中で衝突するとか…
インドでは屋根の上にも乗ります。
https://trafficnews.jp/post/80031
証拠写真みつけてきた。
証拠写真みつけてきた。
GTA5のMOD作成者みたいな会話だな
アントノフの貨物室にすし詰めでどんくらい乗れるかな
東京: TK
京都: KT
大阪: OSK
淡路: AWG
京都: KT
大阪: OSK
淡路: AWG
航空機や原発みたいなクリティカルなシステムでは
全部固定長の配列で書いてあるんじゃないの
全部固定長の配列で書いてあるんじゃないの
釣れますか。
ヒープのほうが少し安全です。
ヒープのほうが少し安全です。
すみません、std::for_each を使っていて continue したくなりましたが、サポートしてないです
よね? これって:
1. for_each は continue する必要がないような処理に限ってに使うべき。
2. ループの中で大きい if ブロックを作って空の処理にすればよい。
3. その他
よね? これって:
1. for_each は continue する必要がないような処理に限ってに使うべき。
2. ループの中で大きい if ブロックを作って空の処理にすればよい。
3. その他
returnすれば？
for_each(begin(foo), end(foo), []{ if(bar) return; });
for_each(begin(foo), end(foo), []{ if(bar) return; });
return は continue ではなく break じゃないの？
質問者の2.大きなif分で実質何もしないでいいと思う
質問者の2.大きなif分で実質何もしないでいいと思う
for_eachをbreakするにはthrowかlongjmpがいるぞ
きったねぇジャンプだ
あ、ラムダ式になってたのか
>>679
for 文で書いた方が短く書けそうだけど、
あえて for_each を使いたい理由が何かあったりするの？
for 文で書いた方が短く書けそうだけど、
あえて for_each を使いたい理由が何かあったりするの？
Perlなら問題無くできる（continue→next、だが
C++規格委員会がfor_eachのcontinueを許可しないのは最後の一線なのかもしれん…
C++規格委員会がfor_eachのcontinueを許可しないのは最後の一線なのかもしれん…
何の一線よ
いやreturnでいいだろ…
許可しないってなんのことだよ
許可しないってなんのことだよ
vectorで一億件ほどで、飛ばしたいのが100〜1000件程度なんだろう
range based forなら普通にcontinueできるぞ
early returnは正義
679がなぜfor_eachを使うのかを無視するのは
他人の領分を侵すお節介だ
for_eachの使い方をアドバイスできんやつは
しゃしゃり出てくるな
他人の領分を侵すお節介だ
for_eachの使い方をアドバイスできんやつは
しゃしゃり出てくるな
よくよく話を聞いてみたらまるで異なる解決策が見つかるなんてよくあることじゃん。そんな経験ないの？
何をしたかったか確認するのは重要
何をしたかったか確認するのは重要
流れをよく読んでみろよ
for_eachをロクに使ってないやつなのモロバレだろ
質問者が尋ねていないことを答えたいから協力しろなんてぬかすのは
回答者の資格ねえんだよ
for_eachをロクに使ってないやつなのモロバレだろ
質問者が尋ねていないことを答えたいから協力しろなんてぬかすのは
回答者の資格ねえんだよ
自分が何か尋ねているときに
質問内容に付き合ってやれる懐のねえやつは
うぜえだけだろが
質問内容に付き合ってやれる懐のねえやつは
うぜえだけだろが
質問内容において自分より下なやつに教えを請いたいかよ
for_eachを使う場合の答えはとっくに出てるのに何言ってんの？
3のその他で答えただけ。
他人の領分なんて侵してナンボ
>>679はループしたいだけだろ
std::for_eachを何が何でも使わなければならない特殊な事情があるなら仕方ないけどそんなこと言ってないし
std::for_eachを何が何でも使わなければならない特殊な事情があるなら仕方ないけどそんなこと言ってないし
Visual Studio 2010（MSVC2010）で
template<class T>
void foo(T x) {
printf("%d: %d\n", targetEntity, x);
}
という関数テンプレートが定義されているときに、
namespace bar { const int targetEntity = 1; }
using bar::targetEntity;
void baz() { foo(100); }
はコンパイルが通るのに、
namespace bar { const int targetEntity = 1; }
void baz() {
using bar::targetEntity;
foo(100);
}
だと
error C2065: 'targetEntity': 定義されていない識別子です。
と言われるorz
template<class T>
void foo(T x) {
printf("%d: %d\n", targetEntity, x);
}
という関数テンプレートが定義されているときに、
namespace bar { const int targetEntity = 1; }
using bar::targetEntity;
void baz() { foo(100); }
はコンパイルが通るのに、
namespace bar { const int targetEntity = 1; }
void baz() {
using bar::targetEntity;
foo(100);
}
だと
error C2065: 'targetEntity': 定義されていない識別子です。
と言われるorz
>>688
for_eachを勘違いいてたわｻｰｾﾝ、
確かにfor_each<bgn, end, Function>のFunction(*it)からならreturnするで良さげ
for_eachを勘違いいてたわｻｰｾﾝ、
確かにfor_each<bgn, end, Function>のFunction(*it)からならreturnするで良さげ
>>708
宣言の有効範囲は宣言された場所からその宣言を含むブロックの終わりまでというのが原則
(クラススコープなどの例外はあるのでその他にも関連するルールはあるかもしれんけど)
なのでどちらもエラーになるのが筋だと思うし、 gcc や clang で試したらどっちもエラーだった。
逆にどういう理屈で前者が通るのかは気になる。
宣言の有効範囲は宣言された場所からその宣言を含むブロックの終わりまでというのが原則
(クラススコープなどの例外はあるのでその他にも関連するルールはあるかもしれんけど)
なのでどちらもエラーになるのが筋だと思うし、 gcc や clang で試したらどっちもエラーだった。
逆にどういう理屈で前者が通るのかは気になる。
- barよりも後方
+ usingよりも後方
+ usingよりも後方
確かにideoneでもVS2019でも両方エラーになるのですだが、
1番目の例はVS2010ではビルドも通って動くもーん
ソース:
https://ideone.com/DC8fMv
実行結果（※ VS2010限定）：
1: 100
続行するには何かキーを押してください . . .
1番目の例はVS2010ではビルドも通って動くもーん
ソース:
https://ideone.com/DC8fMv
実行結果（※ VS2010限定）：
1: 100
続行するには何かキーを押してください . . .
ちな関数テンプレートfoo()の定義をusingよりも後方にしたら全てでビルドが通って動く
まそりゃーそうならないとおかしいが
まそりゃーそうならないとおかしいが
だから何？
ill-formedなのがわかっても自分が正しいと強弁したいのか？
ill-formedなのがわかっても自分が正しいと強弁したいのか？
覆った？
おまえVS2010限定で逃げただろ
ill-formedはill-formed
これを覆せたら出直して来な
おまえVS2010限定で逃げただろ
ill-formedはill-formed
これを覆せたら出直して来な
俺も昔のバージョンのコンパイラは使うがバグ技は使わないし
そういうことをする厨二病とは組みたくない
そういうことをする厨二病とは組みたくない
>おまえVS2010限定で逃げただろ
VS2010ではビルドが通るというのが話の発端なので…
1番目の例がill-formedであろう点は同意
VS2010ではビルドが通るというのが話の発端なので…
1番目の例がill-formedであろう点は同意
orzなんだろ
何が誰が悪いのかわかったら素直になれよ
居直る態度が気に入らねえ
何が誰が悪いのかわかったら素直になれよ
居直る態度が気に入らねえ
何が悪いのか、はともかく
誰が悪いのかとは一体…
つか現象（事実）の提示に対してそれを反発と解釈して勝手に炎上しないでいただきたい；；；
個人的にはVS2010のバグである可能性でほぼ確定とは思いつつ、
例1と例2で動きが違うことから、MSVC2010は、グローバルなシンボルについて
template foo()や関数baz()の中の解釈に入る前に名前空間を確定させる実装なのだと感じる
（template foo()の解釈ロジック自体にバグがあるなら例1、2とも同じ結果になるのが自然
再発防止のためには、C++規格のどこをどう読めば良いんじゃorz
誰が悪いのかとは一体…
つか現象（事実）の提示に対してそれを反発と解釈して勝手に炎上しないでいただきたい；；；
個人的にはVS2010のバグである可能性でほぼ確定とは思いつつ、
例1と例2で動きが違うことから、MSVC2010は、グローバルなシンボルについて
template foo()や関数baz()の中の解釈に入る前に名前空間を確定させる実装なのだと感じる
（template foo()の解釈ロジック自体にバグがあるなら例1、2とも同じ結果になるのが自然
再発防止のためには、C++規格のどこをどう読めば良いんじゃorz
>>719は明らかに煽り口調だろうが
和解したいなら、あの態度を撤回しろ
俺は和解なんかできなくて構わんが
和解したいなら、あの態度を撤回しろ
俺は和解なんかできなくて構わんが
匿名掲示板で誰が何を言ったのどうのとみっともないぞデフォルトの名無しさんよ
どう見ても>>716がイミフな言いがかりつけてるだけにしか見えんが…
> 確かにideoneでもVS2019でも両方エラーになるのですだが、
> 1番目の例はVS2010ではビルドも通って動くもーん
> 確かにideoneでもVS2019でも両方エラーになるのですだが、
> 1番目の例はVS2010ではビルドも通って動くもーん
匿名でも江副とかQZとか片山やはちみつが糞なのは伝わってくるω
単発IDになりやがった
どこまでも腐ってやがるな
どこまでも腐ってやがるな
どこでも動くように標準化しましょうねって話だよね。
G++とかclang++などの複数のコンパイラで警告最大にして自動ビルドすれば再発防止できると思われます。
流れをぶった切って質問です。
あるクラスで生成、削除を一切合切プライベートにしたい（ファクトリメソッドでスマートポインタを渡す）んだけど、
::deleteを対象クラスだけプライベート、あるいはコンパイルエラーにする
ことって可能かしらん？
あるクラスで生成、削除を一切合切プライベートにしたい（ファクトリメソッドでスマートポインタを渡す）んだけど、
::deleteを対象クラスだけプライベート、あるいはコンパイルエラーにする
ことって可能かしらん？
dtorはデストラクターの略ね。
死のトラクターじゃないよ。
死のトラクターじゃないよ。
映画化決定。
>>728
私が馬鹿なのは私自身が認めていることですが、片山さんはすごいと思いますよ、何よりも片山さんは多産ですし、私は片山さんを尊敬しています‥‥
私が馬鹿なのは私自身が認めていることですが、片山さんはすごいと思いますよ、何よりも片山さんは多産ですし、私は片山さんを尊敬しています‥‥
>>733
ありがとう。参考になりました。
流石にグローバルdtorの直接呼び出しを気にしている人は居なさそうですね。
通常の使い方じゃないから気にするな、が正解かしらん。
ありがとう。参考になりました。
流石にグローバルdtorの直接呼び出しを気にしている人は居なさそうですね。
通常の使い方じゃないから気にするな、が正解かしらん。
画像
つかprivate dtorって何の解決にもなって
なくね？
クラスFooのデストラがprivateな時点で
Fooのfirendでも何でもないstd::shared_ptr<Foo>はビルドエラーになる宿命なのでは…
あとp.get()->Delete()とされるのも恐ろしいすぐる………
なくね？
クラスFooのデストラがprivateな時点で
Fooのfirendでも何でもないstd::shared_ptr<Foo>はビルドエラーになる宿命なのでは…
あとp.get()->Delete()とされるのも恐ろしいすぐる………
operator <=>を定義しても
==と!=が使えるようにならないのは、なんで？
==と!=が使えるようにならないのは、なんで？
https://cpprefjp.github.io/lang/cpp20/consistent_comparison.html
のoperator==節で仕様とその理由についても説明してあります
のoperator==節で仕様とその理由についても説明してあります
relops
relops
なるほどわからん。弱順序って何よ？
>>746
擬順序とか半順序と呼ぶ本もありますね、
ただ、その「比較可能性を満たす」とはなんでしょうか？私の教科書では、擬順序には反射律・推移律だけしか要請されていなかったと記憶しているのですが？
擬順序とか半順序と呼ぶ本もありますね、
ただ、その「比較可能性を満たす」とはなんでしょうか？私の教科書では、擬順序には反射律・推移律だけしか要請されていなかったと記憶しているのですが？
普通に言葉通り任意の2つの元を比較できるということなのでは…
木構造で「親は子より大きい」という順序を定義しただけ
（全順序集合（例えば整数）で全ノードをラベル付けしてしまうというチート手段に訴えことなく、
文字通り「if (aはbの親） { a > b; }」という規則と(a, b)の反射律、推移律を導入しただけ
では兄弟間の大小が定まらない、
みたいな
木構造で「親は子より大きい」という順序を定義しただけ
（全順序集合（例えば整数）で全ノードをラベル付けしてしまうというチート手段に訴えことなく、
文字通り「if (aはbの親） { a > b; }」という規則と(a, b)の反射律、推移律を導入しただけ
では兄弟間の大小が定まらない、
みたいな
のは半順序で、
整数みたいなやつが全順序
整数みたいなやつが全順序
なお{ 全順序集合 }⊂{ 半順序集合 }なのは確定的に明らかなので、
反射律・推移律だけしか要請されていなかったらそれは全順序集合の集合を含む半順序集合の集合の意味となりぬ
つまり全順序集合の集合と半順序集合の集合が区別できん
両社を区別したい議論のときは比較可能性の有無を宣明せねばならんぬ、
反射律・推移律だけしか要請されていなかったらそれは全順序集合の集合を含む半順序集合の集合の意味となりぬ
つまり全順序集合の集合と半順序集合の集合が区別できん
両社を区別したい議論のときは比較可能性の有無を宣明せねばならんぬ、
a≦b または b≦aが成り立つ時、比較可能
弱順序ってしらなかったけど、半順序とは違うようだ
「半順序？弱順序？二項関係・順序関係まとめ」って記事
弱順序ってしらなかったけど、半順序とは違うようだ
「半順序？弱順序？二項関係・順序関係まとめ」って記事
束論やってるけど弱順序とか初めて聞いた…
マ界用語？
マ界用語？
弱順序は、半順序よりは制限強いが全順序より弱いもので、
ある種のソートアルゴリズムでは全順序よりは制限緩められるけど
半順序までは緩められない、ってのがあるみたいね
ある種のソートアルゴリズムでは全順序よりは制限緩められるけど
半順序までは緩められない、ってのがあるみたいね
アルゴリズムとの関連はちょっとわからんけど
数学としての束論って単独の本は少なくて、代数学の本に載ってるんじゃないかな
もしくは順序集合の話として集合論の本
数学としての束論って単独の本は少なくて、代数学の本に載ってるんじゃないかな
もしくは順序集合の話として集合論の本
>>748
＞普通に言葉通り任意の2つの元を比較できるということなのでは…
いや、それは全順序ですよ
・擬順序
・順序
これらの演算子を≦としたとき、かならずしも任意の二元 a, b について a ≦ b の真偽が定まらなくてもいいと思います
擬順序に対して「a ≦ b かつ b ≦ a ならば a = b」という縛りが追加されるのが順序、
順序に対して、任意の二元 a, b について「a ≦ b」または「b ≦ a」のどちらかである、という縛りが要請されるのが全順序
だったかと
＞普通に言葉通り任意の2つの元を比較できるということなのでは…
いや、それは全順序ですよ
・擬順序
・順序
これらの演算子を≦としたとき、かならずしも任意の二元 a, b について a ≦ b の真偽が定まらなくてもいいと思います
擬順序に対して「a ≦ b かつ b ≦ a ならば a = b」という縛りが追加されるのが順序、
順序に対して、任意の二元 a, b について「a ≦ b」または「b ≦ a」のどちらかである、という縛りが要請されるのが全順序
だったかと
wikipediaの「推移関係」の項目より
半順序 - 反対称的な擬順序
擬順序 - 推移的であると同時に反射的
全擬順序 - 完全的な擬順序
同値関係 - 対称的な擬順序
厳密弱順序 - 強半順序関係で等価関係での比較が不可能な場合
全順序 - 推移的で反対称的な完全関係
全順序、半順序くらいしか知らんかった
半順序 - 反対称的な擬順序
擬順序 - 推移的であると同時に反射的
全擬順序 - 完全的な擬順序
同値関係 - 対称的な擬順序
厳密弱順序 - 強半順序関係で等価関係での比較が不可能な場合
全順序 - 推移的で反対称的な完全関係
全順序、半順序くらいしか知らんかった
OOPの本だとサブクラス関係は前順序って書いてるよな？擬順序ともいうのか
推移的、A→B∧B→C |- A→C 、サブクラスのサブクラスはサブクラス
かつ反射的、AはAのサブクラス
推移的、A→B∧B→C |- A→C 、サブクラスのサブクラスはサブクラス
かつ反射的、AはAのサブクラス
>>760
一番弱い順序、推移的かつ反射的であるのみの順序関係は、実は任意の二項間においてかならずしも順序関係の真偽が定まらなくてもいいのですよ
すべての二項間で順序の真偽が定まるのは、順序の中でも一番強いものである全順序で初めて導入される、と私は解釈しています
一番弱い順序、推移的かつ反射的であるのみの順序関係は、実は任意の二項間においてかならずしも順序関係の真偽が定まらなくてもいいのですよ
すべての二項間で順序の真偽が定まるのは、順序の中でも一番強いものである全順序で初めて導入される、と私は解釈しています
ブール代数 型システムで検索しても出てこないけど>>523
可補分配束の定義見てると確かにそんな気はしてくる
インスタンス関係かサブクラス関係なのか？どっちでも成り立ちそうだけど、取り敢えず静的チェックをパスすることを考える
要素が無いと言う意味でCのvoidを冪集合ブール代数の最小元、空集合とみなす
void *は何でも指せるという意味で最大元
まともな型システムなら(少なくとも)上記の擬順序以上は要求る
演算は多重継承とvirtual 定義が∨/∧に対応？クラス図書いてみたら成り立ちそうに思える
型チェック通らない全ての型を考えられるし、それが¬
型述語で定義してればそのまま!演算子になる
可補分配束の定義見てると確かにそんな気はしてくる
インスタンス関係かサブクラス関係なのか？どっちでも成り立ちそうだけど、取り敢えず静的チェックをパスすることを考える
要素が無いと言う意味でCのvoidを冪集合ブール代数の最小元、空集合とみなす
void *は何でも指せるという意味で最大元
まともな型システムなら(少なくとも)上記の擬順序以上は要求る
演算は多重継承とvirtual 定義が∨/∧に対応？クラス図書いてみたら成り立ちそうに思える
型チェック通らない全ての型を考えられるし、それが¬
型述語で定義してればそのまま!演算子になる
確証が持てなくてもどかしい…数学できる人ツッコミ待ち
とりあえずダイヤモンド継承を許さない言語だと、常に∧/∨は定義されないからブール代数にはならない事には気付いた
とりあえずダイヤモンド継承を許さない言語だと、常に∧/∨は定義されないからブール代数にはならない事には気付いた
ググってる時点で、というかそのことを隠しもしないニワカ
質問ですがムーブコンストラクタを有する基底クラスの
派生クラスでムーブコンストラクタを
派生クラスがムーブコンストラクトされる際に基底クラスにアクセスしようとする場合であっても
安全に書く方法って何かあるんでしたっけ
派生クラスでムーブコンストラクタを
派生クラスがムーブコンストラクトされる際に基底クラスにアクセスしようとする場合であっても
安全に書く方法って何かあるんでしたっけ
作ったクラスをmapにいれるときoperator<を書かなきゃいけないのがめんどい
あとムーブコンストラクタを有するクラスを
詳細を隠ぺいする目的でインターフェースを設けたとき
インターフェース経由でムーブコンストラクトする方法って何かあるんでしたっけ
アブストラクトファクトリイーを作るしか無い？
詳細を隠ぺいする目的でインターフェースを設けたとき
インターフェース経由でムーブコンストラクトする方法って何かあるんでしたっけ
アブストラクトファクトリイーを作るしか無い？
この場合アブストラクトファクトリイーといっても、元のクラスFooに対して
IFoo IFoo::move() { ... } が定義してあって
IFoo x = (適当な生成手段）
ののち、
IFoo y = x.move()
でxが破壊されるやつ！
IFoo IFoo::move() { ... } が定義してあって
IFoo x = (適当な生成手段）
ののち、
IFoo y = x.move()
でxが破壊されるやつ！
それインターフェースとして使えてないよ
領域が連続しているコンテナなら何でも良いんですが、たとえば array<T> a を vector< vector<T> > b に n 要素分コピーしたいときって
memcpy(b.data(), a.data(), n*sezeof(T))
で良いんですかね？
UNIXコマンドと順番が違ったりして間違えそうなのですが、他に良いやり方ありますか
memcpy(b.data(), a.data(), n*sezeof(T))
で良いんですかね？
UNIXコマンドと順番が違ったりして間違えそうなのですが、他に良いやり方ありますか
>>761
その「一番弱い」とか言ってるのは前順序だろ。
ククク... 前順序は順序四天王の中でも最弱...
ウィキペディアにも書いてあるのに間違うとは面汚しよ...
その「一番弱い」とか言ってるのは前順序だろ。
ククク... 前順序は順序四天王の中でも最弱...
ウィキペディアにも書いてあるのに間違うとは面汚しよ...
半順序とかいう訳が悪い
英語のpartial orderの方が分かりやすい
英語のpartial orderの方が分かりやすい
あとは裁判で争うしかないでしょうね。
我々には判決が出せませんから。
我々には判決が出せませんから。
>>771
前提条件として
・ T の型が trivially copyable である
・ vector の大きさが必要な大きさ分に出来ている
ならそれでもいいよ。
でも、 C の関数を C++ でも使えるのはほとんどが互換性のためでしかなく、
作法的にはあまり使わないに越したことは無いって感じ。
前提条件として
・ T の型が trivially copyable である
・ vector の大きさが必要な大きさ分に出来ている
ならそれでもいいよ。
でも、 C の関数を C++ でも使えるのはほとんどが互換性のためでしかなく、
作法的にはあまり使わないに越したことは無いって感じ。
>>770
どういう意味じゃ…
ムーブコンストラクトする手段をインターフェースとして公開したい需要は論理的に有り得る
それともIFoo::move()に実装が伴うからという意味？
どういう意味じゃ…
ムーブコンストラクトする手段をインターフェースとして公開したい需要は論理的に有り得る
それともIFoo::move()に実装が伴うからという意味？
>>779
なぜ？
行優先か列優先かは置いといて、vectorの要素は連続するのだからvectorのvectorも連続するのでは？
サイズやキャパシティが変わったときに不連続になりうるということ？
なぜ？
行優先か列優先かは置いといて、vectorの要素は連続するのだからvectorのvectorも連続するのでは？
サイズやキャパシティが変わったときに不連続になりうるということ？
vectorのvectorの中身はサイズ値とバッファポインタが連続で並んでるだろうな
>>781
正しくコピーしたければ、
memcpy(b[0].data(), ...)
みたいにしないと。
このとき当然b[1]のデータ領域はb[0]の後ろに連続していない
正しくコピーしたければ、
memcpy(b[0].data(), ...)
みたいにしないと。
このとき当然b[1]のデータ領域はb[0]の後ろに連続していない
ほらCと同じ基本の部分を教えずにいきなりSTLとか勧めるからこういう初心者が出てくる・・
ある程度出てきても問題ないだろ。ちゃんとドキュメント読んで理解してくれる人も多いんだろうし、
「Cと同じ基本の部分」を教えたところでちゃんと理解してくれない人も居るだろうし。
「Cと同じ基本の部分」を教えたところでちゃんと理解してくれない人も居るだろうし。
ちょっと何言ってるかわかんない
相談室に初心者が来て何の問題があるのか
>>771
> array<T> a を vector< vector<T> > b に n 要素分コピーしたいときって
> memcpy(b.data(), a.data(), n*sezeof(T))
> で良いんですかね？
待てよ、b.data()って&b[0]だから型はvector<T>*だろ。書き換えたらいけないアドレスじゃん。
ダメです。
> array<T> a を vector< vector<T> > b に n 要素分コピーしたいときって
> memcpy(b.data(), a.data(), n*sezeof(T))
> で良いんですかね？
待てよ、b.data()って&b[0]だから型はvector<T>*だろ。書き換えたらいけないアドレスじゃん。
ダメです。
C++のvectorでは、演算子[ ]がオーバーロードされてるから、C言語の常識が通用しないんだよ。
memcpyは危険な関数だから簡単にメモリー破壊できるんだよね。
std::vector v;
int a = 5;
memcpy(&v, &a, sizeof(a)); // vのメモリー破壊。
memcpyは危険な関数だから簡単にメモリー破壊できるんだよね。
std::vector v;
int a = 5;
memcpy(&v, &a, sizeof(a)); // vのメモリー破壊。
別にここで何が正しいかを結論できなくてもいいのだが
>>776
そう言うなら「推移的かつ反射的であるのみの順序関係」が「弱順序」と書いてある本を
教えてくれる?
手元になかったらうろ覚えでもいいけど。〇〇の××先生がそう言ってたみたいのでもいいw
知識として一応確認しておきたいかなと。
>>776
そう言うなら「推移的かつ反射的であるのみの順序関係」が「弱順序」と書いてある本を
教えてくれる?
手元になかったらうろ覚えでもいいけど。〇〇の××先生がそう言ってたみたいのでもいいw
知識として一応確認しておきたいかなと。
std::vector v(sizeof(int));
int a = 5;
memcpy(&(v[0]), &a, sizeof(a)); // おk
int a = 5;
memcpy(&(v[0]), &a, sizeof(a)); // おk
つかこうかorz
std::vector<int> v((size_t)1);
const int a = 5;
memcpy_s(&(v[0]), sizeof(v[0]) * v.size(), &a, sizeof(a));
std::vector<int> v((size_t)1);
const int a = 5;
memcpy_s(&(v[0]), sizeof(v[0]) * v.size(), &a, sizeof(a));
この場合は素直にループを書くか、それとも格好良くstd::copy使うのが楽かな。
for文回したら死ぬ病気にでもかかってんのか？
条件を満たすならmemcpyのほうが圧倒的に早いからな
それほど速くならない・速くなくていい場合のほうが圧倒的に多いってのもあるけどな。
