C++相談室 part142

**デフォルトの名無しさん** · 2019/04/01(月) 22:17:05.84

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part137 (正しくはpart138)
http://mevius.5ch.net/test/read.cgi/tech/1535353320/
C++相談室 part139
https://mevius.5ch.net/test/read.cgi/tech/1538755188/
C++相談室 part140
https://mevius.5ch.net/test/read.cgi/tech/1547326582/
C++相談室 part141
https://mevius.5ch.net/test/read.cgi/tech/1550772463/

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

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

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

----- テンプレここまで -----
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** · 2019/04/21(日) 08:19:35.76

>>354-356
ありがとうございます、その手を使わせていただきます
状況によって推定ルールが変わるのはやめて欲しいなってちょっと思ったんですけど。

**デフォルトの名無しさん** · 2019/04/22(月) 23:55:58.01

メンバアクセスにthis->つける？

**デフォルトの名無しさん** · 2019/04/23(火) 00:01:58.24

エディタの補完機能使いたいときにたまにそうやって補完して最後に消す。
が、たまに忘れる。

**デフォルトの名無しさん** · 2019/04/23(火) 00:02:35.52

IDEの都合で付ける事が良くある
付けないと補完候補多すぎて

**デフォルトの名無しさん** · 2019/04/23(火) 00:09:08.10

ああなるほど
補完候補を絞るのには便利ですね

**デフォルトの名無しさん** · 2019/04/23(火) 18:16:01.64

メンバであるという保証ができるので付ける

**デフォルトの名無しさん** · 2019/04/23(火) 19:39:28.32

メンバ名は頭にm_付けろみたいなクソルールよりずっといいと思うので付けるべき

**デフォルトの名無しさん** · 2019/04/23(火) 19:42:38.83

仮引数と別の名前つけるのだるいからm_は別に良いと思う

**デフォルトの名無しさん** · 2019/04/23(火) 20:02:01.86

メンバ変数に専用の色付けたらいいじゃん

**デフォルトの名無しさん** · 2019/04/23(火) 20:13:43.06

引数そのままメンバに入れるなら引数に_つけてvar(_var)って初期化してるわ

◆QZaw55cn4c · 2019/04/23(火) 20:16:13.74

>>366
それって var(var) でも問題ないんですよ…

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2019/04/23(火) 21:18:06.78

バーバー

**デフォルトの名無しさん** · 2019/04/23(火) 21:32:08.36

>>367
綴り間違えたら悲惨なことになった

**デフォルトの名無しさん** · 2019/04/23(火) 21:34:08.78

ハンガリアン記法は、入力補完のないエディタ上での可読性を高めるのに役立ってるでしょ。今でも。

**デフォルトの名無しさん** · 2019/04/23(火) 21:35:06.30

ゴミ使ってる奴のことなんか知らん

**デフォルトの名無しさん** · 2019/04/23(火) 21:36:10.37

あれ可読性落ちるだろ

**デフォルトの名無しさん** · 2019/04/23(火) 21:39:11.30

定期的にunsignedとsigned混在させてハマるアホをみるとハンガリアン必要だと思うわ

**デフォルトの名無しさん** · 2019/04/23(火) 21:40:37.34

C#で入力補完のないエディタがどうとかさすがにナンセンスでは
だってvisual studio使うじゃん

**デフォルトの名無しさん** · 2019/04/23(火) 21:41:16.53

どっちでもいいわ。
大抵の場合そんなとこに気を使わんといかんコードになってることのが問題。

**デフォルトの名無しさん** · 2019/04/23(火) 21:45:47.89

>>375
こういうやつがそのうちハマって丸１日つぶしたりするんだよなw

**デフォルトの名無しさん** · 2019/04/23(火) 21:51:11.17

>>373
関係なくて草

**デフォルトの名無しさん** · 2019/04/23(火) 21:55:03.06

関係あることわかってなくて草

**デフォルトの名無しさん** · 2019/04/23(火) 21:55:54.04

黙ってろゴミｗ

**デフォルトの名無しさん** · 2019/04/23(火) 21:59:25.62

