C言語って設計が悪いから難しく感じるだけ

ポインタが難しいわけでもないし、単に分かりにくい設計が諸悪の根源。

K&Rを今読んでいてそう感じます。

int main(argc, argv)
int argc;
char **argv;
{
return main(argc, argv);
}

例えば、

int (*p)[10];

とかいう表記が最悪。

C++の.hファイルとcppファイルが分かれてるだけで勉強する気失せる

俺からは一つだけ　
char* ptr_something;
この作法だけが正しい
俺以外全員間違い

エセ職人スレ

>>3
ANSI版を嫁

>>6
お前複数の宣言で事故るタイプ

>>4
int p[][10];

C言語からの推奨移行先Rustの場合

T　型T
&T　型Tへの参照

長さが不定なもの
[T]　型Tのスライス値
[&T]　型&Tのスライス値
&[T]　型Tのスライス参照
&[&T]　型&Tのスライス参照

長さが固定なもの
[T; N]　型T長さNの配列値
[&T; N]　型&T長さNの配列値
&[T; N]　型T長さNの配列参照
&[&T; N]　型&T長さNの配列参照

このように[&T]角括弧の内部に＆が来るため区別しやすい

[[T; M]; N]

[[T]; N]
[[T; M]]

>>10
それが等価なのは引数の宣言だけ

C23からのアトリビュートの宣言もかなりの闇
各種コンパイラ独自実装のアトリビュート宣言よりだいぶマシとはいえ中途半端にセマンティクス保存しようとして闇った

よくこんな意味がわからない記号操れるな感心

ポインタは便利

参照も欲しいけどな

クソソースが作りにくい分だけ、C言語は設計が優れているといえなくもない
オブジェクト思考言語は美しいコードを生成できる反面、非常に難解なソースも量産できてしまう

世の中にあるクソソースでも、C言語だと理解してやろうという気持ちになれるけど
オブジェクト思考言語のクソソースは理解する気が起きないどころか殺意を感じる

クラスがないRustは分かりやすい

>>14
まさに設計が悪い例だな

>>15
[[]]で囲むキモい文法はC++から借りたものではあるが、C++のアトリビュートも仕様腐ってるから何とも言えない無念さ
C++のキレイなところだけ輸入するのがC標準委員会の方針でなかったのかよ…

通常の言語と違って年々ゴミになっていく類稀なる発展をするC

>>11
これも大概だろ

int *p, *q; // c
var p, q *int // go

int *p; 派と
int* p; 派が居るけど
前者は int *p, *q; 出来るのに
後者は int* p, q; で詰む

仕様とクセの折り合いをつけて
int* p; int* q;

void func(int a[]);

funcの定義内で、引数 a を使う場合、a[i] などと書きます。

void func2(void (*g)(void));

func2の定義内で、引数 g を使う場合、g() だけでなく (*g)() とも書くことができるそうです。

配列と関数の場合で整合性がとれていないように思います。

>>28
それはCのcallableは関数ポインタだから
関数名を使っても関数ポインタに変換される。
だからなんなら(*****g)()でもok

また宣言の中の配列宣言子はポインタに読み替えられるから、int a[42]であろうとint *aと同じ
中に数字書くのは飾りです
但し配列宣言子内にstatic とか書くと意味が出るのでこれも注意

クソだな！！

>>28
その引数aはポインタのシュガーシンタックスだから、整合を取りたければ*(a+i) と書いてあげるとか

>>29
&&gが出来ないのに**gができるとは、、、

いや、29の話が全てで、30は要らなそうですね、、、

>>28
void func(void){}
に対して
void func2(void (*g)(void));
を使うとき
func2(func); と呼ぶ派と
func2(&func); と呼ぶ派が居るらしい

int *f();
int (*pf)();

という宣言を考えます。この宣言に含まれる「*」や「()」は演算子ではないですよね。実際に演算を行うわけではないからです。

ですが、K&Rにこれについて以下のような説明があります。

* is a prefix operator and it has lower precedence than (), so parentheses are necessary to force the proper association.

これは演算子ではない記号「*」、「()」の優先順位を考えています。

これはおかしくないですか？

もし、これらにも優先順位を考えるのであれば、

「int」と「*」と「()」の優先順位も考えなければならないはずです。

あ、その後に、

「dcl」という関数が書いてあります。これは、「int (*daytab)[13]」が入力されると「daytab: pointer to array[13] of int」という出力を作る関数のようです。

この関数を解読すれば、精密にCでの記法を理解できますね。

&a == &a[0]

30年以上前にfj.comp.lang.cでフレーム起こしながらやってたような不毛すぎる議論で草

やっぱ引導渡さないとダメだこのクソ言語

話題に鮮度がなくて食いつけないよ・・・
初学者はこんなスレ立ててないで黙ってひっそりと独学してください

>>36
型も一緒なの？

>>37-38
残念だが 5ch がお�hる

char (*(*x())[])();
char (*(*x[3])())[5];

上の宣言を解読せよ。

わざと難読化したのを書いて言語がクスという言うスレ

こんなの無限にできるだろ
char (*(*(*(*(*x[3])())[5] )));

>>41
char (*(*x())[])();
x is fun ret ptr of array of ptr to fun ret char.

char (*(*x[3])())[5];
x is array 3 of ptr to fun ret ptr to array 5 of char.

かな？

じゃあ俺からも問題
xの宣言
int (*(*x[3]) [[A]] (double)) [[B]] [5];
を読み下せ

なぞなぞ言語

signalとかqsort_rとかなぞなぞ解かないと使えない関数もあるので…

あとはpthread、特にpthread cleanup handlerあたりはかなりなぞなぞ

gets("(σ・∀・)σ"); // Segmentation fault

>>45
アトリビュートは闇…

アルゴリズムは苦手だけどなそなそは得意

人間がコンピューターに寄り添う優しい言語
それがC
かわりにコンピューターも全力でがんばってくれる

こうやればステップ数少なくなるから速く動くんじゃね？
と書いたコードがびっくりするほど遅くて
やっぱり妙な書き方しない方がまともだと学んだ

どの命令がどんな速度で実行されるかを学んだ方がいい
ステップ数が短い命令は、複雑なことを簡単な命令でこなすように作ってあるから
むしろ時間がかかる

DJNZ

stsb
ldsb

xor a,a

test
https://www.youtube.com/watch?v=5k3jE-NAVQQ

>>1
C言語はUNIXというOSを作るために作られたプログラミング言語です。
だから中水準言語なのです。

だからってなんだよ

Cの楽しさを知りたければIOCCCの作品でも読んでみればいい

>>61
ハードウェアとのやりとりが多いので、ハードウェア寄りのプログラミング言語になっている。

全ての言語はunlambdaと同様の難読化が可能。なぜならSKIコンビネータからの遺伝だから。

K&R時代のC言語を体験してみよう

ポインタはデータまたは関数そのものではなくそのデータまたは関数のアドレスを意味する
簡単に聞こえるし簡単だと思っていたらいつか足をすくわれるのがパターン

メモリマップとかI/Oマップとか一度でも見たことあるのか？サル。

>>66
間違ってないね。

Cは「ちょっと高度なアセンブラ」なんだよ
人間の読みやすさなんて考えてない

