C++相談室 part150

■ このスレッドは過去ログ倉庫に格納されています
2020/03/24(火) 00:04:33.93ID:YFRNwZnv
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part149
https://mevius.5ch.net/test/read.cgi/tech/1581974381/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/


■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

テンプレここまで
2020/04/30(木) 12:38:45.38ID:yesxJOcI
>>512
下のサイト的に言えば、誰もが
固定長に数値が収まるという夢を見た愚か者たち
なので、必要悪な気はするな
2020/04/30(木) 12:45:47.62ID:ERcZittz
>>531
code point単位なら結局utf32にして数える(部分的に可能)
面倒なのはgrapheme clusterから上
もう土方レベルが扱える代物じゃないね
534デフォルトの名無しさん
垢版 |
2020/04/30(木) 12:50:20.00ID:IVFUa3Rm
ICUのイテレータ使えばよいのでは。
2020/04/30(木) 20:12:10.12ID:IOnQoYGj
内部では utf-32 ベースで処理して、出口入り口で utf-8 に／から変換するものだと思いますが…
536デフォルトの名無しさん
垢版 |
2020/04/30(木) 20:49:36.61ID:IVFUa3Rm
そんな単純なものではないだろうけど。
537デフォルトの名無しさん
垢版 |
2020/04/30(木) 23:06:50.07ID:b9TIw4B4
期間工ブログの収入は１５００万円でした。【フリーランスの現実&底辺からの復活編】
https://www.youtube.com/watch?v=aijLjFLOuC4
工場勤務、３０代フリーターが「ブログ」で２００万稼げた理由！　◯◯があったから？
https://www.youtube.com/watch?v=Cjmk4XusQVM
ブログで月２００万稼ぐ、フリーランスの１日
https://www.youtube.com/watch?v=jaV2GyBgNX4
【クラウドソーシング】Webライティングで月商100万円まで稼ぐ方法をプロに解説してもらった！
https://www.youtube.com/watch?v=oYoaBwQt0Cg
1年半でライターの地位を確立した営業術！駆け出しフリーランスは要チェック【ニシキドアヤト】
https://www.youtube.com/watch?v=DFtmkhw-lHM
2020/05/01(金) 00:49:44.42ID:2K4VYu4Y
>>528
リッチーならともかくカーニハンは見てる可能性
2020/05/01(金) 01:06:57.59ID:Qu9UE9Tc
>>535
色んな文字コード (符号化) を扱うときは出入口で変換する方法は妥当な選択だと思うけど、
UTF-32 を中心に据えるのが良いかは一概に言えるものでもないでしょ。

たとえば Windows API がいう Unicode は UTF-16 なわけだし、
外部とのデータのやりとりで内部用の符号に変換する処理が入るのは仕方がないにしても
API の呼び出しのときまで毎回変換が入るのも煩雑なんで、
UTF-16 に統一した方全体としては楽じゃない？

サロゲートペアの扱いが面倒くせぇとかいうのと天秤にかけたとしても
Windows では UTF-16 から離れられない。
結局のところ実行環境とかフレームワークとかの都合に縛られるから
(内部用の符号として UTF-32 が優秀なことは承知しているが)
そのへんの規約とか習慣に従うしかしゃーない。
2020/05/01(金) 01:37:06.74ID:/3xCHgCD
出入り口から内部処理まで出来る限りutf-8で統一して処理するのが
トラブルが少なくて済む(個人の感想です)
2020/05/01(金) 02:27:55.90ID:uatxyJey
それは文字列としてだけ扱って文字単位(code point単位)の操作しないときでしょ
あるいは小難しいところは全部ライブラリに投げてるとかね
2020/05/01(金) 07:33:59.06ID:w4TGDP35
>>539
＞たとえば Windows API がいう Unicode は UTF-16 なわけだし、（略）
＞API の呼び出しのときまで毎回変換が入るのも煩雑なんで、
＞UTF-16 に統一した方全体としては楽じゃない？

