Qiita 7 - キータぞ、来たぞ、キータだぞー (765レス)
1-

698: 01/30(金)12:13 ID:1aPpJmtV(1) AAS
>>696
クラスが良いものとされていた過去の言語と、
クラスは良くないとされている現代の言語を比べてるんだな。
そのケースは共通メソッドPay()を呼べれば良いだけのようだから、
クラス継承関係の必要はないためクラスは不要だが、
そこも理解せずになぜかクラスを絶賛していて草。
699: 02/01(日)14:45 ID:95PY2lcv(1/2) AAS
『なぜあの人と話すと仕事が止まるのか。』
 
責任を避けたいのか指示や説明に曖昧な表現をする人は実際いて、記事では良いこと言ってると思うんだけどもコメ欄見ると曖昧支持派が案外いるようで意外な感じ。そんなんで仕事効率よく回るのかな?
700: 02/01(日)14:51 ID:95PY2lcv(2/2) AAS
そもそもの話として指示してる側がよく分かってない場合まであるかな。
701: 02/03(火)00:37 ID:ZHB7f43X(1) AAS
ネットwatch板に行けや板違いのクソジジイども
702
(2): 02/05(木)11:26 ID:KDeSa5ll(1/2) AAS
会話・チャットでやり取りをしていて、「なんか、このひと面倒くさいなー」とイライラすることがある。
イライラするだけなら、まだ我慢できる。けれど、それが仕事に支障をきたすのであれば話は別だ。
─── で、そういう場面は珍しくない。
そういうひとのことばを観察していると、あいまいな表現が多いことに気が付く。
それで、会話の回数が多くなって生産性が落ちたり、認識の齟齬が生まれて作業のやり直しが発生したりしている。
結論:
コミュニケーションコストは低い方がよい。
仕事の文書は多義性をもってはいけない。
「あいまい」な表現は避けるべき。
今日はこういう話をする。
省5
703: 02/05(木)11:33 ID:KDeSa5ll(2/2) AAS
本田勝一
外山滋比古
ああそういうことか
704: 02/05(木)12:57 ID:E6aSdkxP(1) AAS
コミュニケーション能力の低そうな奴キター(AA略
705: 02/05(木)14:17 ID:jnX8qpUc(1) AAS
noteに投稿すれば利益でるかもしれない情報を
なんでわざわざQiitaに無償提供しないといけないんだよ
706: 02/05(木)18:57 ID:Whvu+Pg2(1) AAS
>>702
本文読んでないけど「その多さに驚く」「たとえばこんな具合だ」とかはGPT構文
707: 02/06(金)17:42 ID:Kt3ZEJjw(1) AAS
>>702
主張の甘さはともかくすごく読みやすいよく出来た文章
現時点のプログラミング能力が低くてもよほど高い技術力を求める職種じゃなければ書類選考は通すかな
708: 02/16(月)21:18 ID:yj7FcTNH(1) AAS
『TRONはマイクロソフトのOSよりも開発が遅かった』
 
> TRON をリアルタイム OS というのであれば、Windows もリアルタイム OS です。
 
とか言ってて草w
709: 02/17(火)07:24 ID:2y9Ezw3R(1) AAS
Windows CEは現行品じゃねえからなあ…
710: 02/18(水)01:29 ID:IBuOhcjB(1) AAS
『アセンブリ言語を学ぶことで得られるメリット【アセンブリ言語さくっと入門】』
 
雑な記事で間違いも散見されるけどこんな記事がいいね多く貰えるのかw
711: 02/18(水)10:07 ID:ECs//W9F(1) AAS
サルでも判る
猫でも判る
こんなのがベストセラーですし
712
(1): 02/18(水)17:20 ID:FZ7FR248(1) AAS
QiitaってCSS/HTMLの埋め込み出来んのね
なんつー不便な
外部サイトをEmbedで埋め込めばいいんだけど
自前で提供してほしいなあ
713: 02/19(木)10:17 ID:cTP/hAta(1) AAS
CSS埋め込むとCSSに攻撃されます
714
(1): 02/21(土)15:04 ID:QrnLkFez(1) AAS
>>712
Qiita Discussions へようこそ
外部リンク:github.com

投稿したら運営が必ず返信してくる有用サイトを教えてあげる
715
(1): 02/24(火)16:30 ID:pFFjUl/D(1) AAS
>>714
リンクもまともに貼れないのか…
716
(1): 02/26(木)11:57 ID:t+HxmJOg(1) AAS
>>715
バカで草
5chは初めてか?
717
(1): 02/27(金)15:56 ID:hatmpLbN(1) AAS
>>716
直リンクなんて今は誰も気にしないよ
おじいちゃん
718
(1): 02/28(土)17:14 ID:TQQUbZKL(1) AAS
>>717
横だが
ほんとに何を間違えたか分かってないのか、
分かってとぼける為に編み出した言い訳なのかどっちだ?
719: 03/01(日)02:50 ID:FIljQNjT(1) AAS
Rustは非常にシンプルで
最も多用されて使いやすい半開区間
従来 i = 0 ; i < n を 0..n と表記
稀に用いられる閉区間
従来 i = 0 ; i <= n を 0..=n と表記
このようにシンプルに従来と対応している
この2種類しかないため逆に取り違えて誤用することもない

外部リンク:youtube.com
720
(1): 03/01(日)04:41 ID:Ihp4TUhS(1) AAS
>>718
ジジイ乙
721: 03/02(月)00:05 ID:rkh+heJs(1) AAS
>>720
みいちゃん…
722: 03/04(水)17:49 ID:umvekOcL(1) AAS
最後に出てくる「みいちゃん」は、過去に5ch(旧2ch)で起きた有名なコピペや「知ったかぶりをする初心者」を揶揄する文脈で使われるネットスラングです。
「君は何も分かってない初心者(あるいは痛い人)だね」という強烈な皮肉を投げ、議論を打ち切っています。

直リン派の認識
利便性と現代基準 今のブラウザやアプリはセキュリティが強く、多くの掲示板アプリ(専ブラ)は `ttp` でも自動で補完してリンク化します。
「h抜き」はもはや二度手間を強いるだけの無意味な儀式に見えています。

h抜き派のに認識
5chには「リンクの先頭の `h` を抜く」という古い慣習があります。
これはかつて、不用意なクリックによるブラウザクラッシュ(ブラクラ)やウイルス感染を防ぐための自衛手段でした。

この状況をAIに解説させて思ったがなぜhttp抜いたか分かってないんじゃない?
ブラクラやウイルス感染を防ぐためじゃなく5chでURL規制で貼れないことが多くIP規制になることもあってhttp削除
省5
723: 03/04(水)18:05 ID:DjLSShMS(1) AAS
規制とかどうでもいいわなURL貼れないならそもそも書き込みを諦めればいいだけだし
724: 03/04(水)18:29 ID:78qp6zA1(1) AAS
http削ると貼れたりするから諦めなくても大丈夫
725: 03/05(木)09:27 ID:GrZo6tuI(1) AAS
リンク貼ったら一発退場が懐かしい
726
(1): 03/05(木)15:06 ID:qwmj+r7o(1) AAS
『C言語とアセンブリ言語の実行速度を比較する』
 
printfで整数値を10万個出力するのに
・アセンブリ言語からprintf呼び出し→約7秒
・C言語からprintf呼び出し→約40秒
 
ちょっとあり得ん結果になってるんだけど考察もなく終了という気持ち悪い記事。
727: 03/05(木)16:59 ID:kRsvyMri(1/2) AAS
Cでcountをレジスタに割り当てたら速くなるんかな
最適化するだけでもっと速くなるかな
728: 03/05(木)17:05 ID:kRsvyMri(2/2) AAS
実行環境が違っててconsoleの性能差だったら笑う
729: 03/05(木)17:21 ID:catlXG/r(1) AAS
__stdcall と __cdecl か
730: 03/06(金)11:57 ID:BuD09eQW(1) AAS
>>726
Cコンパイラで*.asm吐いて比べてほしい記事やなあ
731: 03/06(金)14:37 ID:UfOJQwwp(1) AAS
consoleの差に一票
732
(4): 03/16(月)20:15 ID:BE2T/V4b(1) AAS
『C言語にも配列のlengthプロパティをください ― 配列ポインタ型でサイズ安全な関数引数を実現する』
 
フツー構造体を定義するところを一見便利そうでその実不便な方法を提案する人
733: 03/16(月)20:51 ID:YQ6nobJE(1) AAS
>>732
どんな構造体を定義して何をするつもり?
734: 03/17(火)00:49 ID:jwAJtRGn(1) AAS
分かんない人は黙ってれば良いのにw
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みたいのもいるのは世の中広いなw
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
おっプログラミングの経験ない人か。本当に居るんだねw
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
「そんなクソな書き方しねぇよ」という話が理解できない人いんのねw
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
(2): 03/19(木)02:07 ID:/Wzj236o(1) AAS
『C言語の標準ライブラリを自作して学ぶ、安全なメモリ管理と文字列操作の真髄』
外部リンク:qiita.com

オーバーフローチェックは重要、みたいなこと書いてるのに

> // 実データの前に size_t 分のヘッダ領域を確保
> block = malloc(sizeof(size_t) + size);

冒頭のコードでオーバーフロー無視してるのはなあ、無能すぎね? つか42tokyoかあ。
757
(2): 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のラッパーになっててクソワロタw

> 1. メモリブロックへの「メタデータ」埋め込みによる ft_realloc の実装

glibcならmalloc_usable_sizeでメモリーブロックのサイズ取得できるのに車輪の再発明だなあ。将来的にmalloc部分も自作するとしてメモリーブロックのサイズはどっかに格納すんだしmalloc使ってるならmalloc_usable_size使うで良かろう。
ft_reallocもメモリーブロック再割り当て必要ない場合も常に新しいメモリーブロック割り当てるし第1引数にNULL渡された場合も考慮されてないなあ。
よくこんな記事スクール名誇らしげに明記しながら公開するもんだわw
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;
で良くね?
1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.844s*