>>66
違うよ
ある変数があるとして
そこへのポインタこそ変数そのものなんだよ
値の方は変数ではない

これは代入すればわかる
ポインタがあればその指してる先を書き換えることができる
値があってそれを書き換えても変数の中身は書き換わらない

つまり
ポインタが変数
値は変数ではない

>>70
おい、サル。

int x;
int *xp;

>>70
お前は>>66の内容を理解できてないんじゃないのか？
ズレてて議論になってない

変数の実体はポインタであってるよ
だから関数に渡して結果を入れてもらう時もポインタを渡さなければならない

>>74
小学生ですか？
変数(容れ物)と値の区別を学びましょう

コードの中でxと書いてもそれは値として取り扱われ変数としては取り扱われない
だから例えば関数にxを渡してもそれは変数を渡したことにならず値だけが渡る

変数とはアドレスのことです
そのため変数を受け渡すにはアドレスが必要
関数へ受け渡すときは&xなどになる

変数と変数の値と変数のアドレスが正しく理解できてない

MOV EAX, [0x12345678]
メモリの内容を 4バイト読み込んで EAX に入れるIA-32のニーモニックだけど
これをよく考えたら変数、変数の値、変数のアドレスの違いがわかる

>>75
>>77 の宿題はやったか？

ポインタとか要らねーだろ
遅くなる？関係ねーよ
CPUのパワーでぶん回しゃ良いだけだ

無限ループですらCPUパワーで解決しそうな勢いだ

L[1-3]キャッシュに乗るとポインタでもレジスタでもなくなる

>>80
パイソンやれよ

Lispだろ。

ほれ。

https://www.gnu.org/software/emacs/manual/elisp.html

そのaという配列変数のアドレスは32ビットCPUなら32ビットの値、64ビットCPUなら64ビットの値だろ？

アドレスの値はchar*でもint*でも同じ。当然void*でも同じ。

互換性のないポインタ同士を比較するとウォーニングがでるからそれを抑制するためにvoid*にキャストしているだけだと思うよ。

本当はchar**とvoid**にも互換性があってほしいんだがないんだよ。void*としかない。

a + 4 == (void *)(&a + 1)

sizeof(int)と書こう。

俺はすごいじじいだけど
C言語を初めて見たときは画期的だと思ったよ。
まだ世の中がMS-DOSじゃなくてCP/Mのパソコンあたりがでていた時のことだ。

そのころやっていたのは、CNC装置そのもので、8086が5つ乗っていたと思う。
CNCのNCプログラム実行部は全部アセンブリ言語で書かれていて、UIだけ高級言語のPL/M86で
書かれていたよ。　このPL/MとCが全然違うんだな。
スタックの積み方が違う。いわゆる関数コールが　PascalのABIだし
ポインタは　Based変数というものがあるがポインタに対してBased でint配列や 構造体配列のポインタを定義する。
ポインタ+1しても中身は1しか増えないから、　+sizeof(struct KOZOTAN) を足してやらないといけないとかで
Cは+1するだけで勝手にサイズが足されるから合理的だと思ったけどな。

アセンブラだってサイズ分インクリするけど

>>75
その「変数とはアドレスのこと」というのは機械語で考えればわかりやすいよね
静的な変数なら絶対アドレス
動的な変数なら相対アドレスになる

キモじじみたいに機械語を知らないと
「変数とはアドレスのこと」を理解できない

・静的な変数はヒープ上
・動的な変数はスタック上
どちらもメインメモリ上でありどちらもアドレスである点は同じ。

・任意のアドレスをフルビットで表すのが絶対アドレス
・任意のアドレスをあるアドレスからの相対位置で表すのが相対アドレス

俺はZ80の機械語でインベーダーゲームを書いたしm68kの機械語ではもっと山ほど色々書いた。

結論：サルには機械語は無理。

あ、動的がヒープで静的はbssセクションとかだな。

ん？動的なメモリでなく動的な変数って書いてあるから錯覚したけど動的な変数ってなんだ？やっぱりCのauto変数のことだよな？

>>96
マルキューでは書いていない若造かよ

Z80って書いてあるだろ、サル。

ゼッパチだけ？？
当時究極の8bit CPUと評されたマルキューでも書いていないなら若造か雑魚

例えばシャープは200ラインと400ラインとテレビが3つとも映るディスプレイを作った。一方 FM-7 はテレビはおろか400ラインにすらGRAMの増設と共に専用ディスプレイが必要だった。ましてスーパーインポーズなんて望めるわけがない。

セルフリロケータブルコード以外に6809でしかできないことを言ってみろよサル。究極の8bit CPU以前に8bit CPU自体は知ってんのかサル。

>>102
FM-7ならデュアルCPUだな
YAMAUCHIコマンドによってサブCPUをメインCPUとは別に同時に動かせたろ

CPU評価ボードなんてどのパソコンにも何枚でも挿せるがサルには理解できないかもな。

やっぱり当時の常識を知らない若造だったか
FM-8/FM-7は発売当初から6809二つのデュアルCPU搭載機種だ

CPU評価ボードが理解を超えてるのかサル。当然Z80カードも理解を超えてるんだろうなサル。

>>102でFM-7の名前を出しておきながらデュアルCPU標準搭載という当時の常識を知らずに
>>104で「パソコンにも何枚でも挿せる」と書いてしまったことでキモじじいの無知がバレた
もはや取り繕えないぞ

理論上X1にもPC-88にも6809カードを2枚挿すことはごく容易いはずだって言ってるんだがサルには難しいか？

はい、論破。次のサル来い。

Z80だけでなく6809でも書かなければならないものって「売り物のゲーム」以外になにがあるの？

>>108
やはり分かっていないようだな
FM-8/7には現実にZ80カードが発売されていて挿して使えていた
しかしそんな話ではなくFM-8/7には6809CPUが2つ標準搭載されていた
だからデュアルCPUを活用したプログラムはそのまま標準環境で動いて誰もが使えていた

標準環境でデュアルCPUなら標準環境用のソフトがそれを採用しやすいのはわかるよ？でもそれは商売の話。標準環境以外の話は？つまりコンピュータ工学は？サルには無理？

当時両方の機械語で書いていたならば
何もかも汚いZ80と何もかも美しい6809の格差も常識だろ
それ以前に当時の市販のマイコン状況すら知らなかったキモじじいは実際には若造だからそういう常識も理解できないのだろうが

じゃあさ、こういう話はどうだ？俺は学生時代、6809のように美しい68000を搭載したシャープX68000に、自作のTMS320C25カードを挿して自作のアブソリュートアセンブラを作って、みたいな話。

>>95
>「変数とはアドレスのこと」を理解できない

まだ間違ったことを主張し続けているのか
変数と変数のアドレスを正しく理解できてない

変数とは値を保存するためのエリアであり、保存したい内容によってサイズがかわる
変数のアドレスとは変数の先頭アドレスを指すだけ

メモリの1000Hからはじまる2バイトの変数があったとする
変数は1000Hと1001H
変数の値は1000Hと1001Hに書かれた内容
変数のアドレスは1000H

間違ってないけどアドレス4桁？

8ビット時代の人間にもわかりやすいだろう？

うん。