Windows では UTF-16 を使うといっても、実際に変換しなければならないのは、ファイル名・パス名を扱うときだけですし、
UTF-16 も可変長の部分があって扱いにくいので、私なら UTF-32 で楽したいと考えますね
2020/05/01(金) 08:23:58.09ID:DtDCGOpK
実際にソフト開発したことが無いような書き込みだな
2020/05/01(金) 08:31:51.38ID:NLgIsVNa
UTF-32でも結合文字と異体字セレクタはある
結局ライブラリに投げるでしょ、ならどれでも同じじゃね？
2020/05/01(金) 08:47:44.57ID:sYrLq0eo
マルチプラットフォームのアプリじゃ内部はUTF-8にする場合が多いけどな
なぜならUTF-8にはバイト順問題がないから

どのみち一文字表すのに複数のコードポイントが必要なんだからUTF-8、16、32のどれを使っても言語処理の手間は同じだ
「イングランドの旗」絵文字なんてコードポイントで7要素も必要なんだぜ
546デフォルトの名無しさん
垢版 |
2020/05/01(金) 09:58:16.26ID:k2YlXFh6
マルチコアの高速化と同様に
32bitのCPUで16bitを扱うと2倍速
64bitのCPUで16bitを扱うと4倍速
みたいにならないんですか？
547デフォルトの名無しさん
垢版 |
2020/05/01(金) 10:00:07.33ID:tdkjZBPc
なりますよ。
548デフォルトの名無しさん
垢版 |
2020/05/01(金) 10:02:36.39ID:tdkjZBPc
32ビットと64ビットで二倍の時間になるのではなく、たいてい4倍になりますよ。
2020/05/01(金) 10:13:13.46ID:Ia4c8IgS
文字列関連の処理はだいたいメモリアクセスかIOがボトルネックなので、単純にサイズが　増えればその分遅くなるよ
2020/05/01(金) 10:19:22.16ID:DtDCGOpK
文字処理のほとんどは64bitがいかされない
2020/05/01(金) 10:22:39.64ID:DtDCGOpK
文字処理以外でもそれほど多くない
2020/05/01(金) 13:13:05.71ID:uatxyJey
>>546
simd使えばそれに近づくだろうけど
そうでなければシリアルに計算されるだけなのでほぼ変わらない
大量のデータを処理する場合はメモリ効率の点で速くなるかもしれない
しかしintへの拡大変換が入るので演算自体は遅くなる方向

