26/03/18 22:53:15.63 Pr3hbF5X.net
uint8_tの要素数が3のRGBもYUVも区別できなくて問題ないって人かあ。
750:デフォルトの名無しさん
26/03/18 22:54:00.17 IinJ/Cgw.net
ラッピングは型安全性やカプセル化のためプログラミングの常識だが
今回の問題では一切関係がない
ラッピングすることなくそのまま成立する
751:デフォルトの名無しさん
26/03/18 22:56:26.00 IinJ/Cgw.net
無関係なラッピングを持ち出しそれに固執していることからも本質を理解できていないとみえる
752:デフォルトの名無しさん
26/03/18 22:58:23.97 Pr3hbF5X.net
「そんなクソな書き方しねぇよ」という話が理解できない人いんのねｗ
753:デフォルトの名無しさん
26/03/18 23:05:39.64 3L+0H3qv.net
今回ラッピングなんかはどうでもよくて根本の話は>>742だよね
可変長ならば先頭アドレスと長さをセットで持たなければならない
固定長ならば先頭アドレスのみ持てばよくて長さは型情報として持つべきである
754:デフォルトの名無しさん
26/03/18 23:55:36.84 LfUPYerJ.net
ID:IinJ/Cgwはashworthかな
755:デフォルトの名無しさん
26/03/19 00:25:10.98 1fNhLbVo.net
そこは各型のデータが持つ情報により3つに分かれる
①アドレスのみ
②アドレスと有効長
③アドレスと有効長と容量
①は単体もしくは固定長の連続体
②は可変長の連続体
③は可変長の連続体で伸縮可
①の連続体の場合はその固定長の情報は型に含まれるため受け渡しする必要がない
記事『配列ポインタ型でサイズ安全な関数引数を実現する』が述べているのはそういうことで正しいが説明不足だな
756:デフォルトの名無しさん
26/03/19 02:07:19.07 /Wzj236o.net
『C言語の標準ライブラリを自作して学ぶ、安全なメモリ管理と文字列操作の真髄』
URLﾘﾝｸ(qiita.com)
オーバーフローチェックは重要、みたいなこと書いてるのに
> // 実データの前に size_t 分のヘッダ領域を確保
> block = malloc(sizeof(size_t) + size);
冒頭のコードでオーバーフロー無視してるのはなあ、無能すぎね? つか42tokyoかあ。
757:デフォルトの名無しさん
26/03/19 03:59:02.73 r1H5OpTt.net
>>756
これで満足か？
#include <stdckdint.h>
size_t total_size{};
if (!ckd_add(&total_size, sizeof(size_t), size)) {
block = malloc(total_size);
}
758:デフォルトの名無しさん
26/03/19 04:38:33.92 MpYhWP5O.net
>>757
？
759:デフォルトの名無しさん
26/03/19 07:10:42.84 uGXjP4fl.net
C23でようやく標準化されたオーバーフローチェックなんて99%のプログラマーが今後も知らないままだろう
標準化があまりにも遅すぎた
C++23の新機能も同じだ
みんな知らない学習する気もない使う気もない広まらない
760:デフォルトの名無しさん
26/03/19 11:36:28.97 TvMFZsLL.net
>>757
> これで満足か？
その記事のおかしいとこそこだけだと思った?
761:デフォルトの名無しさん
26/03/19 19:51:52.27 qPkzmLAQ.net
>>759 expectedが追加されてるけど、例外使いまってる既存資産から置き換えも考えずらいし、新規で使うにも別にC++じゃなくても良くね？な型。
762:デフォルトの名無しさん
26/03/19 22:45:04.98 UtYRo7C2.net
CとC++の標準拡張が連携とれてないよな
この言語はもうダメだ
763:デフォルトの名無しさん
26/03/20 13:02:52.79 iXoBkJ/Y.net
>>762
言語は思考を規定する
764:デフォルトの名無しさん
26/03/21 13:52:48.74 JUJDvVUv.net
>>756
> C言語を学び始めると、標準ライブラリ（stdio.h, stdlib.h, string.hなど）の便利さに気づきます。しかし、その内部で何が起きているのかを意識することは少ないかもしれません。
>
> そこで私は、C言語の標準関数のゼロから再実装に取り組みました。
とか言っててft_mallocの実装mallocのラッパーになっててｸｿﾜﾛﾀｗ
> 1. メモリブロックへの「メタデータ」埋め込みによる ft_realloc の実装
glibcならmalloc_usable_sizeでメモリーブロックのサイズ取得できるのに車輪の再発明だなあ。将来的にmalloc部分も自作するとしてメモリーブロックのサイズはどっかに格納すんだしmalloc使ってるならmalloc_usable_size使うで良かろう。
ft_reallocもメモリーブロック再割り当て必要ない場合も常に新しいメモリーブロック割り当てるし第1引数にNULL渡された場合も考慮されてないなあ。
よくこんな記事スクール名誇らしげに明記しながら公開するもんだわｗ
765:デフォルトの名無しさん
26/03/22 02:13:38.55 wZUeCGG3.net
> これで満足か？
>
> #include <stdckdint.h>
> size_t total_size{};
> if (!ckd_add(&total_size, sizeof(size_t), size)) {
> block = malloc(total_size);
> }
記事主のレベルに合わせて
if (size > SIZE_MAX - sizeof(size_t)) return NULL;
で良くね?
766:デフォルトの名無しさん
26/03/23 10:23:25.58 sxw8l0ML.net
>>757
> 2. 線形リストの動的管理と「ポインタのポインタ」の威力
> ポイント：
> なぜ t_list ** なのか？
なんて書いてるけど、理解がハンパだからft_lstadd_backの実装クソダサいことになってるなｗ
767:デフォルトの名無しさん
26/03/23 10:33:36.87 1OOhD5jZ.net
>>766
レス先が間違ってるのか何の話やらさっぱりわからん
768:デフォルトの名無しさん
26/03/23 11:05:37.27 sxw8l0ML.net
誤)>>757
正)>>756
769:デフォルトの名無しさん
26/03/27 13:58:58.93 /DnZZ8sW.net
文字種による組み合わせの数
ASCII文字列に限定して組み合わせの数を考えてみることにします。
アルファベット大文字: 26 アルファベット小文字: 26 数字: 10 記号(印字可能な記号類): 32 使える文字種は 94種類となります。
これらを使って 4桁のパスワードを作る場合の組み合わせの総数は*通りあります。
しかし「大文字・小文字・数字・記号を必ず1つずつ含む」という条件を課した場合には、
各文字から1文字ずつ抜き出した組み合わせの並び替えを考慮して*通りになります。
見た目は「複雑さが増した」ように思えても、実際には総当たりに必要な総数は15分の1に減少してしまいます。
NIST SP800-63の草稿を書いた ビル・バー(Bill Burr)氏6はウォール・ストリート・ジャーナルのインタビューに対して
「今では自分がしたことを後悔している」と述べ、英大文字・小文字・数字等の複雑な組み合わせを提言したことを悔いています。