>>114
不定型でない限り
型が定まればサイズは定まる
そして静的型付け言語ならば実行前に形は定まる
だから先頭アドレスさえあればよい
サイズをデータとして保つ必要はない

>>118
実行時じゃなくてコンパイル時な。

>>119
目が悪いのかね？

>>120
じゃあコンパイル時？リンク時？

>>118
まだ理解できてないなら
変数(容れ物)と変数の置いてある場所の区別を学びましょう

>>122
容れ物の種類は型で決まる
同じ型ならば同じ容れ物になる
各変数を区別するために容れ物のある場所(アドレス)で区別する
つまり各変数に対応するものはアドレス

>>123
変数のアドレスで変数が一意に決まるとしても
変数と変数のアドレスは違うものである

マイナンバーで日本での個人が一意に決まるとしても
個人とマイナンバーは違うもの

「変数とはアドレスのこと」というのは
「個人とはマイナンバーのこと」と同じぐらいに無理がある

>>96
むしろ猿のほうが機械語楽でしょ
絶対アドレスと相対アドレスさえわかってりゃいいだけだしね

オブジェクト指向とか余計なこと考えずとも
全部メモリ空間だけを見てメモリ空間のデータを主役にしてプログラム組んでいけばいいからなぁ

C++を英語の第1版で学んだ人間相手になに言ってんの？

K島さん（現准教授）の主催した輪講だよ。今、憎悪が集中してるあいつもいたよ？他はK村さんとかA川さんとか。

複数の変数名を用意して
それら全部同じアドレス参照してる組み方してれば、くだらない変数＝アドレス論とかアホでしかないが

老人しかいない・・・

コンパイル時ではなくリンク時に決定されるものもある。グローバル変数やグローバル関数の実体だ。リンク時に見つからなければエラーになる。重複していてもエラーになる。

>>128
それ、どうやってやんの？

グローバル変数やグローバル関数の実体だけでなく構造体のメンバ変数のオフセットもリンク時に決定されるようになっていればOO言語でも修正を加えたファイルだけを再コンパイルすればいいようにできたはず。もちろんデニス・リッチーがあの時代にそんなことを心配してくれていたはずもない。

>>128
ねえねえ、同じ値のポインタを沢山用意するの？

>>91-92
doubt
誤 a + sizeof(int) == (void *)(&a + 1)
正 a + 1 == (void *)&a + sizeof(int)

voidポインタに加減算はやめたほうがいいです

a == (void*)&a;
の意味ほんとわからん
神がそう定めたからとしか説明できない

>>134
>>136
aと配列名を単独で書くとa[0]へのポインタ
&aは配列全体へのポインタでアドレスはaと同じ
(void*)はポインタの型が合わないと文句を言わせないようにするためのキャスト

int a[10] = {}; # 混乱しないように配列サイズを4から10にした

a + 10 == (void *)(&a + 1)
aはa[0]へのポインタになるので+1でint分のアドレスがずれる
&aは配列全体へのポインタになるので+1でint 10個分のアドレスがずれる
当然のことながらa + 10や&a + 1は配列から外れたアドレスになるが値を代入しなければ問題はない

>>76
>>124
変数の本質はアドレスにある
入ってる値なんかコロコロ変わるものであって変数と結びついてるものではない

変数のアドレスもコロコロ変わるものなんだよ
知らなかったの？

移動式GCをしない限り
変数のアドレスはその有効期間ずっと変わらない

変数名は特定の番地につけられた名前の印象
スタックに置かれたローカル変数などは別だけど

変数と変数名は

ごめんなさい
途中で投稿してしまいました
変数というとかなり曖昧で、住所不定にも思える

>>141
スタック上の変数は相対アドレスとして不変

>>144
関数なんて、再帰的に呼び出されたりするじゃない
ベースポインタからの相対アドレスは不変かもしれないけど
誤解だったらごめんね

>>145
いつ呼び出されても再帰的に呼び出されても常に同じ相対アドレスが使われて変化しない
変数は常に同じアドレス(絶対アドレスor相対アドレス)に結びついている
だからこそ同じコードで動く

sp相対がアドレスでないと思うのなんで？

関数が呼び出された瞬間に積まれるスタックフレーム内にスタックポインタからの相対アドレスとしてアクセスするんでしょ？それが「変数＝アドレス」でないと思う人いるの？

C言語の言語仕様で定義されてないものは、動いているシステムで
たまたまそう実装されているだけ

register宣言された変数のアドレスはどうなるんだ？
最近の賢いコンパイラならregister宣言がなくてもレジスタに割り当てる
ことができる変数ならレジスタを使うだろう

変数=アドレスなんて馬鹿な考えはさっさと捨てましょう

そもそもC言語の仕様にスタックなんて概念はない

変数はアドレスで合ってる
一時的な変数で他からアクセスされない条件ならば
一度もメモリに戻すことなくレジスタ上だけで済ませられるだけの話

でもフォン・ノイマン・アーキテクチャ以外にC言語ってあるの？データフローってなにでプログラム書くの？

コンパイラがローカル変数をスタックに置くことが多いのは手軽で便利で速いからそうしているだけ
ヒープに置いて管理する実装があったとしても問題ない

そもそもIBMの往年のSystem370とかだとハードがサポートするスタックが存在しないが
それにもGCCが移植されているらしい

スタックに置こうがビープに置こうがその変数の有効期間はアドレス固定で変わることがない

>>140
変わりますよ
もう少し勉強しましょうねｗ

>>151
>変数はアドレスで合ってる
めちゃくちゃ間違ってますよ
もう少し勉強しましょうねｗｗ

>>154
変わりますよ
もう少し勉強しましょうねｗｗｗ

>>154
変わるけど？
だからこそ、ポインタという機能を付けてアドレスで扱えるように工夫して作られてんだよ
それが無ければポインタを駆使して作られるプログラムの手法すら使えなくなる

>>156
「変わる」という結論は同じでも
それは値のアドレスの話で
変数自体のアドレスの話とは違うのでは？

>>155
>>156
変数のアドレスが途中で変わることはありません

ポインタなんてメモリに格納されている数値がアドレスかどうかの話だけなのに

馬鹿しかいない

『変数のアドレスは途中で変わらない』
という常識を知らない人はコンパイラにアセンブリ出力させて見てみるといい
変数のアドレスはアセンブリコードの中のオペランドとして埋め込まれている
実行中に変わることはない

自分で正当化してるところがキモい　5chで架空の像マウントが自分にとっての全てという姿勢が現実を生きていない
今時ハラスメントが当たり前みたいに言ってるやつは会社では絶滅してるのだが何十年も前に社会人だったという人間なのか

>>137
Rustは最悪ですね判ります

>>161
>『変数のアドレスは途中で変わらない』
『変数の本質はアドレス』や『変数はアドレス』からかなり後退したなｗ
『変数のアドレスは途中で変わらない場合がある』なら間違ってないよｗｗ

>変数のアドレスはアセンブリコードの中のオペランドとして埋め込まれている
必ずそうなるわけじゃないんだよ

変数のアドレスは変わらない発言の件
私は正しいと思っている者ですが何を絡まれているのかがちょっとよく分からない。話題の次元が合ってない？