>>376
だから人を嵌めるようなコード書くなつってんだよばか。

**デフォルトの名無しさん** · 2019/04/23(火) 22:06:36.15

>>380
コードの問題じゃなくて言語仕様の問題だから
こういうえらそうなくせに何もわかってないカスが一番始末に困る

**デフォルトの名無しさん** · 2019/04/23(火) 22:53:19.60

いつの間にかハンガリアンが言語仕様になってた。。

**デフォルトの名無しさん** · 2019/04/23(火) 23:10:13.77

ハンガリアンも防御的なプログラミングと考えたら悪くないよ
成り立ち調べてみな
でも基本型とポインタだけだな
クラスには無用だと思う

**デフォルトの名無しさん** · 2019/04/23(火) 23:27:23.37

てめーらはまともなIDEかエディタ使ってねえのかよ

**デフォルトの名無しさん** · 2019/04/23(火) 23:37:57.35

むしろVSがないと何も書けない

**デフォルトの名無しさん** · 2019/04/23(火) 23:55:15.96

VSがあっても何も書けない。

**デフォルトの名無しさん** · 2019/04/23(火) 23:55:30.60

c++みたいに型情報ありがデフォルトの言語でハンガリアンとか二重メンテもいいとこだわ。

**デフォルトの名無しさん** · 2019/04/24(水) 01:00:02.97

前方宣言したクラスをTにしたスマポメンバでコンパイル通るときと通らないときがあって調べてたら
デストラクタがインライン（暗黙）だと駄目だとわかった
しかもこの問題が起こるのはunique_ptrのときだけでshared_ptrはデストラクタの定義に関係なく通る
わけわからんぞ
教科書に書いておいてくれ

class ClassB;
class ClassA{
public:
ClassA();
private:
std::unique_ptr<ClassB> u; // NG
std::shared_ptr<ClassB> s; // OK
}

---

class ClassB;
class ClassA{
public:
ClassA();
~ClassA(); ←これでunique_ptrもOK
private:
std::unique_ptr<ClassB> u; // OK
std::shared_ptr<ClassB> s; // OK
}

**デフォルトの名無しさん** · 2019/04/24(水) 07:38:59.52

>>388
unique_ptr<T>のデストラクタはインスタンス化するときにTが完全型であることを要求する（デストラクタで直接Tのデストラクタを呼ぶ）
unique_ptrを内包するクラスのデストラクタが暗黙だとクラス内でコンパイラによって実装されるけど、その場でunique_ptrのデストラクタを要求する
しかし、その翻訳単位内でTの定義が無ければコンパイルエラーとなる

unique_ptr<T>を内包するクラスのデストラクタがとりあえず宣言だけでもあると
実際の定義がある場所で同様の事が起こるので、その場所でTの定義が見つかればいい
その場合に定義を書かないと、コンパイラさんが適切な翻訳単位内に定義をおいてくれるみたい

shared_ptrは動的削除子のおかげでデストラクタが呼ばれるところで適切にデリータを定義し、デストラクタを呼ぶようになっているのでこの様な問題は起こらない
shared_ptr<T>のデストラクタ内ではTのデストラクタを直接呼び出すようなコードが無い

**デフォルトの名無しさん** · 2019/04/24(水) 18:54:26.06

>>389
解説ありがとう

**デフォルトの名無しさん** · 2019/04/26(金) 01:05:34.79

うーんC++プライマー8500円かぁ。本家のプログラミング言語C++第4版はもっとするし
情報量からすると安いが本一冊にポンと出すにはお高い……日本語である程度網羅的な本となるとこの2冊くらいよね

**デフォルトの名無しさん** · 2019/04/26(金) 19:40:01.51

set<double> って int のときと同様にちゃんとソートされるんですか？

**デフォルトの名無しさん** · 2019/04/26(金) 20:34:04.97

NaNが無ければ大丈夫NaNじゃね

**デフォルトの名無しさん** · 2019/04/26(金) 20:34:22.70

NaNが無ければ大丈夫NaNじゃね

**デフォルトの名無しさん** · 2019/04/26(金) 22:17:06.30

