C++相談室 part139
レス数が950を超えています。1000を超えると書き込みができなくなります。
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part137 (正しくはpart138)
http://mevius.5ch.net/test/read.cgi/tech/1535353320/
このスレもよろしくね。
【初心者歓迎】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 >>863
原因は、main 関数の最後に書いておいた、次のループにあった :
for ( ;; ) {
emscripten_sleep(36000000); // 何日間も待つ。
}
このループをコメント・アウトするだけで、vsprintf() が1つ前の戻り先に
戻ってしまう不具合も、sprintf() が 0 終端文字を書いてくれない不具合も
共に起きなくなった。
このループを書いていたのは、Emscripten 1.35 で、かつ、
wasm ではなく、asm.js で試していたときに、キー押下イベント
などが発生した時に
Assertion failed: the runtime was exited (use NO_EXIT_RUNTIME to keep
it alive after main() exits)
というエラーが出るためだった。つまり、main() 関数が終わると、
「ランタイム」(ランタイム・ライブラリ?) も終了してしてしまうので、
main() を終わらせられなかった。だから、main() の最後に、なんらかの
無限待機の仕組みが欲しくなって書いていたのだった。
現在は このループを除去しても警告が出なくなっているが、
Emscripten の Version を上げたせいか、asm.js ではなく、wasm の方を
使うようになったせいかは分からない。 なんでリトルが自然なん？
あとから拡張しやすいって意味か？ 加算器は下の桁から処理していって桁上げする方が自然とか、複数バイト長のワードで
ビットアドレスとバイトアドレスの増加方向が同じになるとかかな。
ワードサイズが変わっても低位バイトの位置が変わらないから拡張しやすいってのも
もちろんあると思う。 ハード作ってる時はビッグエンディアンの方が自然な気がするがソフト作ってる時はリトルエンディアンの方が自然な気がする
まあ、FPGAと高級言語を使うようになってからは滅多に気にすることは無くなったけど >>867
cast するときにも便利。
メモリに書かれた 32BIT整数を 8BIT 整数として取得したい際など、
先頭アドレスが変わらないので、速度効率が上がりやすい。
もし、BIG ENDIAN だとそのようなときに、「3」足さないといけなく
なってしまうと思う。 fstreamでリトルとビッグの切り替えってどうするの 逆にビッグエンディアンの方が自然に思えるのは16進ダンプ見てるときくらいしか思いつかない。 Uint32 u32;
BYTE u8;
u8 = (BYTE )u32;
とするコードがあったとする。u32 を、ポインタで置き換えたいとき、
Uint32 *pUint32;
u8 = (BYTE )*pUint32;
と書くのも正解だが、
u8 = *(BYTE *)pUint32;
と書くのも正解で、実は、後者の方が効率は良い場合があるとされる。
なぜなら、メモリから前者は4バイト読んでから上位バイトを捨てるが、
後者では最初から上位バイトを読まないから。
この場合、Little Endian だと、後者の書き方でも混乱が少ないが、Big Endian
だと何を意味しているのか分かりにくくなる。というのは、
(BYTE *)のようなポインタ型への cast は、旧来の C では、アドレス値自体は
変更せずに、型だけを変更するというのが伝統的な実装だったため
(ただし、C++ の場合、多重継承していた場合は、その原則を破ってアドレス値が
変化する事があるが。)。
BigEndian の場合、最後の書き方の実装に不安定要素が残るように思える。 >>836,>>839
ありがとうございました。
配列の実態作ったらできました！
_を接頭文字で使うのは結構規模の大きいオープンソースプロジェクトのソースで
メンバー変数の頭に_を使ってたのでやってました。
気を付けます。
話は少し変わるんですが、>>809でクラスをnewせずに使うというのが書かれていますが、
オブジェクトをnewせずに使うことって結構あるんでしょうか？
普段C#やっているのですが、クラスは基本的にnewでインスタンス化して使うものと思っていたので、（コンストラクタで特に初期化処理がなくても） >>874
>話は少し変わるんですが、>>809でクラスをnewせずに使うというのが書かれていますが、
>オブジェクトをnewせずに使うことって結構あるんでしょうか？
どちらかというと、C++では new する必要ない場合は、new しないことが
良い書き方。new は、好きなタイミングで削除したいようなオブジェクトの場合
のみ使用する。構造体やクラスのメンバの中に、別のクラスのオブジェクトが含まれている
ような場合は、new しないのが原則。
ある意味では、そのような習慣があるからこそ、C++ は効率が良いともいえる。
実は、new や malloc は、確保するサイズにかかわらず、大体 170 クロックほど
必要。delete や free と合わせると、合計 300 クロック必要となる。
一方、そのまま、new せずに「埋め込んだ」場合は、基本的に「0」クロック。
この差はとても大きなものとなることがある。 >>874
最初から最後まで存在し続けて、特別な終了処理が必要ないオブジェクトなら、わざわざヒープを確保して実行時に初期化する必要はないでしょ。
あと、staticなオブジェクトのコンストラクタはmain関数の前にグローバルコンストラクタから呼び出されるのだが、
これを利用して、プログラム起動時にやっておきたい初期化処理をクラス内で記述する目的に使うこともあるね。 >>875
さすがに良い書き方っていうのはどうかと思うけどな。
staticなオブジェクトにしちゃうと、初期化の順番が制御できないから、気をつけて使わないとコンパイラ依存のコードになってしまうし。 >>875,>>876
ありがとうございます。
このあたりのC++とC#の慣習の差異に違和感を覚えていたのですが、かなりスッキリしました。 >>877
必要な場合は new しても良い。でも、クラス Cxxxの中には、文字列の CString
クラスのオブジェクトや、何らかのリストのオブジェクトが複数含まれて
いたりすることも多い。それらのメンバを全て new する場合と、埋め込み
でそのまま使う場合とでは、Cxxx をインスタンス化するときの時間に雲泥の
差が出てしまう。Cxxx が、5つのクラス・オブジェクトを含んでいた場合、
それらを new するだけで、170 * 5 クロックも余分に掛かってしまう。
この数値には、各コンストラクタの処理時間は含まれていないので。
この場合だと、全て new すると、850 クロックも余計に掛かることになる。
さらに、Cxxx オブジェクトがデストラクトされる場合には、合計で、この
1.8 倍程度の時間が new しない場合より余計に掛かることになってしまう。 >>872
思い出したので追加しておく。
Little Endian の場合、
>Uint32 u32;
>BYTE u8;
>u8 = (BYTE )u32;
の代わりに、
Uint32 u32;
BYTE u8;
u8 = *(BYTE *)&u32;
という書き方も出来て、こっちの方が、処理効率が良い場合があるとされている。
しかし、BigEndian だとこの書き方は混乱を招きやすく、かつ、処理効率も
上がらないと思われる。
総合的に考えると、Little Endian の方が処理効率が上がりやすいはずだ。 >>877
>>875はstaticな変数のことははじめから言ってなくて、構造体のメンバやスタックに積まれるケースのように自動的にメモリ確保されるケースのことを言っていると思われる。 cのsetjmpを使ってるコードはc++で例外に置き換えられますか？ >>882
確か、関数呼び出し連鎖の途中の関数が誰も catch せずに放っておけば、
親の関数にまで戻れるはずなので、一応、同じようなことが出来る気もする。
長い間使ってないので、むしろ、setjmp, longjmp がどういうものだったか
の方を忘れてしまったけど。
たしかそれでいけたと思うな・・・。 std::variantって見たんだけどこれいいね。 やっぱ整数なら下の桁から上の桁に向かって書いたり送ったりするのが自然
上の桁とか（整数という概念上は）何桁まで伸びるかわからないのだから
しかし一方人間の認識上は上の桁から見て量を把握したいという要求があり、
不幸にもラテン語が左から書くのにアラビア数字が右から書く慣習だったため
二つの文化を取り持つ玉虫色の解決策としてビッグエンディアンとかネットワークバイトオーダーみたいなものが生じた スマホアプリとかのパケット解析するとわりとビッグエンディアン使われてる だってビッグエンディアンはネットワークバイトオーダーでもあるから。
外に出すデータや互換性保ちたいデータは普通そうすると思うよ。 >>890
アラビア数字書くとき右から書いてるの？変わった人ね 数の表記だけじゃないさ。日付、人名、住所の表記も。
単純なASCIIソートで正しくソートできるのはどれかという話にもつながる。 数値を数字に直すとき桁数を調べるには対数とればいいよ。 >>895
数学的にはそれで完全に正しい。
しかしコンピュータには誤差があるので、
itoa() や printf() などを自分で実装するような場合、
よく考えないといけないかも知れない。
log_10(x) で計算すると N 桁だということになったとしても、
itoa() などを実装するアルゴリズムによっては、ある条件の時に
誤差によって、1ケタだけずれるかもしれない。
めったに無いことだが、これで銀行システムや戦闘機のシステムが
ダウンしたりするかも知れないので、数学は重要。 ちなみにオイラは数学は首席だったが、どういう場合にそれが生じるかは
即答することは出来ない。アルゴリズムを慎重に選ばないと、その誤差によって
システム・ダウンやアプリのハングアップ、保護例外などを引き起こす可能性が
わずかだが存在するかもしれない。 n>=0かつ10^n <= m < 10^(n+1)
のときに整数mは十進n桁の数と言える。
不等式に常用対数を適用し、
n <= log_10 (m) < n+1
が得られる。つまり、1以上の整数mに常用対数を適用し、さらにガウス記号を適用したものがmの桁数だ。
m=0のときは一桁になることに注意する。 計算結果の桁数が違うときは、常用対数の誤差とガウス記号の誤差の問題になる。 常用対数の誤差については、有効桁数を使うか、区間演算により、誤差の範囲を見積もることが可能。そこで、誤差の範囲が整数をまたぐかどうかを判定すれば、問題は解決する。 整数をまたぐ可能性があるときは実際に整数を文字列化すれば正確な桁数が算出可能。もしくは任意精度の多倍数演算により自由に精度を高めて再計算すればいい。 ふつー数値から文字列に変換する変換関数そのものに長さを報告させるだろ
文字列の格納先のメモリを確保するときのサイズ見積もりに対数を使う場合は
ワーストケースで誤差が出た場合に備えればいい 具体的なほとんどのプログラムでは常用対数の誤差を一桁以内にすることは可能だろう。 >>911
siv3dみたいなのを探してます
オープンソースで参考になるやつ スマホゲームならWebGL一択、ハイエンドならUnity、Unreal Engine、CoCo3D、ローエンドならOpenGL, DirectDraw, Haxeといったところか。 >>913
>>914
うーん
一応webgl考えてみます >>908
変換関数そのものをプログラムしたい場合に、あらかじめ桁数が分かって
いる方が便利 or 効率が良い、場合があり、log_10(x)を使用したくなってしまう。
ところがが、log 計算には誤差が有る可能性があるので、その値を過信するのは
問題だと言うことが言いたかった。
例えば、文字列化する際には、多くのアルゴリズムでは、下の方の桁から
決まっていく。しかし、文字列バッファには、上のケタから左詰で入れて
行く必要がある。となると、最初から桁数が分かっていれば、簡単に
プログラムできるのではないかと言う誘惑に駆られてしまう。
後、10で割っていって余りを使う方法は簡単ではあるが、そのアルゴリズム
そのものにも誤差が有る可能性が指摘されている。 >>916
＞10で割っていって余りを使う方法は簡単ではあるが、そのアルゴリズムそのものにも誤差が有る可能性が指摘されている。
え？10で割っていくのにどうして誤差が出るの？ >>916
変換関数の中でメモリ割り付けを行うのが好みなのか？ んま実際にわ数値の桁数とか型を見たら一発でわかるんですけどねｗｗｗｗｗｗ
logは人間の感覚特性にマッチした量的尺度を表したり（例：dB）、
情報量の表現に使う（同じものがいっぱいあるという状況は情報量を上げない）という目的が大きい >>910
coronaがオープンソース化されたらしい
2dだが >>917
前提として浮動小数点数(float/double など) の話だけど、誤差が無いとは言い切れない
事は分かると思う。
誤差を少なくする方法として、10で割ったりせずに、最初から、
10000.0, 1000.0, 100.0, 10.0, 1.0, 0.1, 0.01, 0.001
20000.0, 2000.0, ・・・
30000.0, 3000.0, ・・・
40000.0, 4000,0, ・・・
のようなものを計算しておいて、比較したり引き算したりする方法が
あるそうな。
浮動小数点値の場合、当然かもしれないが log を使わずに、IEEE の仕様を元に
指数部のBIT部分を読んで利用する方がいいらしい。 桁数が重要になるような銀行や事務系の話？
それなら10進演算だろ
IEEEでも定義されてる
科学計算だと対数で問題ない >>924
自分で printf() を実装する場合の、浮動小数点数を文字列に直す時の話。 自分でprintfを実装するとか銀行のシステムを作るよりレアケースだな ここがC++スレということを忘れて内科医？
printfはオーバーロードできるしグローバル以外の空間にも導入できる Pythonには素の遅いPythonとJITを使った素のPythonよりとてつもなく速いPythonがあるようですが
Boost.PythonでPythonスクリプトを読み込んで実行した場合は素の遅いPythonの速度になる認識であっているでしょうか？
また、Boost.PythonでJIT版Pythonを実行することは可能でしょうか？ >>929
全然その辺知らないけど、
そもそも、python の言語仕様自体がJITを使ったとしてもC/C++ほどの速度には
ならないはずだし、そもそも NumPy 使わないと遅いということは聞いてる。
大体のスクリプト言語は、言語仕様の段階で例えコンパイル言語化しても
どうすることも出来ない遅さが含まれてしまってる。 numpy使えばC並みの速度が出るようにも書けるが
numpy使ったからと言って馬鹿が描くと素のpython以上に遅くなる 用意されてるライブラリ使えと。
バカがイキって作ったライブラリより普通に速いから。 ・動的型言語
・自動メモリ管理
・リンクリストと配列を余り区別しない書き方をする人が多い傾向。
これらがあるので、pythonをコンパイル型にしてもある程度以上の高速化は
難しいと思われる。 pythonの速度測定は、やってみたことないけどね。(^_^;) Pythonにリンクリストなんか無いだろ
Pythonの配列(list)はvector相当の動的配列
実はリンクリストが動的配列より速いケースってC++でも現実にはほとんど無くて、あまり価値のないデータ構造だよ
拡張・縮小にメモリの再確保が不要で抽象化を必要としないから、Cのような生ポインタを好んで使いまくる言語と相性がいいだけ ttps://github.com/python/cpython/blob/master/Modules/arraymodule.c
3000行のありがたいソースコードを読み解けば何かが分る ハード屋さんが頑張りすぎて必要なくなっちゃったな
でも便利だからforward_listを使うことはある tupleってメンバ関数で値取り出せないのね。
std::get<N>( t ) ってファンキー過ぎやしませんか。
下手に使うとコンパイルに時間食われそう。 関数やテンプレートで、できることとできないことを
冷静に考えてみな >>944
テンプレート化すればメンバ関数にすることはできるのでは？ メンバテンプレートにするとtupleをテンプレートに放り込んだときに
t.template get<0>()
と書かなきゃならなくなってこりゃないわーで皆が合意したからじゃ せめてstd::tuple::get<N>( t ) にして欲しかった。
std名前空間汚れすぎ。 >>943
それは確かに糞仕様だと思うが
テンプレートの意味から言えば仕方ないのかも知れない
(どんな型でも入れられるならテンプレート以外でやるべき) 他のコンテナでも同じように使える様にしたかったんじゃないの
オーバロードで std::getは固定長コンテナなら何でも使えるぞ
std::pairでもstd::arrayでも生配列でも >>949
std::getにすることによってテンプレート引数にtupleと見なせる型(pair,array)を使うことができるようにしたいからそうなっている ちなみにstd::getのユーザーによる特殊化は次から禁止される予定です ポリモーフィズムを使っていて、ダウンキャストを行うときって
dynamic_castをしてみてnullptrかどうかを判断するのがベストな手順なんですか？
RTTIから実際の型情報を引っ張ってくる手段はないものでしょうか >>955
もちできるけど、検査したい型を継承した型を渡されたら動かないよ？ >>955
それこそポリモーフィズムで派生クラスのthisを直でもらえばいいんじゃないの >>955
typeid で type_info 取れるよ。
基底クラスにenum Type 等を持たせてswitchも手の一つ。
処理内容によってはvisitor パターンが使える。俺が知ってるのはこれくらい。 まず、なるべくダウンキャストなんか必要ないようにするのが最初だけどな >>955
ダウンキャストが必要になるなら、選択はそれしかない >>955
ダウンキャストしたいんだよね？
なんで実際の型情報なんかを欲しがる理由がわからん カミカゼキャストについて教えてください。
不意にフレーズが浮かんだのです。 dynamic_castでnullptrなりbad-cast拾うのはお勧めできない。 レス数が950を超えています。1000を超えると書き込みができなくなります。