グローバル変数なら特定の絶対アドレスを対象に値を格納・取得する
ローカル変数なら呼ばれた関数用に確保されたスタックフレーム上の特定のオフセットアドレスを対象に値を格納・取得する(アドレスを必要としないレジスタ変数については今回議論の中心ではない様なので除外してます)
int変数ならintの値を、int*変数ならポインタ値を、特定のアドレスを対象に格納・取得。
Cのコードを翻訳した時に、これらの動作となる機械コードが出力されると思ってます。

一方、アドレスが途中で変わると言う主張は私には例がイメージができないです、、、

>>165
>アドレスを必要としないレジスタ変数については今回議論の中心ではない様なので除外してます
今回の議論の中心は「変数とはアドレスのこと」かどうかですよ
アドレスを必要としない変数があるということは「変数とはアドレスのことではない」という結論には同意済みなんですかね？

ここまでの議論はレジスタ変数の言及ではないと思っているので(質の悪い質問に対する質の悪いAI回答のように)同意はできませんね

>>165
それで正しい
ポインタを理解できていないと「変数のアドレスは変わる」と間違えてしまう
ポインタを正しく理解できていれば事実「変数のアドレスは変わらない」も理解できる

>>166はレジスタ変数の事をどう思ってるの

アドレスを変動させる仕組みASLR
このせいで変数の配置場所がコロコロ変わる
変わってもOSが変わった場所を覚えてくれるので、ソフトはそれを考慮せずポインタで扱える

が、アドレスは明確に変動しているのだ
馬鹿がポインタ＝アドレス＝変数は不変と勘違いしている

他のアプリが割り込んだためにページングファイルに退避され
また戻った時に同じメモリ空間に戻されるわけもなく
絶対アドレスで指定したらおかしくなるわな

マイコンやってるならそう思ってもいいが
絶対アドレスでアクセスしていいならわざわざポインタも変数も使わず直接メモリ叩けばよいが
そんな時代ではない

おもしろい議論してるねぇ。
論理アドレスと物理アドレス（メモリやレジスタやネットワーク上のストレージなど）を考えるなら、
変数の論理アドレスは変わらないが物理アドレスは動的かもしれない。
そのC言語は、必ずしも物理マシン上だけに実装されているとは限らない。みたことないけど。
C言語が扱っているのは、そのC言語実装上の論理アドレスでしょう。
ちょっと、粘菌でできたCPUとメモリを考えてみたい。論理アドレスを維持できるのだろうか。

>>170-171
OSが行うスワップイン・アウトなどで物理アドレスは変わるかもしれないけど論理アドレスは変わらないからC言語コードからは気にする必要ないよ
変数の論理アドレスは不変だ、変数を参照するポインタが扱うのは論理アドレスだからその点安心して使ってね
どちらかといえばローカル変数のアドレスを戻り値として返さない(関数終了時に変数は消滅するから)とかを気をつけてね

しかしASLRなんて技術があるんだね、すごいね。気にしたことがなかった

>>170
ASLRも従来と同じでレジスタ相対アドレスを使うか実行前に解決されます
変数のアドレスが実行中に変わることはありません

>>171
それはまた別の大昔からの話です
各プロセスに専用の仮想論理アドレス空間があてられます
物理アドレスが変わっても変数のアドレスが変わることはありません

>>167
別にレジスタ変数じゃなくても対応するアドレスが存在しない変数なんていくらでもあるでしょ？

>>175
変数には必ずアドレスがあることが保証される
だから＆varnameで必ずアドレスを得られる
その上で、アドレスが使われていない場合、もしくは、最適化でアドレスが最終的に必要とされない場合、
メモリ上に置かれずにレジスタ上だけで済まるなどしてもよい自由も保証される

粘菌CPUはジョークではないが、C言語って高級言語ではなく高級アセンブラ言語なのだから、
物理ソースに（直接）アクセスできなければ意味はない。
なんらかの一般的なOS上で使うC言語ならともかく、
組み込み用のC言語になると、物理的なハードにアクセスするので、
変数とかポインタとか実行コードとかの動作は自分で保証しないといけない。

>>175
extern宣言だけされた定義もない参照箇所もない変数ならアドレスがないとか？良くないコードです
他はちょっと思いつかなかった。寝ますね、、、

>>176
Cの抽象度から見た概念上のアドレスの話じゃなくて
実行時のメモリアドレスの話でしょ
>>161や>>165見れば分かると思うんだけど

>>179
変数の実行時のメモリアドレスは変わらない
実行途中で変化しない
だからこそ変数のアドレスをそのへんの配列や構造体その他にプログラムが勝手に保存してもよい
変数のアドレスは変わらないから後でそれを用いてもよい

もちろん関数内のstaticでない変数が関数を離脱すると無効になる件は本件とは独立した話として注意を要する

まとめるとこんな感じか

変数の有効期限内での変数のアドレスは原則として変更されない

ASLRはプロセス生成時にデータのアドレスをランダム化するだけで
変数の有効期限内でのアドレスは固定となる
ただしグローバル変数だとしてもvolatile宣言されてないものは
最適化により特定の部分でレジスタに割り当てられる可能性がある

仮想記憶で物理アドレスがかわることがあったとしても
プロセスから見える変数の有効期限内での論理アドレスは変更されない

そういう理解の仕方はポインタのポインタでつまづくからやめれ

わざとややこしくしてるヤツがいるなｗ

変数＝アドレスっつってるやつだけが、自分の知ってる狭い世界だけ見て主張してるだけだからなぁ
マシン語もCも直接絶対アドレスを扱えてしまうんだから
いつのまにか物理アドレスと変数アドレスと分けて言いだして恥さらし

だからこそポインタという機能で、そういう危険な物理アドレス意識しないまま連続アドレスとして扱えるように工夫されてるのに、そういう土俵の上だけしか見えなくて、変数＝アドレスなんか言ってるから間抜け

>>185
無知すぎて話にならんな
よくそこまでデタラメを平然と言えるもんだ

>>184
メモリに格納されている値を数値、文字コード、メモリの番地として扱うかどうかはOSとプログラム次第の話だが、C言語とUNIXはOSの仕様が先にある話だ。

C言語はUNIX専用でも何でもないけど？
PC-88や98　DOS/Vやwinやマイコンで使われてる

>>188
C言語のこと何もわかってねえな

>>185
間違ってる
ポインタにそんな機能はない
それはOSの役目
仮想アドレス空間も持つOS環境ではそこで動くユーザプロセスは仮想アドレスのみで動く
物理アドレスを知ることもできず物理アドレスを意識することさえない
そこには仮想アドレスしかない
変数も仮想アドレスしか持たない

頭悪そう
ポインタのポインタってのがある時点で、変数の場所のアドレスが変わることを示してるってのに

ポインタのポインタのポインタのポインタのポインタのポインタ

>>191
それはポインタのポインタが何かを正しく理解できていない初心者が犯す誤解
皆が言うように変数のアドレスが変わることはない

愉快犯に付き合うのは時間を浪費するだけ

ポインタ自体も変数だ
何かのアドレスを保持する変数
ポインタのポインタはその変数（ポインタ）のアドレスを保持する変数

時間の無駄

AIに、変数＝アドレスですかって聞いてみなｗ

