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/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

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

既にLP64とかLLP64とかの呼び方が存在するんだから、そっちを使おうよ
https://ja.wikipedia.org/wiki/64%E3%83%93%E3%83%83%E3%83%88#64%E3%83%93%E3%83%83%E3%83%88%E3%83%87%E3%83%BC%E3%82%BF%E3%83%A2%E3%83%87%E3%83%AB

**デフォルトの名無しさん** · 2019/04/30(火) 20:34:29.38

厳密なbit長が必要なときにintだのlongだの使っちゃ駄目よ

**デフォルトの名無しさん** · 2019/04/30(火) 20:56:09.36

じゃあ何を使えばいいの？

**デフォルトの名無しさん** · 2019/04/30(火) 20:59:46.66

int_leastシリーズでは？

**デフォルトの名無しさん** · 2019/04/30(火) 21:02:03.72

intの配列のラッパーのようなものから再発明すりゃーいい

class Bignumber{
int number[4];

Bignumber(const String num){
for(int i=0; i<4; i++){
number[i] = //考えるのが面倒臭い
}
}

Bignumber operator+(){
//以下、延々とオペレータオーバーロードが続く
}

};

◆QZaw55cn4c · 2019/04/30(火) 21:02:11.05

>>459
int64_t とか int32_t とか cstdint の面々を使うしかないでしょうね…私もデフォでそうするようになりました

**デフォルトの名無しさん** · 2019/04/30(火) 21:08:03.86

あ…ありのまま今起こった事を話すぜ。
平成の終わりにいろんな奴からshort/longに対する認識の誤りを指摘される恥辱を味わった。
何言ってるかわからねーと思うが(以下略

**デフォルトの名無しさん** · 2019/04/30(火) 21:08:35.71

なんかもうビットという表現すら無くそうとしてるんじゃなかった？

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

制限された環境で使える多倍長整数のライブラリくらいいくらでもありそうだけど

**デフォルトの名無しさん** · 2019/04/30(火) 21:42:28.23

>>462
なるほど、cstdint ですか！
教えてくださりありがとうございます

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

ビット数を付けるのは、MISRA-C で決まっているだろ

int8, 16, 32
uint8, 16, 32

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

C++の規格上はintは16 bit以上（ターゲットのアーキテクチャで一番自然なサイズ
、longは32 bit以上
だったと思った

**デフォルトの名無しさん** · 2019/05/01(水) 06:23:13.87

class ClassA
class ClassB: public ClassA
class ClassA::ClassC

のときに、ClassBはClassAのサブクラスと言いますがClassCはなんと呼ぶものですか？

◆QZaw55cn4c · 2019/05/01(水) 06:32:09.33

>>469
＞class ClassA::ClassC
この意味はなんですか？

**デフォルトの名無しさん** · 2019/05/01(水) 06:32:44.82

基底クラス
スーパークラス
親クラス
ベースクラス

**デフォルトの名無しさん** · 2019/05/01(水) 06:56:41.43

細かいことを言えば、規格準拠の処理系でも
int32_t (ピッタリ32bit) が定義されるとは限らないのね。
int_fast32_t, int_least32_t なら定義される。

8bit単位じゃないCPUへの配慮らしいから、
普通の(この表現も危険だけど)コンピュータを使う分には
int32_t があると仮定して書いてもたいがい大丈夫だろうけど。
コンパイルエラーが出るから出たら対処、で十分かと。

**デフォルトの名無しさん** · 2019/05/01(水) 07:06:00.95

>>470
クラス内で定義したクラスです

class ClassA {
public:
...
private:
class ClassC;
ClassC * C;
}

class ClassA::ClassC {
...
}
の場合class ClassA::ClassC からClassA::を取るとコンパイルが通りません

**デフォルトの名無しさん** · 2019/05/01(水) 07:25:40.44

「プログラミング言語C++」だと、入れ子クラス(nested class)とか
メンバクラス(member class)とか呼んでるみたい。

**デフォルトの名無しさん** · 2019/05/01(水) 07:36:13.31

おお、なるほど
ありがとうございます

**デフォルトの名無しさん** · 2019/05/01(水) 09:29:42.19

内部クラス(inner class)もよく聞くけど調べたらJava用語っぽいな

**デフォルトの名無しさん** · 2019/05/01(水) 10:28:09.06

Inner Class、Java用語なのか。そう呼んじゃってたわ

**デフォルトの名無しさん** · 2019/05/01(水) 17:22:15.78

今よみがえる構造体ネストの悪夢

**はちみつ餃子** ◆8X2XSCHEME · 2019/05/01(水) 17:31:05.65

>>473-474
nested class は仕様にあるので、
これが公式な用語と思って良いみたいだね。

**デフォルトの名無しさん** · 2019/05/01(水) 19:23:34.42

以前、「完全さを求めるあまり今存在する良い物を犠牲にしてはならない」という趣旨のことわざをBBCハードトークで仄聞したのだが、原典はなんだろうか？

◆QZaw55cn4c · 2019/05/01(水) 19:59:09.50

>>480
ググってヒットしたもののうち、これについてめぐらせています（ことわざとは関係ありません…）
http://www.kt.rim.or.jp/~hisashim/gabriel/WIB.ja.html
この人（原著者）、最後まで間違ったままでいるような気がしてなりませんが、実際のところどうでしょうか

**デフォルトの名無しさん** · 2019/05/01(水) 22:03:28.27

>>479
ありがとう

**デフォルトの名無しさん** · 2019/05/04(土) 17:19:13.49

>>480 https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good

**デフォルトの名無しさん** · 2019/05/06(月) 08:44:53.70

ストリームの遅さは凄い凄すぎる。
ほとんどの場合、遅くても問題ないということはわかる。
でもあそこ迄遅くする必要があったのだろうか。

**デフォルトの名無しさん** · 2019/05/06(月) 10:41:12.07

突然何？

**デフォルトの名無しさん** · 2019/05/06(月) 12:17:09.96

3.5 　ストリーム
ttps://sicp.iijlab.net/fulltext/x350.html

これだろう
理想的にはこうなるべきだが、技術的には未だに追いついてないだけであり、将来的には解決される

なのでC++では他のどの言語も真似してない<<や>>がある
逆に言うとストリーム・プログラミングが主流になったらC++が主流の座に返り咲く

**デフォルトの名無しさん** · 2019/05/06(月) 15:05:44.09

今やどの言語もprintfのような書式付き文字列を指定する方式に回帰した(jsすら!)。
少なくとも書式付き出力に限れば、ストリームはプログラミング言語の中ではもう淘汰されてしまったんだと思うよ。
早いとこ、string::format()とかbasic_ostream::format()とか作ってほしいわ

**デフォルトの名無しさん** · 2019/05/06(月) 15:24:11.52

多言語対応するためにはC#みたいに %1, %2みたいに引数を番号で指定できる書式じゃないとダメでしょ。