Qiita 7 - キータぞ、来たぞ、キータだぞー (768ﾚｽ)
上下前次1-新
734: 03/17(火)00:49 ID:jwAJtRGn(1) AAS
分かんない人は黙ってれば良いのにｗ
735(1): 03/17(火)01:28 ID:4o/LzC+C(1) AAS
>>732
その記事のやり方が正しい
それが静的な型チェックも実行効率も共に満たす方法
736(1): 03/17(火)08:39 ID:pXgEASqD(1) AAS
chatgpt様に訊いてみた
＞技術的な評価（ざっくり）
＞この記事の主張は Cの仕様としては正しいです。
＞ただし実務では多くの場合：
＞・void f(uint8_t *buf, size_t len)
＞・sizeof(array)/sizeof(array[0])
＞・マクロ
＞・_Static_assert
＞などで処理するケースが多いです。
省6
737: 03/17(火)11:16 ID:nEFxN0Aa(1) AAS
#define _countof(array) (sizeof((array))/sizeof((array)[0]))
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だよね
可変長ならば先頭アドレスと長さをセットで持たなければならない
固定長ならば先頭アドレスのみ持てばよくて長さは型情報として持つべきである
上下前次1-新書関写板覧索設栞歴
あと 15 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.017s