◎正当な理由による書き込みの削除について： 生島英之とみられる方へ:
C++相談室 part155 YouTube動画>1本 ->画像>4枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1616555235/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
msysの thread_local が、わりとちゃんと動くのがありがたい
昔は当たり前にクラッシュしてた
STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
たぶん最初に書いた本人以外はだれも気に入ってないと思う
もうやめたほうがいい
glslのnoise関数のような、特定の入力に対して、特定の乱数を返すような関数はありますか？C++に
完全に(疑似)乱数でよいのなら、
毎回シード設定すれば入力で一意に決まる乱数値を取得できるけど、それでええのん？
例えばこんなの
srand(input);
return rand();
ハッシュと乱数を混同して質問しているに500ペリカ
>>9 それですね
ちょっとその発想を元に作ってみます
C++ の乱数生成器 (linear_congruential_engine, mersenne_twister_engine, subtract_with_carry_engine)
は厳密に挙動が定められているので環境によらず同じシードを与えれば同じ乱数列が得られることは保証される。
(余談だが分布生成器 (uniform_int_distribution など) は完全に同一の挙動は保証されない。)
rand は同じシードからは同じ乱数列になるという保証はあるけど、
他の環境に持って行ったとき (別の処理系を使ったとき) に同じになるという保証はない。
乱数の質についても保証がない。
必要な性質がよくわからんのだが、再現性・移植性が重要なら rand はあまりよくない。
自作のXorShiftでやってみようと思います
スレの流れがそんなに速くないようなので後にコードレビューでもお願いするかもです
コードレビューつってもなぁ、
明らかに未定義を踏んでるとか間違った結果を出力をするとかならともかく、
インターフェイスが綺麗かとか命名が適切がとかいった要素は状況に依存するんで
そこらへんの前提を共有できている状態じゃないと
かなりざっくりした一般論しか言えないと思うよ。
7ですが、すいませんでした
場違いだったようなのですべて撤回します
QZあたりが疑似乱数の理論について本一冊分ぐらい語るのではなかったの？？？
乱数表をどうやって作るつもりなのかとそこはかとなく疑問が………
ガイガーカウンターは放射線源が強力だとカウントミスりそうであんまり高速な乱数生成に向かない
という印象
ていうか量子乱数発生器はスタジアムや野球場など人間が数千人～数万人規模で集まり
興奮するようなところで量子乱数発生器を使うと乱数発生が偏るという実験結果がある
とモーガンフリーマンが言ってたから信頼できない
やっぱ第一選択はシードを19936ビットフルい与えてのmersenne_twister_engineなのでは……
>>17 大抵の用途には、私は MT を使いますね…
メルセンヌツイスタは統計的な性質は良いが状態がやや大きい (普通のパソコンではもはや気にしないでよいレベルだが) ので、
いつでも選択するには過剰な気もする。
スレの流れをぶった切って申し訳ない
boostってもういらなくなったの？
15年ぶりにC++でプログラミングすることになったので
その辺の事情がよく分かりません
当然要るよ
多次元配列クラスとかまだSTLに入ってない
個別には Boost 以外の選択肢もあると思うけどある程度に統一されてないと扱いづらいし、
Boost にあるものは Boost を使っておくのが無難な選択には違いないと思うよ。
boostはヘッダライブラリ自称してる割にビルド必要で使いづらいねん
>>28 > ヘッダライブラリ自称
そんなことどこかに書いてあるの？
公式ページのトップにもビルドについて言及があるし、ヘッダのみみたいなニュアンスはないと思うんだが。
ヘッダのみで使えると過剰に宣伝してるライブラリが多い。
と、あわしろ氏が申しておりました。
ビルド必要なのは別にいいけどbjamが糞すぎるからさっさと捨てて欲しい
class hoge{
public:
constexpr static int aaa[2] = { 1, 2};
static hoge get_hoge();
}
hage::hage()
{
hoge *_hoge = hage::get_hoge();
int tmp;
int i = 0;
tmp = _hoge->aaa[i];
}
とすると、ビルド時、undefined reference to `hoge::aaa'と出るけど、
tmp = _hoge->aaa[0];とするとエラーが出ない
これってなぜ起きて、どうやったら変数を使ってアクセスできるようになるの？
開発環境はSTM32CubeIDEのver1.6.0
ちらちら混ざってる hage は hoge の間違いなのか何か別物なのか。
>>33 サンプルコードが不足しているので何をどうしたいのかよくわからんのだが、
i が定数式じゃないと駄目だよ。
>>34 hogeにはアプリで使う色々な定数が入ってて、hageがそれを参照するようにしてるんだ。
んなもんdefineでいいとかそういう話は置いといて、iが変数だと何がまずいの？
三段活用はhoge、fuga、piyoだろ！常識だぞ
ハゲとか言う人にはもう教えません
>>37 > constexpr static int aaa[2] = { 1, 2};
クラススコープの↑は変数の定義に見えるけど実は宣言でしかなくて、プログラム中に実体を置くには別途定義が要る。
ただし const な整数型や constexpr な変数が定数式の文脈で即座に値として利用される場合はコンパイル時に直接定数として
置き換えられるので、定義が無くてもビルドできる。
定数 0 ではなく変数 i を添え時にすると定数式ではなくなるので定義が必要になる。
>>42 分かったようなわかんないような感じなんだけど、
例えば、
class hoge{
public:
constexpr static int aaa[2];
static hoge get_hoge();
}
hoge::aaa[2] = {1, 2};
みたいにするってこと？
>>42 それだと定数評価できなくなるから、たぶんやりたいことと違うよね。
「別途定義」は、宣言の初期化子はそのままで↓をどこかのコンパイル単位に追記するだけでいい。
constexpr int hoge::aaa[];
static constexpr int * constexpr aaa = …
か
static inline constexpr int aaa[] = … (c++17)
で行けんじゃね？知らんけど。
これで思い出したんだけどメンバ変数のconstexprとstatic constexprに違いってあるんだっけ？
メモリ上に唯一ここだけしかないんだぞって見る奴に分かるようにしてるんでしょ
コンパイラ的にはあってもなくても同じ
>>46 メンバ変数はインスタンス無いとあかんやん
インスタンスごとになるのか・・コンパイル時定数なのに(保証は無いのかもしれんけど
普段staticつけてるから疑問に思ってたんだ、ありがとう
>>43 thx
C++の仕様が古いのか分からんけどうまくいかなかったんで、constで宣言して別に定義したわ
クラスを使わずにフリー関数だけで何もかも実装してしまう
なんでもかんでもクラスに放り込むのは良くないというのはよく認識されるようになってきたみたいだけど、
だからといって C++ を使う以上は非メンバ関数だけで構成するのも不格好だし、いい感じの設計は難しいね。
バカが無理してクラス使っても無駄に状態持つだけだから非メンバ関数使っとけ
ラムダ式で何もかも実装したらクラスを使ったことになる！
>>38 hoge
hage
mage
かと思ってた
メンバ関数を使わなければ関数型的ということはない。
誤解の余地がないぐらいしっかり要件定義できたら一人前の入り口
なんでもかんでもクラスに放り込むのは良くないけど、なんでもかんで名前空間に放り込むのは実に良い
"Raw string literals" は 「生文字列リテラル」 って訳されるけど、「生」の部分をどう読んでいるのですか？
「なま」なのか「せい」なのか、「しょう」なのか
ググってもわかりません
https://cpprefjp.github.io/lang/cpp11/raw_string_literals.html 「生ポインタ」で「なまぽいんた」
界隈で使われてる超専門用語
教科書には読み方はおろかその存在すら一切載って無い
しかしてC/C++使いは総じてその読み方を知ってる
>>67 「なま」なんですね
早速の解答ありがとうございます ｍ（＿ ＿）ｍ
einsumとか添字の入れ替えくらいの本当に基本的な機能だけ持ってる多次元配列クラスがほしいんだけど、なんでこれしきのものがboostにはないの？
君の実装を世界が待ってるんだぞ
文句言う前に公開せよ
>>70 今は自分で実装して騙し騙し使ってるけど、こういうファンダメンタルかつパフォーマンスが必要なものは誰か信用できるプロバイダに作ってほしい
実用的な必要に迫られている人こそ
変な妥協もお花畑なオーバースペックもない
機能美なコードを書けるんだけどな
>>72 実用的なコードというのは進化し続けるコードであって、常に古びた無駄を抱えているもんだ。
std::vector<bool>のpopcountを簡単にとる方法をおしえてくだちい
以下のようにして自力で数えるしかない？
size_t popcount(const std::vector<bool>& vec) {
size_t cnt = (size_t)0;
for (auto it = vec.begin(); it != vec.end(); it++) {
if ((bool)(*it)) {
cnt++;
}
}
return cnt;
}
あとstd::vector<bool>::size()は総ビット数を返すみたいなんですが
では実際に占有しているヒープのサイズは
どうやって確かめたら良いんでしたっけ……＿○／|＿
つかstd::count(vec.begin(), vec.end(), true)で一応動くみたいけど
中でbool型の等値判定していると思うんですが問題無いんでしたっけ……
不安だったらvector<bool>なんか使うな
それは素人が手を出していいものじゃない
集合表現のためのビットマップのロジックを新たに新規に作るよりﾏｼ、
という天才の判断
天才か！
しかしstd::bitsetは要素数が整数の基本型のビット数を超えられないのでは……
2^32以上のサイズが必要だってこと？
何に使うの？
>>82 誤: 2^32
正: 32
当然32個以上の要素からなる集合をビットマップ式に表そうとしたとき
、整数の基本型1個では足りない
訂正orz
誤： 当然32個以上の要素からなる集合
正： 当然64個を超える要素からなる集合
何かこういう訳のわからない事を書き込んでまで質問するならもっとわかりやすく書けよと思う
そもそも動的じゃないなら配列でええやろ
c++関係あるかわかりませんが、テクスチャをバラバラに分割するロジックってどうやって作るんでしょうか？
例えばジグソーパズルや、このモザイク画のように、１枚の絵をバラバラにしたいのです。
ばらばらにしたものを戻すというゲームを作ろうとしています。
https://docs.gimp.org/2.8/ja/plug-in-mosaic.html これが作成したサンプル画像です
グリッドの線がうっすら見えると思いますが、これを２次元配列とみなします。
適当に四角形を選択して、大まかな位置を決めます。
しかし、その後、四角形を三角形や五角形にするにはどうしたらいいのでしょうか？
隣り合う頂点をマージするなどすればできそうですが。
つまり、頂点という概念を使わないとこの機能は実現出来ないでしょうか？
板ポリゴンを2dとして映せば行けるかなと思ってます。
まあ、inkscapeなどで手作業で作れよって話ですけどね。
自動でパズル作ってくれたらいいなと思って。
エンジンはgodotです(´・ω・`)が、processingなどの環境でもいいです。
ヒントください
1ドットずつ走査して近似色以外は透明色で塗りつぶせば
OpenGLとかグラフィックプログラミング系のスレで聞くべき・・といいたいところだが
この板は上から下まで、やれこっちが優れてるだのこのやりかたは汚いだの
アホみたいなマナー・作法論しか議論していない板なのでたぶん書籍かWebを検索したほうがいい
適当に点{ p1, p2, p3, ... } をばらまいてボロノイ境界を描いたら
ボロノイ境界が勝手に種々の多角形になりまくり……！
あとは1つの区画内を点{ p1, p2, p3, ... }における画像の色とかの
適当な色で塗り潰せば良い
言うは安し……！！
とりあえず2Dゲーをいちいちポリゴンでやるのはやめといた方がいいかも・・
テクスチャの内容を一枚のビットマップとしていじった方が楽な気がする
スワイプやドラッグでピースを動かすときは板ポリ使ってもいいかもしれんけど
>>89 その機能がゲームエンジンにあるかどうかすで
>>90 そんな感じですね。
ボロノイというより、三角と四角と五角形で分割したいわけですが
openglはできませんからね、擬似的にそう見せる方法でもいいのですが
アホなので
>>93 ビットマップでやるってのは、マスでなんとかするってことですか？
領域を分割する頂点と辺を決めたらあとは各ピクセルごとにどの領域に含まれるかを判断すればいいように思うが
>>88のサンプル画像からすると、分割された領域の頂点は格子点上にないといけないっぽい
ボロノイ境界の交点は都合良く格子点上に来るとは限らないから、ボロノイ「領域」
の作図式にやるのはいろいろな点でｲﾏｲﾁ感が、
ちゅか要件定義的に（三角形は良いとして）
(1) 四角形や五角形への分割において凹図形を許容するのか否か
(2) ある図形の1つの辺を2つ以上の隣接図形で共有することを許容するのか否か
とか決めねばならない
いや決めたからといって別に頂点決定アルゴリズムの妙案とか無いが＿○／|＿
ここは飛ばしてゲーム作ります(´・ω・`)、、、別に面白さと関係ないしね、、、。
processingで似たような事できますか？ちょこちょこ練習しようかな
ゲームエンジン使うほどでもないので
https://processing.org/download/support.html これダウンロードできます？寄付しろと言われるんですけども
c++言語をググるとビャーネも必ず出てきて
彼が設計者だとのことですが、コンパイラを作ってるのは彼ではないですよね
具体的に彼は何をしたの？
言語仕様の策定だろ
まあ最初のコンパイラー（コンバーターかも）ぐらいは作ってるとは思うけど
当初はCのプリプロセッサだから今で言うとTypescriptみたいなものだな
それとも国際標準化機構（ISO）か何かの配下なの？
>>105 K&R Cにクラスの概念を取り入れて見よう
ということを思いつきcfrontを実装した
TC++PL及びARMを著しC++を広く世界に知らしめた
ビヨーン先生の功績は
ハゲても立派なプログラマになれるという勇気をくれたことだろう
質問ですが
std::vector<SomeBigObject> arr;
std::vector<int> indices;
というデータがあり、
SomeBigObjectは大小比較可能だがarr自体は未ソートで、
for (int i = 0; i < N; i++) { indices[i] = i; }
auto cmpFunc = [](int a, int b)->bool{ return (arr[a] < arr[b]); }
std::sort(indices.begin(), indices.end(), cmpFunc);
としてindices上で間接的にソートされているとき、
指定されたSomeBigObject x以上の値が現れるarr[i]の最小のiを高速に取得するには
どうづればSTLでやるには良いですのん？
arrがソートされていれば
auto cmpFunc2 = [](const SomeBigObject& a, const SomeBigObject &b)->bool{ return (a < b); }
std::lower_bound(arr.begin(), arr.end(), cmpFunc2);
で済む話なんだども、SomeBigObjectはコピーの手間がかかるので直接std::sortしたくないという、
また手動で組めということなら明らかに組める
int custom_lower_bound(int bgn, int end, const int N, const SomeBigObject& x) {
while (bgn < end) {
int mid = bgn + (end - bgn) / 2;
if (arr[mid] < x) {
bgn = mid;
} else if (x < arr[mid]) {
end = mid;
} else {
while (mid > 0 && arr[mid - 1] == x) { mid--; }
return mid;
}
}
while (bgn < N && arr[bgn] < x) {
bgn++;
}
return bgn;
}
みたいなことをしたら多分逝けるが、しかしこんなもん使う都度書きたくないし、
ライブラリとして展開して責任負いたくもないんじゃー
STLはこういうケースのためにあり、論理的に実現できる以上やり方が考えられていないとおかしいはず……
auto cmpFunc3 = [](int a, int b)->bool{ return (arr[a] < arr[b]); }
i = std::lower_bound(indices.begin(), indices.end(), cmpFunc3);
arr[i];
じゃいかんのかしら
>>115 lower_bound()の第3引数に検索キーxを指定する必要があるから
>>115では解決しないっていうかビルドエラーなﾖｶﾝ、
ここで気づいたが
>>113のlower_bound()の例は間違ってたわｽﾏﾝ、orz
↓これに訂正
auto cmpFunc2 = [](const SomeBigObject& a, const SomeBigObject &b)->bool{ return (a < b); }
std::lower_bound(arr.begin(), arr.end(), x, cmpFunc2); // 3番目の引数は検索キーx
ところがソートされているindices上の検索キーは、検索したい実際のオブジェクトxから
ただちには求められない（普通にやったら線形探索の手間がかかる、｡n_
auto cmpFunc3 = [&](int idx, const SomeBigObject& xx)->bool{ return arr[idx] < xx; }
auto i = std::lower_bound(indices.begin(), indices.end(), x, cmpFunc3);
arr[*i];
じゃあこれで
>>117
ﾑﾘｽ、
つか次のように死ぬほど腐った書き方をしたらとりあえずできるた、
/// 間接ソート版lower_bound
int custom_lower_bound(const std::vector<SomeBigObj>& arr, std::vector<int>& indices, const SomeBigObj& x)
{
// SomeBigObjの間接ソート用比較関数
// xのコピーを避けるため[&](a, b)とする。
auto cmpFunc = [&](const int a, const int b)->bool {
// 有り得ないindex値が渡ってきたらxとみなす。
const SomeBigObj& obj1 = (a < 0) ? x : arr[a];
const SomeBigObj& obj2 = (b < 0) ? x : arr[b];
return (obj1 < obj2);
};
// lower_bound()の第3引数(検索キー)を有り得ないindex値にしておく。
auto found_it = std::lower_bound(indices.begin(), indices.end(), -1, cmpFunc);
// Indexに変換
return (int)std::distance(indices.begin(), found_it);
}
動作するサンプル例：
https://ideone.com/xbSHmi const int lb = std::distance(indices.begin(),std::partition_point(indices.begin(), indices.end(), [&x,&arr](const int i){ return arr[i] < x; }));
これでどうかな？
>>122 動かないのをおま環言うのはよく聞くがその逆を聞いたのはこれが初めてかも
確かに動いているように見えるが（呼び出し回数も2分探索相当に見えるが）
Compにそんな引数渡して委員会？！
錯覚じゃないの；；；
std::lower_bound(first last, value, comp);
という呼び出しにおいて、compはcomp((firstやlastと同じ型のiteratorが指す要素), value)
という呼び出され方しかされないこと、および
valueの型はfirstやlastが指す要素の型とま無関係に好きな型にして良いと規格で決まっている？！
チラッと規格見た限り
value は first、last と無関係でいいし
comp の第一引数はfirst、lastのiteratorが指す型で、第二引数はvalueの型に決まっているように見える
>>51じゃないが、オブジェクト指向で設計する意味が分からなくなった
汎用性の高いフリー関数が沢山あればそれで良いじゃん
>>126 > comp の第一引数はfirst、lastのiteratorが指す型で、第二引数はvalueの型に決まっているように見える
そこは決まってないと思う。
・・・いや、 lower_bound() 限定なら引数の順番もその想定でいいのか。
upper_bound() だと comp(value, x) になったりするから、交換可能にしとくのがいいけど、
片方だけ使うなら交換可能にする必要はない、と。
c++20からpreconditionsって書き方に変わったのか。
>>129 upper_boundのpreconditionsには第一引数がvalueのほうしか書いてないよ
質問者ですレス㌧クス、
>>117の書き方で
>>121が正しく動いているように見えるのは未定義動作でなくてSTLの仕様ってことでＦＡ？
>>126や
>>129のような巧妙っていやー巧妙だが風が吹いたら桶屋が儲かるみたいなかりにくい仕掛けなのは
ステパノフあたりの発案なんですかね……
>>132 あ、ごめん。比較関数の引数順を交換可能にするのは lower_bound, upper_bound 両用にすることを想定しての話。
生魚にあたって、
入院した病院の天井みながらSTL考えてたもんな
ニダーランが終了になるそうだ
もう糞スレは立てにくくなるな
ざまあ
>>135 STLなんてかっこつけたネーミングだけど
やってることはリニアサーチwww
C++11でのstd::swapは、次のようなコードになっているそうですが、
仮に、もし(1)が終わった直後にt1の中のポインタ型やshared_ptr<A>のメンバに
nullptr的なものが代入されるんでしょうか。
仮にt1のポインタ的なメンバにnullptr的なものが代入されない場合、
(2)でt1への代入に置いて何が起きるのか心配です。
質問の仕方を変えるならば、
share_ptrは参照カウンタ方式ですのでカウンタのアップ/ダウンは正確でなければ
なりませんが、以下の例では、いったいどの行のどの演算子(またはどの部分)で
カウントアップ/カウントダウンされるんでしょうか。
template<typename T> void swap(T& t1, T& t2) {
T temp = std::move(t1); // (1), or T temp(std::move(t1));
t1 = std::move(t2); // (2)
t2 = std::move(temp); // (3)
}
>>139
誤：仮に、もし(1)が終わった直後にt1の中のポインタ型やshared_ptr<A>のメンバに
nullptr的なものが代入されるんでしょうか。
正：(1)が終わった直後にt1の中のポインタ型やshared_ptr<A>のメンバに
nullptr的なものが代入されるんでしょうか。 >>138 C++03にもstd::binary_searchあるぞ
>>139 > nullptr的なものが代入されるんでしょうか。
この場合はされる。
ムーブセマンティクス一般においてはムーブ後の抜け殻は「無効なオブジェクト」なのでアクセスに対して保証がないことがあるが、
標準ライブラリのスマートポインタについては所有権を移動させた後にそれが空であり
メンバ関数 get で nullptr が返ることも、 nullptr と == で比較して真であることも保証される。
> いったいどの行のどの演算子(またはどの部分)で
> カウントアップ/カウントダウンされるんでしょうか。
= がその役割を持っている。
ムーブコンストラクタとムーブ代入演算子によってカウントされる。
>>140 どうやら、
(1) の中央の = では、TからTへの move-constructorが呼び出され、
(2)や(3) の中央の = では、TからTへの move-assignment operatorが呼び出される、
ということのようですが、
Tのmove-contructorやmove-assingment operatorは、ユーザーの実装次第で、
ユーザーがそれらを明示的に書かなかった場合の「デフォルトの定義」は
現在もまだ論争中で、標準的な仕様が決まってない、ということらしいですね。
間違っていれば指摘してください。
>>141 そんなのも、ちょっとc\c++をかじったことあるなら
誰でも書けるじゃん
わざわざ誰が書いたかわからないようなものより自作できるなら自作するだろ
>>143 以下のサイトによれば、「標準的な仕様は決まっている」ようです：
drafet C++11 standareのsection 12.8のparagraph 15に
implicitly-defined copy/move constructor は、
「a memberwise copy/move of its bases and members」
であると書いてあるそうですから：
https://stackoverflow.com/questions/18290523/is-a-default-move-constructor-equivalent-to-a-member-wise-move-constructor The implicitly-defined copy/move constructor for a non-union class X performs a memberwise copy/move of its bases and members. [ Note: brace-or-equal-initializers of non-static data members are ignored. See also the example in 12.6.2. —end note ] The order of initialization is the same as the order of initialization of bases and members in a user-defined constructor (see 12.6.2). Let x be either the parameter of the constructor or, for the move constructor, an xvalue referring to the parameter. Each base or non-static data member is copied/moved in the manner appropriate to its type:
if the member is an array, each element is direct-initialized with the corresponding subobject of x;
if a member m has rvalue reference type T&&, it is direct-initialized with static_cast(x.m);
otherwise, the base or member is direct-initialized with the corresponding base or member of x.
Virtual base class subobjects shall be initialized only once by the implicitly-defined copy/move constructor (see 12.6.2).
>>142 >ムーブセマンティクス一般においてはムーブ後の抜け殻は「無効なオブジェクト」なのでアクセスに対して保証がないことがあるが、
>標準ライブラリのスマートポインタについては所有権を移動させた後にそれが空であり
>メンバ関数 get で nullptr が返ることも、 nullptr と == で比較して真であることも保証される。
なるほど。
行(1)の場合、
1. 右辺でstd::move()をt1に行った段階では(実行段階で)マシン語は全く実行されない。
2. 中央の = は、move-constructor と解釈され、Tのmove-constructorが呼び出される。
3. Tの暗黙定義のmove-constructorは、メンバ同士のmove-construcotrなので、
メンバに shared_ptr<A> a があると、shared_ptr<A>のmoveコンストラクタが呼び出される。
そして、shared_ptr<A>のmoveコンストラクタは、実行後に「src側(from側)」をnullptr相当の
状態にしてしまう。
ということのようですね。
>>146 逆に言えば、Tのメンバに、A *pA; のような生ポインタがあると、
Tの暗黙のmoveコンストラクタ/move代入演算子では、恐らく、
「src側(from側)」にはnullptrが代入されない(??)ので、非常に困った
問題を招くかも知れないと？
>>147 Tのデストラクタに
if ( pA != nullptr ) {
delete pA;
}
などと書いていた場合、問題を生じそうですね。
c++についてうんちく垂れるやつに限って仕事ができない
そんなうんちくどうでもいいから、さっさと作れよって思われてる先輩いるわ
>>150 プログラマは怠惰であれ、を地で行ってるんだろう
>>144 > わざわざ誰が書いたかわからないようなものより自作できるなら自作するだろ
おまえは一生二度とライブラリもOSも使うな
ベアメタルだけで食っていけ
それができたら、おまえに付いてくる者たちが顕れるだろう
できなければ人知れず消えるだけだ
どうなりたいかは、お前の人生だ
俺がどうしろとは言えない
>>150 またお前か。さっさとプログラミング覚えろよ
std::binary_search()は戻り値とかなんとboolや
こんなのよかちゃんと位置を返してくれるstd::lower_bound()の方がよっぽど使いでがある
ちなstd::lower_bound()が2分探索か線形探索かは使うイテレータの条件次第
std::lower_bound()が線形探索だと断言してくださる香ばしいblogも世の中にはあるが
ｈｔｔｐｓ：／／ｒｓｋ０３１５．ｈａｔｅｎａｂｌｏｇ．ｃｏｍ／ｅｎｔｒｙ／２０１９／０９／１０／１７３７０８
これがまつがいであることは比較関数の中でprintf()でもしたらたちどころにﾜｶﾙ
ｺﾞﾒｿリンク先は必ずしも断言はしていなくって、std::set<T>にstd::lower_bound()を適用する例か、
これのイテレータはrandom-access iteratorでないから確かに線形探索になる
>>144 こういうのが井の中の蛙ってのだな
蛙くん
>>149 生ポインタのメンバ変数がある場合で、デストラクタで
>>148のように
書いている場合は、暗黙のmove関数は自動定義されないようです。
なぜなら、暗黙のmove関数は、デストラクタがユーザー定義されている
場合には自動定義されないためです。
他にも、コピーコンストラクタ、コピー代入演算子、move代入演算子
がユーザー定義されている場合も、暗黙のmove関数は自動定義されない
そうです。
>>158 誤：暗黙のmove関数
正：暗黙のmove-コンストラクタ
コンパイラはともかくリンカに計算負担をかけるのはバカな設計だなと思うわ。
暗黙のmoveがnullptr代入してくれないとか生ポあるクラスに暗黙のctor定義してくれるのか、とか
学ぶ順番間違えて勘違いしてるやつ上の方にいるけど
そもそも生ポの扱いに言語が介入するんならdtorでdeleteしてくれるのか、とか考えつかないのかね・・
質問者はポインタ型とshared_ptrについて聞いてたのに、shared_ptrのことしか答えなかった餃子が悪い。
謝れ！俺に
皆さま御機嫌よう、ちょっと質問させてください
class hogeの内部でenum class fugaを定義し、
そのfugaをclass hogehoge でメンバ変数として使用したいのですが、
hogehoge のヘッダーにはなるべくhoge をインクルードさせたくありません。
もちろんfuga変数はヘッダーに置いて使用したいのですが……
前方宣言でfugaを宣言してもhoge::fugaと互換？が無いため代入が出来ません。
キャストで戻したりして使っているのですがこれならintでもいいかなと……
クラス内クラスの前方宣言は難しいのでしょうか？
何か方法がありましたら教えていただきたく……
class hoge{
enum class fuga{
one,two,three,SUM
};
};
//ヘッダーはソースにインクルードしたい
class hogehoge{
hoge::fuga mfuga;
};
こんかかんじで使いたいのですがエラーになってしまいsまずorz
enum classはグローバルに置いた方がいいんでしょうか？
任意のクラス内部で規定したいenumが見た目も便利だと思ったのでなるべく入れ子にしたかったのですが
>>167 hoge をインクルードしないところで hoge::fuga を使いたいということは
fuga は hoge にそれほど強く結びついていないということで、外に出すのが妥当なのでは？
外に置いたうえで hoge 内で using fuga = outer_fuga とでもすれば、見た目は損なわれないだろうし。
>>168 名前に「ホゲで使うフガ」と名付けるのがいいですかね？
前方宣言で定義したクラスは不完全型みたいでクラス内クラスにアクセスする場合は別途定義が必要みたいです……
難しい感じですかね
std::sortがセーフソートかどうかって決まってないんですね？
安定ソートのことならstd::stable_sortを使え
std::stable_sort<T>はどうしてもstd::sort<T>より遅い
からstd::stable_sort<T>で安定ソートするテクニックが存在するし需要がある
もちろんタダでというわけにはいかずn個のTのソーティングに対しn個の整数型の配列が別途必要だがとにかくできる
まつがえたorz
誤： std::stable_sort<T>
正： std::sort<T>
計算量の仕様からすると何だかんだ言って
std::stable_sort<T>の中身はマージソートで、
std::sort<T>の中身はイントロソートとクイックセレクトとクイックソートの複合技
ぐらいしかありえない
みなさんありがとうございます
安定ソートのことでした
> std::stable_sort<T>の中身はマージソートで、
これはまあそんなもうだろうけど
> std::sort<T>の中身はイントロソートとクイックセレクトとクイックソートの複合技
なんでここまで限定するんだ？
https://cpprefjp.github.io/reference/algorithm/sort.html >C++11以降: O(N log N) (N == last - first) 計算量での比較
>クイックソートは平均計算量がO(N Log N)だが、最悪計算量がO(n^2)である。そのため、C++03の計算量要件には合致するが、C++11の要件には合致しない
ubuntuでの開発環境って何があるんでしょうか？
openglなのでc++を使うことになると思うんですが、c++はideとしてvscodeでいいですよね
guiは何が一般的なんでしょうか？
> この関数には、特定のアルゴリズムで実装すべきという規定はない
古典的なソート議論はユニプロセッサ前提
今どきの並列化の流れに必ずしも当てはまるとは思えない
boost::sort::pdqsort(), boost::sort::block_indirect_sort() あたりならヘッダーだけで並列ソートできる
>>181 GUIなんか使わないのが一般的だよ
開発環境にわざわざC++とLinuxを選ぶような人は自分用アプリにGUIなんて組み込まないだろうし、
他人に使わせるならどうせWindowsでテストしなきゃいけないからLinuxなんて時間の無駄だ
OpenGLだったらOpenGLの描画結果を表示するウィンドウとターミナルでいい
自分用アプリねえ
俺の定規ウインドウなんてGUIだけど
ぐぐったら沢山出てきた
頭が悪くて理解出来ないけど需要あるんだね
unique_ptr<hoge> 自体が型名なんでしょうか？
class unique_ptr<hoge>で前方宣言してもいいのかな？
素人なんで自分の説明が難あると思うんだけど自分なりに精一杯説明すると、
ヘッダー部の引数にclass unique-ptr<hoge>& uhogeを載せて、
ソース部にhoge.hをインクルードして定義する感じでつかいたんだけども……
試してみたけど動くんだけどなんか怖い
想像ではunique-ptr<class hoge>が前方宣言だと思ってたもので……
どこをどう調べればいいのかだけでも教えていただければ……
>>191 テンプレートのインスタンス化は暗黙にやってくれるので基本的にはする必要がない。
どうしても宣言したいのなら
extern class unique_ptr<hoge>;
と書くことは可能。
ただし、このように宣言した場合には暗黙のインスタンス化は抑制されるので、
別の場所で明示的インスタンス化をしておく必要がある。
テンプレートの展開はその仕組み上、各翻訳単位ごとにやった上でリンク時に統合されるというクソみたいなことになってるので、
コンパイル時間を抑制したいなどの理由でこういった変なことになってる。
ユニークポインタ自体の大きさが、ポインタだから4バイトくらいに統一されているのかな？
型テンプレートがどんな型でも、定義部分で明示してあればポインタ長のメモリをアロケートされているから、宣言自体はある程度の許容範囲があるということなのかな？
理解が違ってたらすいません
>>191 1行目yes
2行目はその場合クラステンプレートの明示的実体化になる
前方宣言の場合は
template <class T, class D>
class unique_ptr;
(もちろん名前空間std内
テンプレートは引数与えられてない限りあくまでテンプレートであってコードは生成されないよ
>>194 え、明示的インスタンス化しておけばコンパイル時間抑制できるの？
前方宣言というのはあくまで「こういう名前のこういう奴が（どっかに）いますよ」って言ってるだけ
実体がどんなサイズでどんな値やメンバやなんやかんやを持ってるかとかには関知しない
>>196 > 明示的インスタンス化しておけばコンパイル時間抑制できるの？
ちがうちがう。
extern のほう (宣言) が暗黙のインスタンス化を抑制するからコンパイル時間が短縮されることが期待できる。
でも、インスタンス化を抑制するんだからどこか別の翻訳単位に実体が存在する必要はあって、
それに明示的インスタンス化を使えるようになってるって話。
リッチにテンプレート使いまくって一本ソフト書いてみ
まぁわかりやすいのはspiritとかのET使ったやつ、それを複数のソースファイルで使いまくればわかる
さらに言えば自分でそういうライブラリ書いて少しの変更でほぼフルビルドかかるのを体験すればわかるやろ
>>200 今時コンパイル時間を気にしないほうが頭悪いわ。
いまいちメタプの必要性が理解できん
コンパイル時に決定してる値しか計算できないんでしょ
3の階乗は計算できるけど、ユーザーから入力された値の階乗は計算出来ないって・・・
だったらはなから6ってハードコーディングしとけ
>>203 抽象化の手段でもある。
脳内で計算できる程度のものであっても、
ちゃんと名前が付いた関数になってるほうが
読むほうにとってはありがたいもんだよ。
>>203 こういう書き方出来たら便利なのにな、とかを無理矢理実現できるというロマンはある
(マクロと似たようなもんだが
プロパティみたいなことも一応出来るし
ただまぁ・・・労力に見合うか、というと散々だわマジで。
持て囃すようなものでは決してない(他人のふんどしでドヤりたい連中が持て囃してるだけ
>>203 まあ実際ビルドシステムを自分で構築するかコンパイラにやらせるかの違いしかない。
フーリエ変換の係数みたいなものを事前に設定するとかは少し便利かもね。
それなりに手計算すると大変だけれどそこまで本格的に計算時間がかからないような
事前計算できて使いまわせるようなものが念頭にあるんだろうが、まあそんなないわな。
状況に応じてコードジェネレータを用意するよりはマシってくらいか。
condition_variableってなんでこんなに面倒なんだ
winなら、イベントの方が高速だし楽で懐疑起床も起きないし
>>212 特定変数に依存しないbool条件式で起床できるのはWindowsのイベントよりも楽で応用が利く
今さらイベントには戻れない便利さがある
>>212 ほんまこれ。せめてspurious無かったらなあ。
めんどいから手っ取り早くspinして待ってまうわ。
>>213 その式を書かなくてもいいイベントを使ってからは
condition_variableには戻れなくなった
おすすめ本ってありますか？
C言語のプログラムを、文法などカンニングしながら書けるレベルです。
cppreference.comの何が不満かによる
プログラミングにカンニングという概念はない
常にオンラインヘルプなので正確な仕様を確認しながら作業するのがプログラミングの常なので、
カンニング(仕様確認、他人の書いたコードをチラ見してコーディング規約ぶ追従)は仕事の一部
訂正
プログラミングにカンニングという概念はない
常にオンラインヘルプなどで正確な仕様を確認しながら作業するのがプログラミングの常なので、
カンニング(仕様確認、他人の書いたコードをチラ見してコーディング規約に追従)は仕事の一部
明確なコーディング規約がない場合にはなおのこと、カンニングが重要になる
condition_variableに似た関数SleepConditionVariableCS()がWin32APIにも用意されてるけど、直感的で使いやすいのはcondition_variableでしょ
https://docs.microsoft.com/en-us/windows/win32/sync/using-condition-variables 質問なのですが教えてくだちい
Q1. 64 bit符号付整数の積の結果をオーバーフロー無しで（128 bit等で）で得る方法
※ 64 bit整数を2^32進数2桁とみなして筆算する処理より速い方法ｷﾎﾞﾝ
SSE4.1可
Q2. （Q1にうまいやり方が無い場合）64 bit符号付整数の積がオーバーフローしたことを検知する方法
Q3. 多倍長整数（例えば8要素のunsigned longの配列として表された符号無し整数0～2^256-1）
を10で割る方法orz
Q2は現状a*bの前に std::abs(a) <= std::numeric_limit<int64_t>::max / std::abs(b) という判定をやっているのですが
もっと速いやつ（除算不要のやつ）ｷﾎﾞﾝ、
winならMultiply128、gccやclangなら__int128ってのが使えるみたいだけど
>>223 特定の環境ならアセンブラでやっちゃえば？
ちなみに環境は？
昔その辺の演算は良くやった
Q3は10の逆数を求めておいてかけ算命令でやるのが良いけど
多売長は何進数？
10で割るだけの為にバッファスキャンはもったいない
何かの演算とセットに出来ない？
もしやりたいことが2進多倍長の10進数化なら
もっと良い方法がある
環境 (CPU, OS)
多倍長の構成 (整数？指数部あり？2進？10進？変則？)
最終的に何がやりたいか
この辺がわかれば色々と教えられる
>>223 >>225 も多倍長演算ですか、じゃ、私も私の多倍長演算を
http://2chb.net/r/tech/1434079972/37 ＞Q3. 多倍長整数を10で割る方法
であれば上のリンク先の line:383 から、std::ostream &operator<<(std::ostream &stream, mpz_base_class c) にて、ちょこっと工夫したつもりです、剰余は下位から確定する点では普通、ですので順序を逆にするのはアレかもしれませんが
とりあえず筆算のやつをｺﾞﾘｺﾞﾘ書いてや
った
https://ideone.com/pcltLW ヒント
除算は遅い
除算は逆数の乗算
定数の除算のコンパイル結果
ちゅか10で割るのは10の剰余を知りたいからなのだというのは
言ってなかったわｻｰｾﾝ、orz
多倍長整数の10進数表現を得るために、多倍長整数を10で割って剰余を求める必要があった
この目的には誤差の見積や処置が面倒な方法はNGでありかつ
10進数化とかどうせ表示の時しか使わないのでこの割り算自体はそうメチャクチャチューニングする必要は
ありませぬ（と後出し
もしｶﾞﾁで全く除算を使わずに10進数に変換せよと言われたら
5*10^n、2*10^n、1*10^nを作ってnがデカい順に元の数と比較して引いていく、
ぐらいしかなさげ
知らんけど
>>223 トンチンカンなこと聞いてたらすみませんが、Q1って多倍長整数を文字列で持ってカラツバ法とか高速フーリエ変換で計算するやり方だと「遅い」んですか？
>>236 であれば
>>230 で
まあ多倍長演算を実装するのならアセンブラが最適で、なんといってもキャリーフラグやゼロフラグを触れるのはアセンブラしかないですからね
というか、C/C++ だけで多倍長を実装するなんて馬鹿なことを思いつくのは私くらいですかね‥‥
>>238 ＞カラツバ法とか高速フーリエ変換で計算するやり方だと「遅い」んですか？
これらは、オーダーは O(n^2) より下のクラスなので速いのはそのとおりですが、しかし使えるのは掛け算のときだけですね
まあ逆数を掛けるという意味では割り算も OK かもしれません、そして逆数計算は「単桁 vs 多桁」だから、オーダーは無視できますし
それはそうと、昔バグっていた例のペンティアムの除算アルゴリズムを解説してくれるサイトはないですかね‥‥
>>236 いいわすれましたが、商が高速に求められれば、剰余は 被除数－商×除数、で求めるものですし、多分高速除算・高速剰余計算は多分そうしているでしょうね
>>240 質問者は掛け算と10で割る (小数点以下は無視する割り算ですよね？) しか聞いてないので、掛け算さえできれば良くないですか？
ああ、10で割るのはあまりを求めたいからって書いてあった
でも10で割った余りって1の位の数字ですよね？
そんな話じゃない？
まあいいや
チューニングする必要はないって話なんで、わり算の話は置いといて、結局やりたいのは整数同士の掛け算ですよね？
質問者が情報を後出ししたりしていてイマイチ信用に欠けるので、普通の整数のように何でもできる多倍長整数がほしいのか掛け算さえできればOKなのかは不明
>>243 そんな話です
でも2進10進変換をやりたいのなら、基本的に 10 で割った剰余を求める以外に手はありませんね
>>246 では、最初から10進数を文字列で持てば2進10進変換をする必要がない、というのが僕の立場の回答になりますね
やりたいことが掛け算だけなら、という条件が付きますが……
>>247 最初から10進で数値を持つと、加減算ですら速度が低下します
10進化の頻度は各種演算の頻度よりも少ない、というか、演算を何千回・何万回した最後に 10 進に変換する、かもしれない、っていう状況で、最初から 10 進で持つのは無駄以外の何ものでもないかと
それに32bit までは BCD 補正命令がありましたが 64 bit の今は BCD 補正命令（AAA とかね）ですら削除されちゃっていますし
一応私
東大大型計算機センター時代に円周率ギネスに関わったこともあって
多倍長の知識や技術は確実にこのスレで一番だと思うのだけど
スルーするなら消えるね
だって多倍長「整数」、と最初に断ってあるのに小数や指数表示の話を始めそうなふいんきだったし、
Q1、Q2に関しては64 bit同士の積の話なので
今日日のなんちゃら漸化式を使う円周率計算とかに使う
多倍長の掛け算みたいな別次元テクニックは明らかに使いどころが無いいいし……
>>249 する
ただしQ1とQ2の質問の直接の範囲ではありません
しかし、とはいいつつ筆算のアルゴリズムで実装したら必要になったので
とりいそぎ加減算を実装してみた（
>>231 Q3は多倍長整数を32 bit整数で割るやり方をガチで忘れたので質問したorz
のですが途中で思い出し実装した、というろくでもない経緯ですたｻｰｾﾝ、
>>235はついカッとなって書いた
>>234の人はｽﾏﾝｶｯﾀorz
今後の方向性としてはコンパイラはVCを使っているのでSSE4.1のイントリンシックを使って
お手軽に64 bitデータの積和を128 bit幅で計算する方向なｷﾓｽ
>>239 >キャリーフラグやゼロフラグを触れるのはアセンブラしかないですからね
それは思わないでもないが積をやりだすと上位桁への伝搬が1 bitでは済まないので
C/C++ だけで多倍長を実装するのは結果ｵｰﾗｲかと、
2進多倍長の10進化にQ3を使うのはアホ
これだけは書いておいてあげる
>>253 多倍長がどれほど多倍長かというのにもよりますが、とにかく速いQ1の回答はカラツバ法とか整数環上でFFTして畳み込みだと思います
Q3はそもそも多倍長整数をどう持つかによるので、仕様を確定しないと難しいんじゃないでしょうか
あ、64ビットにおさまるくらいの桁数の話なんですね
だったらパースとかするオーバーヘッドが大きそうなので、僕の言った方法は有効じゃなさそうです
失礼しました
肩書きとかキャリアを己の発言の信憑性の根拠にするって、お前ここはニュー速VIPじゃないんだぞ
多分勘違いしてる人がいるかと思うので一応書いておくと
>>251と
>>257 (cH3u..)は別人です
いやクソどうでも良いんだが
捨て台詞 (
>>254) 吐いて退場したけど勘違いされてたら悪いと思って戻ってきたの？
>>257がバカ発言してて
同じ人と思われたらイヤだなあと思って
>>262 長い多倍長整数の掛け算で数論変換して畳み込むより速いやり方ってあるんですか？
64ビットに収まる話なのに数論変換なんて持ち出すのがバカってことですか？
こんなところで身バレしそうな職歴晒してまでどうしたいんだろう
時々いる煽り耐性ゼロの人かな
いやフツーに嘘でしょ
精々が
・学生のときにデカいプロジェクトに名前だけ入ってた
・技官がイキってる
・隣の研究室にいた
くらいじゃない
> 東大大型計算機センター時代に円周率ギネスに関わったこともあって
「関わった」という控えめで奥ゆかしい言い方を思えば、PIとかそのクラスではないことは明らか
盛り上がってるところすいません
マルチスレッドで1バイトの変数に対してatomicな操作をしたいのですが
ロックフリーで行いたい場合
ATOMIC_CHAR_LOCK_FREEの値が2以外の場合は保証されないのでしょうか？
>>266 1バイトの変数がatomicに読み書きできない環境？
断言するが、そんな環境でお前のプログラムはどうせまともに動くわけないんだから気にしなくていい
規格的にはそうですとしか言えんわな
現実的にはともかく
>>267 いやだからそれを聞いてるんです
手元のマシンではできるのは当たり前じゃないですか
そう言うケースがあるのかそれはどう言う場合か？を聞いてるのです
>>263 特別サービス
>>238 64bit同士の乗算でカラツバやFFTなんかやらん
>>247 文字列で保持？バカ？
>>248 2進、10進どっちもある
実際ギネスの記録もどっちも使ってる
まあ質問者の内容からすると
そのうちカラツバやFFTが役立つ時がくるかも知れないけど
今の段階だと豚に真珠
役立つ可能性は
>>255がヒント
>>269 4bit CPU
C++環境は無いかもしれないけど
>>270 結局コイツが出した新しい情報一つもなしｗ
ついでに言えば
>>270 > 64bit同士の乗算でカラツバやFFTなんかやらん
さえ
>>258 > あ、64ビットにおさまるくらいの桁数の話なんですね
>>263 > 64ビットに収まる話なのに数論変換なんて持ち出すのがバカってことですか？
の後追いっていう
100パー
>>265ですわ
言語、規格バカはマジでウザい
ちょっとした言い間違いで、配列とポインタについて
30分語られたわ
先輩だから、聞いてやったけど・・・
そいつ、仕事できないなくてハブられてるwww
30分しか語れないんじゃそりゃハブられるわ
ポインタだけで1日終わるくらいがスタートラインだろ
C++に関しては知識と開発能力が比例しないということを採用担当者は知っておくべき
配列とポインタは混同してると危険だから怪しいこと言ってる奴がチームにいたら捕まえて説明するよ
どんな言い間違いか知らんけど心配させるようなこと言う方が悪い
こんなとこに同僚の愚痴書いて気晴らししてるやつが仕事できるとは到底思えないな。
同僚と先輩の区別もつかない奴はプログラマーには向いてない
linuxとwindowsで使える共通の開発環境ってなんでしょうか？
guiアプリを作りる場合です
エディタ：vscode
言語：ｃ＋＋
gui：qt
という感じですか？
pythonやelecrtonなんかもありますね
>>282 マイナーだけどwxWidgetsを推す
見た目がOSネイティブに近くなるのが好き
Karatsuba法を実装できるから実装してみた
https://ideone.com/W1j1o0 Karatsuba法推しの香具師はいっぺん自力で実装してみたらいいかもしんない
かもしんない運転、
言うは易しの好例に思えるorz、、、
>>281 辞書くらい持ってるだろ？日本語も勉強しような
>>285 お前が勉強しろよw
同じ職場の人という意味で同僚とか言ってるだろうけど
>>275があえて先輩と書いてる意味もわからんのか？
>>286 そこ区別して同僚の愚痴を先輩の愚痴に書き換えたところでなにも変わらんだろアホ
技術的な話で太刀打ちできなさそうだと枝葉末節で揚げ足取りが始まる掲示板はどこでしょう？
そう、ここです!
>>284 測定してみればわかるけど
カラツバの守備範囲は非常に狭い
>>279 御意
俺も文字列リテラルはポインタって言ってる先輩がいてバトルになったことがある
>>287 マジで日本語の理解力がないんだな…
>>275はパイセンより理解してる俺スゲーって言いたいんだよ
まあ底辺同士の争いでしかないけどw
>>283 wxpythonというのがありましたね。
qt＋ｃ＋＋の組合せよりも簡単ってことでしょうか？
C++11以降はそれ以前のC++とまるで別の言語のような感さえある。
だが基本中の基本である文字列操作がJavaやPythonほど簡単になってないのが残念。
>>292 pythonでは使ったことないのでわからん
つかここはC++スレなので、言語関係なくGUIツールキットについて聞くのはスレ違いかと
linuxでopenglやりたいので、ｃ＋＋かなと。
>>284 長
カラツバの計算量が桁数の何乗かは忘れたが、ちゃんとスケールした？
あと当然FFTの方が早いよ
まあどの道64ビットに収まる桁数だったら意味ないってことは上で結論出てるけどな
掲示したソースコードにおける
最適化に対するメモリエリアシングの影響について：
クラスに特定のoperatorが定義されているか調べるために、
以下のようなtemplateを作ってMSVCでもclangでも一応期待通りに動いてはいるんだが、
VS2019のintelliSenseの解析が異常終了するらしく機能しなくなるんだよね、VS2017は大丈夫なんだけども
何か変かな？
template < typename OPERATOR, typename T > class has_operator
{
private:
template < typename U > static auto check(U x) -> decltype(x.operator OPERATOR(), std::true_type());
static std::false_type check(...);
public:
static bool const value = decltype(check(std::declval<T>()))::value;
};
>>284 ＞Karatsuba法推しの香具師はいっぺん自力で実装してみたらいいかもしんない
わたしも、やろう、やろう、とおもってても最後は「この野郎」になってしまうのです
カラツバ、今の私には強敵です…
桁数nとしてカラツバはおよそnの1.6乗でFFTならnlognなのになぜか皆カラツバの方をチョイスしててワロ
文系の皆さんにはフーリエ変換なんて難し過ぎるか
FFTの方は奥村のCアルゴリズム本に載ってるからアクセスしやすいけどね
カラツバはクヌース本くらいしか知らん
>>302 だって DFT とか概念すらわからないし
高卒には無理です‥‥
カラツバだったら意味ならなんとかわかります
高卒・・・そんなんで偉そうに留数定理とかのたまってたのか
複素数に関するアレコレが指導要領に入ってた頃の高卒だと思うと逆に悲しいな笑
>>309 大昔あって今また復活したみたいな流れじゃなかった？
留数定理を必ず習った/習うかどうかは知らんが
>>312 なにが「ないはず」？
留数定理という特定のサブジェクトの話かもっと広い複素解析の話か
複素平面と複素関数論のさわりは少なくとも昔と今は習うよ
QZを批判すると必ず現れるD:DSKXDkbAみたいな奴
怪しい
同一人物だろうな
QZは
>>304と同じIDで書き込みしてみろよ
無理だろうがなｗ
それに多価関数がわからないと泣いていたよなQZｗｗ
哀れ過ぎる
>>304は昨日なので、同じIDが出せたらモノホンのハッカーでは
なるほど
昨日だから今日これだけ暴れているのか
なおさら哀れになってくる
実際の自分より良く見せようとする病気＝自己愛性パーソナリティ障害
技術系の板に精神分析を書き込む人って、その人自身が精神を病んだ経験ありそう
鏡に話しかけてる感じ
お大事に
>>313 複素解析の話だろ
複素平面と複素関数論に含まれると言いたいのか？
言語規格厨のウザさは以上
コピー代入が、ムーブ代入がってそんなことより
さっさと仕事しろよ
工数足りないんだよ
>>317はQZ
間違いない
それとこれ精神科の話だよね？
クロルプロマジンなんか普通の人が薬局に行っても買えないぞ
精神科で処方箋出してもらわないとな
な、自作自演で同一人物が書き込んでいると思い込んでるだろ？
やたらと薬物(合法)の名前に詳しいだろ
この辺が病んでいる・病んでいた証拠なんだよ
>>324 ある者が薬物の名前を知っているという命題から
その者が病んでいるという結論はどうやって演繹したんだ？
薬の名前はQZが自分で書いてたんだぞ
http://peace.2ch.net/test/read.cgi/tech/1313183984/303 >303 名前： ◆QZaw55cn4c [] 投稿日：2012/07/28(土) 18:08:51.36
>
>>302 >飲んでるお薬
>>326 >>324に聞いているんだ
おい
>>324、無責任な推測から逃げるなよ
>>284のKaratuba法のコードには計算結果に影響するバグがあった（爆
修正したやつを貼る、
https://ideone.com/mhRQte バグとしては、
>>284のままでは次の計算を誤る。
0xffffffffffffffffに対し0x0000000100000001を乗算
Num in hexa: 0xFFFFFFFEFFFFFFFF <== BUG!
Expected: 0x100000000FFFFFFFEFFFFFFFF
げいいんは、Karatuba法であるmul_mlen_mlen()の末尾で
z2 * 2^(b+1) + z0 に対し、z1 * 2^bを加算する
という演算をやっているのですだが、桁上がりをきちんと2^(b+2)のワードまで
伝えていなかった、|||｡n_
あと細かい点として、符号反転を0に対して無駄に行う個所があったのでそこも修正すた、
ｶﾅｰﾘ切羽詰まってきているのでレスはあとでまとめて読みませていただきまつ以下略、
>>329 桁数がスゲー長くないと意味ねえってお前以外全員分かってるんだけど大丈夫？
128ビット以内の計算にカラツバなんか使うと逆に定数倍遅くなる可能性すらあるだろ
mul_mlen_mlen()自体は桁数がスゲー長いケース（任意長）に対応していることは読めばﾜｶﾙ
Wrapperであるmul_u64_64()が128 ビットでそれを使っているというだけ
いや、カラツバなんか実装する意味ねえつってるんだがどこまで馬鹿なんだ
>>335 >>333 >128ビット以内の計算にカラツバなんか使うと
桁数がスゲー長いケースならカラツバなんか使わんし
数倍長程度でも使わん
もちろん速度やリソースを無視して単に動くって意味なら何でも良い好きにしろ
>>340 面白くないよ
面白いことを言ったつもり？
お前らlong long long long使えるのしらねーの？
精度、用途、環境
で色々な方法を使うのがベスト
カラツバだけ知っててもほとんど役に立たない
下位レイヤーでもFFT, double-double, ...
など色んな方法があるし
上位レイヤーから下位レイヤーまで全体を考えて最適化しないとダメ
boostって使える？
あれって、単なるテンプレートで遊んでるだけだろ
そのくせにやたら遅い
正直使い物にならないイメージ
>>226でいいじゃん。
これ以上早くしたかったらどうせ環境依存になる
>>344 使えるかどうかは置いといて、遅いのは最適化が効いてないとかでは？
>>344 boostは標準ライブラリとして採用するための実験場的な側面があるから、C++11以降を使っているならboostに足を向けて寝ちゃだめよ
stlもコンテナ類からして設計哲学に問題あると思ってる。
それにsize_tがunsignedで、ssize_tがsignedなのも馬鹿。
伝統的なCでは、strlen()などはintでsignedだったのだから、
短く書ける方のsize_tを最初からsignedにすべきだった。
伝統的なCでは、
int strlen( const char *str );
だったのが、なぜか、64BITにも対応した後は、
size_t strlen( const char *str );
となってしまった。size_tは、必ずunsignedであるとされる。
ならばこのプロトタイプ宣言は、伝統的なCと互換性がない事になる。
しかも、伝統的に int a = sizeof(buf); のように、sizeof() は符号付き int
を返す処理系が多かった。
一方、size_t は、sizeof()演算子の結果の符合なし整数とされる。
これもいろいろな意味で矛盾している。
C++11以降のC++はめちゃくちゃ。
何年前のものだか忘れてんじゃね？
まだ単一継承が宗教のような存在だった頃だぞ
これから新しく作るライブラリがああなってたらアホかとも思うが
当時そんな批評できてたやつを憶えているか？
Cの教科書で、
int a;
a = strlen(ptr);
見たいなのはよく見た記憶が有るが、
size_t a;
a = strlen(ptr);
というのは記憶に無い。
昔はsize_tなんて型は本には書いてなかった。
ところがネットだととても昔からstrlen()の戻り値はsize_tであった
と言う事になってしまっていて、全世界的に事実を改竄している。
というか俺の記憶だけが世界の記憶と食い違ってる・・・。
「サイズは本質的に負になることは無いから、符号無しでよい」
なるほど、これには一理ある。しかし、ptr2 - ptr1 は、ptrdiff_t
で符号付きとされる。これは伝統的なCがそうであったから分かる。
しかし良く考えてみると、例えば32BITマシンで、2GBを越えるデータ
を扱う場合、確かにそのサイズは符合つきでは扱えないので符合なしで
良い。ところが、この場合、最後のバイトをptr2、最初のバイトをptr1
でアドレスしているとすれば、ptr2 - ptr1 は、2G を超えた値になる。
おー、となると、ptr2 - ptr1 を ptrdiff_t のような符号付きで解釈すると
負の数となる！！！
おう神よ！！
>>354 もう少し深く考えて見ると、ptr2 - ptr1 は、どちらが若いアドレスかが
わからない時でも結果を理解するためには、結果は符号付き整数である
ことには合理性がある。つまり、ptr2 < ptr1 なら、負、ptr2 > ptr1 なら
正と。
ところが、32BITマシンで、2GBを越えるデータを扱うと、この解釈では
問題が出る。
結論的には、sizeof()や ptr2 - ptr1 の結果の型に対してどんな場合にでも
上手く行く定義は存在しないようだ。
K&R1にはsize_tなんか出てこない
strlenの戻り型はintとすら書いておらず
省略時の解釈で暗黙にintとなっている
>>351 「伝統的」っていつの話だよ。
C89 が制定されて以降、 strlen の返却値や sizeof の評価結果の型は size_t だろ。
念のためにちょっと確認してみたら
Turbo C 1.0 なんて 1987 年の日付 (C89 制定前) だが strlen の返却値は size_t になってるぞ。
>>358 当時の本でも、
int a;
a = strlen(ptr);
と書いてあったと記憶してるので、指導的立場の人も含めてほとんどすべての人が
unsigned int の戻り値を int の変数に入れていたということだね。
https://stackoverflow.com/questions/32985119/strlen-to-int-c-why-cant-i-do-this ↑こんなにC++に詳しそうな人達も、なぜか、符合無しの size_t を
intと比較している：
std::size_t length = s.size();
for (int i = 0; i < length; ++i)
どこかでC/C++の長さは、intであると刷り込まれているようだ。
しかし、35年以上前のTurbo C ですら、unsigned intであったのに。
質問者は、
for (int i = 0; int n = (int)strlen(s); i < n, i++)
がエラーになることの理由を聞いているようだが、これは単純に
for文の書き間違いで、少なくとも、
int i, n;
for (i = 0, n = (int)strlen(s); i < n, i++)
と書けばコンパイルは通るはずだ。
スマン:
誤: for (i = 0, n = (int)strlen(s); i < n, i++)
正: for (i = 0, n = (int)strlen(s); i < n; i++)
> どこかでC/C++の長さは、intであると刷り込まれているようだ。
これは違う
double a = 0;
と書いたからって0がdoubleと思っているのと違うようなものだ
>>353 > 全世界的に事実を改竄している。
世界で自分だけ正しい、あとの70億人はすべて間違っていると考える病人
>>365 ガリレオの時代にガリレオ以外に地動説を考えてた奴が他にいなかったと思い込む馬鹿。
>>360 その場合に int で表現可能な範囲内の値である限り暗黙の型変換で不整合は生じない。
strlen の返却値が size_t なのは、最大でそこまで対応可能ではあるが、
扱うデータの大きさが int の範囲内にあるという「想定」をしてもすぐさま誤りではないし、
int の範囲を超えるほど長大な文字列を想定しなきゃならない機会はそう多くもないだろ。
常識的な想定と言語仕様を混同するべきではない。
>>365 私も、ある意見について「世界で自分だけ正しい、あとの70億人はすべて間違っている」という実感を持っています
問題はそれを世の中に知らしめす方法ですが、今の私はリアルで打撃につぐ打撃、その上におまけの打撃まで食らう状態で、いわば瀕死の状態‥‥
さてこんなボロボロな私はどうすればいいのでしょうか？
>>368 短期目標と長期目標を立てて、目標に達成したら、自分を褒める。これを繰り返す。
>>368 あんたはビョーキだから何をしても無駄
「自分は間違っている」という実感を持てたら少しは回復した証拠
.hファイルと.hppファイルって何が違うんスかね
includeするならincludeしたがわの拡張子でコンパイル方法？が決まるわけで
ヘッダの拡張子の違いとは？
.hには宣言だけ書いて.hppには実装を書くという使い分けをしている人が多い
宣言と実装を同時に行うときも .hpp
STLコンテナに機能を追加したい (たとえば vector の要素の順番を自分のルールで並び替えるメンバ関数を追加したい) ときってどう書くのですか？
この場合はメンバ関数じゃなくてフリー関数として実装した方が良いとしても、メンバ関数を追加する方法を知りたいです
(それとも、STL コンテナの継承が忌避されるのと同じ理由で、こういうのはやらない方が良い話ですか？)
>>375 仕様上の違いはない。
習慣的にもそれほどはっきりした使い分けが確立しているわけでもなくて
確かに
>>376 もひとつの例として納得はできるけども
多いっていうほど多くもないような印象。
どういう意味で使い分けているのかは人 (組織) によるので、
違いがどういう意味を持つのかを一律には言えない。
個人的には、 C のヘッダとしても使えるように配慮した場合は h にするかな。
>>376 >>379 なるほど
そういや自分もCのヘッダを意識する場合は.hにしてるかもですね
どうもです
>>378 でも STL コンテナの継承って凄い忌避されてる印象を持ってます
罠が多いって
やっぱり引数で取って引数で返す方が良いのかな、、、
>>381 STLはソース(ヘッダだけど)を見ると物凄く解読に時間が掛かる書き方になって
いて、正しく現状どうなって実装されているかを理解するのがとても難しいが、
継承するとなるとちゃんと理解出来てないと危険なので継承したがらない人が
多いのだと思う。
>>382 あと、テンプレートを普通のクラスの基本クラスにすることは容易だけど、
テンプレートを継承したテンプレートを作るのは、C++をかなり深く理解して無いと
色々と危険かも知れない。
また、ややこしくしてるのは、perfect forwarding や reference collapsing、
右辺値参照、moveセマンティクスが多用されていることに加えて、
余りドキュメント化されて無い解釈の難しい独自関数を使用して書かれている
ことが多いこと。
>>383 それ以外にも、template引数に「...」があったり、それを使う場所でも「...」
があったりして、それぞれの意味や展開のされ方を正しく理解するのは難しい。
コンパイラがどういう解釈をするのか途方にくれることが有った。まるで
魔法のように見えることすら。結果的な意味は何とか分かっても、コンパイラが
どういう原理や順序で理解したりコンパイルしているのか深く理解できないこと
が多かった。
最新のSTLのソースをちゃんと理解できるまでC++を理解するのは、C++を
本格的に勉強する必要がある。
>>384 古いC++にも「initializer list」という言葉はあったが、C++11以降は
独特の概念が追加され、それに関連したオブジェクトを関数の引数にとったり
できるようになったりして、それの働きを深く理解するのがまた難しい。
また、全体的に lvalue, rvalue に加えて、xvalue, prvalue, glvalueを正確に
理解し、何がどれに属するかを徹底的に理解してなければ、STLのソースコードを
正確に理解することはままなら無い。
僅かでも理解してないことがある状態でSTLのコンテナを独自に継承した
テンプレートを作った場合、思わぬ不具合やメモリー関連の原因が特定しにくい
バグをアプリ開発で忙しい時に遭遇してしまうかも知れない。
間違ってるかも知れないが、
initializer_list<T> は、「list initializer」に関係したテンプレートで、
登場したのはC++11移行なはず。
一方、member initializer listや、class initializer listは、名前が同じだが
全く別の概念なはずで、コンストラクタを関数定義する時に、
: MyBase(0), m_x(x), m_y(y)
のように書く部分。
initilizer list と list initializer はかなり異なった概念なハズだが、
後者に関係したオブジェクトの型は、initializer_list<T>と書くようだ。
間違っていれば指摘して欲しい。
間違ってるかも知れないが、
initializer_list<T> は、「list initializer」に関係したテンプレートで、
登場したのはC++11移行なはず。
一方、member initializer listや、class initializer listは、名前が同じだが
全く別の概念なはずで、コンストラクタを関数定義する時に、
: MyBase(0), m_x(x), m_y(y)
のように書く部分。
initilizer list と list initializer はかなり異なった概念なハズだが、
後者に関係したオブジェクトの型は、initializer_list<T>と書くようだ。
間違っていれば指摘して欲しい。
クラス A の中で他のクラス B のインスタンスをメンバとして持ちたいとき、B のコンストラクタに引数を渡す方法が初期化リストくらいしかない
つまり後でわかる情報を使って B のコンストラクタを呼ぶ方法がない
B じゃなくて B のポインタを持てば良いって思うかもしれないが、こんなどーでも良いところでポインタの使用を強制する言語仕様ってゴミだろ
もーちょい頑張んなよ、C++クン
using namespace std をヘッダファイル内で使いたいです。なんせ短くなるので
でも、そうすることでリスクを負うというのもわかります
どう折り合いをつけるべきでしょうか
皆さんはどうされていますか
>>381 メンバ関数追加するだけならまぁ問題は思いつかないけど(スライシングや非仮想のデストラクタはメンバ変数追加が無ければOK
ただ素のvectorからの代入やコピー、ムーブコンストラクトは出来ないので追加で書いてやらないといけない
さらにそのメンバ関数を呼ぶには派生型にキャスト(コピーとか防止のために参照でキャスト)をいちいち書かないといけない
まぁそんな面倒な派生クラス使うくらいならフリー関数にしといた方が楽だよね
そんなこんなで安易な機能追加のための継承(まして継承される前提でないクラスを)ってのは普通避ける
>>391 ARM C++のコンパイラ使ったら？
#include <iostream.h>
これならstd空間が元々ないよ
コンテナは継承するまでもないほど完成されていること、
コンテナを継承するくらいならコンテナをメンバ変数にもつクラスを定義したほうが機能拡張や仕様変更に対応しやすい
などなどでしょ
>>393-394 でも例えば公開するとかなってくると当然 using namespace std; は問答無用で除くべきですよね？
あと近い話で、マクロってどこに書いたら良いんでしょうか
REPマクロ等を多用するんですが、同じマクロをいろんなヘッダファイルの冒頭に書くのって変ですか？
共通するマクロは、親に該当する utility.hpp みたいなヘッダファイルを作ってそこに書く等するべきですか？
>>397 ああ、それなら俺もやる
開発初期はusing namespace std;で色々試していて
公開がちらついてきたあたりで律儀にstd::を書くスタイルに変えていく
自分はC++17でusingディレクティブでなくusing宣言のパック展開使ってるけど、(using std::cout, std::endl, std::string; とか)
これも好ましくないのかな
using std::* したいスコープを独自の名前空間で囲めば他人に迷惑かけずに済む
マクロは名前空間を超えるので他人に迷惑かけやすい
>>401 その理屈だと、公開するプログラムにおいてはマクロはよほどユニークな名前じゃない限り使うべきじゃないってことですか？
ヘッダーファイルでマクロを定義するなら名前衝突を警戒すべきであって理屈とかじゃなくてマナー
>>397 ユーザーにincludeされるヘッダじゃなくてcppでだけusingすればいいやろどうせ実装書かないんだから
(テンプレートとかでヘッダに実装書くならすでに出てる通り名前空間に隠すとか
>>402 まず被らない名前ならいんじゃね
それかundefするヘッダも作って使い終わった段階でそれをインクルード
Windowsのmin,maxとかAppleのcheckとか
考えなしの公開マクロ名は使う側に大迷惑だから慎重にしないといけない
minとmaxが関数型マクロなのはやさしさ
#include <Windows.h>
#include <stdio.h>
#include <algorithm>
int main() {
int a = 3, b = 4;
//int x = std::max(a, b); // NG! ビルドエラー
int x = (std::max)(a, b); // OK
printf("x=%d\n", x);
}
#include <windows.h>
#undef max
#undef min
>>398 >>401-403 namespace hoge {
using namespace std;
プログラム本体
}
って書いておけば他と干渉しないんじゃないの
>>409 ×留数とかもう忘れた・・・
◎留数なんて勉強してません高卒てすから
学歴コンプレックスって醜いよね～
ところでラプラスって何ですか？
ラプラシアンなら知ってるんですけど
Lhaplusのことですか？
>>409 そういうのは小さい次元,2x2あたりで計算してみて、大きい次元でも成り立ちそうだなと納得するのが早いかもですな
つか人生相談は板違い、
一生虐げられ続ける弱キャラとしての宿命がC++の規格書に書かれているなら話は別だが
ヘッダオンリーライブラリの体で自作のプログラム配布するときって、全体を namespace でくるむのがマナーなんですかね
普通な名前の関数を定義したりして衝突したら不味いから？
>>417 もしプリコンパイルヘッダーに
#define NOMINMAX
#include <Windows.h>
と書いてしまった暁には、マクロ版のmin()やmax()を使いたい人は
どうやって生きていくんじゃ……
boost の多次元配列ライブラリ multi_array を使ってるんだが、両辺の shape が違うときに = で代入できないのがストレスなので、引数の shape が違うときには左辺を右辺と同じようにリサイズしてから代入するように = の定義を変えたい
演算子のオーバーロードってテクを使えば良いらしいが、これは諸刃の剣で注意が必要みたいな記事を見て戦々恐々としてる、、、
代入演算子のオーバーロードで最低限気をつけるべきことってどういうものですかね
気をつけるべきこと
代入演算子を一時的なストレスでオーバーロードしない
代入はグローバルに書けないはず
メンバとして書くしかない->multi_arrayのヘッダを書き換えるしかない
new して確保するわけじゃない、既存の変数のアドレスを格納するだけのポインタって別にスマートポインタじゃなくて生ポで持てば十分だよね？
生ポでいい用途を自信を持って判断できず「念のため」スマポ使うやつでも見かけた？
用途次第だけどnullにならない分参照の方がいいかもしれない
もしくはshared_ptrと一緒に使うならweak_ptr
>>426 後出しですみませんが、vector の各要素へのポインタを vector で持つ事も考えてます
参照の vector は普通には持てないので、その意味でももう生ポインタの vector で良いかって気になっていました
reference_wrapperなら参照vector作れるけど、そこまでしたくないってことならポインタでいいんじゃない
気をつけてな
考えるべき所がズレてる
既存の変数はポインタを保持してる期間に必ず存在しているか
別スレッドから既存の変数へのアクセスが発生するか
表記方法を考えるのはその後
>>423 こういう場面では生ポインタでいいよね？ っていう意味？
#include <memory>
int main(void) {
int a;
std::unique_ptr<int> b(&a);
}
むしろ不必要に解放しようとしてワヤになるんで、生ポインタである必要がある。
デリータが何もしないようにすればスマートポインタでも大丈夫ではあるけど、
あえてそうする必要もないし。
>>427 std::vector は要素を追加するなどしたときに再配置が起こる可能性があるから
要素へのポインタ (または参照) を持つのはあまりオススメできない。
(インデックスで持ったほうがいい。)
適切に管理できるならポインタでもそれほど問題でもないんだけど、
質問の雰囲気を見る限り十分な理解があるような感じでもないので……。
vectorの中身なら
要素の参照やポインタ
vectorの参照やポインタと要素のインデックス
イテレター
色々と持ち方があるから
場面場面において適切なのを選ぶ
メモリ管理をしてないのにスマポで保持は無い
>>430 > std::vector は要素を追加するなどしたときに再配置が起こる可能性があるから
> 要素へのポインタ (または参照) を持つのはあまりオススメできない。
> (インデックスで持ったほうがいい。)
再配置が起きたとして、ポインタが指してる先が危険にさらされることなんてあるんですか？
newした新しいメモリにコピーして古いのをdeleteしたら古いのを指してるポインタはもう使えんだろ
ほら最近初心者への教え方がおかしい&最初からスマポ押し付けるからこういうのが出てくる・・
いや new や delete はしないって書いてあるよ
よく読んでおじいちゃん
最近のC++が難しく感じる原因は、cppreferenceに頼ってる人が多いから
ではないか。あそこはドキュメントの品質が悪くて混乱の原因になる。
C++は、代入/コンストラクタがmove系とcopy系で原理的には好き勝手にプログラム
できるので、バグが出た時にプログラムの流れを追うためにはmoveとcopyのどちらが
呼び出されているかプログラマがコードから明確に区別ができないと困るね。
その点、デフォルトmoveで、xxx.clone()としない限りは複製されないRustの
設計思想はそれはそれで便利と言えるかな。
どちらが優れているかは一概には分からないかも知れないけれども、デバッグ
時の追いやすさの観点からすればRust流の方が良いかな。
>>438 C++の場合は、x=std::move(y);と書けば明示的にmove系が呼び出されるので
その場合、混乱は生じないが、右辺が関数の戻り値が構造体型/クラス型の場合、
RVO(Return Value Optimization)が働いたり、右辺が「クラス名(引数列)」
のようなテンポラリオブジェクト作成の場合にはmove系が選択される
という「自動振り分け機能」があり、自分が知らないだけでそれ以外にも
特殊なパターンがまだあるかもしれないことが、不安や予想しづらい
原因になっていると思う。
Rustの場合は、自動化されているかと思いきや、実際には、代入などが
move/copyのどちらになるかに関しては、自動ではなく、
デフォルトmoveで、x.clone()とした場合にのみcopyという明示的に
区別する方式なんだと思う。
std::vector<int> v((size_t)3);
printf("&(v[2])=0x%p\n", &(v[2]));
v.resize((size_t)5000);
printf("&(v[2])=0x%p\n", &(v[2]));
↓実行結果（例）
&(v[2])=0x000002376EF91658
&(v[2])=0x000002376EF93A08
new,deleteが起きないとかいうトンデモ理論はshared_ptr<T>のstd::vectorと混同した感じ？
数値計算畑の人間だけど、numpy with MKL が C++ より速くてワロス
もうホントにニッチな領域でしか使わなくなっていくな C++
>>442 それはシングルユーザーライセンスであっても 500千円からという価格のインテル製コンパイラやライブラリを使うからなのでは？
多次元配列の添字を入れ替える関数を実装したいのですが、任意の次元に対応するものをどう作れば良いのかわかりません。
たとえば v[a][b][c] を v[c][b][a] と入れ替えるのを全ての a, b, c について行ないたいです。
次元が 3 と決まっていれば、整数 a, b, c についてループを回して
v_[c][b][a] = v[a][b][c]
のようにコピーすれば良いのですが、次元が任意だと鉤括弧 [][][] を用いた要素アクセスをどうすれば良いのか分かりません。
不可能ですかね？
その場合、多次元配列を 1 次元で持つことにして、各次元の長さを la, lb, lc,... として、整数 x を 0 から la*lb*lc... -1 まで回して、その都度 x の各桁を取り出して要素をコピーする、みたいなことしかやりようがないですか？
そうなると各桁を取り出すのに割り算とか剰余演算を駆使しないと駄目なのでパフォーマンスが落ちるのが懸念です。
あるいは、3 次元に対応した関数、4 次元に対応した関数、…… といった感じで各次元に特殊化した関数を実装するべきでしょうか？
できれば一般的というか汎用の関数を作りたいのですが。。。
シングルユーザーライセンスであっても 500千円からという価格のインテル製コンパイラやライブラリ
を使ってもnumpy with MKL が C++ より速いとかこの世は暗黒だな
v[0]やv[i][0]が配列なのか単一の型なのかは判定できるから
enable_ifで分けてオーバーロード(再帰するかしないか)とか出来るはず
>>433 >>427で「vector の各要素へのポインタ」って書いてるからそっちの話だろう
>>445 MKLがIntel製で、
「Intel Math Kernel Library (MKL) というのは, Intel 製の高速な数値計算ライブラリ」
だよ。
つまり、Pythonでは、Intel製の高速なライブラリを使っているが、C++では
使って無い場合の速度比較。
>>446 なるほど……
勉強してみますが大変そうですね
外部ライブラリに頼るか迷いますが、多次元配列は非常に基本的な機能だと思ってるので最低限度で取り回しの良いものを自分で持っておきたいという思いがあります……
作るなら[x] [y] [z]の形にしない方が良い
[]の中にベクトルを入れる方が融通がきく
>>452 v[ {x, y, z} ] みたいに要素アクセスするってことですか？
MKLが元々c/c++のライブラリってことも知らん輩がおるのか。。
まあ確かにnumpyやってりゃ問題はないが。
MKLが元々c/c++のライブラリってことは知ってたが
Pythonでシングルユーザーライセンスであっても 500千円からという価格とは思わなかった
、
>>448 生ポインタのvectorってだめなんだ
やってたかも
まあpush_backとかしなければいいんかしらんけど
>>454 でも
「numpy with MKL が C++ より速くて」
という言葉からすれば、Pythonの時だけそれを使い、C++の時にはそれを使ってない
としか思えない。
PythonでもC++でも同じMKLを使ってて、Pythonの方がC++より
速いなんて事は有り得ないだろうし。
>>456 だれも生ポインタのvectorがだめなんて言ってないから何か勘違いしてそう。
>>456 ん？ダメなのはvector要素へのポインタだぞ？
>>459 だめなのであれば、std::vectorの存在意義を否定することになりかねない。
C互換の配列およびポインタを実現するコンテナはstd::vectorだけ。
危険性を分かったうえで使う、というのが正しいかと。
>>460 どういう意味で存在意義を否定することになると言っているんだろうか。
必要に応じて再配置してくれるのもvectorの存在意義だと思っているが？
昔のstd::vectorは先頭アドレスを取得するメンバ関数data()がなかったのでポインタとして使うことに多少の背徳感があった
>>459 ポインタ保持中にvectorがresizeしないなら
ポインタ保持で何の問題もない
要素の再配置ができない場合や要素のポインタを扱う場合は、多少効率は落ちるがstd::dequeつかえば良いと思う
>>465 > vector とは異なる欠点として deque は連続した位置のストレージに全ての要素を持つことを保証していないため、ポインタ演算を介しての安全なアクセスの可能性を排除する。
https://cpprefjp.github.io/reference/deque/deque.html >>466 あぁ、連続要素アクセスは確かにだめだなw
でも、連続要素アクセスならポインタなんか使わずに範囲for分なりiteretor使った方が楽だよね
なるべくキャッシュに入れたいって率でメモリ連続性を求めてる人たちはたぶんそれだとキツい
Win32APIなどOS固有のシステムコールはC言語を前提に作られているので、C++でその恩恵を得たいならメモリ連続性が保証されたコンテナが必要不可欠
APIがらみだとstd::arrayのheap使用版みたいなのが欲しくなることがあるな
vectorだと初期化が若干面倒なんだよね
>>450 ごめんさらっと言ったけど、現在の各次元のインデックスも実行時の数値として渡す必要あるし再帰と相性悪いかも
ただ文法上、次元数に関わらず同じコードで、ってなるとテンプレートと再帰は必須だと思う
けどそこまでしても、君が書いてた一次元で除算と剰余使うのと比べてそんな速くなるとも思えんので無理せず一次元でいいと思うw
https://wandbox.org/permlink/XpJkS3veZNwNOlaQ 気になったのでやってみた、実測(一次元、および要素数決め打ちとの)はめんどいので頼む・・
numpy のAPIを C/C++ から使うのがお薦め
>>473 ありがとうございます
正直 beyond me って感じですが、勉強になります
こういう再帰的な定義って STL の [] も同じなんですかね？
>>474 これって、numpy の記法で C++ の配列を操るというわけではなく、Python (numpy) を C++ から操るということですよね？
全ての処理を numpy の機能で行なうことにすれば、全ての計算が事実上 C++ で動くことになるから速いって感じなんですかね
>>475 いや再帰してるのは単にint[I][J][K]をint[J][K]のループ、さらにint[K]のループに(配列の参照で)分解するためにやってるだけ
(そうすればどの階層でもt[i]で書けるから
ただこれ、コンパイル時に要素数も次元数もわかってる固定長の配列でしか使えないんだよね
ポインタを要素数決め打ちで多次元配列の参照にキャストして渡すのは出来るかもしれんけど・・
まぁ要素数が実行時にしか分からなくても使える一次元での計算のが汎用性高いと思う
皆さまコロナ禍いかがお過ごしでしょうか
ちょっと質問させてください
特定のクラス内部で自身の型を格納するコンテナを実体として確保し、そのコンテナから入れ子状？のような形で使用しています
私の環境では動くのですが、これを動かしても安全なのでしょうか？
クラス内部には自身の型を確保できないと聞いたことがあります……
問題が起きそうな気配がしなくもない感じがしますが
当方素人です
class hoge{
Int a;
bool b;
vector<hoge> hoge_vec;
};
このクラスを
hoge Tochigi;
Tochigi.hoge_vec[0].a=315;
というように使っているのですが……
>>479 問題ない。 クラスは自分自身を内包できないが、
それは自分を内包した自分というものが可能だとすると
大きさが無限になってしまって確定できないからで、
参照やポインタとして持つ分にはそういった問題にならない。
std::vector の実体としてはヒープに確保した配列に要素を入れていく形になるので、
この場合に hoge が hoge を内包しているわけではない。
>>481 ありがとうございます
アロケーターがコンテナ用の領域を確保してくれるので確保可能と言うことでしょうか？
クラス内部で要素数ゼロのvector領域を確保してメモリを予約してるのかな？
vectorの型がvector分の領域を計算できないから見た感じ不可能だと思って
どういう処理してるのか
>>482 std::vector が適当な大きさの配列へのポインタを持つ構造だと思ったらだいたい正しい。
>>483 その言い方でなんとなくわかった気分になりました
連続で確保できる適当な長さの配列の先頭へのアドレスを確保してるってこと？
自身の大きさは除外してほかのメンバ変数の大きさだけを配列0番目に確保すればいいのかな
前回も餃子さんに答えていただいた記憶
どうもありがとうございました
いずれ共有ポインタのvectorを使いたくなるはず
GW期間中に循環参照の罠を思う存分楽しむといい
共有ポインタのvectorって何だろう？
sheared_ptrの事ですか？
>>478 標準ライブラリは遅いから、使いたくないです
多次元コンテナってもう標準ライブラリ入ってるんですか？
>>493 や、
>>478さんはどういう意味で仰ってるのかなと思った次第です
良いのがあったら使えば良いし
無きゃ作れば良い
っていう感じ
多次元コンテナなんて
使い方によって最適な実装はいくらでも変わるんで
汎用性を追及するのは時間の無駄
左辺には置けないものがある、その一覧とか例とかありますかね・・・
>>496 ・定数リテラル、const属性が付くもの、は置けない。
・関数呼び出しの 関数()は、戻り値は、伝統的に右辺値扱いになるので左辺に置くとエラー
になる様になっている。
戻り値は、構造体型(クラス型/union型含む)/整数型/浮動小数点型/ポインタ型/列挙型の場合
を想定した。
・*ptr のようなものは左辺値になるので置ける。
・変数名はconst 修飾されていないなら置ける。
・構造体変数名.データメンバ名 は const 修飾されていないなら置ける。
・「関数名」は置けない。これは関数呼び出しの関数()とは別の話。
・&x は置けない。理由としては右辺値であるから。constでもあるが。
・x + y は、組み込み演算子の場合でも、関数呼び出しに置き換わった場合でも
置けない。後者の場合は、関数の戻り値が置いてあるということになるが右辺値だから。
前者の場合は、右辺値だからだと思う。
>>500 >・構造体変数名.データメンバ名 は const 修飾されていないなら置ける。
これについては、構造体変数名が、右辺値の場合は、
構造体変数名.データメンバ名も右辺値になるため、置けない。
[続き]
・(cast)x は置けない。理由は、右辺値になるから。
なので、int i; (char)i = 5; はエラーになる。
そうしたい場合は、*(char *)&i = 5; と書く。
配列を要素展開して、可変長引数の関数に渡したいんですけど、どうかけばいいか分かりません
template<typename... Ts>
void g(Ts... ts){}
template<typename T,size_t N>
void f(T (&a)[N])
{
g(a[0],a[1],a[2]/* なんて書くのか*/);
}
>>502 (char &)iでええやん...
>>503 index_sequence
通常クラスのコンストラクタにテンプレート引数がある場合ってどう呼び出したらよいでしょう？
class Test{
public:
template<class T>
Test() {}
};
Test test = Test::Test<int>();
で呼び出せるかと思ったのですが出来ず...
class Test{
public:
template<class T>
Test(T dummy) {}
};
コンストラクタに引数を持たせると、msvcでは一応できました。
Test test(0);
代入演算子ってメンバ関数じゃないとだめなんだな
thisを返すから当たり前だが、オーバーロードしたいとき困る
a = b を意味する assign(a, b) を作るしかない？
thisがどうのじゃなくてコピー代入演算子とムーブ代入演算子が特別扱いだから
>>506 https://timsong-cpp.github.io/cppwp/n4861/temp.arg.explicit#8 > [Note: Because the explicit template argument list follows the function template name, and because constructor templates ([class.ctor]) are named
> without using a function name ([class.qual]), there is no way to provide an explicit template argument list for these function templates. - end note]
unique_ptrって、unique_ptr<T>とuniqu_ptr<T[]>が、1つのテンプレートではなく、
テンプレート自体が別に用意されてるんだよね？
そもそも前者の規則と後者は使う時の記号としても違っていて、前者は、
unique_ptr<int> a = new int;
*a = 5;
と書くのだから、a は、int*、つまり、intへのポインタのように振舞う。
この規則のままであるなら、
unique_ptr<int[]> b = new int[10];
と書いた場合、b は、int[10] へのポインタ、つまり、int (*b)[10] のように
振舞わなければならない。
となると、
b[idx] = value;
とは書けずに、(*b)[idx] = value; と書かねば成らないが、実際にはそうではない。
>>511 > テンプレート自体が別に用意されてるんだよね？
特殊化で配列の場合は特別に用意されている。
> unique_ptr<int[]> b = new int[10];
> と書いた場合、b は、int[10] へのポインタ、つまり、int (*b)[10] のように
> 振舞わなければならない。
(そのように b を初期化することは出来ない (生ポインタを受け取るコンストラクタには explicit が付いてる) が、意図はわかるのでとりあえずわきに置く。)
new int[10]; という式の型は int* なので、この時点で配列の大きさに関する情報は失われている。
(配列の先頭要素を指す生ポインタではなく) 配列を指す生ポインタのようにスマートポインタを抽象化する意味がない。
どうしてもやりたければ std::array と組み合わせればいいし。
>>512
すまん。正しい書き方は：
unique_ptr<int[]> b(new int[10]); //(1)
だったようだ。
ちょっと意図が伝わらなかったのか、言いたかったのは、
unique_ptr<T> a; //(2)
の場合、a の型は、T* のようになるのに、
unique_ptr<U[]> b;
の型は、U* のようになるので、数学の様に最初のT=U[] すまん、まちがって送信してしまった。
>>512
正しい書き方は：
unique_ptr<int[]> b(new int[10]); //(1)
だったようだ。それはともかく、ちょっと意図が伝わらなかったのか、言いたかったのは、
unique_ptr<T> a; //(2)
の場合、a の型は T * であるかのように振舞う(T *a と宣言していたかのように振舞う)のに、
unique_ptr<U[]> b; //(3)
の場合、b の型は U* のように振舞うが、数学の様に(2)にT=U[]を代入してみると、
b の型は本来、T *b とした場合のように振舞うはずなので、数学的には U (*b) [] とした
場合の型になっていなければならないはずなのに、実際には、U *b のようにした場合
の型になっているということで、(3)は数学的には (2)の特殊形とはみなせないということ。
なので、unique_ptr<U[]>のテンプレートは、unique_ptr<T>のテンプレートとは別に人間が
意図的に専用のコードを書いて「特殊化」していることの証拠となるということ。
もちろんそれが「テンプレート特殊化」という仕組みで行われていることは知っているが、
数学的な意味で(2)を一般形とみなした場合の自動的な特殊形にはなってないということ
(だからこそ「テンプレート特殊化」で特殊な場合だけを例外的に特記するのではあるが)。
これは、unique_ptr<T>は、Tが配列型の場合は、Tがその他の場合と比べて
「一般性を失っている」と言える。
一般性を失っていることは、言語として分かりにくくなってしまうと俺は思うんだ。 「数学的に」
数学を知らないヤツがよく使う言葉
類義語
「物理的に」
規格的にってのも仕事ができない言語厨がよく使ってるw
>>515 「数学的に」と書いたのは、法則に従った「規則変化」しているということだ。
言語仕様で決まっているとかではなく、記号パターンで「導出」されるというか。
「代入」の概念というか。
優先順位のために、U (*b)[] のような 記号になっているが、これも数学的に
演算子が演算される順序に従って「平坦」に書くと
b --> * --> [] --> U
となる。読み方は、一番左の b の部分以外が右から順に
bの型は「Uの配列へのポインタ」
となる。ちなみに、
T b の場合は、
b --> T
となり、読み方は、
bの型は「T」
となる。
>>515 ちなみに、俺は数学記号に関するIQは200を越えている。
トータルでも150以上。
>>517 もう少し噛み砕いて書くと、コンパイラ内部では、
U (*b)[];
という宣言は、優先順位に従って、
b --> * --> [] --> U
となり、コンパイラ内部では左から順に
「bは、ポインタ(*)であり、その元の型は、配列([])であり、その元の型は、
U である」
と理解している。
>>519 b --> * --> [] --> U
は、英語で読むと、左から順に、
「b is a pointer(*) to array([]) to type U.」
と読めて、言葉と記号の順序が一致する。
void hoge(){
vector<int> a(10);
vector<int*> p(10);
for(int i=0; i<10; i++) p[i] = &a[i];
// play with a and p
}
っていう関数で a とか p に対してやったらやばい操作ってどんなんですかね
>>521 理屈を理解してない状態なら何やったってやばいよ
まあ、みんなやらかしながら覚えるもんだから心配せずどんどんコード書いて地雷踏んで地獄に嵌まれ
ただしプロダクションのコードだけは書くなよ
すごい
クソゲボゴミ老害の意見
頼まれたことはできない、自分なりに行動しても何も産まない、家族と職場の全員から疎まれてるバカ
天晴
>>510 ありがとうございます！できないんですね…
ああなるほど、最近多い
>>521みたいなのは、中で何が起こるか想像できてない(基本すら出来てない)から
いちいちこんなこと訊いてるのか・・・
何度も言ってるけど教える順番おかしいんだよマジで
>>524 自己紹介？
>>521 pのサイズが変わるような操作はアドレスが変わる可能性があるので全てアウト
>>515 そうか、禿Stroustrupは数学を知らないのか
pのサイズ変わるのもまずいよね？
勝手に new/delete されて使用不能になりえるので
>>530 何がまずい？
勝手にnew/deleteとは？
自作クラスや構造体に対して範囲forを使うための条件って、そのクラスや構造体が
・メンバ関数としてbegin()、end()を持つ
・begin()、end()が間接参照演算子、インクリメント演算子、不等価演算子を持つクラスか構造体を返す
で合ってますか？
cpprefjp見てたら一個目の条件しか書いてなかったんですが、二個目の条件要りますよね？
>>535 前者の条件はコンテナの要件として書かれているが、
後者はイテレータの要件として定義されているはずだぞ。
もう一個質問させてください
範囲for文ってfor文スコープ外の変数を使えないんですか？
int i;
vector<int> v;
// v を初期化
for(i: v){
...
}
みたいなことをしたいです
>>535 なぜ不要だと思った？
int begin();
じゃダメだろ？
>>531 ISBN4-7561-1895のP.500 16.1.1 設計上の制約
>>538 最近こういうゴミ返しするバカめっちゃ増えたね、このスレ
「intじゃダメ」は「間接参照演算子、インクリメント演算子、不等価演算子を持つクラスか構造体である必要がある」を全く意味しないだろ……
一方で、ではイテレータを返せば良いのかというとそこまで条件が厳しいわけでもなくて、イテレータ「らしき」性質を持ったクラスを返せば良いということなので、この話はそこまで単純じゃない
そういうこと全く分かってないバカが場当たり的な回答をしてるのは甚だ不快ですね
えっっ
Tをイテレータ様のふるまいを示す型として
T begin()だけではダメで
T end()も最低限定義いないといけないんじゃ……
>>537 できない
int i;
vector<decltype(i)> v;
// vを初期化
for (auto&& j : v)
{
i = j;
// iを使用
}
のようなことになる
>>540 反例を1個あげれば十分
あとは自分でかんがえろってこと
お前は何か役立つ回答をしたか？
質問者がbegin()とend()の定義の必要性を把握しているのに対して
begin()のみではNGだとレスするのがそんなにﾄﾞﾔるほどのことなのかどうか……
>>544 前者ってbeginのことだと思っちゃった？
お前日本人じゃないだろ
>>542 ありがとうございます
v は必ずしも vector<int> ではなく vector<vector<int>> とかで、かついっぱい回るループを想定してるのでできるだけ定数倍を軽くしたいのですが、j を右辺値参照にすればコピーは起きないので相当マシと思って良いですかね
右辺値参照つってもauto&&は左辺値参照も兼ねるぞ
>>545 ちょっじゃあ
>>538のレスのどこが反例だったの？？
>>547 for()のカッコの中でiをjの参照として定義できたらそれでも良いんですが、そういうことはできるんでしたっけ？
すみません「定義」というよりは、forのスコープの外にiの宣言はあって、for(ここ)でiがjの参照であることにできたら良いってことです
>>551 ちょっそのforまで範囲forに含めるんなら
>>535に加えてbegin()やend()が返す型がデリファレンス可能という条件が必要なんじゃ……
は？加えて？
>>535に入ってるだろ
最初からrange-basedの話なのに屁理屈言ってるから突っ込んだだけだよ
>>553 i が j の参照ということは
int& i = j;
という宣言が必要で、
int i;
としてしまったものを後で参照に変更ということはできない
>>556 reference_wrapper って
i = ref(j);
みたいなことできませんっけ？
>>557 無理
実体定義された変数を途中から参照に変更なんて
>>541 begin()とend()の型が一致してる必要はない（C++17～）
https://negation.hatenadiary.org/entry/20111203/1322876171 ↑で、簡単に書けば、
class Book {・・・};
class Novel : public Book{・・・};
class Comic : public Book{・・・};
class Shelf { public: std::vector<Book> list; ・・・ };
Shelf g_shelf;
int main(void) {
Novel n = Novel("Hoshio wo tugumono");
Comic c = Comic("Kimetsu no Yaiba");
Shelf s = Shelf();
g_shelft.list.push_back(n);
g_shelft.list.push_back(c);
}
のようになっているところがあるけど、
vector<Book>って、Bookの実体の動的配列で、
Book a[100];
とにら様なものだと思うんだけど、NovelやComicのクラスのバイトサイズが
Bookを越えたら、入りきれないと思うんだけど、これで合ってる？
合ってるとしたら、どういう仕組み？
もしかして、vector<Book>って、
Book *p[100];
みたいな配列なの？
>>561 すまん。間違った。正しくはこう :
int main(void) {
Novel n = Novel("Hoshio wo tugumono");
Comic c = Comic("Kimetsu no Yaiba");
Shelf s = Shelf();
s.list.push_back(n);
s.list.push_back(c);
}
>>561 s.list.push_back(n);のところはn(Novel)のBook部分を首チョンパしてコピーしたオブジェクトがpush_backされる
スライシングというよく知られたホラー現象
https://stackoverflow.com/questions/16126578/vectors-and-polymorphism-in-c ↑によれば、やっぱり、
>>561 や
>>562 のようなやり方は間違いで、
std::vector<T> の T は、Bookではなく、shared_ptr<Book> のようなものを入れるべきで、
以下の様になっている。だから、
>>561 や
>>562 は間違いだよね？
class Instruction {・・・};
class Add: public Instruction{・・・};
typedef shared_ptr<Instruction> PInstruction;
vector<PInstruction> v;
v.emplace_back(make_shared<Add>());
>>564 その認識で合ってる
561のShelfにはNovelやComicじゃなくて、そいつらから刈り取った生首が並んでる
絶対やったらいかんやつ
>>563 なるほど、では、正しい書き方としては、たとえば、こうかな：
class Book {・・・};
class Novel : public Book{・・・};
class Comic : public Book{・・・};
typedef shared_ptr<Book> PBOOK;
class Shelf : public std::vector<PBOOK> {・・・};
Shelf g_shelf;
int main(void) {
std::shared_ptr<Novel> n = make_shared<Novel>("Hoshio wo tugumono");
std::shared_ptr<Comic> c = make_shared<Comic>("Kimetsu no Yaiba");
g_shelf.push_back(n);
g_shelf.push_back(c);
}
パブリック継承している型のオブジェクトが基底クラスへ暗黙に型変換されるのは抑止する方法がないんだよな。
>>567 Dog d;
の時に func( Animal &a )に対して、
func(d);
がエラーにならないということ？
それは別に問題ない
func(Animal a)だとやばい
funcがAnimalの情報しか使わないんなら別にいいんだけどね
単にポリモーフィズムにはポインタか参照が必要ってだけ
shared_ptr<T>もいけるでしょ
スタックを使った60バイト近いメモリーコピーが発生するから最適ではないけど
>>569 class Animal {・・・};
class Dog : publoic Animal {・・・};
std::vector<Animal> g_list;
void func( Animal &a )
{
g_list.push_back(a);
}
int main()
{
Dog d;
func(d); // コンパイルエラーにはならないのに、スライシングが発生。駄目な例。
return 0;
}
>>572 スライシングが発生してるのは g_list.push_back(a) であって、 func( Animal &a ) は関係ないでしょ。
なんで範囲for文ってBOOST_FOREACHを完全に置き換えれるようにしなかったの？
>>537,542はそれで解決するし、逆順のループとかもできるのに
ポリモーフィズム前提の時は、コピーコンストラクタはdeleteするのが良いのかね
あー範囲forが使える条件とBOOST_FOREACH使える条件って違うのか
後者は自作クラスじゃ使えない？
あるいは使える条件が
>>535と違う？
>>573 この場合、スライシングが発生しても問題ない、という観点もあるかも。
>>575 そしたら派生クラス同士でコピー出来んやろ、コピー禁止にしたいのでなければ書くべき(で派生のコピーコンストラクタで基底のコピーコンストラクタを初期化リストから呼ぶ
必ず派生させて使うのが前提ならコンストラクタをprotectedにするとかその辺のテクニックは大昔から色々出てる
スライシングが起きるとき、基本クラス部分だけをコピーすることになるが、
その際、仮想テーブルへのポインタが継承クラス用のままだと、コピー後の
操作が危険になる可能性があるが、もし、仮想テーブルへのポインタを
基本クラス用に変えてしてしまえば、コピー後の動作は完全に基本クラス的に
なってしまうけれど、その反面、メンバー関数を呼び出しても特にメモリーの
破壊などは起きないはず。
そのようにしてしまえばスライシングが起きても問題ないような気が。
>>578て書いたけど実際ポリモーフィズム目的の継承ツリーだとコピー禁止にしてること多いな・・
どうせポインタ(orスマポ)で管理するから確かにコピー禁止のが無難かもね
>>570 それぞれのコピコンをプログラマが自由に記述できる以上、例えAnimalの情報しか参照しないとしても問題が起こることはあるんじゃね？
例えば、DogのコピコンはAnimal::cuterThanCat変数を強制的にtrueに書き換えてるかもしれない
>>581 戦争勃発するぞ
まぁスライシングが常に危険とは限らないと言いたかっただけ
誰かBOOST_FOREACHを自作クラスに使う条件教えてください
>>579 >スライシングが起きるとき、基本クラス部分だけをコピーすることになるが、
>その際、仮想テーブルへのポインタが継承クラス用のままだと、コピー後の
>操作が危険
そんな恐ろしいことが！
と思って試したが、少なくともデフォルトのコピコンは仮想関数テーブルへのポインタを
コピー先の型に合わせて付け替えてくれるらしい
↓そうでなけれはfunc_with_ref(Animal a)の中でa2.get()がDogの値でなくAnimalの値を返す説明がつかない
https://ideone.com/eJMsYG 規格でどうなっているかは知らん
訂正orz、
誤： そうでなけれはfunc_with_ref(Animal a)の中で
正： そうでなけれはfunc_with_copy(Animal a)の中で
ていうかよく考えたらAnimalのコピコンは
Animalのコンストラクタでもあるのだから
>>585の挙動は当然かorz
コンストラクタはコンストラ
コピーコンストラクタはコピコン
デストラクタはデストラ
アルゴリズムはアルゴ
と略すのが効率的
取引先がそんな言葉を使ってきたら
今後の契約を考え直すかも
少なくとも評価はマイナス
取引先とそんな細かい内容を話す打合せも無いだろうけど
機能を引き継ぐために継承して、インスタンス化して使うために移譲もしたい
継承も移譲もするのってありですか？
わかんねえ
継承が相応しくない場合が山程あるのはわかった
継承が相応しくないが一部機能を引き継ぎたいときは、コードのコピペをするべきなのか？
>>598 より小さいクラスか構造体として切り出すということ？
>>600 ダメってことはもちろんなくて、そう実装することにすればそう実装するだけだが、継承である以上は依存関係が生じるし、相応しくない場合もあるなあと思うだけ
intをとるかcharを取るかで振る舞いを変えるオーバーロード関数って作れるんですか？
その場合、受け取ったのがintかcharかプログラムはどうやって見分けるのですか？
オーバーロードという単語を知っておきながら、何故できないと思ったんだ
>>602 関数シグネチャってもんがあるわけよ。
リンカは関数名ではなくこのシグネチャでリンクする。
引数の型が変わるとこのシグネチャが変わるので、
プログラムというかコンパイラはそれを間違えることはない。
intとcharは使う側が間違いやすいから
間違えたら問題がある場合は名前を変えよう
>>604 厳密に言えばリンカは関数名しか見ない。
C++はオーバーロードのためにシグネチャの違いを関数名に埋め込むマングリングを行う。
>>602 C++で関数呼び出しを書いた場合、どの関数が呼び出されるかは
Best Matching Algorithm で選ばれているので実引数が charの場合は、
同じ場所の仮引数がcharである関数を優先的に選ぼうとする。
もし、同じ場所の仮引数がcharであるものが見つからなければ、
同じ場所の仮引数が int であるものを探して、見つかればそれを選択する。
このとき、実引数と仮引数の型の「距離」のような概念があり、
距離が近いものが選ばれる。複数の引数が有る場合で、二つの引数で
距離が近い関数がどっちもどっちになる場合には、「曖昧」であると、
され、エラーになる。
>その場合、受け取ったのがintかcharかプログラムはどうやって見分けるのですか？
ここであなたの言っている「見分ける」という意味が分かりにくいが、
オーバーロードされた関数は、C++レベルでは同じ名前に見えていてもが
アセンブラレベルでは別の関数名になっていて、別の関数として扱われていて、
別の関数が呼び出されているから「見分ける」以前問題になっている。
>>606 「リンカは関数名しか見ない」はおかしい。
リンカが見るのは、関数名を含むシグネチャをマングリングした結果のシンボル名。
>>605 それは、実際そうだと思う。
char idx = xxx;
func( 'a' + idx );
と書いた場合、func(int)とfunc(char)のどちらが呼び出されるのかを
事前に予想するのは非常に難しい。
なぜなら、伝統的にCでは、char + char は、それぞれが int に昇格
されてから、int + int になって、結果も int になるとされていたから。
ファイル出力で、1バイト出力と4バイト出力の違いは、単に人間が見るための
stdout出力とは訳が違って、後からファイルを入力する時にその部分のバイト数の違い
が大きな意味を持つので、オーバーロードの仕組みだけでコンパイラに自動振り分け
させるのは、分かりにくいバグを入れてしまう可能性がある。
なので、やはり、出力するのは1バイトなのか4バイトなのかを、明確に関数名で
区別できるようにした方が望ましいと思われる。
>>609 そのマングリングした名前で関数を呼び出すことができるわけだし、関数名以外の何物でもないと思うが。
そもそもリンカはマングリングされているのかされていないのかも関知しないし。
> 589 名前：デフォルトの名無しさん[sage] 投稿日：2021/05/01(土) 09:28:33.15 ID:18idEqJd [1/2]
> コピコン
> たまに見る
> 頭悪そう
>>595に何も言えねえ
頭悪そうｗ
>>612 ?h@@YAXH@Z みたいなのを関数名って言うのは違和感しかないわ
> そもそもリンカはマングリングされているのかされていないのかも関知しないし。
それを言うならリンカは関数かどうかすら関知してない
>>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. ...
私は「関数名」派
C++のコンパイラは元々はC++からCに翻訳してたわけだし
>>616 だなあ。
C++のコードにおいて、関数名と呼ぶ場合、それはマングリング込みとかのシグネチャではなく
あくまでもソースコード上にある関数の名前だからなあ。
>>618 これはあんまりどっちでも良くない。
つか、
>>612の言い分を認めるとオーバーロード/オーバーライドってもんがなんだか分からなくなるｗ
同じ関数名で関数の実装を選べるってのがオーバーロード/オーバーライドだから。
オーバーライドの意味も知らない子は無理して回答しなくていいよ
C++初心者はクラス継承の学習にこだわりテンプレートの学習が後回しになるので、テンプレートが最適解になることが多いと悟るのが遅くなる
>>619 Cに翻訳された段階だと変数名まで含んだ名前が関数名
当然リンカの段階ではC++の関数名は残って無い
C++以外のドメインでどれが関数名かを議論すること自体意味がない
>>619 overrideキーワードは派生クラスで仮想関数を上書きするときに使う
overloadキーワードはcfront 1.0世代のC++で関数を多重定義する予告として使われていた
基底クラス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対応は崩れるのだから
関数名≠関数のシンボル
を示す例としてオーバーライドはオーバーロードと同じく妥当であることは変わりが無い
、と思うが知らん
>>621 継承とテンプレートが対立するかのように考えてる時点で
テンプレートどころかクラスや継承もまともに理解できてないやつの発言にしか見えない
>>626 丁寧な御説明ありがとう。
それで正しいですよ。
このクソ議論見ても関数オーバーロードの仕様は失敗してるってのがよくわかる。
悪い子: この仕様はクソだ！
普通の子: この仕様は〇〇だから良くないね
良い子: この仕様は〇〇だから良くないね、△△とすれば良いのに
>>626 それは単に別のクラスで同じ名前のメンバ関数はシンボルが違うってだけの話だろ
オーバーライドは全く関係ない
そもそもオーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない
オーバーロードと並べて語る意味が全くわからない
>そもそもオーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない
では聞くがvtblに乗っける関数へのポインタのアドレスは誰が最終的に決めるんじゃ
ちな1つのクラスのメソッドの定義が必ずしも同一の翻訳単位内とは限らないから、
相対インデックス指定の出番は無い＝コンパイル時解決は不可能
＞では聞くがvtblに乗っける関数へのポインタのアドレスは誰が最終的に決めるんじゃ
実行時に実行バイナリが決めるに決まってるだろ
リンカがリンク時に静的に決めるとでも思ってるの？すげえなそのリンカ
よく知らんけど、多くの場合vtblを作るのはコンパイル時であって、リンク時でも実行時でもないのでは？
>>635 vtbl内のアドレスを最終的に決めるのはリンカなんだろうけど、それは
「オーバーライドの関数選択はvtblの仕事だからリンカは何も関知してない」と両立するので
反論ぽく挙げてる意味がわからない。
ビルバインはもっと禍々しいデザインになる予定だったが、競合アニメだったマクロス・シリーズの影響で変形ギミックが追加され色も派手になった
>>627 実際にプログラムを改修したりする場面では継承とテンプレートどちらでやるか
悩むってのはよくある話。
テンプレートだと元のクラスをいじらなくちゃならないからためらいがち。
その点継承だと元のコードいじらなくて(あるいは最小限の修正で)済むからな。
継承してテンプレートってのもなしじゃないがｗ継承するくらいなら、テンプレートまで
やんないｗ
継承とテンプレートって全然違うけど
悩む場面が想定出来ない
もう継承はしなければしないだけ偉いっていう気持ちになって久しい
つーかOOPに飽きてるというか見限ってる
C++を使ってるのは単に自由度が高くてパフォーマンスが良いから
普段どの程度の規模のどういうコード書いててその結論に至ったかで評価が変わるな
>>644 改修にテンプレートがどう役立つのか想像つきにくいけど
そのコードが前提としてる特定の型以外でも受け入れられるようにするとか？
(それで継承とテンプレートどっちが優れてるという話にはならない気がするが
>>649 > そのコードが前提としてる特定の型以外でも受け入れられるようにするとか？
まあ、一番単純なパターンだとそれだね。
まあ、自分は
>>621ではないので、
> (それで継承とテンプレートどっちが優れてるという話にはならない気がするが
その真意はわからんけど、自分の経験でも対処療法的に継承でやっつけちゃうより
やっぱりテンプレート化しときゃ良かった、と思ったときは多々あったｗ
(「神は細部に宿る」んだわ、ほんとｗ)
低レイヤーコードの置き換えを前提にモデル化できるってのがオブジェクト指向の一つの売りだが
まああんまりそこの置き換えってしないわけだわな。
言うほど有効な場面は多くないってのはそれはそう。
素直に関数かけやって場面のが圧倒的に多い。
>>651 オブジェクト指向や継承の概念を使いまくっても、メンバ関数の形で
関数は書きまくるよ。
>>651 >低レイヤーコードの置き換えを前提にモデル化できるってのがオブジェクト指向の一つの売りだが
>まああんまりそこの置き換えってしないわけだわな。
>言うほど有効な場面は多くないってのはそれはそう。
めちゃくちゃ低レイヤーな部分の書き換えは余り起こらないけれど、
クラスは階層的に継承して行くから、中間的な部分は結構修正が入る。
また、やはり仮想関数(ポリモーフィズム)の作法は便利。
>>653 というか、基本クラスの Animal 的なクラスの修正はそんなに頻繁には入らなくて、
Dog, Cat, Lion, Bird, Fish みたいな部分の修正がプログラミングの主戦場になる。
例えばゲーム作りの場合、Animalクラスの中にwalk(), eat(), battle(), sleep(),
jump(), set_velocity(), set_position() などを仮想関数で用意しておいて、
Animalを継承したDog, Cat, Lion, Bird, fishみたいなクラスがそれぞれ
どのように歩いて、どのように食べて、どのように戦って、どのように寝て、
どのようにジャンプするかをプログラムするというのはとても便利。
クラスや継承、仮想関数の概念が無ければその様に便利にプログラムする
ことは簡単にはいかない。
シンプルにポリモをやるための継承はいいんだけど
それ以外をやるための道具として流用し始めると途端におかしくなるって経験上思ってる
>>654 そういうゲームみたいなシチュエーションがそんなにあるわけじゃないって話だよ。
よっぽどプログラマ間で共有できる抽象概念がない限り逆にわかりにくくなることのが多い。
派生関係がなくても関数名を一致(つまりオーバーロード)させるだけで動いてくれるテンプレートのほうが楽なことが多い。
実際、最近C++に追加されている機能は大部分が派生関係のないテンプレートクラス。
一方、派生して使うiostream系クラスは機能追加される気配がまるでない。
というか、単に間違ったクラス化や間違った継承してた奴が多かったんじゃないの
>>657 クラステンプレートでも結構継承使ってるぞ
皆様おはようございます
ちょっと質問させてください
テンプレートクラスを宣言定義する時に、ヘッダーに定義を書かないとエラーを吐いてしまいます
テンプレートクラスのヘッダーファイルを、他のヘッダーファイルにインクルードして使う場合、なるべくテンプレートクラスのヘッダーに必要なファイルをインクルードをしたくないので、テンプレートクラスをヘッダーソースに分けて記述できれば嬉しいのですが……
//テンプレートのヘッダー
template<class T>
class Hoge{
public:
Hoge();
};
//テンプレートのソース
template<class T>
Hoge<class T>::Hoge(){
cout<<“hego !”<<endl;
}
//テンプレートを使うクラス(別なヘッダーファイル)
class UseHoge{
public:
UseHoge(){
Hoge hoge;
}
};
これをメインで記述すると未解決の外部エラーになってしまいます
テンプレートをUseHogeのヘッダーソースに分けて記述すればエラーは出ないのですが出来るなら独立させたいです……
何かいい方法がありますでしょうか？
基本的にテンプレートの実装をソースに書くことは出来ないよ
与える型を決め打ち(明示的実体化)すれば出来るけど、当然汎用性は大幅に下がる
Hogeをvectorやunique_ptrの様に、インクルードすればどこでも使えるようなテンプレートクラスにしたいのですが、そういう場合はHogeの定義もヘッダーに記述して、そのヘッダーを適宜インクルードするような形になるんでしょうか？
それを出来るようにするためのexportという機能が昔の標準規格に定義されてたんだが
難しすぎてほとんどのコンパイラが実装できなかったので消えた
>>662 vectorやunique_ptrも全部ヘッダに実装書いてるんだよ
見た目の問題だけなら、宣言と実装を分けることはできるけど(実装もヘッダのどこかに書けば
>>663 ありがとうございます
難しい感じなんですね
インクルードでコンパイル時間が余分にかかるかも……と思っていたのですがそれが一番近い方法なのでしょうね
コンパイル時点でTの大きさがわからないから明治化しない限りはリンカ？でのエラーになるのでしょうか？
>>664 すれ違いになりました
ありがとうございます
ベクター等もそうなっているんですね
一度覗いてみたときにマクロの大文字が並んでて頭痛がして以来じっくりみたことが無かったので……(大汗)
>>656 ただ、MFCを見ても分かるように、例えば、左ボタンをクリックした時には、
が OnLButtonDown()というメンバー関数が呼び出される様になっていて、
それは、CWndで基礎が定義されていて、CWndを継承したクラスも同じ関数名で
同じイベントを処理する様になっている。
これを純粋なCだけで書くのは分かりにくいだろう。
>>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で統一した書き方で分かり易く書くのは不可能。 WTLって知ってる？
MFCとほぼ同じ機能を派生クラスではなくテンプレートクラスで実現しているんだが、ソースが綺麗
何言ってんだWTLも継承使ってるしユーザーもWTLから継承するだろうがアホか
典型的なポリモーフィズムではないけど、それがそのままデメリットにもなってる(ウインドウのインスタンス管理をまとめられない
継承といっても1世代だけじゃん
多重継承も使ってるから感じにくいけど
テンプレートは実体化された時に存在の有無を判定されるので、最低限のオーバーロードで済ませる
そういえばどこかの超人プログラマ集団がいる組織では必要になったら設計を気にせずどんどん
機能を増やしていって、どうにもならなくなったらさっさと捨てて作り直す文化があるというのを聞いたことが有る。
剛腕があれば綺麗な設計なんて必要がないし、無能ならば綺麗な設計は出来ない。
つまり大体の場合にあんまり綺麗な設計にならないってことになる。
それでもなんとかするしか仕方ない。
>>674 完全に捨てるというのは、多分、大きなプロジェクトでは無理で
リファクタリングするんだと思われるが、その際に基本クラスの
設計や継承の仕方が変わる、ということなんだと思われる。
例えば Windowsエミュレータの Wineや、clangのソースなどを
いくらソースが汚くなったからといって完全に書き換えるというのは
どんなに超人豪腕プログラマ集団でも効率が良い方法とは
思えない。なぜなら、例えばWineのソースは150MB位あるから。
>>674 アジャイル開発の説明によれば、ソースがきれいかどうかについては、
そのコードに機能追加や改良を続けられているのであれば、それで良し、
と考えるとあった。本当に問題が有るのは改良を続けられなくなってきた
時で、その時はその時で、リファクタリングしてソースを整理すると良いと。
常に綺麗にし続けるというのは努力はしても良いが、基本的には不可能に
近くて、むしろ、ソースを綺麗にすることが目的になってしまっては、
無駄に時間が掛かりすぎてかえって時間のロスになってしまうことがあるから。
ソースコードからひたすらcall treeを書きまくって独立した関数やクラスに切り分けていって
依存関係を整理していく仕事が今日もまたはじまるお、
>>674 将来の破棄を前提とするなら、そのための準備が必要でしょうな。エージェントとかを使ってモジュール間の結合度を落とすとか、モジュール間で公開するIFを限定的にしてモジュール単体を捨てやすくするとか。
そのへんの話題はなかったのかしらん？
>>675 でも、そのポリシーは「完全に捨てる」ことを
しないと機能しないよ。
結局、前に書いてある「あの関数」とか「例のクラス」とかが
縛ってしまうからね。
リファクタリングするだけじゃ、結局程度の問題でしかない
>>679 どれは違う。
数学で代入したり、共通部分を括りだして M という変数に代入して
分かり易くしたり、展開したり、足し算して一つにまとめたり、
同類項をまとめたり、因数分解したりするなどして、式を簡単化
するのと同じようなことをプログラミングに置いて行えば、
前のソースを残しつつ、コードをわかり易くできる。
export機能は確かに立ち消えになったが、現状のC++において
テンプレートの定義をcppに書くことは、明示的実体化をしたら一応はできる
どうするのかと制限事項とかはここを見たらﾜｶﾙ↓
■ テンプレート関数の宣言と実装を分離する方法 ( 補足 )
https://qiita.com/MasayaMizuhara/items/b1e3a53f62df88205eb7 一方、
>>664で言っている
>見た目の問題だけなら、宣言と実装を分けることはできる
というのは（多分）こっち↓
■ テンプレート関数の宣言と実装を分離する方法
https://qiita.com/MasayaMizuhara/items/37f8c2a5462a4f7f8ea0 >>680 言うは易しの典型例ktkr、
実際には依存しなくていいものが依存しまくりで
同値類が何かとか読むだけでばさっぱりわからなくなっている状況が多く、
>>677のような汗みどろ血みどろの作業になるんである
すんなり逝くのはGUIの場合みたいな切り分けのゴールが意味的に明白なケースぐらい
これはフォームの絵面を見てUI要素の塊別にinner classにでもしてやっていけば
ソースコードの行数Nに対してO(N*log(N))ぐらいで何とか整理がつく、
ネットつうのはド素人が平気でシッタカかますとこだから
いちいち釣られててもしゃーない
ここ最近の流れだと
>>677さんだけガチ勢だと思う
doxygenはワイらのお友達
C++で3値ブールってどうやって表現してますか
char？
>>684 // #include <compare>
class strong_ordering;
class partial_ordering;
class weak_ordering;
および、これらのクラスの随伴関数operator<=>
BOOST_FOREACHで自作クラスをイテレートするのダル
なぜC++11の範囲for文で完全にカバーする努力をしなかったのかますます謎だ
vector<int> v;
vを初期化
for(int& x: v){
int y = move(x);
}
これって文法的には問題ないっていうかコンパイルエラーなりませんよね？
参照をmoveするってどういう意味なんですか？
引数の型から返り値の型が明らかに決まるとき、返り値の型をわざわざテンプレート引数として書くのがめんどいんですが、省略するテクありますか
>>691 引数の型で明らかに決まるんなら、戻り値の型を引数の型引数から導出される型として表現できるはずでしょ
>>689 boost foreachができたのは15年以上前だから仕方ない。今更使う必要もないと思うぞ
>>690 xを、このあと殺すだけだから
ぶっちょんぶっちょんに犯しまくっていいよってこと
それがconstのない右辺値参照にキャストするってこと
>>692 どうやって書くの？
template<class T1, class T2, class T3> T3 func(T1 a, T2 b){
T3 c;
return c;
}
みたいなやつのT3をテンプレート引数じゃなくしたいってことなんですが
>>696 int64_t ret = func<int, size_t, int64_t>(100, 200);
>>694 v とか x は y = move(x) の後で使い回しても良いんですよね？
つまり、vector v の要素の参照 x を move しても、v の要素も x も影響を受けなくて、y の構築のされ方が違うだけということで良いんですかね？
超初歩的なこと聞いてすみません
>>697 ？？？
> func<int, size_t, int64_t>
の int64_t をテンプレート引数じゃなくしたいってことです
実行時に返り値の型が分かるような関数を作るテクはあるかと言い換えても良いです
無理なら無理で良いです
>>698 右辺値参照はあくまで、一時オブジェクトですよと示すだけなのでそのコードでは問題ない
けどyがint yじゃなくてvectorなどの、
「一時オブジェクトを受け取った場合、メモリ確保やコピーのコストを減らすために中身のポインタだけすげ替える」
クラスだった場合、その後のvの中身は使えなくなる
moveはただのT &&へのキャストだよ
>>700 うーん、そのためだけに使うってのはちょっとなあ
>>699 >>695に出てるじゃん
T3無しで自分で書いてみた？
>>692,695,697,703
返り値の型がautoな関数って普通に作れるんですね
すみませんでした
ありがとうございました
初歩的な質問かつスレチ気味ですみません
vscodeを用いて簡単なコードを書きました
ビルドとデバッグを試みました
ビルドは出来ましたかデバッグにエラーが出て、No such file or directryとあります
パスを指定する際に日本語が含まれていることでエラーが出たのかと思うのですが正しいですか？
>>705すみません VScodeスレがあるのに間違えてこちらで質問してしまいました スルーしてください 大変失礼しました
std::stringとstd::string_viewって何が違うんすか？
>>707 動的メモリを使うのがstring
使わないのがstring_view
大昔からあるのがstring
C++17で新設されたのがstring_view
>>708 なるほど
最近の開発ではstring_view使うほうが主流ですかね
>>709 string_viewを使う機会はほとんどない
>>710 string_viewのほうが軽いのではないのですか？
バッファを操作するライブラリはC以来の蓄積があり、string_viewに移行する利点があまりない
これから新しく作るならstring_view特化でもいいかもしれないけど
テンプレート引数にstring::size()みたいな非定数を渡す方法教えてくんろ
部分文字列の抜き出し繰り返す構文解析的なプログラムをstringをつかって自前でゴリゴリ１から書くなら、string_viewでかなり速度上がりそうではあるね
>>714 渡せるわけないだろ
constexpr付いててコンパイル時評価になるならともかく
>>716 なんかテクねーの
例えばarrayの長さをどうしても実行時に決める技みたいの
原理的に不可能だよ
定数値が必要ですとか言われるやろ
実行時分岐でテンプレート引数を決めるとかは出来るだろうけど
>>717 使う全ての長さの分のstd::arrayのパターンをマクロか何かで生成して、入り口で分岐させればいけるんじゃない？w
>>717 裏テクはある
当然糞コードになる
後で観る気が起きなくなる
やめとけ
size_t n = str.size();
switch (n) {
case:1
return array<int, 1>;
case 2:
...
こんなん？(でも戻り値の型の違いもテンプレートに出来ないのでanyとかで吸収しないといけない
ありがとうございます
上の方で関数の返り値用のテンプレート引数をautoで省略したいとか言ってた者なんですが、大人しくテンプレート引数一個追加します
>>717 system()でコンパイラを呼び出してDLLをビルドしてLoadLibrary()
あーarrayの必要サイズがわからん状態で型決めようとしてたのか
それはユーザーが指定しないとしょうがないね
>>724 arrayは例えですが、それに近いことです
実行時に計算した値を変数テンプレートに入れたかったです
pow(int, int) の型って int なん？
Promoted pow(Arithmetic1, Arithmetic2) とあるが、int と int が promote されたら何になるの？
>>707 std::string はそれ自体が文字列のデータを所有している。
std::string_view は他の文字列の一部 (または全部) の範囲を表現しているだけで、文字列の本体は所有していない。
(なので参照先の寿命が先に尽きたらダングリングになることに注意。)
文字列全体の参照は単に std::string& で良いのだが、
一部の範囲だけを表す型が従来は無かったので std::string_view が新設された。
std::string_view は Go や Rust で言うところのスライスのような概念に近い。
std::ifstream ifstream;
ifstream.open(filePath);
std::stringstream stream;
stream << ifstream.rdbuf();
とやったとします…この場合…flushって必要なんでしょうか？…
stream << ifstream1.rdbuf() << std::flushやstream.flush()…そもそもifstream.rdbuf()を使っているのが…
なんか…怪しくて…全て書き込まれていない事って…起きるんでしょうか？
ofstreamだと…flushがいるのは解るんですが…この場合って…どうなん？
stream << ifstream.rdbuf()の振る舞いが解らなくて…本当にいつも…全部…読めているんでしょうか？
ifstream.rdbuf()って…怪しいじゃないですか…悩みます…。誰か…詳しい人…います？
ostreamを継承してるので…一応…儀式として… << std::flush を付けておきます…
>>728 operator<< を呼んだ直後の時点では完全に書き込まれていない可能性は有る。
ただ、色んな場面で pubsync が呼ばれて辻褄合わせをすることになってるんで、
その時点で完全でなくても大抵の場合に問題にならない。
ストリームがキャラクタデバイスに接続されている場合のような
書き出しのタイミングが意味を持つような状況でなければ明示的に flush が
必要な場面はあまりない。
coutとcerrでコンソールに出すときcoutを適宜flushしないとcoutとcerrで表示が同期しないという印象、
coutのようにバッファリングしながらもstderrに出力するclog
>>726 promoteはintよりサイズの小さい整数がintになることだぞ
浮動小数点の場合はdoubleになること
powは<cmath>で次のように宣言されていて
float pow(float x, float y);
double pow(double x, double y);
long double pow(long double x, long double y);
pow(int, int)の返却値はdoubleとなる
hoge() という関数の意味で hoge_() という書き方を使いたいとき、using hoge_ = hoge ってできますか
>>737 ？
auto hoge_ = hoge？
C++にmemcpyの代替ってあるんですか？
メモリが連続でコピーする区間が重複してないときに型 T のものを x 個分コピーするときは、2021年現在も
memcpy(destのアドレス, srcのアドレス, sizeof(T)*x);
で良いんですかね？
>>728 stream << ifstream1.rdbuf() << std::flushやstream.flush()
ifstream1.rdbuf() を実行する前に fush しないと意味無いと思わないか？
>>736-738 関数の別名を作るなら constexpr を付けておいたほうがいいかもね。
>>739 C++ 的には std::copy を使うんでないかな。
memcpy はメモリが連続していることを利用した最適化をしている可能性が高くて効率的だけど、
T が trivially copyable でないときに memcpy で正しく複製できるかは未定義なので、
汎用的な部品として構築するには memcpy は向いてない。
低レイヤでビットパターンのコピーで良いことがわかっているなら memcpy でも良いだろうし、場面による。
テンプレート引数の部分指定みたいのってないんですかね
template<class T, int x, int y> auto hoge(array<T, x> fuga){
、、、
}
って関数を
array<int, 5> aaa;
hoge<int, 5, 8>(aaa);
みたいに呼び出すときってintと5はaaaを渡した時点で分かりきってますよね？
だから
hoge<8>(aaa);
みたいに呼べたら良いなと思ったんですが
>>744 後ろのほうのパラメータは省略できるが、頭のほうのパラメータは省略できない。
順序を変えれば OK
#include <array>
template<int y, std::size_t x, class T> auto hoge(std::array<T, x> fuga){
}
int main(void) {
std::array<int, 5> aaa;
hoge<8>(aaa);
}
ある条件でvectorを返してある条件でintを返す関数って作れないんですよね？
>>749 「条件」がコンパイル時に決まるものなら作れるよ。
実行時に決まる条件でも variant<vector, int> を返す関数なら作れるよ。
>>750 ないんでやめます
あるいはオーバーロードで作ります
あるオブジェクトの参照を受けたときはそのオブジェクトを変更する void 関数で、一時オブジェクトを受けたときはそれを変更したものを返す関数
を作りたいとき、後者ってどう表現したら良いんですかね？
>>756 右辺値を受け取った場合をオーバーロードするってことですか？
つ右辺値参照
void func(Hoge& h) {
...
}
Hoge func(Hoge&& h) {
...
return h;
}
そういう形でオーバーロードするのはお勧めできないな。
ムーブできるところでは知らんうちにムーブになって効率的に動作してたってのが理想的で、
右辺値か左辺値かによって使い方も異なるってのはやめたほうがいい。
別の名前を付けたほうが良さそうに思う。
stringstream hoge を seekp するとき
hoge.seekp(a, ios::cur);
と
hoge.seekp(a, ios_base::cur);
のどちらが正しいですか？
>>760 どちらでも問題ない。 ios::cur は ios_base から継承したもので、同一の存在。
しかし習慣的には ios_base を直接使うべきではない (ios::cur を使うべき) と思う。
右辺値参照って、扱ってるクラスがムーブコンストラクタを持ってない限りは、「これは右辺値参照です」という意思を表示することにしかならんのですよね？
非const&はともかく
const&と&&の多重定義は普通だろ
template<class T> void hoge(pair< vector<T>, vector<T> >);
を、vector<int> A, B として
hoge({A, B})
って呼ぶのは T の deduction/substitution に失敗するからダメで
hoge(make_pair(A, B))
って呼ぶのはオッケーだったんだがホワイ？
そんくらいできろやって思うんだが
>>764 推論できないわけではなくて std::initializer_list に推論されるというルール。
そのルールが結果的に妥当かどうかはともかく今更変えるわけにもいかんし、
仕方がないんだわ。
可変個の参照をとる関数の一番簡潔な書き方って何ですかね？
呼び出すときは
hoge(a, b, c, d)
あるいは
hoge({a, b, c, d})
みたいにしたいです
いくつか方法がある:
va_list
std::initializer_list
variadic template
要素の型が全て同じなら std::initializer_list が比較的扱いやすいとは思うが、
それだけでまかなえないからこそ選択肢があるのでもう少し条件を提示して欲しいね。
武器禁輸措置に抵触する認定プログラマのお値段がたったの2000万円？
安すぎだろ
そういう額って「保証する額」なので上限が保証されてても意味ないんだよな。
ベストエフォートが 1Gbpsでも現実は 10Mbpsみたいな話だな。
最近知ったことだけど回線品質が悪いからではなく沢山の人に共有利用させすぎているせいで速度が出ないだけらしい。
実際、ダウンロードは遅いのにアップロードは速いのはそれで説明できるそうだ。
>>777 割り当てを失敗してるんだからそれは「回線の品質が悪い」んだよ。
運用も回線の一部。
ダウンロードが遅い原因は経路の他にサーバーという場合もあるね
人混みではWiFiも奪い合いでブツブツ切れまくる
保証するのは普通「下限」だよな
>>778 ADSLとかで遅いのも回線がズタボロに品質が悪いからではなく
多くの人で分けすぎていることが原因の場合があるらしい。
給料でも、100万円みたいに上限を書いているものは、無意味。
嘘広告と同じで、絶対にもらえない
給料で大切なのは、15万円みたいな下限。
最低保証額
直接的に関係ない話になってはいるが、
保証の内容の違いはプログラミング的にも割と重要な話。
十秒で十の仕事をするという保証と
一秒で一の仕事をするという保証は異なる。
アホみたいな質問というか雑談なんですが、皆さんは同じ型のものを2つまとめるのにpairって使いますか？
2要素vectorの方が要素アクセスのしやすさ等の観点から自分にとっても他人にとっても親切な気がしてきました
>>786 同じ型かつ二要素という保証が重要な場面なら std::pair より std::array を使う。
std::pairは機能拡張に弱いので自発的には使わない方がいい
IntelコンパイラはParallel Studioが終了してoneAPIになったけど、
これ無料なん?Intelからは無料ダウソできるけど、
エクセルソフトは有料販売続けてるのはどこが違うの?
>>786 POINTやSIZEは普通に構造体宣言だね
complex<T>も明らかにTとTだね
こんなもんpairで作るやついたら全力で逃げる
template <class T>
struct point : private std::pair<T, T>
{
T& x;
T& y;
point() : x(std::pair<T>::first), y(std::pair<T>::second) { }
};
・・・アホくせｗ
std::equal_range() の戻り値がstd::pairだよ
std::pair を使うかという問いに対して std::pair をなんと継承している例を持ち出してアホくさいとはね
アホくさいんじゃなくアホなんだよ
>>796 あ？ 自分は答えないくせに他人のコメントにいちゃもんつけるやつにだけは言われたかねえぜ
どーせ継承いらん厨とかそういう手合いのゴミだろてめえ
twitterでC++というキーワードがどうやっても検索できないのは独占禁止法に抵触するよね？
>>798 継承………
いらないと思います、最近の私は全部委譲で書いていて、その方がまともだとおもっていますね
こういうのは技術だけじゃダメだからなあ
相手の心理を読み解く嫌らしいまでの知略がないと
継承は多用こそしないが要る
std::pairの継承はもちろんしない
std::pairは使う
終わり
同じ型で2要素のものをpairにするかvectorにするかarray<T, 2>にするかは好みとしか言いようがない
どれにしたから怒られるということもなかろう
でもそれが可能だということはやってはダメと言われてるわけでは無く許可されてることだろ
本当にダメならそもそも出来ないハズだ
やれることをやってなんでダメと言われるのか全く理解出来ない
出来ないのであれば不可能にすべきだがそうなってない、
ならばやっていいことに決まってる
>>793は無理してpair使うとアホなことになると言いたいのかと思ってたんだが違うのか
自分は使わない、以上だってpgr
コードを常に1人で書く人ってことだね
チームでやってるときに異端な主張で
クセ強すぎるコード書くやついたら叩き出す
大昔全部ヘッダファイルにコード書いてやった俺は正しかった
今になって大流行
自分の先見の明が恐ろしい
XXという機能は要らないという奴はたいてい
自分の特定ジャンルのコーディングしかしたことない奴が多い
本当にいらないものは大体ここ10年の規格改訂で削除かdeprecated行きになってる
まだそうなってないものは多分必要なんだよ
ヘッダファイル内で定数使いたいときって結局どうしたら良いんですか
ネームスペース作るほどじゃないが、スコープはそのファイル内だけで良いって状況です
32bit整数なら列挙型
それ以外なら定数をあきらめて定数を返す関数にする
>>810 流行っていうか仕様上仕方なくってことなら判る
template とか obj にコンパイルしても
必要な時に見つからないって言われるの
回避する方法あったら教えて
>>801 悪いが、やっぱQZは、頭の働きが余り良くないと思う。
継承はオブジェクト指向ではなくてはならないものだし。
>>820 ただし、個人的には委譲についてはそんなに詳しくは無く、#include程度のものだという理解しかない。
しかし、C++のクラスには元々継承の機能が付いているのだから敢えて委譲方式を使う必要は無いと思う。
また、委譲にしたときのデメリットは分かるが、メリットは分からないし。
C++において委譲てメンバ変数に持つだけやろ
vectorにデータ保持するクラスがvector継承とかおかしなことになる
昔から言われてるis-aとhas-aで考えるのが自然じゃないの
継承は今となっては注意して使うべきものって評価が定着したものと思ってた
リスコフ置換原理とか、差分プログラミングとか、composition over inheritanceとか
>>823 そんな高度なことをUQが知ってるのか？
>>820 確かにいちいち相手を口撃しないと議論もできないのは頭が悪いね
> 個人的には委譲についてはそんなに詳しくは無く、#include程度のものだという理解しかない。
> vector継承
えっちょっとレベル低過ぎて驚愕してるんだが、休日プログラマたちが張り切って変なこと言ってるだけだよね？
「委譲は#include程度のもの」は意味不明としか言いようがないし、STLコンテナの継承って典型的なアンチパターンなんだがなんでそんなもの引き合いに出してくるのか分からんし
>>822 ほぼその通りだが
メソッドとか共通のときって
全部のメソッド描くか？
template <R, P>
R *(P a){return ($1)(a);}
観たいに描けたら良いのに
ああ違う
R *(P a){return (m->($1))(a);}
観たいな感じ
>>826 安心せい
ド素人がシッタカかますスレへようこそ
釣り、知ったか、荒らしは単にスルーされます
>>820 ＞継承はオブジェクト指向ではなくてはならないもの
私も昔からそう習ってきてはいましたが、さて、いろいろ書いてみたものの「継承で書いた方がスマート」という経験が皆無なのです、「委譲で書いた方がスマート」ならば沢山あるのですが
あえて継承が有用な場面といえば、エラー等の例外関係の個々のクラスを大雑把にカテゴライズするための基底型、くらいのものでしょうか…
なにかお題を定めて「①：継承だけを使って書け、②：委譲だけを使って書け、③：①②を評価せよ」という例をいただけないでしょうか。
>>830 「委譲」って具体的にどういう書き方のことなの。
>>831 ええ、頭の働きが悪いと煽りつつそれ聞いちゃうの？
>>826 Rubyでの委譲は #includeのようなものの様に見えたんだよ。
さっき検索してみたら、一般的にはそういうことではないらしいが。
>>832 委譲という言葉はC++では余り耳慣れなかったので本人がどういう意味で使ってるか聞いて見たい。
C#でのdelegate、Rubyの委譲(#includeみたいに見える)、Wikipediaに載っている委譲、それぞれかなり違うことを言っているように思える。
記憶だと、C#のdelegateって他の言語でClosureと呼ばれているもののように思えた。
FunctorとClosureの違いはちゃんと分かってないが。
>>835 あ、Rubyは、Mix-inの方だったわ、スマン。
別のところに処理を丸投げするような仕組み (ただし丸投げする先をディスパッチする仕組みには色々とある) が委譲なので、
基底クラスのメンバ関数が呼ばれるのも広義には委譲の一種なんじゃないかなぁ……。
C#のdelegateって、クロージャとかオブジェクトのメソッドをレシーバごと格納できるコレクションだよね
同じ引数と返り値を持っている関数みたいななものならば、なんでも追加できる
そいでその引数と返り値の関数として呼び出すことができる
移譲先を格納しておくのに便利な機能
>>834 そうかあ・・・耳慣れないのか
耳が悪いんだね
コンストラクタの委譲もピンプルも知らないのに
キリッちゃってる人って・・・(自粛)
委譲とコンポジションってのはオブジェクトの合成方法だ
具体的にはオブジェクトAにオブジェクトBを持たせる
そしてAのメソッドを定義してBのメソッドを呼び出す
継承先でoverrideした関数があって、継承元の関数使いたくなった場合、何か手段ある？
継承は、is-a
委譲は、has-a
内部に部品を持って、その部品にやらせる
最近の言語は、Go, Elixir みたいに継承がない
一方、Ruby on Rails では、継承がめちゃめちゃ便利。
継承して、カスタマイズするだけ
>>845 そのリスコフ置換原則＝ is-a が必ずしもいつも使えるとは限らないのですよ
例えば、数の体系は例えば
複素数⊃実数⊃有理数⊃整数⊃自然数
ですが、じゃあ、「複素数」からインプリメントするか？というと、私はそうは思えません
Ruby の委譲は、Forwardable を使う
例えば、自分でスタッククラスを作る場合、
Array 型のインスタンス変数に丸投げして、push/pop を使う
ただし、他のメソッドを呼ばれても困るので、使えるメソッドを限定する
文字列・配列などは継承用のクラスじゃないから、
継承するのはアンチパターンなので、委譲を使う
ただし例外的に、Ruby on Rails など、有名なフレームワークでは、
標準クラスを継承して、カスタマイズする事も認められる
require 'forwardable'
class Stack
extend Forwardable
def initialize( ) @ary = [ ] end
def_delegators( :@ary, :push, :pop )
end
stack = Stack.new
stack.push 1
stack.push 2
stack.pop
p stack #=> @ary=[1]
>>826 ＞STLコンテナの継承って典型的なアンチパターンなんだが
だからおかしなことになると言ってるだろ何をドヤってんだアホかお前は
>レベル低すぎて驚愕
してんのはこっちだ
is-aなら継承、has-aなら委譲(この場合メンバで持つ)が自然だと言ったんだよ
>>848 その is-a, has-a は、実際の設計作業にはあまり役にたたない気がします
私がやっている小規模／個人コーディングでは、差分プログラミングを取るしかない（まずプロトタイプを書いてから継承または委譲を使ってテストコードと併用して膨らませていく）わけですが、その記述としては最初に委譲を考えます
実際のところ継承と委譲の使い分けは何でしょうかね、少なくともリスコフ置換原則ではカバーできないという気がしますね
>>849 ＞私がやっている小規模／個人コーディングでは、
>継承または委譲を使ってテストコードと併用して膨らませていく
いつもその条件で部品テストしてるだけならそうだろうなー
すでに言われてるけど違うことやり始めたら考え変わるんじゃね
個人的には、やっぱり自然かどうか、とか書きやすいかを考えた方が正解だと思うよ(その方が後で破綻しない
そのリスコフ置換原則？も上にあったように数学関係のクラスだと微妙だろうし
>>849 QZは日常的に「実際の設計作業」をやってるの？
無職じゃないの？
>>850 なるほど、それはそうかもしれませんね
java のクラスライブラリは、かなりなじみがあるので、ああいうものを白紙から書くのならば継承抜きでやれといわれても困ると思いますし
……
(10分程度思考後）
……うーん、実は継承抜きでもやれそうな気もしていたりして
>>830 で希望しているとおり、簡単な例で委譲よりも継承の方が（すべての点でなくてもいいから、何か一つか二つの観点から）優れているという好例はないものでしょうか？
C++ で ifstream で開くファイルが存在するかどうかチェックしたいのですが
ファイル名が utf-8 だと
string hoge = "utf-8のファイル名";
ifstream fuga(hoge);
if(fuga.is_open())
で存在しないと看做されます(全部ASCIIのときとか存在するときもある)
どう対処するのが良いですか？
出来れば Win32API は使いたくありません
使いたくない理由の99%は霧散解消する
胸に手を当てて考えてみればわかる
>>854 #include <filesystem>
if(std::filesystem::exists("utf-8のファイル名")) goto hell;
でもダメ？
filesystem::path ならUTF16のファイル名で渡せる
UTF8をUTF16にする標準機能が非推奨になっているので注意
>>855 そうですね
>>856 ありがとうございますやってみます
>>857 codecvt ですね判ります
移譲は……
クラスAをクラスBに所有させたとき、Bの公開したいいいメソッドを逐一クラスAにも書かねばならないのがﾒﾄﾞｲ
public継承なら継承させるだけで済む
タイピング量の削減は継承で解決すべき問題か、というのはあるが現状はそう
訂正orz、
誤： クラスAをクラスBに所有させたとき
正： クラスBをクラスAに所有させたとき
no_such_method() が C++ にあれば・・・
あとクラスDがクラスBとほぼ共通でBが公開隅でB::foo()を金輪際他の実装を許したくないという3点揃ったケースでは
DをBから継承する他無い
BのインターフェースIBを設けようものならIBを継承してB::foo()の別バージョンを実装してしまうことを阻止できない
そもそも複素数と実数の例がよくない。
確かに要素としては複素数は実数を含むが演算(特に比較演算)は実数のが広い。
そういう意味で例として間違ってる。
>>863 ＞複素数は実数を含むが演算(特に比較演算)は実数のが広い。
詳しくお願いいたします
複素数よりも実数の方が「演算が広い」とはどういう意味ですか？
確かに現状は複素数の順序関係はデフォルトで定めていませんが、用途に応じて複素数の順序関係を別途定義すればいいのでは？
例えば複素数の順序関係を複素数の絶対値の大小で定義したっていいのですよ、複素数の範囲での収束を論ずるときにはこれはよくやる手だと私は考えています
>>864 でも、ちゃんとした数学では、それは複素数の絶対値の大小比較に過ぎなくて
複素数自体の大小比較は出来ないということになってる。
>>846 >例えば、数の体系は例えば
>複素数⊃実数⊃有理数⊃整数⊃自然数
>ですが、じゃあ、「複素数」からインプリメントするか？というと、私はそうは思えません
なるほどな。
これは初めて聞いた観点。
言われてみればそうかも。
>>866 動物⊃哺乳類⊃犬
動物⊃哺乳類⊃猫
動物⊃哺乳類⊃馬
・・・
だから、
class 動物 {・・・};
class 犬 : public 動物 {・・・};
class 猫 : public 動物 {・・・};
という例は割りと適切だとされているが、
「複素数⊃実数⊃有理数⊃整数⊃自然数」
であるからといって、
class 複素数 { double m_re; double m_im; ・・・};
class 実数 : public 複素数 {・・・};
class 有理数 : public 実数 {・・・};
とは確かに書きにくそうだな。
オブジェクトのサイズから言っても、実数の場合、複素数よりメンバ変数が減らせるわけだし。
>>865 ＞複素数自体の大小比較は出来ないということになってる。
出来ないのではなく、決めていないだけでは？
>>867 その例を使って私が主張したいことは
「リスコフの置換原則は参考にする価値があることは認めるが、リスコフだけが基準ではない」
です、どのような時に型の継承を行うのが適切か、という問いの別の基準を探しています
>>868 x1 < x2 ⇔ x1 - x2 < 0
は一般的に言えるけれど、複素数の場合にこれと同じ法則を成り立つような比較が定義しにくい。
たとえば、あなたが定義したがっているような複素数での比較は、絶対値を採った後の値での比較にするという発想では、
|z1| < |z2| と、|z1 - z2| < 0
が同値ではないから上手く行かない。
>>846 リスコフの置換原則は基底と派生型の間に成り立つ規則を定めているだけで順序は関係ないのでは？
あらかじめ実数を基底として実装した型階層に後から新たな基底として複素数を導入する形でも
規則が成り立つならそれでいい気がする。
もちろんリビルドが必要になる場合もあるだろうけどそれは別の話。
>>870 [追加]
あなたが考えたような複素数における大小比較の定義が、もし数学的に適切ならば、
複素数の1つである実数に対しては、通常の実数の大小比較に戻らなくてはならない。
ところが、2つの実数 x1, x2 に置いては、
|x1| < |x2|
と
x1 < x2
は同値ではない。だから戻らない。
なので残念ながら不適切と言える。
別に
aとbの大小比較は、
a+0iとb+0iの大小比較としてそのまま複素数でも通用する
ちゅか実数クラスRealから複素数クラスComplexを派生させるという話なのに
Realが複素数の比較演算を備えて居なければならないとする前提がおかいし
一般的に特殊化すると出来ることは増えるんだから別に何もおかしくないだろ
実数は複素数で出来ない大小比較ができる
有理数は実数で出来ない既約分数を求めることができる
自然数は有理数が出来ない素数判定が出来る
それぞれ子クラスにメンバ関数を付け加える事に相当する
書き方まずったけど874の言う通りで
子クラスでしかできない比較のインターフェースを複素数に持たせることがおかしい
抽象ストリームクラスにファイル名を取得するインターフェースを持たせるのと同じようにおかしい
>>874 しかし、メモリー効率まで考えれば
sizeof(複素数)=sizeof(double) * 2
sizeof(実数)=sizeof(double)
なので、
sizeof(実数) < sizeof(複素数)
なのに、
class 実数 : public 複素数 {・・・}
とすると sizeof(実数) >= sizeof(複素数) に必ずなってしまうという問題が出てくる。
Realクラスは実数としての単項演算および実数同士の算術演算と比較演算を備えるものとして、
ComplexクラスはRealからComplexへの暗黙の変換（つか単純にコンストラComplex(const Real& src)）を備えた上で
複素数の単項演算および複素数同士の算術演算（と必要なら比較演算）を備えたらよろし
まあ特段継承関係にするまでもないかなあという気がしてきたorz
厳密に言ったら虚数単位iを使った実数から複素数への構成的定義はis-a関係ではなくhas-a関係なのでむしろ所有の出番、という見方もできるし、
一方数のクラス、としてみたらReal⊂Complex、なのでRealの方が特殊化という見方もできうる
ぶちゃけ継承するかどうかとは独立に、RealクラスとComplexクラスの自然な共存は上記のように事が済んでしまうということや
これが有理数クラスとかだったら普通の人は整数クラス2つを所有するクラスとして設計するであろう、
>>874 読み違えていた。
>ちゅか実数クラスRealから複素数クラスComplexを派生させるという話なのに
is_a の関係から考えた OOP の哲学から言えば、逆さまになってしまうということ議論している。
>>873 通常の数学ではそんな定義されてない。
複素数 z の次数部分を Re[z] で表した時、2つの複素数 z1, z2 に
対する比較 z1 > z2 を
Re[z1] > Re[z2]
と定義する方法は可能と言えば可能ではあるが。
しかし、複素数は複素平面上で原点の中心とした回転対象の性質を大体
持っているから、実数だけを特別扱いすることは、余りよくは無い。
(いくつかの一般的性質で破綻が起きる可能性が高い)。
回転対象 ---> 回転対称
すまん、リアルではややこしいプログラムを考え中だから。
学部数学の話をｇｄｇｄ続けてる奴らは順序体でググってくれ
複素数体に勝手な比較関係はいくらでも入れられるけど（辞書式順序も含めて）、どう入れても算術と両立しないから役に立たないんだよ
プログラム的にはソートのために便宜的な物を入れることはあるだろうが、数学的には無意味
>>883 まあ複素数体上でノルムを考えることはあっても広く「使える」全順序を定義するのはむずかしいでしょうね…
ノルムと順序関係を混同していてミスリードを引き起こしていたことは私のせいです、ごめんなさい
>>887 数学的に無意味、とか言い切られちゃうとかえって反発したくなりますね…
>>889 いや、数学では、対称性や破綻の無さ、一般性などを考慮するので
その意味での「大小関係」は「入れることが不可能」ということを
これまた数学的に証明できる、と彼は言っているのだと思われる。
だから、個人的に意味があると考えても、数学体系としてはダメ
ということ。
>>889 反発するのは勝手だけど、何をどう入れたってただのR^2の順序にしかならないんだよ、これは数学的に証明された事実
実数ペアと見なした順序でしかないものを無理矢理「Cの順序」と言い張ってどうすんのさ
Cの構造と両立しないのに
そういえば、二次元の実数を一次元の実数と対応させる事は不可能という証明
があって、順序集合であるためには一次元の実数と対応できないといけない
ことも証明できる、というようなことも関係あるのかな。
だから順序体でググれよ
全然関係ないし、そもそもRとR^2の全単射はあるし（無限集合論の有名な話）
>>893 濃度論で
|(0,1]|=|R|
|R|=|R x R|
や
|R|=|R^n|
というやつですか。
自然数の集合と実数の集合の間には全単写が無く、前者がアレフ_0、
後者がアレフ_1でしたかな。
それと記憶違いしてたかも。
>>889 アホすｗｗ
やっぱりQZは頭悪いなあｗｗｗ
複素数のハウスホルダー法によるQR分解のプログラム書いてみろよ
できねーからｗ
>>892 ＞順序集合であるためには一次元の実数と対応
それは順序関係のなかでも一番強い全順序（反射律・推移律・反対称律・全律）についてならば理解できますが、よくある普通の順序＝半順序（反射律・推移律・反対称律）の場合はどうでしょうか
>>893 連続体の濃度ですね
>>896 そんな急に難しいこと言われても高卒には無理ですよぅ
今はカラツバ法に御執心なんです、でもキーワードありがとう
余り難しい順序集合とかの事を知らなくても複素数に大小関係が入れられないと数学者が主張していること自体は信じていい。
数学者が「できない」と言った場合、(絶対に)出来無い事が証明された上で言っていることが多く、この場合もそうだから。
しかし実際に証明を確認したわけではない。
でも直感的にわかる。
そもそも上記の議論において、「大小関係が入れられない」として設計の話を続けても全く問題ない。
普通に考えればこうなると思うが。
>>899 まあ妥当だとは思いますが、しかし、この場合であってももっとも数学的な態度とは「権威のいうことを疑って証明を調べること」でしょうね、権威のいうことを鵜呑みにすることは数学的ではないと私は思います
>>890 数学体系と言うから混乱する。
ちゃんと数学の体とか代数系と言わないと。
>>901 まだ権威とか言ってる・・・
数学的に無理というのは権威関係なしに「無理」なんですよ
なんかごちゃごちゃしているけど……
・複素数の体における比較は未定義
・複素数体に距離の位相を入れて比較を定義することは可能（複素平面など）
と言うことだろ。
まあ、直接比較するのは使い勝手が悪いので、距離の位相には適当な写像を使うのが普通だけど（絶対値とか）。
複素数は自然な全順序にはならない
特定の条件を満たす順序は存在しない
ってだけで
順序を定義することは可能だし実際定義して使うこともある
証明にだって厳密さが欠けていることが後からわかった（適用条件が誤っていた）り超ごくまれにだが結論自体誤っていたりしたことが……
ケンペ鎖とか、
あとABC予想の証明ぐらい高度なやつになったら職業数学者であっても査読者の質で
是非を判断せざるおえないﾊｽﾞ
もちろん直接関連論文を書く人は自分が納得するところまできちんと追うだろうがPGがなんでそこまでせねばならんのやヽ(#`Д´)ﾉ
やっぱ自然演繹は良くない
あらゆる証明は最初から形式証明にかけるべきや
>>904 それやっても大小関係を使ったアルゴリズムは実数では正しく動くけど
複素数ではことごとく破綻するけどな
数値計算でなければ独自の大小関係を定義したら動くかも知れないが
それはオナニーと同じだ
>>900 そういうことだよな
>>908 そんなにプリンキピア・マテマティカを書きたいか。せめて読破してから言え。
>>909 破綻とは矛盾のことかな？
複素平面が矛盾するとは世紀の発見だ。ぜひとも論文を。
>>911 何言ってんの
実数では正しく動く大小関係を使ったアルゴリズムを
どうやって複素数で正しく動かすんだよ
頭大丈夫か？
絶対値の大きさ云々の話ならピボット選択は正しく動くだろうな
まあこれは浮動小数点演算の特性からそうなるのであって数学的には関係ない
>>912 距離に写像すればいい。
数値計算でも普通に複素数の絶対値取って比較しているだろ。
>>914 おいおい・・・
上にも出てきてるけどQR分解を複素数で書いてみろよ
>>917 「結果が間違っている」て言われたってなぁ。
>>917の指導教官でも上司でも無いから助言する気無いし。
まあ、複素平面の距離は半順序だから（狭義の弱順序よりさらに弱い）、全順序を必須とするアルゴリズムには使えんわな。
>>914は一部撤回するよ。
2つの複素数 z1, z2 に対して z1 < z2 を |z1| < |z2| と定義してしまうと、
z1, z2 がたまたま(複素数の一部であるところの)実数である場合は、
x1 < x2 が |x1| < |x2| と定義されることになってしまうが、
そうすると、負数の時に通常の実数の比較と結果が違ってきてしまう。
だから複素数体を順序体にできないことなんて代数の教科書にいくらでも証明載ってるんだから読めよ
いつまでやってんだ
std::locale::global(std::locale("japanese"));
必要ですか？
無くても動いてるときに敢えて描くと可笑しくなりますか？
>>921 何のために？
挙動が変わることはあるけどそれがおかしいかどうかは目的次第
>>920 QZがあまりの悔しさにID変えて荒らしてるんだよ
>>906 >判断せざるおえない
単刀直入に言ってバカっぽい
QA分解はそもそも数値誤差を減らすのがめちゃくちゃ難しいからあんま使われんのよ。
特別な事情がない限りは軽はずみに手を出すのはやめた方がいい。
g++で Member 'x' was not initialized in this constructor
って警告が出るんだが、これをpragmaで抑止したい。
このwarningを抑止するためのキーワードを教えてもらえないだろうか
C++20のコード晒せるところ、どっかある？
ideoneやcodepadはダメだった
>>863 複素数より実数の方が演算が広いから複素数を継承して実数を作る
継承してメンバ関数を増やす
作り方として適切かどうかはともかくとして、
例としては何も間違ってないと思うのだが
C++的に複素数に順序を取り入れるなら
辞書的順序が一番使われ方として多いかと
コンテナに入れるのに順序が必須な場合とか
std::pair < double, double >
これだって勝手に定義される
C/C++に数学的な汎用性が必須ではないのは
C/C++をやっていればわかると思う
1./-0. < 1./0. とか pow(0,0) = 1 とか数学的には明らかにおかしいでしょ
>>931 c++のpublic継承は継承先クラスを継承元クラスと同じものとして扱うので、特性の包含性が重要。
なので、失われる特性があるなら継承はしないほうが良い。
上でも挙がっているけど、複素数は実数の全順序性という特性が失われるので継承はしないほうが良い。やるなら無限体を継承元クラスにすべきだわな。
>>934 継承したからといって継承元クラスで定義される演算を継承したクラスにも引き継がねばならない理由は無い
演算子のオーバーロードと型変換関連のコンストラクタまたはキャスト演算子を定義したら
同じ演算子に対してパラメータの型毎に許す演算と許さない演算を任意に設定できる
特にComplexクラスからRealクラスを派生させた場合は
（この場合は|z|やarg(z)といった複素数の演算子がReal以外の実数を返すComplexのメソッドとすることになりそうだがそれはおくとして
ある意味話は簡単で、Complex同士のoperator<()の一族を定義せずにおもむろにReal同士でだけ定義するだけにしたらええんじゃ
つか個人的にｶﾅーﾘ疑問なのですだが、AがBの真部分集合であることと、
Aを表すのクラスとBを表すクラスの継承関係は一体追求すべき何の関係があるん？？
継承元として振る舞えるのはポリモーフィズムの必須要件じゃない？
親クラスとして振る舞えなくなる子クラスとか存在価値ないでしょ
>>934 は？
複素数を継承して実数を作る
という話だけど
>>939 実数を複素数としてふるまわせたいならRealをComplexに型変換したら済むので継承やポリモーフィズムは必須ではない
>>938の問いに戻るがなんで集合としての包含関係をそう執拗に継承関係に反映させようとするんじゃ……
だいたい実数から複素数を作る演算（|z|とarg(z)で複素数zを作る）もあるし
複素数から実数を作る演算（|z|やarg(z)）があるから変換は双方向的なので、
この場合派生クラスから基底クラスへの一方的変換だけでは片手落ちなのは明白
無理矢理やったら
>>938に書いたみたく|z|やarg(z)といった複素数の演算子がReal以外の実数を返すみたいなgdgdな話に……
>>941 おまえ文系だろ
>>939に「ポリモーフィズムは必須」なんて書いてない
>>938 ＞継承したからといって継承元クラスで定義される演算を継承したクラスにも引き継がねばならない理由は無い
さすがに演算が別物レベルで違うのはc++のpublic継承を使うべきじゃない。
public継承は継承元クラスのポインタ変数・参照として使えるという意思表示でもある。使えると言っているのに使えないのはクラスのユーザーを混乱させるし、コンパイラとかからの支援も期待できなくなる。
継承元か継承先かを意識してプログラムしなきゃいけないのは典型的な「継承の危険な使い方」だよ。
>>940 えっ、そうなの？
それなら継承の問題は無いと思うけど、継承を使うメリットある？ c++だと性能的に不利な気が。
浮動小数から整数を継承するのと似たような臭いがする。
浮動小数と整数は継承関係にない代わりに個別に暗黙変換のルールが作り込まれているわけだから
同列には語れんような。
>>944 元は
>>846 >>863が逆だと勘違いしたんだろうねえ
そこから中身のないプライドを保つ為だけの書き込み多数
ここまでのアホみたいな流れは全部
>>793のクソコードのせいにして終わり終わり
>>942 >939 は >938 に反論する形で
継承元（Complex）として振る舞えるのは（Realが満足すべき）ポリモーフィズムの必須要件、
と言っているのだから
>ポリモーフィズムは必須」なんて書いてない
なんて大嘘
全く
>>946はこの問題でいっぱいレスしている割にｶﾞﾁで頭悪いのではないか
<=>使ったことないけど==は自分で定義しとかないといかんらしいぞ
あとこれ仮想関数にする必要あるのか疑問(無駄にサイズ増えるし。あと継承もいらん気がする
<=>から==を導出させるには=default;しなきゃいけないんだけど
=default;した関数の内容を独自なものにするには
virtualで上書きするくらいしか思いつかない
わからんけど、そのpointの大きさ(内積してsqrt)で比較するようなコードをコンパイラが勝手に作ってくれるのけ
メンバの辞書式順序で比較するコードを勝手に作ってくれる
そんなわけないと思うからこそ=default;した関数の内容を独自の内容に変更したい
だから==も書かないといけないんじゃね
多分だけど、そのpointの==は中身point_baseの比較しかしてないんでしょ
独自の定義にするには == 必須で
<=> から導出させようという考えがそもそも間違い？
pointの方で=defaultはうまくいくかもしれんね(今試せないのですまん
こんなしょうもない例でもこれだけもめるんだから
抽象的な定義をするときは思った以上に概念を共有できないということだな。
ンなこと言うんなら最初っからお前が揉めないような定義をバンと出せばいいんじゃないの？
出来ないなら黙ってて
だから揉めないような定義なんかないって主張なんだが。
>>965 なら黙ってろカス
無能ほど自己主張は強い
UQを含めてC++流のクラスや継承に価値を見出せない人が結構いるようだが
当時、アメリカではCだけでは複数のプログラマによる共同開発に問題が
来たしていて大問題になっていたのがC++の登場で解決したとされているぞ。
どうしてかというと、protected属性などでメンバ変数を「隠蔽」できることで
他の人の作ったパーツを破壊することなく使えることになったことが大きいと
聞いた。もちろん継承もその一つ。
>>967 継承は、他の人が作ったプログラムに機能を「追加」するときに何が追加された
のかが明確になるので便利。
継承の機能が無ければどの部分が追加されたのか分からないし、
追加した際に元々動作していた基本部分までバグが入る可能性があるが、
継承した場合にはそれが無い。
UQみたいに「委譲」でなんとかするのは、言語機能のサポートが得られないので
記述量が増えてメンドクサイ。
UQってなんやと思ったけどQZのことか
てかまともにソフト書いたことない奴には言ってもわからんと思う
自衛隊の大規模接種センター(東京センター)は生年月日の入力欄初期値が1970年1月1日なんだが、Unixタイムを意識したのかな？
https://www.vaccine.mrso.jp/ >>970 適当な番号でも受付完了するらしいな
受付出来るけど接種に来ても打ってもらえないから
そういう適当なことなしないでくれってアナウンスしてるけど
テロリストにDoSに準じる攻撃方法教えてるようなもんだろ
中国のハッカーはHoneypotなのではと警戒してるらしいよ
>>971 それは全く違う。
1990年くらいにCからC++に移行が進もうとしていたとき、C++にはまだ
namespaceキーワードで指定するnamespaceの概念は無かったから。
>>976 http://www.ced.is.utsunomiya-u.ac.jp/lecture/2015/prog/p3/kadai3/inherit.php 「継承の機能を使うことにより、すでに定義済みのオブジェクトに
・機能を追加
・変数を追加
・機能の一部を変更
などをエレガントに記述することができるようになり、オブジェクト（コード）の再利用性が向上します。すでに実装済みの機能に、自分が実装したい機能として足りない部分だけを追加してプログラムを作成できるようになりますので、これを差分プログラミングと呼んだりします。」
>>977 それは委譲でも十分で、差分プログラミングだけしたいのなら継承は不要だと私は考えています
>>859 ＞クラスAをクラスBに所有させたとき、Bの公開したいいいメソッドを逐一クラスAにも書かねばならないのがﾒﾄﾞｲ
鋭い意見です、唯一共感できるレスポンスだと思いました
確かにおっしゃるとおりですが、しかし、このメンドクサイ手順を踏めば vtable が不要になる、という意味ではメリットの方が大きいと私は思います
あとは基底クラスへのポインタを一括して握っておいて、派生クラスへのポインタごとに仮想メソッドで処理を分け分けする、というのが出来なくなりますが、私はそういう場面で出会ったことがありません……
https://ideone.com/e5NOWO 差分プログラミングかー 昔はそんなこと言われてたね
ユーティリティクラスに持つべき共通関数をベースクラスに実装しておけばサブクラスでも簡単に呼べる！とか間違ったクラス設計が横行してた時代
その時はまだ失敗してなかったんだから「間違ったクラス設計」じゃないんじゃないの
間違ってるのが後からわかったんでしょ
なら間違いの原因は別にある
>>978 >私はそういう場面で出会ったことがありません……
それはあんたが仕事をしてないからですよ
>>978 一行目、普通は、C++においては委譲より継承の方が楽に書けるのだから、
C++での差分プログラミングは継承を用いるのが基本で楽なので「継承で十分」と
考えるべきで、C++はそういう設計。
あなたは逆さまで、C++の初期のころからの基本設計に逆らおうとしている。
継承使わずに委譲って言ってる人はvirtualはどうしてんの？
つーka仕事で使ってないやつによくある感違いだけど
C++にしろ他の言語にしろ、道具であって目的は「トータルとして楽する」ためにすべてはあるので
別にアート作品や哲学やってんじゃねーんだから、「本質的に美しい」とか「こうあるのが正しい」
とかはどうでもいいからな
トータルとして楽にするためには時に面倒な実装や仕組みをつかうこともあるが、結局最終的に
楽できなきゃそんなものに意味はない
>>982 それは間違った考え方。
継承は機能を追加するためのものではない。
機能を追加したいなら機能を追加すればよい。
継承したくないとか言ってる奴らってインターフェースの概念ないバカだけでしょ
virtual は必ず描く
private は使わず protected を使う
必ずってのもどうかと思うけどな
上にあったpointクラスもそうだけど、メモリ上のサイズがメンバ変数のサイズと一致して欲しい&組み込み型のように配列をmemcpyできるべきクラスなら
無意味にvtblなんか付けるべきじゃない
>>984の言うように楽かどうかもそうだけど、何をユーザーに提供するか、どういう要件が必要なのかと突き詰めていったら最終的に取れる選択肢なんかほとんどない
QZもやはちみつもそうだが、お遊びの長くても数百行のコードしか書いたことないやつは多分それらの部品を何か作るためにまともに年単位で使い倒したことが無いんだろ
それら思いつきで書いた程度のコードは全くブラッシュアップされてないから全く使い物にならんのだが、使ってないからそれに気づかない
実際気付き始めたらあちこち直しまくって膨大な時間使って最後にはゼロから書き直して全く違った設計になると思うが、そうして初めてOOPや継承の利点もわかるんだけどね
可変個の参照の組 (vectorでいい) を関数 hoge
に渡したいときって、hoge が vector< reference_wrapper<T> > を取るようにして
hoge({ref(A), ref(B), ref(C)})
みたいに呼ぶか、可変引数テンプレートを使って hoge の中でパースするかっていうのが普通のやり方かな？
ちょっと冗長な感じがしてしまう
参照の組じゃなくてポインタの組にするとかも手かもしれんが
いきなり継承いらんｷﾘｯとかすげえ極論を言い切るやつ
自分の発言に将来にわたってずっと責任を持つ気なさそう
その時のその場だけ俺カッケーできりゃいいってやつ
>>989 どれがいいかはさておき可変長テンプレート引数はめんどいよ、やってみたらわかる
同じ型のものを可変個受け取るためのものじゃない(トリック的に回避はできるが)し、hoge内だけでパースは無理
>>990 継承イランといってる奴なんていなくね？ QZは怪しいが...
継承が適切な箇所なら継承を使う、機能追加で差分のコードが少なくてすむからという理由だけでは必ずしも使わない(その場合に継承が適切な関係ならば使う、そうでないなら委譲なりなんなり他の設計にする)ということを言ってるだけでないの？
継承いらないっていうのはこういうことだろ？
インターフェースは継承するが、クラスは継承しない
クラスを継承するようなことをしたい場合には、メンバー変数としてクラスのオブジェクト持って、それへ処理を移譲する
今時のオブジェクト指向プログラミングでは、わりと常識的な概念だと思うが
＞インターフェースは継承する
いるやん
＞クラスを継承するようなことをしたい場合
その場合C++的には素直に継承した方が上手くいくと思うけどな(D&Eで禿が言ってたが、継承を全部委譲に置き換えるというのをやってみたらしいが「結果はひどいものだった」と
普通に継承してうまく行かんか破綻するなら、そもそも継承的なことを考えてはならない関係だと思うけどね
継承いる！に飛びついた連中も
その後の流れで
継承要らない！に飛びついた連中も
本質的には同じなんよ
周回遅れで誰かの後追いするマシーンなんよ
インターフェースは実装するって言うでしょ
C++的にはどっちも継承だけど
>>995 メソッドがそこそこ少なきゃいいけど
世の中そんなに甘くない
lud20241224233702ncaこのスレへの固定リンク： http://5chb.net/r/tech/1616555235/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「C++相談室 part155 YouTube動画>1本 ->画像>4枚 」を見た人も見ています：
・C++相談室 part153
・C++相談室 part154
・C++相談室 part152
・C++相談室 part133
・C++相談室 part137
・自営業 悩みごと相談室 16
・自営業 悩みごと相談室 52
・C#, C♯, C＃相談室 Part93
・自営業 悩みごと相談室 45
・自営業 悩みごと相談室 48
・C#, C♯, C＃相談室 Part95
・アパート経営なんでも相談室【135号室】
・【真剣相談】大阪市営住宅の浴室給湯器設置
・シーバスなんでも相談室 17©3ch.net
・【ハゲ】髪の毛の悩み相談室 in DQO【彡⌒ミ】
・アパートマンション経営なんでも相談室【152号室】
・アパートマンション経営なんでも相談室【137号室】
・アパートマンション経営なんでも相談室【151号室】
・アパートマンション経営なんでも相談室【150号室】
・【皇室】小室圭さん、｢解決済み」声明文 宮内庁に事前相談なし
・【皇室】眞子内親王殿下がお気持ち表明「結婚に向けて家族とも相談しながら進んでまいりたい」★9 [記憶たどり。★]
・【名古屋】いじめ相談も「報復」恐れ学校側は直接指導せず…中1女子が下校後に自殺 2月から教室に行かず別室で授業 [ばーど★]
・【ガルパン】マライ・メントラインの勝手にお悩み相談室「困っています。全力で『ガルパン』を推すために私は何を為すべきでしょう」 [鳥獣戯画★]
・室井佑月「(日の丸マスク)謝罪し訂正したのだけど、お詫びしろ、という意見…。弁護士に相談…」 ネット「被害者面」「実害出てるけど？ [Felis silvestris catus★]
・荒らし相談室
・不登校相談室5
・エイブル相談室
・ハゲミン相談室
・船乗りなんでも相談室・10
・シーバスなんでも相談室71
・シーバスなんでも相談室62
・シーバスなんでも相談室85
・シーバスなんでも相談室70
・精神障害者の人生相談室
・シーバスなんでも相談室36
・シーバスなんでも相談室39
・アダルトの何でも相談室
・◎蟹座の子育て相談室◎
・Dr林のこころと脳の相談室17
・綾子88kg♪の恋愛何でも相談室★
・病巣院クルリのお悩み相談室
・苔 コケ 初心者なんでも相談室-4回目
・必ず誰かがなんたら相談室 Part.3
・明るい悩み相談室 [無断転載禁止]
・初心者の為のボート相談室 Part1
・レポ神のピンサロ相談室 ©bbspink.com
・鍼灸マッサージ質問相談室パート１7
・鍼灸マッサージ質問相談室パート11
・【本家】船乗りなんでも相談室 22【内航船】
・鍼灸マッサージ質問相談室パート１６
・【本家】船乗り何でも相談室 20【本元】
・【ﾉｰﾜｯﾁｮｲ】船乗りなんでも相談室 27【内航船】
・初心者優先デジタル一眼質問・購入相談室 53
・（・３・） ぼるじょあの卓上相談室（・３・）
・08070507787 ★ 真智宇 先生の悩み相談室
・【スノーボード】初級者なんでも相談室 ☆6
・初心者優先デジタル一眼質問・購入相談室 103
・初心者優先デジタル一眼質問・購入相談室 157
・初心者優先デジタル一眼質問・購入相談室 109
・■一級建築士設計製図試験相談室(192室)■
・■一級建築士設計製図試験相談室(180室)■
・初心者優先デジタル一眼質問・購入相談室 101
・■一級建築士設計製図試験相談室(183室)■
09:37:04 up 12 days, 20:01, 0 users, load average: 8.52, 12.81, 22.40
in 4.579488992691 sec
@2.1947269439697@0b7 on 122423
|
