C++相談室 part150
■ このスレッドは過去ログ倉庫に格納されています
>>455-456
事例としては
例1： 使い捨てスクリプト
その程度の管理で良い。
ガッと動かしてそのまま終わるので管理もクソもない。
例2： サービスの変更が多いウェブサービス
まずは早期に動かすことが大事。
細けぇことは後でプロファイラを見ながらなんとかする。 >自動化されてるんだから手を出しちゃダメ
ﾊｱｗｗｗｗ？
コードで明示的にマークも出来ますが何かｗｗｗｗｗｗｗｗ
>あげく解放されませんでした、解放されてるかどうか確認をせよ
ﾊｱｗｗｗｗｗｗｗｗｗ？
>>456は不具合を発見してから不具合がないか確認するタイプ？ｗｗｗｗｗｗｗｗｗｗｗｗ >>457
テキトーこきたいって正直に言ってくれれば
こっちもあっそーで済む
>>458
明示的にマークという時点でGCの敗北なんだよ
仕事でもそうだろ、引き受けたことをやってくれないやつは
もう信用されない できねえことは端っから引き受けるな
おまえさん、ぬるま湯に浸かってる人かい？ 「資源の解放はお任せくださいっ！！(ｷﾘｯ
「あのー循環参照が・・・
「メモリーだけです！！（汗
「資源じゃなかったんですか？
「そのくらい察して下さい！！（滝汗
「もういいです 仕事でしゃーなしに使う言語あるいは
知ったかしたいアマチュアが使う言語、それがC++ 仕事で喜んで使う言語だな
c#とかjavaとかだと嫌になる >>462
java は、少なくとも昔の java は、厳しく抑制のきいた文法と豊富なクラスライブラリでいい感じだと思いますよ、文法は意味があっての簡素なほうが好みですね
c# は、クラスライブラリの全容を把握していないので、まだ評価にとりかかれないのですが、これからじっくり調べたいと思っています Javaは新しいCOBOLになってしまった
当初の理想は良かったと思うけどままならんもんだね >>461
シッタカにいつもマウント取られる水準のやつからは、そう見えるだろうな まともにコンパイルも通してないで知ったかしてるバカに言えることなんてないけどね。 >>459
gcの勝ち負けなんか論じてないだろ
話すり替えて誤魔化すな
お前態度でかいわりに理解が周回遅れなんだよ >>467
俺も論じてないんだがｗ
何が怪物に見えたのかな？ 病院行ったほうがいいと思うぞ なんで
long long abs(long long x)
なんだろうか
負の数の方が絶対値の大きい値が表せちゃうのに 0x8000000000000000 代入してみろ long longでないとすると、何型が妥当だと思う？ >>465
このスレで知ったかの相手すると荒れるから、大抵中身の無いマウントカキコはスルーされてるんだが つまり、こういうことか
template <typename T>
auto abs(T val) -> enable_if_t<is_integral_v<T>, make_unsigned_t<T>>; singedとunsigned混在すんなってことだよ
c言語レベルの質問はc言語スレでやれ
というか語りつくされた話題だから適当にググれ 背伸びしたい無職が使う言語は
C++かHaskellと相場が決まっとる C++14(gcc)でUTF8の正規化をする場合、どんなやり方が良いとされているのかご教示ください。
C++ではやったことがないので初歩的なところからご教示いただけるとありがたいです。
・ICU以外の選択肢はあるのか？
・ICUを使う場合、直接APIを使うよりBoost.localeを使った方が良いのか？ >>477
文字コードスレできいたら？
icuで足りるんならicuでいいと思うけど
自分の経験ではicuのでかくて重いのが問題だったらから
必要な機能だけ自作したな
(unicodeがリリースしてるテストデータをパスさせた) 普通はc++だろ
javaとかc#とか環境整えるの面倒くさいじゃん >>476
Cはかつて最大人気言語だった歴史があるのに対し、HaskelやRustはそうではない。
C++もCの人気を受け継いだ言語だし、処理速度が高速でメモリー使用量も少なく、
起動も速いし、Windows以外でもとても広いプラットフォームで簡単に動くのだから、
使うのは自然な流れだし、背伸びとかではない。
例えば、C#をAndroid/iOS/Linux/Macで動かすのは容易ではない。
Wasmで動かすにもネットからのダウンロード量が多くなり起動が遅くなる。
一方、C++ならWasmでも起動が速い。 >>483
C++を動かすのはOS以外に基本的に特殊なランタイムが要らない。
C#やJavaでは.NET環境やJVMが必要となる。
AndroidでもJNIを使えばC/C++は起動も速く動作速度もJava/Kotlin以上に軽快に動く。
同様にiOSでも、Swiftとリンクできるので同様。
逆にC#は、iOSやAndroidで動かすにはダウンロード時間や起動速度に問題があり、
動作速度にも desktop マシン以上に問題がある。
Androidだと、Java/Kotlinの仮想マシンの上に、.NETの仮想マシンを二重に載せる
形となるため、C/C++と比べれば、掛け算の形で遅くなってしまう。 例外やRTTIをイネーブルしてるとでかいスタティックリンクつくけどね CならRAM16バイトのPIC10F200でも使える >>486
ソースコードの見た目とバイナリのサイズがCと違いすぎって意味 Arduinoで使ってること考えたら、十分使える。
RAM2KBしかない。 >>485
スタティックリンクってどのライブラリをリンクするってこと？
そんなのあったっけ？ >>485
.NET環境は、それどころじゃない。
それはWindows Updateを見ていれば分かる。
.NETのUpdateのために、数百MB〜数GBダウンロードされる。 >>479
自作はやりたくないのでICUを軸に色々試してみることにします。
ありがとうございました。 >>494
gcc のオプションに -static を加えればいいのでは？ >>498
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Link-Options.html#Link-Options
-static
On systems that support dynamic linking, this overrides -pie and prevents linking with the shared libraries. >>499
流れを読め。 >>485 みたいな状況でバイナリがデカくなる→何がスタティックリンクされるんや？ って話題だぞ。 マップファイルを出力させてみれば実際に何がリンクされるかはわかるんちゃう？
試してないけど。 libgccの大きさじゃなくてunwind用のハンドラコードの増加じゃないの？
(間違って別スレに書いてしまった) >>503
RTTI の場合は、仮想テーブルと同様の場所に、実行時型情報へのリンクポインタが
書き込まれるようになる。
それがなかなか複雑な構造をしている。
RTTI情報も、ヘッダファイルの中に構造体が書いてあると、COMDAT形式で
全ての *.obj ファイルの中にいったん書きこまれることがある。
リンク段階で同じデータのsectionがある場合は、単一のsectionだけを残して
他は削除されてしまうが。 >>504
構造化例外もなかなか複雑なコードになる。
そのコードもある程度の大きさになる。 >>484
mono、core、zamarin調べて出直してこい enum class を1オリジンにするスタイルはどの程度使われていますか？ char8_tってどういう経緯で採択されたんですか？
Microsoftを利する提案が受け入れられるのは相当珍しいと思いますが。 >>508
色々と事情はあるみたいなんだけど、
UTF-8 の文字列と従来の文字列を型で区別したいというのが主な理由だと思う。 その要望は昔からあるけど阻止してきたのに、なぜ解禁されたのか事情知りませんか？ >>510
江添亮のブログで関連する提案や議論が取り上げられているので順番に読んでみたらいいと思う。
https://cpplover.blogspot.com/search?q=char8_t
具体的にこれが理由と言えるひとつの理由があるわけではないけど、
やってみたらやっぱ要るわ……という雰囲気っぽいかな。
要するに文字列をナメてたんだろう。 charにutf8突っ込むだけでunicode対応できるとか考えるやつがようやく淘汰されてきてありがたい そもそも「Microsoftを利する提案」てなんだよ
C++は別にアンチMSじゃないだろ std::size(u8"あいうえお" - 1)みたいな感じですかね。 std::u8stringとかC++は規格に出すのが遅い >>514
W3CもアンチMicrosoftではないのだけど、会員がIT業界の人たちなので、結局のところ、如何にしてMicrosoftを落とすか討論する場所になってました。 >>508
どう利するわけ？
windowsの中はutf8じゃないよ >>519
>>508がアンチMicrosoftなだけじゃないかな enum class とか、MS起源の機能なんていくらでもあるんだけどな >>504
そのあたりも増加原因になるのはわかる
でもどちらにしろlibgccのリンクとは無関係では？ >>512
下のみたいなノイズだらけのクソブログを挙げるな
もっとマシなのあるだろ そうかな
utf8をコア仕様にいれたら「文字とは何かを理解する」ってのは
ちょっと同意できないな constexprがあるので、エンコーディングを型に組み込んでしまっても、困ることは全くない。
C++のお作法になじんでいれば、お得な事しかない。 UTF8ベースにしたらどうやって1文字ずつ処理するの？めんどくさい？ >>512
下のサイト的に言えば、誰もが
固定長に数値が収まるという夢を見た愚か者たち
なので、必要悪な気はするな >>531
code point単位なら結局utf32にして数える(部分的に可能)
面倒なのはgrapheme clusterから上
もう土方レベルが扱える代物じゃないね 内部では utf-32 ベースで処理して、出口入り口で utf-8 に／から変換するものだと思いますが… >>528
リッチーならともかくカーニハンは見てる可能性 >>535
色んな文字コード (符号化) を扱うときは出入口で変換する方法は妥当な選択だと思うけど、
UTF-32 を中心に据えるのが良いかは一概に言えるものでもないでしょ。
たとえば Windows API がいう Unicode は UTF-16 なわけだし、
外部とのデータのやりとりで内部用の符号に変換する処理が入るのは仕方がないにしても
API の呼び出しのときまで毎回変換が入るのも煩雑なんで、
UTF-16 に統一した方全体としては楽じゃない？
サロゲートペアの扱いが面倒くせぇとかいうのと天秤にかけたとしても
Windows では UTF-16 から離れられない。
結局のところ実行環境とかフレームワークとかの都合に縛られるから
(内部用の符号として UTF-32 が優秀なことは承知しているが)
そのへんの規約とか習慣に従うしかしゃーない。 出入り口から内部処理まで出来る限りutf-8で統一して処理するのが
トラブルが少なくて済む(個人の感想です) それは文字列としてだけ扱って文字単位(code point単位)の操作しないときでしょ
あるいは小難しいところは全部ライブラリに投げてるとかね >>539
＞たとえば Windows API がいう Unicode は UTF-16 なわけだし、（略）
＞API の呼び出しのときまで毎回変換が入るのも煩雑なんで、
＞UTF-16 に統一した方全体としては楽じゃない？
Windows では UTF-16 を使うといっても、実際に変換しなければならないのは、ファイル名・パス名を扱うときだけですし、
UTF-16 も可変長の部分があって扱いにくいので、私なら UTF-32 で楽したいと考えますね UTF-32でも結合文字と異体字セレクタはある
結局ライブラリに投げるでしょ、ならどれでも同じじゃね？ マルチプラットフォームのアプリじゃ内部はUTF-8にする場合が多いけどな
なぜならUTF-8にはバイト順問題がないから
どのみち一文字表すのに複数のコードポイントが必要なんだからUTF-8、16、32のどれを使っても言語処理の手間は同じだ
「イングランドの旗」絵文字なんてコードポイントで7要素も必要なんだぜ マルチコアの高速化と同様に
32bitのCPUで16bitを扱うと2倍速
64bitのCPUで16bitを扱うと4倍速
みたいにならないんですか？ 32ビットと64ビットで二倍の時間になるのではなく、たいてい4倍になりますよ。 文字列関連の処理はだいたいメモリアクセスかIOがボトルネックなので、単純にサイズが 増えればその分遅くなるよ >>546
simd使えばそれに近づくだろうけど
そうでなければシリアルに計算されるだけなのでほぼ変わらない
大量のデータを処理する場合はメモリ効率の点で速くなるかもしれない
しかしintへの拡大変換が入るので演算自体は遅くなる方向
まぁ自分でベンチとってアセンブラ眺めてみたらいい
かなり環境依存・実装依存なんだから人にきいてもあんまり意味ない
4倍になる人とかいるらしいしw SIMDなら32bit CPUとか64bit CPUとか関係ないし ■ このスレッドは過去ログ倉庫に格納されています