機械科のCの授業のテキストが要点をまとめたようなスライドで、それをノートに取って、演習をやるんだけどAIに聞かないと正解率がゼロとか15問中1とか。テストでできる気がしない。ダブルポインタでのlinked listの書き換えとか、関数のポインタを引数に渡すあたり。AIがなかった頃はみんな授業で理解してたのかな

C言語の要素だけで考えてるからパズルになる
メモリイメージを把握してたらなんてことはない
逆に言うとそういう感覚がないなら活用できないし危険
機械科ならさわりでいいからマシン語もいっしょに学習してみては

ノート取るよりもコード書いて動かす方がよさそうだけど

>>198
>ダブルポインタでのlinked listの書き換えとか、関数のポインタを引数に渡すあたり
前者は文法覚えたての初級者ができなくても全然問題ないが
後者は基礎なのでできないとまずい

高校ならともかく大学の話なら授業だけで理解できると思うのは間違い
一般的に偏差値の高い大学ほどその傾向が強い

*p …　ポインタ
**p …　ポポインタ
***p …　ポポポインタ

ボインと命名すればよかったのに

>>198
main関数のargvも実質ダブルポインタでchar *argv[]ではなくchar **argvとも書ける
K&R本の図がわかりやすかった思い出
https://imgur.com/a/l2qqJXK

先生やAIがいい図を描いてくれればいいんだけど

K&RはまさにCを設計した人の本ですね。アマゾンで見たら書評のpros & conがすごい極端。理解できるかどうかわからないけどkindleで1500円くらいで買えるので買ってみるです。ありがとうございます

学習本を買うならできるなら実物を見ながら検討した方がいい
自分が理解している事、自分がわからない事を説明してあるページを見て
自分に合う本なのか確認すべし

大昔なら柴田望洋の本を買っておけば大体間違いなしという感じだったが
今はどうなのか知らない

>>205
ANSI Cが基本だ。

歳とると思い込みがコントロールできなくなるよね
205はそもそも2ndでしょ

「ダブルポインタ」だれが言い始めたのか知らんがこの用語を使う香具師は判ってない香具師
判ってる香具師は正しくポインタノポインタと言う

https://i.imgur.com/AWm5ULD.mp4

元はといえばC言語の仕様が悪い
Rustなら
・生ポインタと参照の区別がある
・配列は静的固定サイズNを伴った型
・スライスは動的サイズを伴った型
なので
例えば文字列の配列への参照なら&[&str; N]型
文字列のスライスへの参照なら&[&str]型
それらの要素一つへの参照なら&&str型
これらがCでは**char型などに縮退されてしまうのが辛い

typedefやマクロ活用すれば分かりやすくはなるけど
型の互換があればそのままやりとりできるし
書けちゃうのがよくないってことだよね
でも16ビット機で開発できる高級アセンブラと考えたら十分かな
複雑なことはC++でという流れだし

>>211
それはC言語の初心者にうんざりさせられることワースト10

ダブルポインタって英語圏で確立された用語が輸入されただけやで
MITやスタンフォードのCS講義でも普通に使われてるんだがお前ら大丈夫か？

C言語でうんざりさせられる所
1. 宣言
void (*f[10])(int);
void (*f)(int)[10];
2. プリプロセッサ
馬鹿な使い方をすれば混乱の極み
3. 実装依存
f1() + f2()
関数内部で同じグローバル変数を使ってたりすると...

ああ、間違えているw

C言語の設計が悪いんじゃなくて、C言語を教える時にコンピュータについて教えないのが悪いだけ
C言語は隠ぺいしてないだけだよ

>>207
ANSI Cなんてもう時代遅れだぞ
C99以降が標準

>>206
今も柴田望洋でいいんじゃねえかな
C言語なんてそんな変わらないし

柴田望洋ってまだ生きてるの？

K&Rとこれ以外は全部サル用。

https://www.amazon.co.jp/dp/4774133345

Cの本はK&RとCプログラミング専門課程しか覚えてない

自分はANSI C(C89)が最新の時期にK&R2ndその他を手に取り、その後の追加仕様はWebで補給する形を取っている
今新規で学ぶ人はどのような学習スタイルが最適なのだろう。最新C(C23)をカバーしながら言語自体と適用例を学べる本って無さそうだし、Webだけで学ぶのは常に資料が変容するイメージがあって学習達成感を得にくいと思うんだ

機械語やってるとCは処理系の説明書だけで十分

C言語なんか、アセンブラをラップするだけの言語なんだから、設計も糞も無いだろ

馬鹿ってそう感じてたのか

Cで脆弱性だらけのプログラムを書くやつが多いのはK&Rのせい
今では非推奨の書き方も多用されてるから新規で学ぶ人用の本ではない
歴史的書物として経験者が読むもの

今となっては特殊組み込み以外はC使わずにRustがいいよ

カニ飯リッチ

Cは文法が糞

ザイログ形式のニモニックのまま高級言語化してほしい

>>231
76H

なぜかC9H(Ret)だけ覚えてる
初見の関数どこで関数が終るのか目星をつけるのは今でも変わらないね

🎯👈👈👈👈👈
🤜💥ＡＢＣ💯🌴

↑PCG: Programmable

🎯👈👈👈👈👈
🤜💥ＡＢＣ💯🌴

↑PCG: Programmable Character Generator
　↑by X1シリーズ

>>224
https://www.amazon.co.jp/dp/477411328X

voidさんの本か
読んでみたいような読みたくないような

止めとけ
本がでた頃に2chに本人がきたけど本の内容酷評されたりおちょくられたりで撃退されてたｗ

1. Effective C
2. Modern C
3. SEI CERT C Coding Standard

Effective Cは第2版がModern Cは第3版が出てる
SEI CERT C Coding StandardはWebで読める

おすすめ情報元紹介ありがとうございます。
英語文献はブラウザで翻訳できるところは読むようになりました。洋書を読む方は自分で翻訳ですか、すごいですね、、、

俺はCをやるにあたって「はじめての8086」を読めと言われた
「はじめての486」も併せて買ったけど積ん読した

6502がいちばんおもしろかったなぁ。

初めて読むマシン語、8086、486ナツカシス

4004で電卓戦争やってた人いますか？

これのひとかな
https://www.youtube.com/watch?v=Kx0pVrx2TRw

>>242
だがCをインプリメントするとしたら最悪なCPUだよなあ

>>246
ゼロページが変数として使える最強やないか

09良いよね
http://www.st.rim.or.jp/~nkomatsu/mc680x/MC6809.html

ざいろぐちゃん
もすちゃん
もとらちゃん

Abstract Data type(ADT)を使ってstackとqueueを、固定長配列、動的配列、linked listで書く演習をやっている。逆ポーランド記法の電卓とか括弧の対応が正しいかというやつ。コードを読めば一応わかるけど一から書けといわれたら無理。stackとqueueは3種類の方法で自在に書けないと試験合格は難しいらしい。もう、6パターンまる覚えするためにひたすら書いているけどいちいちmakeするのが面倒くさい。
来週からはビット演算。そのあとI/Oと標準/数学ライブラリとやって、これでCは一旦終わり。後期からはアセンブラ。どんどん難しくなるんだけど方向性が情報系とは逆な気がする。あっちはあっちで大変そうだけど。

へー、高度なことやってるねー。MIT系の教科書かなぁ。

