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 メンバ名は頭にm_付けろみたいなクソルールよりずっといいと思うので付けるべき 仮引数と別の名前つけるのだるいからm_は別に良いと思う 引数そのままメンバに入れるなら引数に_つけてvar(_var)って初期化してるわ >>366
それって var(var) でも問題ないんですよ… ハンガリアン記法は、入力補完のないエディタ上での可読性を高めるのに役立ってるでしょ。今でも。 定期的にunsignedとsigned混在させてハマるアホをみるとハンガリアン必要だと思うわ C#で入力補完のないエディタがどうとかさすがにナンセンスでは
だってvisual studio使うじゃん どっちでもいいわ。
大抵の場合そんなとこに気を使わんといかんコードになってることのが問題。 >>375
こういうやつがそのうちハマって丸１日つぶしたりするんだよなw >>376
だから人を嵌めるようなコード書くなつってんだよばか。 >>380
コードの問題じゃなくて言語仕様の問題だから
こういうえらそうなくせに何もわかってないカスが一番始末に困る ハンガリアンも防御的なプログラミングと考えたら悪くないよ
成り立ち調べてみな
でも基本型とポインタだけだな
クラスには無用だと思う てめーらはまともなIDEかエディタ使ってねえのかよ 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だの使っちゃ駄目よ ■ このスレッドは過去ログ倉庫に格納されています