まぁ自分でベンチとってアセンブラ眺めてみたらいい
かなり環境依存・実装依存なんだから人にきいてもあんまり意味ない
4倍になる人とかいるらしいしw
2020/05/01(金) 13:22:02.62ID:DtDCGOpK
SIMDなら32bit CPUとか64bit CPUとか関係ないし
2020/05/01(金) 14:33:57.85ID:RpLrbaMs
例えばRGBAの計算は早くなるよ
2020/05/01(金) 14:54:56.02ID:8qmJgOle
tclインタプリタに投げる
邪魔くさい
556デフォルトの名無しさん
垢版 |
2020/05/01(金) 15:22:00.38ID:tdkjZBPc
>>552
ベンチとるとおよそ4倍になりますよ。
2020/05/01(金) 16:04:33.87ID:uatxyJey
>>556
そのベンチどっかに貼ってみて
wandboxとか
2020/05/01(金) 16:07:40.19ID:wrmDV0oq
64bitを使っても、大部分のソフトウェアは速くも良くもならない事が知られている。
16bitから32bitの時には急激に多くのメモリが使えるようになって劇的にソフトウェア
が作り易くなったのと対照的。
メモリ容量に関してはたいていのアプリでは32bitでも既に十分。
速度に関してはそもそもCPUが扱えるデータビット数を多くしても滅多に速くならない。
速くなるのはグラフィックで単純なBitBLTを行うような場合のみ。
縮尺や回転が入るだけで64BITの効果は通常、生かせなくなる。
2020/05/01(金) 16:13:27.06ID:DtDCGOpK
>>554
変わった文字列処理だな
2020/05/01(金) 16:15:49.44ID:wrmDV0oq
>>554
RGBA計算も、(SIMDを使わずに)単純にデータバスが64BITになっただけでは速く出来ない。
なぜなら、R,G,B,Aはそれぞれ1バイトだから1バイトずつの計算するしかないため。
SIMDを使う場合は、CPUの種類によっては、SIMD自体のベクトルの要素数が倍になるため、高速化できる可能性はある。
ただしそれは、整数命令が64BIT化されたこととは直接関係ない。
SIMD命令のベクトルの「次元」が上がったかどうかの問題。
2020/05/01(金) 16:18:51.22ID:DtDCGOpK
>>560
なんでわざわざ関係ないことを書いてわざわざ混乱させようとするかなあ
562デフォルトの名無しさん
垢版 |
2020/05/01(金) 16:20:54.72ID:tdkjZBPc
64ビットの演算1回の時間で、32ビットの演算4回出来るんですよ。
2020/05/01(金) 16:22:03.22ID:wrmDV0oq
>>547
なりません。
ならないからこそ、GPGPUのようにマルチコア化が進められています。
SIMD命令も扱いにくいので、マルチコア化が適しています。
例えば、3Dのレイトレーシングなどは、SIMD化することはとても難しい
のですが、マルチコア化は比較的容易です。
人工知能のニューラルネットワークの計算はSIMD化し易い部分もあります。
しかし、300コアなどのマルチコアと、8要素のSIMD命令では、
前者に軍配が上がり易く、しかも、コア数が増えてもプログラムの修正が
ほぼ不要なので、マルチコアの方がSIMDより好まれます。
ただし、命令自体の速度がx86系は速いため、どちらが実際に速いかは
単純ではありませんが。
2020/05/01(金) 16:23:18.73ID:wrmDV0oq
>>562
CPUの一般論としてそんな事実は有りません。
あるなら具体的に書きましょう。
565デフォルトの名無しさん
垢版 |
2020/05/01(金) 16:25:25.15ID:tdkjZBPc
測ると大抵そうなってるというお話です。
2020/05/01(金) 16:33:18.55ID:DtDCGOpK
測定結果みせて
567デフォルトの名無しさん
垢版 |
2020/05/01(金) 16:33:57.33ID:tdkjZBPc
これ最初に気が付いたのは、固定小数点は速いらしいというのを見て、いろいろやってみたら、特に早いことは無くて。
じゃあ何が影響するかというと、単にビット幅だったんですよ。
floatとint32_tは同じ、doubleとint64_tは同じ。
つまり、アキュムレータの性能はあまり関係なくて、バス幅とキャッシュがすべてなんですよ。
じゃあ32ビット2回分が64ビット相当になるかというとそうでもなくて。
たいてい4回分で64ビット相当になるんですね。
2020/05/01(金) 16:37:43.83ID:DtDCGOpK
だから測定結果早くみせて
2020/05/01(金) 16:38:04.32ID:w4TGDP35
>>558
まさか！
2^32 bit 空間が狭すぎる、というのは windows XP の頃から問題になっており、2^64 bit 空間は必然でした

＞メモリ容量に関してはたいていのアプリでは32bitでも既に十分。
個々のアプリ単体ではそうであっても、個々のアプリを複数稼動させる OS では32bit では足りないのでは？
そして 64bit OS に対応した 64bit アプリの存在も必要でしょう
570デフォルトの名無しさん
垢版 |
2020/05/01(金) 16:38:26.67ID:tdkjZBPc
自分で測ってもらえませんかね。
571デフォルトの名無しさん
垢版 |
2020/05/01(金) 16:41:04.33ID:tdkjZBPc
あと、僕はベンチマークのカタログとしてVSのテストエクスプローラ使ってますよ。
テストケースを一つずつ呼び出せるので大変便利です。
2020/05/01(金) 16:42:32.75ID:8qmJgOle
何をして速くなったと言っているのか不明なのに自分でってw
2020/05/01(金) 16:45:05.04ID:uatxyJey
>>570
測るのは自分でやるからベンチのソース見せてよ
比較実験やるにあたって環境も実装も変えたら比較にならないんだしさ
ここで逃げたらかなりださいと思うよ
574デフォルトの名無しさん
垢版 |
2020/05/01(金) 16:46:27.92ID:tdkjZBPc
>>573
そっちが出してくださいよ。
アセンブラ見ると速度がわかる奴。
2020/05/01(金) 16:51:31.85ID:wrmDV0oq
Qz は馬鹿だ。
2020/05/01(金) 16:54:18.57ID:uatxyJey
>>574
やっぱり無理か
そうだと思ってたよ
577デフォルトの名無しさん
垢版 |
2020/05/01(金) 16:57:02.32ID:tdkjZBPc
めんどくさいんですよ。
アセンブラ見れば速度がわかると言ってる時点で、僕は得るもの無いじゃないですか。
何か作業を手伝ってくれるならわかりやすく提示しても良いんですが。
作業を手伝ってもらうのに、色々教えないといけないなら、やっぱりめんどくさい。
2020/05/01(金) 17:00:18.65ID:DtDCGOpK
64bit命令を使うと4倍以上速くなるのは
64bitの乗算くらい