なんか80年代の教育内容だね
Secure Codingについては学んでるんだろうか

Securityについては、interface(ヘッダ)とimplematation(.cの実体)を使って、high cohesionとlow couplingを意識しろくらいことしか学んでないです。もっと高度なやり方があるんだと思いますが、今のところ応用まで手が出ないです。。。

それはまあCの普通の書き方というか昔々からのよくある設計の方針みたいな話で、セキュアコーディングとは何ら関係ない
本質的にはCに限った話でもないし、もっと言えばその回答は何も言ってないのと同じくらい内容がない
大体ヘッダとソース使ってってCならそらそうだろw

セキュアコーディングという私の知らない概念かあるんですね。これから習う内容に入っていれば良いんだけど

メモリを直接操作できる故の話よね
いうてOSやマシン語の知見も必要だし人間が気をつけるにも限界があるから
現実的にはコンパイラや周辺ツールを活用するのが常套(いまならAIもある)
体系だって学ぶ以上に指摘くらって得るものが大きい

構造体型のtypedef宣言とそれを操作する関数のプロトタイプ群をヘッダで宣言してエクスポートする。実体はソースに書く。継承なしのカプセル化であり「データ抽象化」と呼ばれるものである。

error handlingて項目が今後の項目にあった。assert.hやsignal.hなど。これがセキュアコーディングの入り口かな？ 今はここまで手を広げられないけど

いまはいったん忘れていいよ
後期でアセンブラ着手しだしたら
毎日のようにある脆弱性のニュースと頭の中でつながるから

>>257
ADTの前方宣言の構造体(incomplete)てやつですね。まさに写経中。freeするのがムズイ。別の関数でmallocしたのをきちんと順を追ってfreeしてやるのが難しい。意識せずにできなきゃいけないんだろうけど。パターンだからそのうち覚えられるかなあ

解放を忘れたり解放して場所を指したまま使ってしまったり人間はミスをする
特に複雑化して込み合ってくると見落としてミスる
だから現実にセキュリティホールなどが知らぬ間に生じて発見されて悪用されてきた
今はメモリ管理など含めた多くの問題の安全性を言語レベルで保証してくれるRust言語が登場したから移行できるなら移行すべきだけどね

>>260
異なる型の2つの構造体が相互にリンクを持ち合う時、そして俺の知る限りその時にのみ、構造体のタグによる前方参照が必要。

他は別にtypedefした構造体を普通の型としてインスタンスを宣言するだけ。newは芋蔓式に次から次へと下請けのnewを呼ぶだろうしdeleteも同様。

頑張れ。

ある構造体を型としてtypedefしようと思えば、もしそのメンバーとして別の構造体型が用いられていればその構造体型もその時点でtypedefされていなければならない。それをするためにはその別の構造体型のtypedefが行われている別のヘッダをインクルードするのが普通で、それは芋蔓式のインクルードになる。ヘッダの多重インクルード対策は簡単なので問題は起こらないと思う。

ていうかC++もそうでしょ？

typedef struct { A a; } B;
typedef struct { int i; } A;

struct A_;
typedef struct { struct A_ a; } B;
typedef struct A_ A;

>>265 >>266
コンパイラがBのサイズを決めるために必要なAの定義を先にしてあげよう

// 相互参照はインクルードでは対応できないで前方宣言する
struct B;
struct A { …, B *b, … };
struct B { …, A *a, … };

こんな感じにできない？（うろ覚え）

typedef struct tag_1
{
struct tag_2* ptr2;
} Type1;

typedef struct tag_2
{
struct tag_1* ptr1;
} Type2;

オンラインのコンパイラでしか試してないけどC++も
class A { class B *b; };
class B { class A *a; };
みたいな記法は許容されてるな
Cはtypedefしないと毎回structが必要になるから省略できるC++とは標準スタイルが違いそう

C言語が難しいなんて思うやつは、C++を少しでも知ったら発狂して自殺しそうw

>>270
こういう書き方大っ嫌い

後方参照を許さないC言語が時代遅れなことに気づかないとな
Cコンパイラしか提供されない組み込み環境なら仕方ないが
そうでないならC言語を今すぐ捨てるべきだ

>>274
C言語はUNIX用のプログラミング言語なんだが？

x 設計が悪い
o 設計がシンプル

設計が悪いも何も、ポータブルなアセンプラとして計算機に寄り添う形で設計してあって、それは今も変わらないのでは
今となっては古いと言われればそうかもしれないけど、古いことは別に何も悪いことじゃない

アセンブラはカッタルイからこんなん作ったよ
なレベルの言語に文句言ってもなぁ

もともとのC言語はハードウェアの性能を100%出せることを前提に設計されているから
機種依存がわんさかとある言語

>>279
UNIXの仕様を想定して作られたC言語は、別のOSでは前提条件が違っていて勝手にC言語を移植されて問題になった。

アセンブラがかったるいからと言って
｛とか
｝とか
＝＞とか醜い表現使うなっての

自分の知らないC言語のようだ

#define begin {
#define end }

ゲーッ。17章も参照のこと。

begin/endをdefineするのは懐かしいなぁ。
やったよねぇ、Pascal風の言語にしちゃうやつ。
おれはstructuerにfunction入れてsmalltalk風に使ってた。C++できる以前。

プリプロセッサの素晴らしく駄目な使い方だな

comp.lang.cのFAQに載るくらいだから>>283とか>>285みたいのは昔から腐るほどいたんでしょ
バカというかセンスがないやつに道具使わせるとどう使うかっていうよくある例だわな

pascal風の簡易DSLをヘッダーだけで作成して、
最上位の業務階層は、簡易DSLで保守。
pascal部隊もいたので。

可読性の問題だよねぇ。C言語でも効率より可読性をとれば、わかりやすくはなる。
だけど高級アセンブラなので、効率がよく可読性の高い「設計と構築」が求められる。

プリプリプロセッサを作らないならば、
プリプロセッサだけで効率と可読性を求める。

ラダー回路が最高

初期のC++がただのプリプロセッサだったというのは皮肉

ポインタと配列の違いとかまあ微妙だわな。全部ポインタでええやろとは思う

さらにポインタはintの使い方の一つという扱いで補って、あれアセンブラのままがシンプルでよかったかな？

intじゃ代替出来んわな

ちょっと厳しかったですか
やっぱりポインタが持つ型というものは、生成コードに間接的にしか表れませんが偉大ですね

まあunsigned charとかintとか設計悪いよな
i8 <- 8bit符号あり整数
u64 <- 64bit符号なし整数
な感じで、i8/i16/i32/i64、u8/u16/u32/u64、f32/f64とかでええやろ
ポインタ型も最初からpi8/pvoidみたいなの使えるようにしとけ
構造体やクラス(C++)もあるから*は必要だが

>>297
C言語はUNIXを作るために作ったと何度、言われればわかるのか？

メモリが56KBとかのマシンで作られた言語だからな
仕様なんて必要最低限しかない

もともとの仕様な

こういう>>297みたいな「dmrより俺の方が分かってる」みたいな手合いって世界中にいるんだろうな
誰かのやった仕事に対して何十年も経った立場からキャンキャン吠えるとかそんな恥知らずなマネよく出来るなw

仕様の解釈に柔軟性を持たせたから今でも現役で残っているとも言える