のちに永久保存される平成最後のスベり

**デフォルトの名無しさん** · 2019/04/26(金) 23:59:20.16

たしかにそうだな・・いよいよ平成最後なんだな
みなさん、>>393-394 みたいな事にならないよう、気をひきしめましょう

**デフォルトの名無しさん** · 2019/04/27(土) 00:20:06.56

平成最後っていう言い回し使われすぎて嫌いになってきた

**デフォルトの名無しさん** · 2019/04/27(土) 00:23:11.48

イテレータの参照を次に移すときってなんでitr++ではなく++itrなの？

**デフォルトの名無しさん** · 2019/04/27(土) 00:33:20.40

ヤフーでぐぐれ

**デフォルトの名無しさん** · 2019/04/27(土) 01:04:24.73

素直な実装だとitr++より++itrのほうが速いんじゃないかなあ、となんとなくみんなが思っているから

**デフォルトの名無しさん** · 2019/04/27(土) 01:07:57.61

速度に差が出るのか
知らなかった

**デフォルトの名無しさん** · 2019/04/27(土) 01:35:51.19

インクリメント後のイテレーターの値を返す処理の実装を考えると
先の場合はインクリメントしてそのまま渡せばいいけど
後の場合はインクリメント前の値を保存しといてそれを渡さないといけないので一手間かかるから
・・なんだけど諸々の最適化とか色んな条件とか考えたらそこまで差がでるかどうかはよくわからん

**デフォルトの名無しさん** · 2019/04/27(土) 01:38:33.58

it++だと、戻り値をコピーしてとっておいてから、ポインタなりを進めた後にreturnする必要があるが、
++itだと、ポインタを進めた後に参照を返すだけでするからな。

**デフォルトの名無しさん** · 2019/04/27(土) 01:39:08.58

被ったw

**デフォルトの名無しさん** · 2019/04/27(土) 11:13:20.29

>>398
ite++と++iteなんて気持ちの問題
てか範囲for文使えばいい

**デフォルトの名無しさん** · 2019/04/27(土) 11:46:20.51

>>402-405
cppcheck にかけたらちゃんと警告出るね。

**デフォルトの名無しさん** · 2019/04/27(土) 14:06:33.77

どうせ戻り値捨てるんだったら++itを選んでおいて損はない
無駄にit++を使うのは時期尚早な最不適化って奴だ

**デフォルトの名無しさん** · 2019/04/27(土) 19:31:57.61

C++で書くんだから後置インクリメントの方がメインに決まってんじゃん
前置は異端だ

**デフォルトの名無しさん** · 2019/04/27(土) 19:37:22.12

殺せ

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

++C

**デフォルトの名無しさん** · 2019/04/27(土) 20:53:36.82

C++でいいんだよ。
規格は一歩進むけど、使ってるやつはbetter Cばかりってな

**デフォルトの名無しさん** · 2019/04/27(土) 20:55:05.03

++C++まだかよ

**デフォルトの名無しさん** · 2019/04/27(土) 22:37:09.45

>>411
vectorとかstringとか使わんの？

**デフォルトの名無しさん** · 2019/04/28(日) 03:35:47.43

CArrayとCStringだぞ
コピコンは定義されてないから自分で作るぞ

**デフォルトの名無しさん** · 2019/04/28(日) 11:01:20.49

CArrayは、<algorithm>ヘッダーで定義された信頼性の高いユーティリティ関数を使えないのがね・・・。

**デフォルトの名無しさん** · 2019/04/28(日) 13:46:52.13

>>413
この思考がbetter C

**デフォルトの名無しさん** · 2019/04/28(日) 14:25:38.47

>>416
わけわからん

**デフォルトの名無しさん** · 2019/04/28(日) 14:29:28.69

俺がBest Cだ

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/28(日) 14:56:12.05

>>415
イテレータをうまいこと定義すれば使えるやつも結構あるんじゃね？
そうでもない？

**デフォルトの名無しさん** · 2019/04/28(日) 15:37:56.41

inconsistent begin/end types in range-based ‘for’ statement