64bit加減算もCPUによっては数倍にはなる

それ以外は特殊な場合のみ
2020/05/01(金) 17:17:48.30ID:9YfMO5iP
intとint64_tで適当なfor分で配列計算やらせてみればわかる。
手元じゃint64_tのが若干遅い
2020/05/01(金) 18:21:10.38ID:wrmDV0oq
>>569
それは当たり前で、マシンには4GB以上のメモリが乗っているので、32BIT
では、OSレベルでは扱いにくい。
多くのプログラマにとって大事なのは、個々のアプリの問題だから、
OSレベルの話は関係ない。、
また、Windows OSがメモリーを食いすぎているという問題もある。
2020/05/01(金) 18:23:48.97ID:wrmDV0oq
>>580
補足すれば、グラフィック用のRAMは大きくなりがちで、最近のWindowsでは、
1つのWindowに仮想VRAMを割り当てているから、アプリが起動するたびに
グラフィック用になかなか大きなメモリーを消費する。
それと、ブラウザで複数のタブを開いている影響。
あれもグラフィックのレンダリング用に大量のメモリーを食っているのかもしれない。
2020/05/01(金) 18:31:06.76ID:IyliQkiG
>>577
他人を説得するつもりがないなら不特定多数が集まる場で自論を展開せず、馬鹿なこと言ってるなフフッて一人悦に入ってればいいんでない？
2020/05/01(金) 18:32:39.35ID:IyliQkiG
>>575
全面的に同意
2020/05/01(金) 18:40:33.09ID:DtDCGOpK
>>575
私も同意
2020/05/01(金) 19:15:32.79ID:wrmDV0oq
>>580
今は、見えないものまで含めれば50個のプロセスが動いているなんてことは当たり前になっている。
だから、個々のプロセスが80MBのメモリしか使って無くても、合計すれば4GBになる。
さらにファイルバッファや、OSが高速化のためにさまざまなキャッシュ的なデータを保持している。
しかも、ファイルバッファやキャッシュはいくらあっても不足する時代となった。
ブラウザがページを記録するためのキャッシュも必要だ。
そういう訳で、アプリが80MBしか使って無くても、OS全体では4GBではメモリが不足する。
というわけで、4GBを超えるメモリが必要となっている。
タスクマネージャーで見ていても、個々のアプリは、多くても数百MB程度のものが多い。
ファイル高速検索ツールなんかが、1.6GBも使っていたりするが、それは特殊。
だから「特殊なものを除いては」今のアプリが2GBを超えるメモリーを必要とすることは稀、だと言っている。
2020/05/01(金) 19:19:38.83ID:DtDCGOpK
それ
64bitで4倍
とどういう関係？
2020/05/01(金) 19:22:30.31ID:DtDCGOpK
32bit Windowsが4GBまでなのはWindowsの仕様であってCPU自体はそんな縛りは無いし
2020/05/01(金) 19:51:53.68ID:wrmDV0oq
>>587
典型的には、32BIT mode でも、PAE サポートによって OS は 4GB を超える
メモリーを扱えるね。
2020/05/01(金) 20:58:17.99ID:9yUywlA0
64GBまで使えるようになったのPentium Proからだぜ？ｗ
Klamathより前！！
2020/05/02(土) 00:04:20.13ID:jVHOaTi/
>>547
釣り針でかいなw ここム板だぜw
2020/05/02(土) 00:05:14.57ID:jVHOaTi/
>>587
おまえ嘘ばかりだなw
2020/05/02(土) 01:38:26.25ID:2lkgjmOV
>>591
いや、彼は正しいことを言っている。
あなたがIntel CPUの仕様を詳しく知らないだけ。
PAEという仕組みなどで32BITモードでも4GBを超える物理メモリーを扱うことができるようになっていた。
593デフォルトの名無しさん
垢版 |
2020/05/02(土) 01:45:40.91ID:ZXOrLboX
PAEが何なのか全く分かってなさそう
2020/05/02(土) 02:28:22.28ID:2lkgjmOV
QZは女なのだろうか。
ショックかも知れないがはっきり言えば、本質的に物事が正確に理解できていないようだ。
2020/05/03(日) 09:20:54.04ID:slLa0KBW
EMSなら前に聞いたことがある
2020/05/03(日) 09:24:35.32ID:WVD/IFzz
8bit CPUは256Bしか扱えないと思ってる人いる？
2020/05/03(日) 09:29:47.71ID:6v/wuiGx
16bitのCPUでも16bitアドレスの最大値である64KBを超えて1MBもアクセスできていたからな。
2020/05/03(日) 10:03:25.11ID:WVD/IFzz
>>594
女なら180度対応を変えます
2020/05/03(日) 10:22:47.73ID:LxtsyLet
>>597
16BIT CPU であった 8086は、16bit アドレスを超える範囲は、セグメントレジスタ
と合わせた seg:ofs の形式の far pointer を使わなくてはならならず、
単純に扱えるのは16BITまでで、16BITを超えた範囲では、seg レジスタの値を
足していかないといけなかった。しかも、segがアドレスの上位16BITだったなら
まだしも、16バイト単位のアドレスだったので、segレジスタに入れる値を計算
するのがとても重くなってしまっていた。
ところが、Z80 などの 8BIT CPUは、普通に 16BIT レジスタの
HL や DE, BC, IX, IY をもっており、8086 と比べれば扱いは容易だった。
その意味では、8086は、メモリーアクセスに関してはZ80と同じくらいしか
能力を持っていなかった。
それで8086の16BITモードでは限界が来て32BITモードのOSが待望された。
そしてMacのGUIを真似た機能を持っていたこととも合わせて32BITモードで
動いたWin95となった。