>ポインタ型も最初からpi8/pvoidみたいなの使えるようにしとけ
>構造体やクラス(C++)もあるから*は必要だが
矛盾してるな
構造体aのポインタをpaとするルールを入れろと言ってるようなもの
それなら*aと何も変わらん

結局上流の仕様を深く考えられる俺たちがC言語設計しとけばだいぶ世の中変わったよなあって話だな
ポインタ一つとってもvoid*でポイドポインタにキャストできる利便性と引き換えに本来の型情報喪失っていう致命的なミスしてるしメモリバグの要因になってる
当時の人は何を思ったのやら

だから、アセンブラ直接使いたくなかっただけだから
変数の型なんてレジスタの延長としか考えて無いんだよ

Cコンパイラしかない組み込み環境でないのならC言語を今すぐ捨てろ
ちゃんとした強い型付け言語を使え

むかし某旧帝大の講義でヌルポインタを全ビットゼロのポインタのことだとか説明してるのを聴いたときは
所詮日本ってこの程度なんだなあとガッカリしたな

>>307
初期のCの時代にはそれで合ってるよ
ヌルが特別な状態を示す様になったのは
最近だろ？

>>307
当時は合ってる
全bitが0のバイトで文字列の終端もしくは文字がないことを表したり
全bitが0のアドレスでポインタ列の終端をもしくはアドレスがないことを表していた

#define NULL ((void *)0)
だもんなあ

しかし、アドレス 0 が有効なアドレスであるシステムならまた違った値になっているだろう

#define break exit(-1)

>>306
Rustと以外でおすすめある？

>>310
なんとあるんだよな
組み込みの場合な、RAMが先頭に配置とか
ブートモード設定でアドレス空間を選択できたりするんだが、その中で選べるから怖い
セクション割り当てなきゃいいんだけど

CPUのアーキテクチャ次第だからヌルポは0じゃ無くて定義次第

>>314
なるへそ

すごいな惨憺たる感じだな
>>308-310,314とバカばっかりじゃんかw
まじてFAQくらい読んだ方がいいよそんな知識なら

>>314
CPUのアーキテクチャは一切関係ありません
各プログラミング言語の取り決め次第です
使わないと決めたアドレス値を特別扱いして無効アドレスとみなして取り扱っているだけです

>>317
あ？
どんなCPUで動かすコード吐くのかが一番大事だろw
机の上だけでニンマリするだけならいいけどなw

>>318
C言語の規格書 ISO/IEC9899 にて
NULLポインタは値0と定められています
CPUアーキテクチャとは一切無関係です
プログラミング言語Cが定めているためどのCPUアーキテクチャにおいても同じ値0です

>>319
これ
昔は不定で後に0として定義された
だから何人かは反対のこと書いてる

ゼロ番地にアクセス出来ないとかモトローラ系とかディスってる？

>>319
どのCの規格書だ？C89、C99、C11のドラフトっぽいもので確認すると
stddef.h の所で以下のように記述されている

The macros are
NULL
which expands to an implementation-defined null pointer constant; and ...

すまぬ
C11の 6.3.2.3 Pointers の 3 に以下の詰があった
確かに 0、もしくは void * にキャストされた 0 だわ

An integer constant expression with the value 0, or such an expression cast to type
void *, is called a null pointer constant.

C11まだ導入してないな
C99には移行したけど

>>308-310 >>314
まずポインタが現れるべきところに書かれた0が具体的な数値型の値やアドレスじゃなく、ただのシンボルってことは分かってる?
シンボルだから0でも1でも9999でもnilでもどう決めてもいいんだが、Cは0を選んだってだけの話なんだけどな
具体的なメモリの番地がどことかそれが番地を数値で表記できるアーキテクチャなのか、そうでない例えばタグ付きアーキテクチャみたいなのかとか内部表現はどうでもいい
これが分かってないなら悪いこと言わんからイチから勉強し直した方がいいよアタマ悪すぎて話がループして結局FAQと同じ結末だから

>>325
数値0と定められている

ほんまかいな!?

>>325
ただのシンボルだという事は知らなかったわ
実装依存の話だが、仮想記憶のあるモダンOSならユーザーアドレス空間の0ページ目は潰しておいて
ページフォールトが発生するようにしているから、内部でもNULLは0にしているのがほとんどだろう

null pointer constantとnull pointerは別のもの

>>325
嘘つくなよ
シンボルではない
明確にinteger 0と決められている
ISO/IEC9899/1999の6.3.2.3を見ろ

整数0をnullポインタとするがnullポインタのビット表現は全ビット0とは限らない
となっているけど今現在nullポインタのビット表現が全0でない処理系は一つも存在しない

>>325
nullポインタの内部実装が全0以外の現在も使われているCPUを教えてくれまいか

ポインタをメタ情報＋アドレス（いわゆるfat pointer）で表現する系とか想定してそう
メタ情報は型IDとかサイズを保持してvoid *だとメタ情報も含めて0になる

c/c++って情報更新しなくて古い知識で語ってる場合がよくある

c11を理解せずにc99ぐらいで止まってる老害は多い。ちょうどJavaのヌルポで老害があぶり出されるのと同じ。
昔から老害の不勉強は変わらない

車載制御ソフト開発のときはマイコンメーカが提供するコンパイラの縛りはあったかも

ワシはC89じゃ
いやマジで

実務じゃ環境指定もあるもんな

AIにどの規格で書いて欲しいか頼めば書いてくれるやろ。しょーもない。

俺はC99

構造体の変数初期化で
.member=true
使いたいためだけ

それを除けばAPIは89でもいいや
しかし、俺らの生まれる前の規格まだ使ってるのなんとも言えん
89年って、、、

>>336
車載ってテキサスインスツルメンツとかのecuのイメージだが
最近は中華でいいらしいな

当時自分の生息圏ではルネサスのNEC系32bit 16bitが多かった
今もC89対応コメント//等一部C99対応という状況みたい
日本企業だからJIS規格に追従なのかも、そしてJISのCは実質C99止まり

同じ車載といっても画面表示系という話になれば状況は全く異なるでしょうが

仕事場で使われている処理系ってどこのやつが多いんだろ？
昔はGreen Hills一択だったが

昔じゃなくて大昔か

ちょっと興味深い話
https://note.com/sane_tulip3289/n/nd8f91c397479

「たまたま今まで動いていた」という話は耳が痛い人も多いはず

>>345
出だしの内容は共感できたのだけど
いかんせん長文過ぎて引用箇所は分からず仕舞い
こういうのはテーマを注入してAIに書かせるテスト結果？

Geminiに相談

問題が起きたときに責任転嫁できる相手がいることが重要

だからいまだにファックス使ってるんだよな

Green Hillsのコンパイラの話とか詳しく聞きたいなあ。
もう5chの存在意義ってこういう話題くらいじゃない？

GHS懐かしい
コンパイラが変わる移植作業でビットフィールドの順序が逆になるから並べ替えを行った記憶がある
その時の片方のコンパイラがGHSだったかも
pragmaで変更できる場合もあるけどその時は無理で並び替えたんだと思う

Green Hills絶賛使用中だよ
車載だと多いんじゃないか

グリーンヒルズ懐かしいな
昔、組み込みやってた頃に触ったっけ