gcc(g++) 8.2で　-std=c++17オプションでコンパイルで
範囲forでこのエラーが出るんだが
begin endの型不一致の制限緩和されいるはずだよな？
原因わかる方いますか？

**デフォルトの名無しさん** · 2019/04/28(日) 15:49:39.60

>>415
GetData()とGetData()+GetSize()を渡せば、とりあえず動くんじゃね?

**デフォルトの名無しさん** · 2019/04/28(日) 16:05:30.47

>>420 比較演算子定義されてないとか？

**デフォルトの名無しさん** · 2019/04/28(日) 16:22:25.11

>>422
int _n = 0;
auto __begin = _container.begin();
auto __end = _container.end();
for (; __begin != __end; ++__begin) {
_n = *__begin;
}
比較演算子はちゃんと定義してるし
上のコードは何故かコンパイル通る
だけど
for (const auto _n : _container) {
//hoge
}

は何故か通らない

**デフォルトの名無しさん** · 2019/04/28(日) 16:41:14.97

範囲for文のconst autoをconst auto&かauto&&に変えるとどうなる？

**デフォルトの名無しさん** · 2019/04/28(日) 16:43:13.35

>>424
auto&&にした時のみエラーが増えます
cannot bind rvalue reference of type ‘const long unsigned int&&’ to lvalue of type

**デフォルトの名無しさん** · 2019/04/28(日) 16:54:13.46

beginとendのシグニチャは？

**デフォルトの名無しさん** · 2019/04/28(日) 17:02:57.34

>>426
using iterator = typename std;;vector<int>::iterator;
using const_iterator = typename std;;vector<int>::const_iterator;
using my_iterator = MYIterator;
my_iterator begin();
iterator end();
const my_iterator begin() const;
const_iterator end() const;
const my_iterator cbegin() const;
const_iterator cend() const;

**デフォルトの名無しさん** · 2019/04/28(日) 17:18:10.81

これで動かん？
for (auto&& _n : _container) {
}

**デフォルトの名無しさん** · 2019/04/28(日) 17:28:42.95

>>428
動かないです

**デフォルトの名無しさん** · 2019/04/28(日) 18:12:40.94

MYIteratorの実体がunsigned longみたいだけど
vector<int>::iteratorの実体がポインタだったらoperator!=の定義できなくない？

**デフォルトの名無しさん** · 2019/04/28(日) 18:13:25.64

>>420
wandboxで再現コード作って出直すか、それができないんならエスパーに頼んだほうがいいんじゃないかな。
https://mevius.2ch.net/test/read.cgi/tech/1187922645/

**デフォルトの名無しさん** · 2019/04/28(日) 20:53:07.97

>>423
bool operator != (～) const　←　これ付け忘れてないか？

**デフォルトの名無しさん** · 2019/04/28(日) 20:57:20.67

constつけ忘れは時々はまる

**デフォルトの名無しさん** · 2019/04/28(日) 23:15:17.87

>>427
自己解決
const iteratorとconst_iteratorが一緒だと勘違いしていた
const my_iteratorではなくmy_const_iteratorを実装して返り値とすべきでした

**デフォルトの名無しさん** · 2019/04/29(月) 08:12:30.69

struct A{
int member;
};
struct B: A{
void run(){member = 0;}//ok
};

template<typename T>
struct TA{
T member;
};
template<typename T>
struct TB:TA<T>{
void run(){member = 0;}//NG。this->memberとするとok
};
クラステンプレートを継承してクラステンプレートを作成した場合にthisでないと継承元のメンバーが見えないのは仕様？

**デフォルトの名無しさん** · 2019/04/29(月) 10:32:33.68

仕様
一寸前までのmsvcではなぜか通っていたけど

**デフォルトの名無しさん** · 2019/04/29(月) 11:47:53.29

>>436
なんでそんな仕様になってるんだろう…

**デフォルトの名無しさん** · 2019/04/29(月) 12:13:25.59

>>437
2phase lookupだから
最初のTB解釈時にはTAが型引数一つのtemplate classであるという情報以外使わない
だいたいTAが特殊化される可能性があるだろ