ただし、このような状況は64BIT化に関しては全く無い。
2020/05/03(日) 10:32:19.81ID:6v/wuiGx
そりゃまあ、64bitCPUがすでにいきわたっていてOS変えるだけで対応できたからね
WINAPIだって16→32のコンパイルはまず動かないけど32→64なら普通は動く
DOS時代のUMBみたいなみみっちい事態にならなくてよかったじゃん
2020/05/03(日) 10:35:22.17ID:OJMdC3Cv
86用コンパイラでnearとfarの他にhugeが有ると知らず、無限ループ作ってOSごと来なくなったあの頃
2020/05/03(日) 11:16:28.83ID:WVD/IFzz
結局64bit CPUだと速度4倍のコードは？
2020/05/03(日) 13:08:16.85ID:m/iHOjCC
long longとint64_tの違いってlong longは環境によって64bitじゃなくなるけどint64_tは常に64ってことですか？
2020/05/03(日) 13:13:36.85ID:LxtsyLet
>>603
まあ、そういうこと。
2020/05/03(日) 14:04:07.52ID:slLa0KBW
　　　　　　　　　　　|
　　　　　　　　　 　 |　　彡⌒ミ
　　　　　　　　　　　＼ (´･ω･`)　またhugeの話してる・・・
　　　　　　　　　　　　　(|　　　|)::::
　　　　　　　　　　　　 　(γ　/:::::::
　　　　　　　　　　　　　　 し ＼:::
　　　　　　　　　　　　　　　　　 ＼
2020/05/03(日) 14:24:10.29ID:m/iHOjCC
>>604
ありがとうございます
2020/05/03(日) 15:56:11.79ID:gvP0MmQx
32bitの環境で32bitの境界を超えるような64bit値の計算ってどうやって実現してるの？
2020/05/03(日) 16:00:56.90ID:uzK0zokK
cpuに命令なければソフト的にやるに決まってんじゃん
2020/05/03(日) 16:06:34.35ID:uzK0zokK
ちなみに32bitの掛け算の答えに64bit必要ってわかってない人多いよね
同様に64bitなら128bit
610843
垢版 |
2020/05/03(日) 16:22:11.00ID:OGvyQUVV
>>607
まずは筆算の足し算からやり直そうか
2020/05/03(日) 16:54:49.03ID:+PpSUNNp
64bitだとdoubleとかの書き込みはアトミックになるの
612デフォルトの名無しさん
垢版 |
2020/05/03(日) 17:17:29.21ID:VkK7EFZv
C/C++にキャリーフラグ観る機能が無いのはなせ？
2020/05/03(日) 17:56:41.69ID:baOIQvWk
アトミックにしたけりゃstd::atomicを使え
使わない場合は保証されない
2020/05/03(日) 18:16:14.79ID:uzK0zokK
>>612
いれるとしたらどんな仕様でいれる？
そこまで考えてから書いてみたんだよな？
2020/05/03(日) 18:19:51.49ID:uzK0zokK
>>613
64bitでない環境だとatomic持ち出したところで使えないじゃん
2020/05/03(日) 18:25:40.26ID:baOIQvWk
使えるぞ
内部でロックするから遅いけど
2020/05/03(日) 20:09:19.86ID:7Ft0FuY4
>>598
90度だろ？
2020/05/03(日) 20:16:01.21ID:s7MuzCvB
モダンc++入門ってどこみたらいい？
2020/05/03(日) 21:01:49.43ID:0Fr9Yznx
cpprefjp
2020/05/03(日) 22:43:31.73ID:WVD/IFzz
>>611
ほとんどの環境でYES
32bit CPUでもアトミックな環境もある
2020/05/03(日) 22:46:00.66ID:WVD/IFzz
>>612
キャリーフラグが無いCPUも有るから
CPU固有の機能はintrinsicを使う
2020/05/03(日) 22:52:17.09ID:WVD/IFzz
>>609
整数の乗算を全範囲正確に求めたい場合の話だな
これもC++では書けない
intrinsicを使う
2020/05/03(日) 22:53:53.78ID:WVD/IFzz
>>617
なんで90度？
180度だって書いてるのに
2020/05/04(月) 03:33:26.41ID:BnrivxPo
int128でもint256でも自由に型が作れるのがC++の強みなのに書けないってw
2020/05/04(月) 06:12:26.01ID:/zUHO7E0
int_<256>みたいの作ってたけど
サイズが発散する問題がすぐ起きる
626843
垢版 |
2020/05/04(月) 07:19:32.37ID:oxprEh+7
>>620
> 32bit CPUでもアトミックな環境もある
具体的な環境名教えて
627843
垢版 |
2020/05/04(月) 07:20:47.92ID:MJc5y26W
>>623
（女は）話をはぐらかすって事だろ
2020/05/04(月) 07:22:03.70ID:nMCshN11
x86
2020/05/04(月) 08:03:18.75ID:S2aUUuq2
shared_ptr<Hoge>をvoid *の領域に格納したいのですがどうすればいいでしょうか？
SetPointer(void *),void* GetPointer()で設定します
shared_ptr<Hoge> hoge
として
SetPointer(hoge)

取り出す時
shared_ptr<Hoge> hoge = GetPointer()
2020/05/04(月) 08:04:47.44ID:S2aUUuq2
後、SetPointerする前にshared_ptrの参照カウントを一つ増やしたいです。
2020/05/04(月) 09:54:06.17ID:Fiop0J3e
>>629-630
所有権込みで格納したいだけなら。
SetPointer(new shared_ptr<Hoge>(hoge));
shared_ptr<Hoge> hoge = *static_cast<shared_ptr<Hoge>*>(GetPointer());
あとはどうにか delete が抜けないようにする。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況