C++相談室 part142
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の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 c++みたいに型情報ありがデフォルトの言語でハンガリアンとか二重メンテもいいとこだわ。 前方宣言したクラスを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
} >>388
unique_ptr<T>のデストラクタはインスタンス化するときにTが完全型であることを要求する(デストラクタで直接Tのデストラクタを呼ぶ)
unique_ptrを内包するクラスのデストラクタが暗黙だとクラス内でコンパイラによって実装されるけど、その場でunique_ptrのデストラクタを要求する
しかし、その翻訳単位内でTの定義が無ければコンパイルエラーとなる
unique_ptr<T>を内包するクラスのデストラクタがとりあえず宣言だけでもあると
実際の定義がある場所で同様の事が起こるので、その場所でTの定義が見つかればいい
その場合に定義を書かないと、コンパイラさんが適切な翻訳単位内に定義をおいてくれるみたい
shared_ptrは動的削除子のおかげでデストラクタが呼ばれるところで適切にデリータを定義し、デストラクタを呼ぶようになっているのでこの様な問題は起こらない
shared_ptr<T>のデストラクタ内ではTのデストラクタを直接呼び出すようなコードが無い うーんC++プライマー8500円かぁ。本家のプログラミング言語C++第4版はもっとするし
情報量からすると安いが本一冊にポンと出すにはお高い……日本語である程度網羅的な本となるとこの2冊くらいよね set<double> って int のときと同様にちゃんとソートされるんですか? たしかにそうだな・・いよいよ平成最後なんだな
みなさん、>>393-394 みたいな事にならないよう、気をひきしめましょう 平成最後っていう言い回し使われすぎて嫌いになってきた イテレータの参照を次に移すときってなんでitr++ではなく++itrなの? 素直な実装だとitr++より++itrのほうが速いんじゃないかなあ、となんとなくみんなが思っているから インクリメント後のイテレーターの値を返す処理の実装を考えると
先の場合はインクリメントしてそのまま渡せばいいけど
後の場合はインクリメント前の値を保存しといてそれを渡さないといけないので一手間かかるから
・・なんだけど諸々の最適化とか色んな条件とか考えたらそこまで差がでるかどうかはよくわからん it++だと、戻り値をコピーしてとっておいてから、ポインタなりを進めた後にreturnする必要があるが、
++itだと、ポインタを進めた後に参照を返すだけでするからな。 >>398
ite++と++iteなんて気持ちの問題
てか範囲for文使えばいい >>402-405
cppcheck にかけたらちゃんと警告出るね。 どうせ戻り値捨てるんだったら++itを選んでおいて損はない
無駄にit++を使うのは時期尚早な最不適化って奴だ C++で書くんだから後置インクリメントの方がメインに決まってんじゃん
前置は異端だ C++でいいんだよ。
規格は一歩進むけど、使ってるやつはbetter Cばかりってな >>411
vectorとかstringとか使わんの? CArrayとCStringだぞ
コピコンは定義されてないから自分で作るぞ CArrayは、<algorithm>ヘッダーで定義された信頼性の高いユーティリティ関数を使えないのがね・・・。 >>415
イテレータをうまいこと定義すれば使えるやつも結構あるんじゃね?
そうでもない? inconsistent begin/end types in range-based ‘for’ statement
gcc(g++) 8.2で -std=c++17オプションでコンパイルで
範囲forでこのエラーが出るんだが
begin endの型不一致の制限緩和されいるはずだよな?
原因わかる方いますか? >>415
GetData()とGetData()+GetSize()を渡せば、とりあえず動くんじゃね? >>422
int _n = 0;
auto __begin = _container.begin();
auto __end = _container.end();
for (; __begin != __end; ++__begin) {
_n = *__begin;
}
比較演算子はちゃんと定義してるし
上のコードは何故かコンパイル通る
だけど
for (const auto _n : _container) {
//hoge
}
は何故か通らない 範囲for文のconst autoをconst auto&かauto&&に変えるとどうなる? >>424
auto&&にした時のみエラーが増えます
cannot bind rvalue reference of type ‘const long unsigned int&&’ to lvalue of type >>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; これで動かん?
for (auto&& _n : _container) {
} MYIteratorの実体がunsigned longみたいだけど
vector<int>::iteratorの実体がポインタだったらoperator!=の定義できなくない? >>423
bool operator != (〜) const ← これ付け忘れてないか? >>427
自己解決
const iteratorとconst_iteratorが一緒だと勘違いしていた
const my_iteratorではなくmy_const_iteratorを実装して返り値とすべきでした 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でないと継承元のメンバーが見えないのは仕様? 仕様
一寸前までのmsvcではなぜか通っていたけど >>437
2phase lookupだから
最初のTB解釈時にはTAが型引数一つのtemplate classであるという情報以外使わない
だいたいTAが特殊化される可能性があるだろ 8bitや16bitのintしか使えない環境で、
32bitなどの大きな数を扱うにはどうすれば良いですか?
変数をいくつかつなげて大きな数を表現できないかと思っているのですが、やり方が分りません。
ご存知の方いらっしゃいましたら教えて頂けると嬉しいです。 補足させて下さい。
足し算、引き算は出来るようにしたいです。
可能でしたら、掛け算や割り算もできると助かります。 >>438
> だいたいTAが特殊化される可能性があるだろ
なるほどそりゃそうか、サンクス >>439-440
https://mevius.5ch.net/test/read.cgi/tech/1434079972/51
近々、委譲をやめて継承に戻すつもりです
あと掛け算はkaratsubaを適用できる目処がたちました
x64 に特化してインラインアセンブラ化することも考えています karatsuba はかなり桁数が多いときじゃないと効果がないとも聞くけど >>439
stdint.h で int_least32_t とか使えるのでは? >>446
8bit/16bit CPU で int_least32_t とかはそもそも存在しないのでは? >>447
「8bitや16bitのintしか使えない」を見て long や long long はもっと大きいんじゃないの?と思ったんだよ。
「整数型」の意味で"int"って書いてたんなら、確かに存在しない環境のことを言ってるのかもしれない。
その場合は ISO C/C++ の LONG_MAX の最低絶対値の要求に準拠できないってことになるんだけど。 8bit pic用XCでもlongは32bitなのに >>449
それはそれですごいインプリメンテーションですね…
8 bit PIC で 32bit int がさくさく書けちゃうとは、そのインプリメンターは根性がありますね、それか頭のねじが何本か外れていて「無理を無理と思わない人」とか… shortは16bit固定でlongは32bit固定でしょ。何言ってんの? >>451
残念でした、short も long もインプリメンターが好きに実装していいのですっ!きりっ! >>451
64-bit Linux でsizeof(long) が8だった。移植がある場合は<cstdint>使わんとあかん intが16bitならISOの規格は満たしてることになるかな。
32bit以上の長い整数はクラスと演算子オーバーロードで誤魔化すか。
頑張ってもリテラル表記もダメだろうから、使い勝手は悪いよな。 >>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 厳密なbit長が必要なときにintだのlongだの使っちゃ駄目よ intの配列のラッパーのようなものから再発明すりゃーいい
class Bignumber{
int number[4];
Bignumber(const String num){
for(int i=0; i<4; i++){
number[i] = //考えるのが面倒臭い
}
}
Bignumber operator+(){
//以下、延々とオペレータオーバーロードが続く
}
}; >>459
int64_t とか int32_t とか cstdint の面々を使うしかないでしょうね…私もデフォでそうするようになりました あ…ありのまま 今 起こった事を話すぜ。
平成の終わりにいろんな奴からshort/longに対する認識の誤りを指摘される恥辱を味わった。
何言ってるかわからねーと思うが(以下略 なんかもうビットという表現すら無くそうとしてるんじゃなかった? 制限された環境で使える多倍長整数のライブラリくらいいくらでもありそうだけど >>462
なるほど、cstdint ですか!
教えてくださりありがとうございます ビット数を付けるのは、MISRA-C で決まっているだろ
int8, 16, 32
uint8, 16, 32 C++の規格上はintは16 bit以上(ターゲットのアーキテクチャで一番自然なサイズ
、longは32 bit以上
だったと思った class ClassA
class ClassB: public ClassA
class ClassA::ClassC
のときに、ClassBはClassAのサブクラスと言いますがClassCはなんと呼ぶものですか? >>469
>class ClassA::ClassC
この意味はなんですか? 基底クラス
スーパークラス
親クラス
ベースクラス 細かいことを言えば、規格準拠の処理系でも
int32_t (ピッタリ32bit) が定義されるとは限らないのね。
int_fast32_t, int_least32_t なら定義される。
8bit単位じゃないCPUへの配慮らしいから、
普通の(この表現も危険だけど)コンピュータを使う分には
int32_t があると仮定して書いてもたいがい大丈夫だろうけど。
コンパイルエラーが出るから出たら対処、で十分かと。 >>470
クラス内で定義したクラスです
class ClassA {
public:
...
private:
class ClassC;
ClassC * C;
}
class ClassA::ClassC {
...
}
の場合class ClassA::ClassC からClassA::を取るとコンパイルが通りません 「プログラミング言語C++」だと、入れ子クラス(nested class)とか
メンバクラス(member class)とか呼んでるみたい。 内部クラス(inner class)もよく聞くけど調べたらJava用語っぽいな Inner Class、Java用語なのか。そう呼んじゃってたわ >>473-474
nested class は仕様にあるので、
これが公式な用語と思って良いみたいだね。 以前、「完全さを求めるあまり今存在する良い物を犠牲にしてはならない」という趣旨のことわざをBBCハードトークで仄聞したのだが、原典はなんだろうか? >>480
ググってヒットしたもののうち、これについてめぐらせています(ことわざとは関係ありません…)
http://www.kt.rim.or.jp/~hisashim/gabriel/WIB.ja.html
この人(原著者)、最後まで間違ったままでいるような気がしてなりませんが、実際のところどうでしょうか ストリームの遅さは凄い凄すぎる。
ほとんどの場合、遅くても問題ないということはわかる。
でもあそこ迄遅くする必要があったのだろうか。 ■ このスレッドは過去ログ倉庫に格納されています