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/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みたいに引数を番号で指定できる書式じゃないとダメでしょ。

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

ストリームの精神はrangeに受け継がれて生き残るよ
だから書式はそろそろ負けを認めよう

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

どうしてprintf使わないの？

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

オーバーロードできないから

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

<<には<<なりの良さがあると思うので、ストリームというより、stringがoperator <<をサポートすれば良いと思う。

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

文字列操作するためのインターフェイスとしては最悪だよ。
考えた奴は自分では絶対使わないで人に使わせるだけのタイプだろうな。

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

そもそもだけど、なんで文字って表示されるのに
<< とか %s とかこういうのが必要なの？
どの言語でもprint(a);だけで表示させればよくない？aが文字列でも整数でも小数でもさ。
引数で判断してくれよ。

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

>>493
え、そう？
文字列を連結する時に、+=と+を使い分けるより<<だけですむ方が楽だし、連結する順番も自明だし結構良くない？
std::string str;
str << "hoge" << 123 << ".txt";
みたいな。

◆QZaw55cn4c · 2019/05/06(月) 17:27:51.75

>>492
それは私も考えていました、cerr に都度吐いているメッセージを、もう一度プログラムの最後にまとめて吐きなおす、とかをやってみたいんです…

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

>>495
そのやり方は引数の順序を変えられないから語順が違う言語間での翻訳で困る

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

コンストラクタの引数に出力先stringインスタンスを渡すostream派生クラスを作ればいいじゃない。
string str;
hogestream sstr(str);
sstr << "hoge" << 128;

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

別にstringstreamで良いじゃない

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

別にstringstreamで良いじゃない

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

iostreamの<<はC++の黒歴史の一つだね

**はちみつ餃子** ◆8X2XSCHEME · 2019/05/06(月) 18:19:09.50

stream の機能はいらんからとにかく文字列に差し込むだけ出来ればいいってのなら
単に operator<< を定義すれば出来るけど……。

https://wandbox.org/permlink/dIkEh0LDZEixGoiF

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

>>499,500,501
ostream派生クラスじゃなくて独自のクラスのほうが軽量でいい。
stringインスタンスへのポインタのほかに、数値書き込み時の進数設定(oct,dec,hexを覚えておく)などをメンバ変数に持てばOK。

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

>>502
をを、なるほど、これは素晴らしいw

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

>>492
stringstream・・・

**デフォルトの名無しさん** · 2019/05/07(火) 19:51:10.38

basic_ostream使えよっていつも思う
なんで決め打ちするのかわからない

**デフォルトの名無しさん** · 2019/05/08(水) 21:52:50.27

to_charsというものをみつけました。

**デフォルトの名無しさん** · 2019/05/09(木) 18:03:02.17

b配列全てをa配列のケツにコピーするとき

std::vector<char> a;
char b[]={0,1,1,3,4};
a.insert(a.begin(),&b[0],&b[sizeof b]);

これでいいの？

&b[sizeof b]
これが死ぬほど気持ち悪いんだけど

**デフォルトの名無しさん** · 2019/05/09(木) 18:18:44.76

そんな気色悪い書き方しなくてもこれでいいよ
a.insert(a.end(), std::begin(b), std::end(b));

**デフォルトの名無しさん** · 2019/05/09(木) 18:25:51.81

なるほど！ありがとう

**はちみつ餃子** ◆8X2XSCHEME · 2019/05/09(木) 18:44:16.05

>>508-509
std::copy に back_inserter を渡す方が効率的という豆知識。

**デフォルトの名無しさん** · 2019/05/09(木) 18:53:31.44

>>511
insertのが速いんでね？
resizeしてmemcpyになるはず

**デフォルトの名無しさん** · 2019/05/09(木) 23:40:45.34

アルゴリズムよりvector::insertのほうが実装による最適化の余地は大きそうだな

**デフォルトの名無しさん** · 2019/05/10(金) 00:47:30.50

ポインタがイテレータとして渡された時点で相手が連続バッファだってわかるからね

**デフォルトの名無しさん** · 2019/05/10(金) 11:00:01.95

&b[sizeof b]でもstd::end(b)でもやってることは変わらないんだけどな
見映えは重要だな