【初心者歓迎】C/C++室 Ver.102【環境依存OK】
■ このスレッドは過去ログ倉庫に格納されています
エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります
コードを貼れる所
http://codepad.org/
https://ideone.com/
前スレ
【初心者歓迎】C/C++室 Ver.101【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1500329247/ 計算量とかメモリ使用量のオーダーは気にするけど、オーダーが変わらないレベルの差はそんなに気にしてもしょうがない。 待て待て、>>257は速度追求の話ではないだろう
無駄なループを通らせないとかそういう話でしょ? エッジケースで極端なことになってしまうって話かな?
そういうのは単に気をつけるしかしゃーない。
発覚したときに直せるような体制にしておけ〜 >>257
とりあえず注意すべきは線形探索かな
何も考えずに使われると素敵なことになる クラスAのメンバ関数へのアクセスをクラスBのみに許すにはどうすればいいですか?
(メンバ関数をfriend指定するのはBがAのプライベートメンバにもアクセスできてしまうのでNGです) 自己解決
passkeyイディオムを使えばいいんですね
言語仕様でサポートしてほしい気もしますが できる人にとってはくだらないことなんだと思うのですが、
char* c;
char *c;
この2つは一緒なのですか? char * c;
とか
char
*
c
;
も含めて一緒 >>270
>>271
ありがとうございます
どちらが正しいのか、機能が違うのか、よくわかっていなかったのがスッキリしました >>270
前者だと
char* a, b;
って書いたとaとbの型が変わっちゃうから常に後者方式で
char *a, *b;
みたく書くことをオススメする ワイはアスタリスクを型名の方に寄せて、複数の変数の宣言をまとめないスタイルを推しておるやぞ。
char* a;
char* b;
まあ人によって色々やね。 C++ なら std::add_pointer を使うのも手やぞ。
普段から使うには綴りが長い気もするな。 ワイも後ろに寄せるスタイルの方が好きやな
別に自由ではあるけど、前に寄ってるとなんか違和感あるわ この話始まるとスレが荒れるわけだが。
俺は
char *a;
int & ref;
だ。 C++ だとスッポスッポ先生が (というより D&E の文中にあるコードが) アスタリスクを型名にくっつけるスタイルで書いてあるから、
設計者的にはこれが推しなんやろなて思うたんや。 そもそもCならまだわかるがC++になってもこの謎仕様が改善されてないのがおかしいわな char *a;派だがキャストは(char*)だな >>274
それな
前者は誰が流行らしたんだハゲか 変数との間に空白を入れるか入れないか選択の余地がある あと数字の後ろにも置けるよな確か
x[2]は2[x]でも普通に動作するらしい、使ったことはないが >>293
宣言の中の型としての*の位置を問題にしてるのだから、式の中での*が使える位置については別の話でしょ。 インデントってタブ文字使うよりもスペース使った方がいいんですか? >>297
見た目とコンパイル速度のどちらを優先するかによる。 タブコードはエディタの設定に見た目が左右されるので使わない方がいい エディタの機能向上による要素が大きいな。
インデントやその削除にキーを何度も叩かなきゃならない状態だったらTABがまだ主流だったろう。 >>294
他にも変な仕組みは色々とあるけど、これはひとつとして使いどころが思いつかんよな。 int a[10]; で a[5] でも 5[a] でも同じようにアクセスできるのは、
a[5] と *(a + 5) が同等で + 演算子の交換可能性から *(5 + a) も可、
それなら 5[a] も同じじゃなきゃ片手落ちだよね、って発想というか、
過去のコンパイラの実装とも関係がありそうな気がする。
もちろん、古いCコンパイラとのソース互換性が問題になるほど
みんなが使ってた書き方とは思わないけど。 i++ と ++iって最適化すればほとんど変わらないか、あるいは++iの方がちょっと速いくらいですよね?
なんでi++の方がデファクトスタンダードみたいになってるんでしょう?
ほぼ無視できる程度のメリットしかないとしても、++iと書くデメリットがないと思うのですが >>307
インクリメントの対象が整数しかなかった C からの習慣がなんとなく引き継がれてるだけ。
後インクリメントは気持ち悪いと考える人は少なくはないし、
値を使わないなら前インクリメントにするのは C++ では良い習慣だよ。 >>308
なるほど、最初はちゃんと意味があったんですね
納得できました
ありがとうございます Cでインクリメントやデクリメントに後置が使われがちな理由は
a = *p++; みたいなポインタの使い方で手が慣れたせいもあるかと思う。
C++では性能的な理由で前置が好まれたのは指摘のとおり。
個人的には、どっちでも構わない場面ではCでは後置、C++では前置で書くかな。
特に単純なforで++iと打つと、途端にC++で書いてる気がしてくる。 GCC 6.4.0 最適化なしで計測してみたけど、平均的な差は無いな 単純な整数型のインクリメントなら前置も後置もさが無いだろうけど、C++ではユーザー定義のクラスでインクリメントを実装できるから、
基本的には更新前のオブジェクトの状態の退避などの処理が必要な後置インクリメントよりコストの少ない前置インクリメントが好まれるのだと思うよ。 結果が使われないことが明らかな場合には後インクリメントのかわりに前インクリメントを呼び出すとかいったことをしても
ほとんどのコードは壊れないと思うんだけど、そういうルールを言語仕様に追加するのはもう出来ないかなぁ? まぁ、出来るなら既にやってるでしょ
ぶっちゃけ、よっぽどシビアに速度を求める訳でないなら前置後置の差なんて気にする必要無いんじゃないかなぁ そもそも速度を気にして
記述を変えるって
間違ってる気がする・・ 機能に対して糞重いソフトが多いのも
ソフトに対する価値観が変わったからか >>318
速度を気にするというのもあるけど、意味的にも無意味な処理をするってのがダサいだろ? >>321
お前のコードは無駄ばかり
コンパイラも無駄命令を吐く
そもそもCPUの動作自体が無駄ばかり
そのプログラムを作るのも無駄だったり
お前の存在は? 手間が変わらず、かつデメリットもないのにその選択肢を取らない理由がなくない?
後置の方が保守性が高いとか可読性が高いならともかく、そうじゃないんだから天秤にかける必要さえない 効率を言い出すと値を返さないインクリメント、デクリメントが標準で欲しくなる ホントは最適化でだいぶん上手いことやってくれるんやけどな。
というか最適化でやるべきことだと思う。
細かいことまでいちいち配慮しなきゃならないのは最適化技術の敗北。
仕様に [[likely]] なんて入ったのは不格好な話だ。 イテレータの++や―に戻り値があること自体設計ミス
ポインタのと類似性そこまで要らんし
イテレータで *it++ とか書きたくて仕方ない人もそんなに居ないだろ
void型でよかった アセンブラの inc やdec 命令実行時のフラグ反映は不要?
高級アセンブラの名残じゃね? >>329
逆じゃないかなぁ。
ポインタをイテレータとしても使えるように一貫性を持たせたら結果的にそうなったって感じじゃないの。
どちらにしても、そこで無理に一貫性を持たせようとしてしまったことが良くなかったとは思うけど。
ちなみに operator++ の返却値を void にすることは出来ます。 >>330
inc/dec でフラグが変化しないアーキがあった、というか、それが普通だと思っていたんだが なぜポストインクリメントがよく使われるかは、
PDP-11とかのアドレッシングモードにあるオートインクリメントが起源。
間接参照したあとにレジスタが増える。
オートデクリメントは逆にプレデクリメント。
あとinc,decでフラグが変化するのもPDP当時は当然の動作。 Linuxさあ、Ubuntuとか使ってるんだけど、俺はプログラムやネット以外にあまり
PCつかわないから、Ubuntuなんてプログラム環境は大体パッケージで手に入るし
スゲエ良いと思ってたんだけど、エロ動画配信サイトが今時は必ず専用の○○プレーヤーじゃないと
見れないんだな。たとえば、DMMプレーヤーとかそのサイトの専用の奴。なんでもDRMとかいう不正禁止のが
付いてて、普通のプレーヤーじゃ見れないのよ。スゲエ不便だからそれ専用にWindows10準備しちゃおうかな・・w
俺はプログラム言語でC++が一番すきです。 >>336
ググればすぐにわかることだけど、有るよ。 unordered_setやunordered_mapは
reserve(size_type)はあるのにshrink_to_fit()がないのはなぜですか? void DumpCode(const char* str) {
for (int i = 0; str[i] != '\0'; ++i) {
printf("%02X ", (unsigned char)str[i]);
}
cout << endl;
}
↑の文字コードを16進数で表示する関数ですが、なぜ
printf("%02X ", str[i]);
ではなく、
printf("%02X ", (unsigned char)str[i]);
とキャストしているのでしょうか? char型の値は 0 から 127 までであると本に書いてあるのですが。。。 >>343
その本は窓から投げ捨てろ。
ー128〜127が正解だ >>344
本にはそうは書かれていませんでした。申し訳ありません。間違っていました。
アスキー文字コードは、0から127までの値しか取らないからOKかなと思ってしまったのですが。 >>344
何か不具合が起こる例を教えていただけると助かります。 >>346
char ch = 255;
printf("%d\n", ch);
C/C++では、オーバーフローは警告なく普通に起こる。 signedな整数型は、最上位ビットが符号フラグになるんだ。charは8ビットの整数型で、printfに渡す過程で、符号付きのint型になる。まあ、やってみたらわかるけど、
printf("%c\n", (char)255); printf("%d\n", (char)255);
%dね。 charのビット数、CHAR_BITが8ではない環境はほとんどない。 4ビットCPUで動作するトースターのコンピューターの話でもするつもりかね。 ほとんど無いから何?
「決まってない」の反論になってないよ
現行品でcharが16bitの環境があるんだけどね charが符号付きとも決まってない
ちょうど今符号無しの環境を使ってるよ char と signed char を混同するクソコテ 今後char関連の質問をするときは、charのビット数や符号などの環境を明示しましょうということで。
初心者お断り感あるけど、重箱の隅を全力でほじくり返す人がいるからしょうがないね。 unsigned char がデフォなんてMS-C 3.x or 4.xの /J オプション付き
以外に遭遇した事無いけどな >>359
>>341の質問に対してcharの符号有無が環境によって異なるというのは本質的な回答であり、ビット数の話は不適切だったというだけで、重箱の隅がどうこうという話では無いだろう。
そもそも初心者歓迎のスレで初心者を除外する要件を設けるのは本末転倒では? ???
環境を明示しろって言うのは>>1にも書いてあるんだが... >>361
初心者だろうと質問に付随する前提知識は必要
変数知らんデータ型知らん制御文も分からないじゃ説明しようがない事なんていくらでもある
まずそこら辺の知識を理解してもらわん事には説明できないですってのは初心者を除外とは言わんだろう ■ このスレッドは過去ログ倉庫に格納されています