Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
上下前次1-新
738: 03/17(火)11:34 ID:VXykxZTj(1) AAS
>>732
あほやん
これでも良いけどさ→(*buf)[i] = (uint8_t)0x00U; /* ポインタを一段デリファレンスしてからアクセス */
これと等価やで→buf[0][i] = (uint8_t)0x00U;
蛇足→0[buf][i] = (uint8_t)0x00U;
しかも結局buf[1][i]とかにもアクセス出来るので根本的な解決になってない
739: 03/17(火)11:55 ID:TEC35O2v(1) AAS
実行効率も落ちるんじゃね
740: 03/17(火)20:41 ID:pIcpFrGA(1) AAS
>>736
それは悪手
741: 03/18(水)13:05 ID:cAhzJBL5(1) AAS
>>732 が本気で便利なら40年50年あるCの歴史でそのやり方が主流にならないはずがない
「フツー構造体」は違うかも試練が「不便な方法」は同意
742(2): 03/18(水)13:49 ID:LfUPYerJ(1/2) AAS
記事主がコメント欄で
＞＞特定の要素数を前提とする場面なら struct が手っ取り早いような気がしますが，どうなんでしょう？
＞
＞ご指摘の通り、自分の触っているコードベース上でも struct でサイズと buf をセットで持たせる設計が一般的で、筆者自身もそちらを採用することがほとんどです。本記事は「素の配列をそのまま渡す設計を採用した場面で、型にサイズ情報を持たせる手段がある」という紹介にとどまるものでした。ちょっと自分の書き方が一般的と誤解させるような内容になってしまいました。気をつけます。mm
と書いてる通り一般的方法ではないんだけど>>735みたいのもいるのは世の中広いなｗ
743: 03/18(水)15:00 ID:zkfG4cW3(1) AAS
配列の配列
配列のポインタ
であればどちらも一般的な訳で
744: 03/18(水)15:14 ID:Np+iCs7f(1) AAS
>>742
それは二つの違いをわかっていない
その「struct でサイズと buf をセットで持たせる設計」はファットポインタ
つまりアドレスと長さの両方を持つことで可変長のものを受け渡しする方法
一方で今回は固定長の配列
長さを関数呼び出しなどで受け渡しする必要がない
structでサイズを持って受け渡しすることは無意味で無駄で非効率になる
この違いがわからない初心者なのだろう
745: 03/18(水)22:28 ID:Pr3hbF5X(1/5) AAS
記事の趣旨は下記のような場合にエラーが検出できるってことなんだけど
#include <stdint.h>
#define BUF_SIZE 5
#define DATA_SIZE 7
void fill_zero( uint8_t (*buf)[ BUF_SIZE ] );
int main( void )
{
uint8_t data[ DATA_SIZE ];
fill_zero( &data ); /* ここでコンパイラが警告またはエラーを出す！ */
return 0;
省10
746(1): 03/18(水)22:31 ID:Pr3hbF5X(2/5) AAS
要素数がBUF_SIZE個のuint8_tの配列がなんかのデータ型表してんなら普通に構造体にするよねえ、
#include <stdint.h>
#define BUF_SIZE 5
typedef struct {
uint8_t data[ BUF_SIZE ];
} NANKADATA;
void fill_zero( NANKADATA* );
省15
747: 03/18(水)22:45 ID:IinJ/Cgw(1/3) AAS
>>746
struct {
uint8_t data[ BUF_SIZE ];
} NANKADATA;
フィールド数が1個の構造体は単なるラッピングであり本質的な話ではない
当然ラッピングしなくても使うことができる
わざわざラッピングした時の事例を持ち出す必要はない
748: 03/18(水)22:49 ID:Pr3hbF5X(3/5) AAS
おっプログラミングの経験ない人か。本当に居るんだねｗ
749: 03/18(水)22:53 ID:Pr3hbF5X(4/5) AAS
uint8_tの要素数が3のRGBもYUVも区別できなくて問題ないって人かあ。
750: 03/18(水)22:54 ID:IinJ/Cgw(2/3) AAS
ラッピングは型安全性やカプセル化のためプログラミングの常識だが
今回の問題では一切関係がない
ラッピングすることなくそのまま成立する
751: 03/18(水)22:56 ID:IinJ/Cgw(3/3) AAS
無関係なラッピングを持ち出しそれに固執していることからも本質を理解できていないとみえる
752: 03/18(水)22:58 ID:Pr3hbF5X(5/5) AAS
「そんなクソな書き方しねぇよ」という話が理解できない人いんのねｗ
753: 03/18(水)23:05 ID:3L+0H3qv(1) AAS
今回ラッピングなんかはどうでもよくて根本の話は>>742だよね
可変長ならば先頭アドレスと長さをセットで持たなければならない
固定長ならば先頭アドレスのみ持てばよくて長さは型情報として持つべきである
754: 03/18(水)23:55 ID:LfUPYerJ(2/2) AAS
ID:IinJ/Cgwはashworthかな
755: 03/19(木)00:25 ID:1fNhLbVo(1) AAS
そこは各型のデータが持つ情報により3つに分かれる
①アドレスのみ
②アドレスと有効長
③アドレスと有効長と容量
①は単体もしくは固定長の連続体
②は可変長の連続体
③は可変長の連続体で伸縮可
①の連続体の場合はその固定長の情報は型に含まれるため受け渡しする必要がない
記事『配列ポインタ型でサイズ安全な関数引数を実現する』が述べているのはそういうことで正しいが説明不足だな
756(3): 03/19(木)02:07 ID:/Wzj236o(1) AAS
『C言語の標準ライブラリを自作して学ぶ、安全なメモリ管理と文字列操作の真髄』
外部ﾘﾝｸ:qiita.com
オーバーフローチェックは重要、みたいなこと書いてるのに
> // 実データの前に size_t 分のヘッダ領域を確保
> block = malloc(sizeof(size_t) + size);
冒頭のコードでオーバーフロー無視してるのはなあ、無能すぎね? つか42tokyoかあ。
757(4): 03/19(木)03:59 ID:r1H5OpTt(1) AAS
>>756
これで満足か？
#include <stdckdint.h>
size_t total_size{};
if (!ckd_add(&total_size, sizeof(size_t), size)) {
block = malloc(total_size);
}
758: 03/19(木)04:38 ID:MpYhWP5O(1) AAS
>>757
？
759(1): 03/19(木)07:10 ID:uGXjP4fl(1) AAS
C23でようやく標準化されたオーバーフローチェックなんて99%のプログラマーが今後も知らないままだろう
標準化があまりにも遅すぎた
C++23の新機能も同じだ
みんな知らない学習する気もない使う気もない広まらない
760: 03/19(木)11:36 ID:TvMFZsLL(1) AAS
>>757
> これで満足か？
その記事のおかしいとこそこだけだと思った?
761: 03/19(木)19:51 ID:qPkzmLAQ(1) AAS
>>759 expectedが追加されてるけど、例外使いまってる既存資産から置き換えも考えずらいし、新規で使うにも別にC++じゃなくても良くね？な型。
762(1): 03/19(木)22:45 ID:UtYRo7C2(1) AAS
CとC++の標準拡張が連携とれてないよな
この言語はもうダメだ
763: 03/20(金)13:02 ID:iXoBkJ/Y(1) AAS
>>762
言語は思考を規定する
764: 03/21(土)13:52 ID:JUJDvVUv(1) AAS
>>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: 03/22(日)02:13 ID:wZUeCGG3(1) AAS
> これで満足か？
>
> #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(1): 03/23(月)10:23 ID:sxw8l0ML(1/2) AAS
>>757
> 2. 線形リストの動的管理と「ポインタのポインタ」の威力
> ポイント：
> なぜ t_list ** なのか？
なんて書いてるけど、理解がハンパだからft_lstadd_backの実装クソダサいことになってるなｗ
767: 03/23(月)10:33 ID:1OOhD5jZ(1) AAS
>>766
レス先が間違ってるのか何の話やらさっぱりわからん
768: 03/23(月)11:05 ID:sxw8l0ML(2/2) AAS
誤)>>757
正)>>756
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.028s