**デフォルトの名無しさん** · 2019/04/30(火) 10:16:07.47

8bitや16bitのintしか使えない環境で、
32bitなどの大きな数を扱うにはどうすれば良いですか？
変数をいくつかつなげて大きな数を表現できないかと思っているのですが、やり方が分りません。
ご存知の方いらっしゃいましたら教えて頂けると嬉しいです。

**439** · 2019/04/30(火) 10:20:33.67

補足させて下さい。
足し算、引き算は出来るようにしたいです。
可能でしたら、掛け算や割り算もできると助かります。

**デフォルトの名無しさん** · 2019/04/30(火) 10:25:07.05

多倍長演算で検索

**デフォルトの名無しさん** · 2019/04/30(火) 10:45:28.19

>>438
> だいたいTAが特殊化される可能性があるだろ
なるほどそりゃそうか、サンクス

◆QZaw55cn4c · 2019/04/30(火) 11:43:40.55

>>439-440
https://mevius.5ch.net/test/read.cgi/tech/1434079972/51
近々、委譲をやめて継承に戻すつもりです
あと掛け算はkaratsubaを適用できる目処がたちました
x64 に特化してインラインアセンブラ化することも考えています

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/30(火) 12:03:49.54

karatsuba はかなり桁数が多いときじゃないと効果がないとも聞くけど

◆QZaw55cn4c · 2019/04/30(火) 12:09:22.58

>>444
多分それは乗算FFTのことかと

**デフォルトの名無しさん** · 2019/04/30(火) 12:28:54.66

>>439
stdint.h で int_least32_t とか使えるのでは？

◆QZaw55cn4c · 2019/04/30(火) 13:43:58.68

>>446
8bit/16bit CPU で int_least32_t とかはそもそも存在しないのでは？

**デフォルトの名無しさん** · 2019/04/30(火) 14:19:40.82

>>447
「8bitや16bitのintしか使えない」を見て long や long long はもっと大きいんじゃないの？と思ったんだよ。
「整数型」の意味で"int"って書いてたんなら、確かに存在しない環境のことを言ってるのかもしれない。
その場合は ISO C/C++ の LONG_MAX の最低絶対値の要求に準拠できないってことになるんだけど。

**デフォルトの名無しさん** · 2019/04/30(火) 14:19:47.17

8bit pic用XCでもlongは32bitなのに

◆QZaw55cn4c · 2019/04/30(火) 15:03:05.44

>>449
それはそれですごいインプリメンテーションですね…
8 bit PIC で 32bit int がさくさく書けちゃうとは、そのインプリメンターは根性がありますね、それか頭のねじが何本か外れていて「無理を無理と思わない人」とか…

**デフォルトの名無しさん** · 2019/04/30(火) 15:29:16.24

shortは16bit固定でlongは32bit固定でしょ。何言ってんの？

**デフォルトの名無しさん** · 2019/04/30(火) 16:18:35.89

>>451
いや、お前こそ何を言ってるんだ？

◆QZaw55cn4c · 2019/04/30(火) 16:37:10.66

>>451
残念でした、short も long もインプリメンターが好きに実装していいのですっ！きりっ！

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2019/04/30(火) 16:45:08.36

>>451
64-bit Linux でsizeof(long) が8だった。移植がある場合は<cstdint>使わんとあかん

**デフォルトの名無しさん** · 2019/04/30(火) 17:46:03.06

intが16bitならISOの規格は満たしてることになるかな。

32bit以上の長い整数はクラスと演算子オーバーロードで誤魔化すか。
頑張ってもリテラル表記もダメだろうから、使い勝手は悪いよな。

**デフォルトの名無しさん** · 2019/04/30(火) 19:51:46.33

>>451
うろ覚えだが
VC Win32bit: int 32bit long 32bit pointer 32bit
gcc Linux32bit: int 32bit long 32bit pointer 32bit -ここまでは同じ

VC Win64bit: int 32bit long 32bit pointer 64bit -int64_tで64bit整数
gcc Linux32bit: int 32bit long 64bit pointer 64bit