コンパイラの選定や環境設定は自分でやってないので特に覚えているような事はないかも
つまり印象に残るようなトラブルはゼロだったという意味ね
グリーンヒルズは下手な人がアセンブラで書くよりもいいコードを出すということは耳にしていた

>>345
典型的なAIで造った文に観えるが

ポインタを!ptrみたいに否定演算子でナル判定するのってお前ら的にはどう？

株式会社アイ・エス・ビー
https://kizuna.5ch.io/test/read.cgi/infosys/1756826944/

https://special.nikkeibp.co.jp/atclh/ONB/24/isb0809/

別にどうも

>>356
個人的には有り
コールした関数が状況次第でXXX_NULLを返します、なんて仕様の場合の戻り値はXXX_NULLと比較。

NULL安全でないC言語は使うのをやめるようにと米政府が表明してから脱Cを進めてるよね

>>356
普通に使われてるが個人的には無し
検索する時区別がつかなくて面倒

esp32とかマイコンベンダーもrust推してる

Cコンパイラしか使えない一部の組み込み環境があるけど
そうでないならRustを使った方が良いね

なぜかRustは誰も使ってないからなあ

周囲や知人で誰も！？
珍しい偏った環境だな

5chのおっきいおともだちをのぞく

char*みたいにポインタなのにリテラルも入るとゆうガイジ仕様

アセンブラを楽に使いたいって発想で作られた言語だから型と言う概念が曖昧なんだよ

>>367
文字列リテラルchar[]を指すポインタを同時に定義できることからの誤解
アドレスとメモリのイメージができてない

char*に文字列リテラルが入っているわけではなく
文字列リテラルへのポインタでしょ？

いや、アドレスサイズに収まるデータならリテラルだろうが入るだろw

入るから入れちゃうおじさんにはちょっと難しい言語なんだと思う

配列もポインタとして機能するてそれじゃコード見ただけでコピーか参照を渡してるのかわからんやろ
さすがにゴミ仕様すぎ
cに関わってたケントンプンもgoでこのうんこ仕様使ってないしなんでこんなことになったんや

だから、アセンブラ面倒くさいでお気楽に作ったトランスレータだからだよw

それ
アセンブラすっ飛ばしてCやるにも相応の理解がいる

>>371
斬新な考え方だなw

>>373
Cの関数への引数は全部が値渡し
参照渡しはなくて、それっぽいことはポインタを数値として値渡ししているだけ

C言語の開発に携わったケントンプンw

アセンブラをラダーのように進化させたうえで
構造化すりゃ最高なんだが

もはやCがアセンブラみたいな扱いされとるわ

将来的にAIがアセンブラ吐き出すよりCを吐き出す方がいいよな

AI利用でC言語のコードを吐き出させるのはリスクが高すぎてほとんど行われていない
安全が保証されてほぼ同じ速さで動くRustが使われている

それがリスクなら最初からAIなんか使っちゃだめだよね

AIにとっても人間にとっても強い型付け言語が書きやすい
Cのような弱い型付け言語は実行デバッグに陥りやすいため

AIによる手抜きコーディングに対するプログラミング言語ごとの耐性が異なるってことは、AIコーディング時代を迎えるにあたっての知っておくべき現代プログラマーの基礎知識であり、リテラシーなんだよ。

リーナスがc以外に唯一認めた言語だしesp32とかマイコンもrust向けツールチェーン出してるから組込もどんどんrust移行が増えてる

ここにまでRust応援隊が来てるｗ

そもそもrustはC言語の代替として作られたものであるから速やかに移行することが望ましい
懐古趣味でもないかぎりわざわざ質の低い骨董品に固執する理由がない

Rustを使いこなせるようになった人は100%がCに戻りたくないけど
Rustの抽象的なコーディングのしやすさを会得できない人と食わず嫌いな人が残ってるよ

Rustの学習コストはCプログラマにはかなり高いそうだねえ

>>389
普通のモダンな言語を理解してる人たちはRustを難なく理解して使えてるから
C言語しか理解できない人は普通の言語に慣れていないのかあるいは

rustは自動型推論もあるからcと比べたらだいぶ楽よな
式で返せるのもなんかかっこいいし

ドットネットに慣れたらRustもちょい使いにくいけどな
派生、継承、オーバーライドをトレイトベースで書くことになる
でも、組み込みやってるとドットネット使えんからCかRustでええや！となる不思議

案件によって言語の得手不得手があって苦手だわ
適材適所な言語選ぶんじゃなくて一個で済ませたい

includeでまずつまずく

じゃぁ何をincludeすりゃ足りるのか
それで疲れ果てて終わる
最近の開発環境も拡張機能の巣窟で、そこでめんどくせーってなる

いいこと思いついた！
Rustでウェブブラウザとか作ったら安心安全じゃね？

>>392
クラスの派生、継承、オーバーライドは現在は悪設計とされている
だからモダンな言語Go・Rust・Nim・Zigなどにはクラスが存在しない
言語仕様からクラスを排除することで良い言語になってる

FireFoxがRustですんごいことになるからもう少し待て

>>396
マジか！
これから作り始めるの？

>>396
FireFoxのメモリ管理はC++
ソースが公開されてるのだから見てみろ

Servoを使ったVersoというのがあったはず

ChromeもEdgeもFireFoxいずれも部分的にRust化を進めている
新たな機能や改善のため作り直す機能から順に進めてる
どのWebブラウザも長期間にわたってハイブリッド状態が続くだろう

Rustの話題はRustスレでやれば、興味をもってくれる人が多いのに
ここではスレ違いなだけなんだぜ

オブジェクト指向はオワコンみたいな事言う奴に限って
なぜオワコンなのか説明出来ない

オブジェクト指向は重要だからRustなどモダンな言語でも採用している
オワコンはクラス継承があるクラス

とりあえずrustのことは忘れような
ここはCのスレだ
rustの話をするならCの話を巻き込んでしよう

^^

>>393
関数名で検索すれば出るだろアホか

>>389-390
それはない
むしろRustはCと感覚が近いから他の言語より親和性高い

Rust応援隊の書き込みを真に受けちゃダメ

スクリプト言語から来た人たちですらRustはメモリが自動解放されるからCと違って楽と言ってるもんな

>>393
>>406
今は検索すればそこそこ出て来るが
昔は関数のreferenceを観ても何をincludeすれば良いか描いてないあほなreferenceもザラにあった

まともな言語は関数や型を使う時
その名前空間を宣言する
Cだと名前空間とは別のヘッダー名でインクルードの怪奇

何かをしたいって時に、なぜあるかどうかもわからん関数名を知ることが出来るってんだね？
頭悪い馬鹿がいるもんだ

>>411
C言語は名前空間がないから仕方ない
全てグローバル直下
こんな時代遅れの言語を使うべきでない

makefileとかゆううんこどうにかならんの

ならない
それはCに限ったもんじゃないし

今のプログラミング言語はライブラリなどの依存関係を自動的に正しく解決するからmakefileのようなものは不要

漢は黙ってコンパイラ直接起動

パイ直

autoconfだっけmakefileつくるやつ

autoconfがconfigure作ってconfigureがmakefile作るはず

./configure
,/make
./make install

最後にこれやったのいつだろう