Ukicode@Mastodon優先

いやまぁ確かにGPTはプライマリヘッダかバックアップヘッダのどちらかが正常であれば動きはするのだが、なかなかに攻めたことしてるなと。安全に作るんだったら、ループバックデバイス作ってパーティション構成して、データを書くなりしたほうが良いと思うのだが・・・

某OSのインストールイメージ、複数のパーティションで構成されてるはずなのにパーティションがない状態なのはなんでだろうと思ってgdiskで見てみたら、バックアップヘッダがない状態で作られてることがわかった。 どういうことなの・・・

Windows11、WindowsOSの法則に漏れずやはりク〇OSなんだなと。
OSイメージすらまともに書けない

Funky! カーネルパニック、2！

流行にちょっとだけ敏感なLinux君「APT APT　APT APT　APT APT　Uh Uh-huh Uh-huh」

ZigはC++をも現代風にしたって書いたけど、Zigの場合は自動メモリ管理をサポートしない(スマートポインタがない)ので、C++っぽくはない。訂正しておく

俺の認識に間違いがなければ、安全性と処理速度に対して中間的な立場を取っているのがGoで、Goの場合はスコープ内で完結できていたらC, C++の間接アクセスと同等になる(はず)けど、スコープ内で完結できなければ、GCを使うようになっている(はず)。
Zigも挙げられてたけど、Zigは、C, C++を現代風にした言語(ただしメモリ安全ではない)という感じ

Rustの所有権の一番のメリットは、GCによる実行時オーバーヘッドをなくし、安全にしたうえで処理速度が高速なプログラムを作ることを可能とする点にある。
だから、パフォーマンスを意識しない人にとっては、あまりありがたみを感じないのよね。ハッキリ言って

たとえばTypeScriptでクロージャで自由変数を閉じるっていう有名なパターンがあると思うんだけど、あれってC, C++でやろうとすると危ないんだよね。
なぜなら、普通はダングリングポインタになって未定義動作になりかねないから。
しかし、TypeScriptだとこれは起こらない。なぜならGCによって安全にメモリアクセスできるようになってるからだ。
Rustだと、これはコンパイルエラーとなる。だから所有権を奪うなりRcを使うなりする必要があるわけ

Rustが嫌いです。

一応、俺もRustに関しては中立的なスタンスでいる所存だけど、一つだけ確かなことは、TypeScriptやPythonは所有権以外で安全を保証している言語だから、パフォーマンスを意識しなければあまりありがたみはわからないかも / “Rustが嫌いです。” htn.to/2PabMdeetL

まぁカーネルコンフィグを変更する場合、結局ソースコードが必要になるわけだけど、もしすでに有効化されていたならば、ソースコードを持ってくる必要がなくなるのでそういう場合に効果的だと思われる

Linuxのカーネルコンフィグを確認するためには、わざわざソースコードを確認する必要があると今までは思っていたが、ソースコードがなくても確認できる方法があるみたい。
まぁ、menuconfig使ったほうが圧倒的に見やすいけどな・・・

なんでTypeScriptが生まれたの？
=> JavaScriptがヤバすぎるから

なんでReactが生まれたの？
=> JavaScriptがヤバすぎるから

なんであなたはJavaScriptを嫌ってるの？

=> JavaScriptがヤバすぎるから

あなたが誤解しているRustの「安全」について - なんか考えてることとか 最近(2024/1/18現在)、チェスプログラムの評価を通して、Rustをボロクソに叩いた記事がZennに投稿された。 zenn.dev Rustはデバックモードでのスタックサイズが限られていて、これが非常に愚かだ。 安全な言語なのにスタックサイズに制限がある事は愚かだ。 こんな事を書いたら、後からクレームのコメントがバンバン来るだろうなとは思ってますが、この動画で私が共感したのは、Rustは糞だ...

Rustの「安全」について、ボロクソに叩かれた記事が出たので、Rustの「安全」について、俺が認識していることを書いた

はてなブログに投稿しました
あなたが誤解しているRustの「安全」について - なんか考えてることとか opaupafz2.hatenablog.com/entry/2025/0...
#はてなブログ

RustのSend/Sync、ごく一部の型にだけ実装されているのではなくて、むしろ逆で、ほぼすべての型がSend/Syncで、ごく一部の型がそうではないという感じなのねと思うなど

Member Detection使っても良さそうだけど、Member Detectionだと穴がありそうで、この方法だと確実にoptionalであることが保証されるから、安心できると思う

optionalはクラステンプレートなので、自前で作るのもなかなか面倒だが、is_optionalを自前で作っても良さそう

C++で戻り値をoptional<T>に限定したいとき、template <typename T> optional<T> f()とかだとテンプレートパラメータの明示が必要になってしまうので、template <typename T> auto f()として、戻り値の型decltype(f())とoptional<remove_reference_t<decltype(declval<decltype(f())>().value())>>が同型であるかチェックすれば同じことを実現できた

どうでも良いけど、個人的に難しすぎる案件が片付きそうでようやく一息つけそう。ドキュメントがほんっとうになくてめちゃくちゃ苦戦したが、何とかなった

GCCだけかもしれないが、C++で実行時じゃないとサイズがわからない配列がある場合、VLAを使うよりも、std::vectorを使うほうが圧倒的に高いパフォーマンスを得られるので、VLAは使うべきではない(というか、C++標準にはない機能なのでそもそも使うべきではない)。
まぁ、std::vectorのほうがファイルサイズが若干増えるということも確かなようだが

要約すると、未定義動作というのは、「やらなければならない」または「やってはならない」を破った結果だということだ。つまり、「やっても良い」ではなく、文字通り「やってはいけない」んだよな

> If a "shall" or "shall not" requirement that appears outside of a constraint or runtime-constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this document by the words "undefined behavior" or by the omission of any explicit definition of behavior.

未定義動作を書いても良い！とか言っている奴。
C標準規格には、こう書いてある

つまり、何が言いたいかと言うと・・・

処理が高速になることを祈って未定義動作コードを故意的に書くんじゃねえってことだ

未定義動作コードというのは、「こう動作する」という確実なものはなくて、コンパイラが「PCを爆発させるコード」にコンパイルしてもC, C++の標準からは外れない。
C, C++とはそういう言語だ

過度で無意味なセキュリティ対策ほど害悪なものはない。それが効果のあるセキュリティ対策ならまだしも、時代遅れで、むしろ逆効果なものを、とりあえず導入しようとしている。はっきり言って時間の無駄でしかない

std::chrono::trigger;

実体化していないから、未定義扱いになるっていうのは、理屈としてはわかるんだけど、どうにかならんかったのかこの仕様。
特に、ヘッダに全部実装するとなると、定義だけであれば不要なincludeも必要になってしまう可能性が出てくるので、モジュール結合度の観点から良くない

ほかの方法だと、明示的実体化をして、共有ライブラリにして動的リンクをする方法がある。
ただこれはMakefileで書くには面倒くさかった記憶がある

C++ヘッダファイルのテンプレートの仕様ヤバすぎる。定義と実装を分けたいだけなのに、普通にやろうとすると、未定義扱いになる。だから、簡単にこれを解決したい場合はヘッダファイルに実装も全部書く必要がある。
単なるコンパイラだと、実行するまでわからないが、Makefileだとリンクもチェックしてくれるので、止まる。シンプルなCはまだ良いが、C++はMakefile必須ですな