【初心者歓迎】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/ まぁ、出来るなら既にやってるでしょ
ぶっちゃけ、よっぽどシビアに速度を求める訳でないなら前置後置の差なんて気にする必要無いんじゃないかなぁ そもそも速度を気にして
記述を変えるって
間違ってる気がする・・ 機能に対して糞重いソフトが多いのも
ソフトに対する価値観が変わったからか >>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
初心者だろうと質問に付随する前提知識は必要
変数知らんデータ型知らん制御文も分からないじゃ説明しようがない事なんていくらでもある
まずそこら辺の知識を理解してもらわん事には説明できないですってのは初心者を除外とは言わんだろう 4ビットCPUだとcharは4ビットと思ってんのか? >>341 >>346
不都合と言う程の不都合か分からないけど、
単なる char が signed char のコンパイラで、例えば str[i] == -1 の時、
printf("%02X ", (unsigned char)str[i]); なら表示は "FF "
printf("%02X ", str[i]); だと表示は "FFFFFFFF " (intが32bitの環境)
てな具合に表示結果が指定桁数とずれて見苦しい、という現象が起きる。
ただし void DumpCode(const char* str) でASCII文字列しか扱わないなら、
意図せずASCII以外(漢字など)を含んだ文字列を引数に与えたときに
「見苦しい表示結果」のおかげで関数の使い方の間違いに気付きやすい。
よって (unsigined char) のキャストをしない方が好ましい、て考え方もある。
>>360
ARM で GCC だと、単なる char は unsigined が普通みたい。
元のCPU設計で符号付8bitが拡張機能だったことと関係あるとかないとか。 4bitのcharか、アルファベットが表現できないな
まぁ、341の例だと渡されるポインタ配列が文字コードの範囲内ならキャストは要らんね
なんかの理由で文字コード外の数値が入ってきた時に文字揃えがズレる事を嫌って一応キャストしたって感じだとは思うけど int *p = new int[100];
delete[] p;
delete[] p で int 100個分の領域を解放するのだと思いますが、
どうやって、 p が int 100個分の領域を指していると分かるのでしょうか?
p は単なる int 型へのポインタです。 >>366
つ -fsigned-char/-funsigned-char スタックオーバーフローが起こった時に、すぐにエラーが起こらない可能性がある
そうですが、なぜ、エラー終了にしないのでしょうか? >>368
良くある実装としては
newが返すアドレスの前にヘッダ情報がある 素人考えだと並のOS環境ではスタックオーバーフローは自動伸長に失敗してアドレスを割り当てられない時に起こると思うから直ぐにエラー終了しそう
バッファオーバーフローの場合は割り当てたメモリとバッファ境界がミスマッチなら直ぐにエラー検出できないとしても仕方がないけどこれは質問とは別の話 配列への添え字アクセスの計算量はO(1)の定数時間とのことですが、これは通常の変数へのアクセスと同じということでしょうか?
例えばint型配列のfooとint型変数のbarがあったとして、
int n = foo[10000]; と
int n = bar;
の速度は同じですか? 添字の値にかかわらず一定
foo[10000] と foo[1] が同じって話だぞ >>375
ありがとうございます
だとすると、同じ添え字に何度もアクセス(読み取りのみ)する場合、一旦変数に待避させてその変数を参照した方がいいですかね? レッツ実測&吐き出したコードを確認
最適化具合でも全然ちがう >>377
吐き出したコードってどうやって確認するんですか? >>371-372
ありがとうございました。
そのあたりのことを詳しく書いてある本はありますか? >>377
確かにそうですね
ありがとうございます、やってみます >>378
使っている環境による
機械語一歩前のアセンブラも出力するオプションで出てきたアセンブラとデータシートから推定する
もっと前のアルゴリズムの検討は済んでて、
もはや、枝葉を削ってでも速度を出さなきゃいけないという最終段階の話だよね? >>343-344
char 型が符号付きであってもなくても格納可能な範囲という意味では 0 〜 127 であると思って使ってれば間違いないのは確か。
あと、厳密にはマイナスの表現に 1 の補数を使ってる環境は有りうるので
char が符号付きだとしても -127 〜 127 しか表現できないかもしれない。
>>345
言語仕様では文字がアスキーコードとは保証してないんだ。
ほとんどの環境ではアスキーコードかそれと互換な文字コードだろうけど、
EBCDIC とかでも言語仕様には違反しない。 >>373
並のOS環境って何だよwww
一般的なMCUのほとんどは
アドレス変換テーブルの仕組みがなく
スタックオーバーフローを検出するハード的仕組みも無い 二つスレッドがある
片方はstd::queueにつんで、もう片方はそれを取る
これで詰まれた瞬間に取るにはどうするのがいいのかな?
簡単に作るなら、無限ループでスリープ挟みながら取り続けることだけど、無駄も多いから積んだのをトリガーに取りたい
環境はg++とVC++です >>379
stackoverflow で、たまたまアクセスしたメモリに、
どんな値が入っているかは、誰にも分からない。
単に前に入っていた値が、入っているだけだから
その値が、たまたまCPU 命令にあれば、CPU を実行するから、
エラーになるのは次の命令以降になる
一方、CPU命令に無ければ、不正な命令となり、即座にエラーとなる スタックのメモリ領域がこの範囲からこの範囲というように管理はしていないのですか? >>387
昔汎用メッセージポンプを検討したときのサーベイにstd::condition_variableと書いてある。
注意としてspurious wakeupというのも書いてある。
もうすっかり忘れてしまって何のことだか自分でも思い出せないのだが、「条件変数」というのがキーワードになるようだ。 >>389
ページ単位ではしていることがある。
OS がメモリの割付を管理していて、
足りなければ追加で割り当てたりもする。
割り付けてないメモリ空間に変に触ったら検出できる。 >>389
スタックエリアの管理は当然してる
オーバーランの監視は環境次第
ハード的に仕組みがあるものもあし
ソフトで(コストをかけて)やる場合もあるし
全くしない環境もある 今のWindowsとかLinuxとかならもちろん瞬時にわかる 最近のC++ってかなり進化していてTaskとかLinqなんかもできるんだろ? PCだとC#があるから
C++は使わないが組み込みだとC++を使いたい。CからC++に変えてみようとおもっってテスト
してみたことがあるが、メモリーを食い過ぎてStringはつかえなかった。
どこまでなら使えるんだろ? なにか目安はないか? 組み込みなら自分で書いたものだけ使うというか
STLは一切使わないのが普通じゃないか? new/delete
例外
ラムダ式
は使わない
もちろん規模によるけど 組み込みってピンキリだからなんとも言えんわ
業務用複合機なんてそこらのパソコンより凝ったハード積んでたりするし STLってC#のLinq並みに表現力があるんだろうか? Linqは最初嫌いだったが使い始めて
見ると非常に便利で驚いた。C++のSTLは全然しらなかったがWikiを読んだらなんかかなり魅力
的に見えてきた。 内部で new / delete 使用している stl は使わないリストに入れず
new / delete は使わないリストに入れんのかよ… STLコンテナとSTLアルゴリズム
どっちの話をしているんだ コンテナ使わない有用なアルゴリズムってあるか
あるなら使いたいからご教授ください
min とかあるか >>403
内部でnew/deleteしてるものは当然含まれる
当たり前
そもそもヒープエリア自体無かったりするし
あってもアロケートのみで解放機能が無かったりする
小規模組み込みでメモリを確保出来ないなんてことは想定しないし
確保解放のコストもバカにならない
アドレス変換が無いから隙間だらけで連続領域が取れなくなるなんてことも心配したくない ヘッダファイルを作るときに、2重インクルードを防止するための対策を書けと本に書いてあります。
注意していれば、2重インクルードをせずに済むにもかかわらずなぜ、このような
対策をしなければならないのでしょうか? >>410
人間の注意力なんてクソザコだからだよ。 >>410
複数のヘッダで共通のヘッダの定義が必要な場合を考えてみようか header_1
header_2
…
header_n
で共通に必要なヘッダ header_a がある。
header_1
header_2
…
header_n
のそれぞれの中で header_a をインクルードしている。
header_i と header_j (i ≠ j) が必要なファイル file1 がある。
というような状況でしょうか? 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) あなたはstdlib.hとstdio.hの作者です
stdlib.hとstdio.hの両方でerrno.hが必要だとします
あなたはstdlib.h stdio.hの中でerrno.hをインクルードしますか?しませんか? >>416
入門書にこう書きます
「studio.h や stdlib.h をインクルードする際には、事前に errno.h をインクルードすること」
どうかなとは思うが実際こういう流儀でヘッダーファイル書く人も見かける ■ このスレッドは過去ログ倉庫に格納されています