ขนาดวิดีโอ: 1280 X 720853 X 480640 X 360
แสดงแผงควบคุมโปรแกรมเล่น
เล่นอัตโนมัติ
เล่นใหม่
C言語で一番驚いたのはarray[index]は内部的には*(array+index)でしかないからarray[index]はindex[array]でも参照できる、ってやつ。
わたしもびっくりしました。し、最初はなんでそうなるのか理解できなかったです
これ未だによく分かっていないのですが、なぜこのような仕様になってしまったのでしょうか…
@@143658906 二項演算子の＋は2つの項が可換だから。C言語の文法の対称的な美しさだと思います。
でも書き方によっては最適化が変わって動作速度に影響が出るんだよなぁ
ほえおもろ
DOS時代にCでプログラムしていると、自由にメモリアクセスして（もちろんよくぶっ飛ぶｗ）ハードを直接制御できたりして、目の前のパソコンを自分がすべて乗っ取った気分になって楽しかった気がします。VRAM領域に適当に値を書き込んだら画面上にゴミとして表示されたりｗ、コンピューターの基礎構造が近く感じられて勉強にもなりましたね。
楽しそう
こういう動画のコメントにはプログラマの体験談やプログラムがあるから勉強になるし読んでて面白い。
C言語から入った人間からすると、メモリ管理しない言語の方が不安がある。Javaとかで原因が分からないエラーとかに当たると、ガベージコレクションとか疑う。
C++とかいうCの皮を被った全く別の化け物言語すこ
今現役でCの開発、コーディングをしていて、Cしかまともに使ったことが無い新人プログラマーだけど、これがここまで丁寧に説明されないとわからないくらい他の言語ではありえないって事実に逆にびっくりしてる業務上mapファイルでメモリの配置やソフトでアセンブリ言語に変換後のコードを見てms以下の単位で高速化を見たことあるので、ここまでではないにしろ他の言語でもメモリ配置は大まかに管理してるものだと思ってました
Cは便利なアセンブラってイメージですね。DOSの頃の知人は標準ライブラリ使わずに、まんまアセンブラ代わりにプログラミングしてました。
図鑑にない変なポケモンを捕まえたりできた理由かもしれない。というか、ほぼ確定的にそう。
このコメントのおかげで何を言っているか理解できた本当にありがとうございます
ぷにぷに あのバグの原因はまさにこれなんですよね・・・
アイテムや技の入れ替え裏技はポインタバグによるもの。
めちゃくちゃしっくりきた。ありがとう
教授みたいな声で聞いてて凄い安心する
C全然知らないんですが、こうやって特徴だけ教えてくれると楽しく勉強できるので良かったです
ポインタが難しいのは文法の設計と記号の使いまわしのせいだと思う。
プログラミング学習はPython3から入った勢だけど、1年前に初めてC言語触った時は眩暈がしそうだった...「こんな面倒くさい言語が何のために存在するのか」と......今は存在意義をﾁｮｯﾄﾀﾞｹ理解していると思います
言語単体を存在意義で考えると当然新しい言語の方が利便性が高く優れた点が多いのは間違いないですが、その言語がいつ、何に使われているのか？ということを考えると、なぜ今現在も存在するのか理解できます例えば自動車はC言語で書かれているプログラムがたくさんありますなぜか？それは今までの実績あるコードを捨てて、新たに書き直すなんてことはコストがかかるからしませんほとんどがテストにとてつもなく膨大な時間と労力が費やされます自動車はテストがアホみたいなにたくさんあってたった一行書き換えただけなのに数か月のプロジェクトとかありますそのほとんどがテストです
実は Python の処理系で最もメジャーなものは C で書かれてるんですよね。現代的なプログラミング言語を縁の下で支えているのは、多くの場合 C 言語なのです。
@@kyoniti2681 ありがとう！そういう意味で今もまだ使われている事もあるんですね！
ポインターの説明が分かりやすくて助かりました！
char s[6];sprintf(s, “apple”);s[5] = ‘!’;printf(“%s”, s);この実行結果を保証できないC言語。解説：char型配列sに文字列“apple“を入れると、’e’の次の配列の要素はヌル文字が自動的に入る。C言語ではヌル文字が来たら文字列の終端と見做しているのでヌル文字が’!’に変わった途端文字列の終端がわからなくなり実行結果を保証できなくなる。またint *a;a = 256;*a = 1024;とやるだけで一般保護例外でOSが落ちるプログラムを作れるのもC言語。
初めまして。僕の昔の失敗談ですが、ヌル文字でなくてstdio.hで宣言されているgetc()と同じところで定義されているEOFで困ったことが起きたことがありました。簡単な部分コードですが、以下のものが期待通り動く処理系と動かない処理系があったのです。FILE *fp;char c;// fp をfopenし終えたものとするwhile ((c=getc(fp)) != EOF) { putchar(c);}何がまずかったかというと、char c; （←ここ訂正しました）のところで c が signed char になるか unsigned char になるかが処理系依存だったのです（大きなプログラムで異常を発見してからここに到達するまでに一晩徹夜しました）。いずれの場合もEOFは -1 と定義されていました。教訓として「getc のプロトタイプ宣言通り、getc の値を代入する先は int にするべきこと、またはどうしても char に代入したければ signed char とするべきこと」を得ました。他の言語でもそうですが、ある言語がどうこういうより、ライブラリのバージョンとか処理系依存性を気にすることが大切だと思いました。（追記 本文中 char c; とするべきところを間違って int c; と書いていたので訂正しました。）
同じ経験しましたよ。POSIXが制定される前にRTOSにかかわりはじめ、今でいうスレッドセーフで無い！ソースにもげんなりしたことがあります。
初めてのプログラミング言語がC言語でよかった。
アセンブラはメモリアドレスも明示するからコードを書く人が挙動を理解しているけど、Cはメモリ空間の割当はコンパイラ任せなので、オーバーフローした配列の領域に何が入ってるかわからないから、アセンブラより危険ですね。
C言語の元は読み書きしやすいDEC アセンブラ MACRO11です。DECのアセンブラのアドレッシングモードそのまま、というのがポインターです。ポインターが意味しているものは、まさにメモリーのアドレスそのものでした。
Cやったあと、PDP-11のアセンブラやりましたが、アドレッシングモードがCと同じで楽だったです。VAX11に移っても楽だったですね。。。懐かしい。
@@suenucata6964 R1にアドレス入れて(R1)で中身にアクセス。でしたっけ。@R1なんてのも。スタックポインターはR6、-(R6)でパラメーター保存して、(R6)+で取り出す。これ、--iとi++の原形。なので、Cはiの前にも後ろにも使えるから便利〜と感激した記憶があります。
@@QuadraPro そうそう！。インテル・モトローラもあわせてやっていて混乱しましたが。。。レジスタにまつわる流儀はその後ARMに継承された感じです。
pop-11のアセンブラだとレジスタ相対アドレッシングモードが非対称で R++と ---Rしか無かったので自然に C 言語でもそう書きます。
ミニコン時代にCを覚えました。その前には紙テープを切り貼りしFORTRAN3000で高級言語を勉強をした世代です。 昔のCはK&R仕様でコンパイラも大らか・・・「引数の数」が合わなくてもパスしていました。（VMS-C）処理系の制約で変数などの文字数制限などは当たり前。。。 メモリ節約のためにあらゆる技を使いましたが、現在では悪いこと？に使われるので墓場にまで持っていきます。RISCプロセッサが登場したころ、当時のコンパイラが生成するマシンコードはコンパクトで驚いた記憶があります。 当時汎用性を高める（かなり性能は落ちる）ソースの工夫がいろいろありましたが、現在のPythonに受け継がれています。コンストラクタ・デストラクタのアイディアも当時からありましたが、メモリーリークすると「ほぼ瞬時に」落ち、バグとなったので現在ほど危険視されなかったです。主記憶MByte級になり検査ツールが重要視されてきましたね。
ハード寄りのC言語等しか触れてこなかったので、近年の高級言語の利便性が分かりました。組込み系なら製品の小型化、低コスト化、リアルタイム性などを考え、必要最低限のコンピュータ(マイコン等)を高速動作させる必要が出てきます。なのでオーバーヘッドが小さく高速動作するC言語を使用しているようです。
組み込みをVxWorks（というUNIX系OS）で昔からよくやってました。昔はオールアセンブラでしたが（80386時代位まで）、今はブート時のコードがアセンブラ必須で（というか先ずVxWorksのポーティングしないと話にならない）ファームもＣ＋＋で書くのが普通になってきてますね。
初学者向けプログラミング講義を受けたとき、初めてC言語を触ったが、絶対初学で習うような言語じゃないだろと思った。この動画を見て実際そうっぽくて安心した……配列の要素数を途中から増やせないとか嘘だろ？？って思ったし……
でもホントは他の言語では増えたときに全コピーしてくれるだけなんですよね
mallocで配列作ってreallocすれば要素数変えられますよ
アセンブラとかBASICみたいなメモリ直書き時代と比べると、充分初学者向けになってるんですよねぇ···時代の流れって恐ろしい
最初にC++じゃなくてよかったと思うしかないですね。
本当に低レベル言語は奥が(闇が)深い
配列範囲外へのアクセスは未定義動作なので、仕様の上では任意の処理が実行されうるんですよね。もちろん殆どの処理系は範囲外にそのままアクセスすると思いますが
c言語の特徴としてアセンブリ言語を呼び出せるというのがありますよね
面白いです。ありがとうございます。
C言語を始めて習った時はポインタの概念がなかなか理解できなかったのですが、アセンブラを知るとすんなり理解できて、先にアセンブラを教えてくれればよかったのに、と思いました。
興味深く拝見させていただきました。Cのメモリモデルに関わって色々面白いですね。9:56のところで「結構危険なところがあります」についてちょっと補足したいと思います。データの破壊を発生しかねないほか、そういった「out of bound」なアクセスが「undefined behavior」であり、コンパイラーが最適化することでコードを変形して違う意味になってしまう場合もあります。例えば、コードにない無限ループを生み出してしまうかもしれません。改めて、気をつけないと。
cは知ってるけどGOは初めて見たから異星人見てる気分やｗ 変数の後ろに:って新鮮だわ
組み込み系だとそもそもマイコンメーカーがC言語のコンパイラしか用意してないので仕方なくC言語使ってるという意識の人も多いかも。個人の主観ではマイコンの各種機能使おうとするとレジスタをいじり倒すことになるのでメモリを直接操作できるC言語が色々と都合がいいのかなと思う。まあ、CPUが変わると命令セットが違うので機械語もアセンブリ言語も変わってしまうのでその一つ上の水準になるC言語が一番組み込み屋さん的には使いやすいよねってだけの話でしょうけどね。OSを作るような人たちだとさらにCPUモードとか例外レベルとかそういうCPUの仕様レベルの話が必要だからアセンブリ言語から逃れられないらしいけど…本当かどうかは知らない。
メモリを壊しながら進んで落ちた場合、その上書きした内容から壊した個所を予想しながらデバッグしてもんです。COBOL→Cの後にVB6を使いましたが、どうやってメモリ管理してるんだ？という気持ちになりましたね。string型とか。
ポインタで面白いと思ったのは、関数のポインタも作れるっていう点ですね。いわゆるコールバック関数を使えるし、関数の配列というのも作れる。
変数aの値が格納されているメモリアドレスと、変数bが格納されているメモリアドレスは、必ず隣り合っているかは分からない。配列a[1]とa[2]なら必ず隣り合うので、ポインタの演算する時は、だいたい配列と関係がある。逆に、配列と関係無いところでポインタの演算は、しない方がバグが減る。
マルチプロセッサでなければ、配列でなくても結局は隣り合うので、それ前提にコーディングすることはあった。というかポインタは配列でなくリスト構造でつかう。あくまでも動画は比較するための無理やりな例示だから、これはこれでアリだと思う。
第一言語(?)がpythonで次の言語としてcを授業で習ったときは難しかったのを思い出しました
びっくりしたこと・sprintf が文字列の変数代入に使われてること・atoiが ASCII to Integer (文字列型から数値型への型変換)の略であること・デバッグの時などのログ出力でも型を気にしなければいけないこと・使われているメソッドの参照元を探すのが難しいこと(そもそもメソッドの中身を見に行かなければ分からない設計なのも悪いけど)・try-catch機構が無いことjava,python,typescriptとか触った後にやると発狂しかける
プログラマーとして仕事をやって初めて分かる恐ろしさCさわりたく無くなった
PICみたいな、メモリーが1KB以下のマイコンを使っていると、おそらく将来的にもC（もしくはアッセンブラ）が最適。高級言語は遅いとかメモリー食うと言うけど、それはつまり「電気を食う」ということで、電池駆動やワイアレス給電、太陽電池給電のように、ギリギリの電力で動かすアプリケーションでは、致命的な欠点になる。まあ、どんな言語使っても、パンチカードやマークシートでプログラム書いてた時代からすれば楽。
cobolとBASICしかやったことのない自分がC見るとプログラム短くてびっくりしました。変数の宣言もシンプル。あと、ループの終了条件も、COBOLなら「Aになるまで」と定義するのが、Cは「Aにならない間」と定義するので、最初は混乱しました。あと、桁落ちの処理ってCOBOLだとあり得ないので、それもびっくり。
ポインタと配列が曖昧なのを悪用して、3次元配列に見せかけた3重ポインタ配列とか謎コード書いた記憶が💦
今はCが高級言語に含まれない事に驚いた。
これは口が滑った(テキストにも書いちゃってますが)ので反省しています。そもそも高級言語と低級言語というのが明確に定義されていない言葉なので安易に使わずに「アセンブリ言語といまどきのリッチな機能を持つ言語の間」くらいの言い方をすべきてした。
ネット黎明期にC言語を習っていたけど、すぐにC++とか出てきてさらにhtmlとかやらされたりで全部投げ捨てた記憶がある。
長いのでチャプター分けしてくれると🙏
shoutout to the youtube algorithm for recommending this to me when i don't speak japanese
プログラマーの掲示板みたいな所で、C言語は最も低級言語に近い高級言語と仰っている方がいらっしゃったのですが、実際そんな感じなのでしょうか？
はい、そんなかんじです
生産性の良いアセンブラみたいな感じですね。
PC用C言語と組込み用C言語は別物のように感じます。前者はソフトウェア上でお膳立てされて他言語とそれほど違和感なく使える。後者はハードウェアの構造・挙動の理解前提でないと使えない。結局「CPUが何か」という部分が、他言語はPC前提でOS依存になってるから知らなくても動く。…合ってます？
はい、おおむねそんなかんじです
配列のサイズについて。厳密にはCにおいても配列が定義されたスコープであればsizeof(a)のようにサイズを取ることができる。ただ他の関数に渡したときにはどうやっても配列はポインタになってしまうのでサイズが取れない。ただし配列へのポインタという宣言ができてそこで配列のサイズを指定できる。それで配列を受け取るようにすると一応はサイズを取ることができるけど、関数の定義時にサイズを知ってなきゃならんのであんまり意味がない。つまりこういうこと。$ cat a.c#include void func(char (* ap)[100]) { /* apは要素数100のcharの配列へのポインタ */ printf("%ld", sizeof(*ap));}int main(void) { char a[100]; func(&a); return 0;}$ cc a.c && ./a.out100という結果が得られる。非常に重箱の隅をつついた話だし、全く知らなくてもCのプログラムはかけるので本当に要らない情報でしたw
配列の要素数はCだとsizeofで配列全体の大きさを一つ分の要素数でわるんだっけ
初めまして。僕はCやC++を長らく使っていた者ですが、興味深く拝見しました。他の方もコメントでおっしゃっていますが、自分でメモリ管理（あるいは配列の長さの管理）をするならするで、最後まで面倒見ないと気持ち悪いと思いました。少し気になったのですが、最初の要素5個からなるint型の配列aについて、C言語でもsizeof(a)を使えば配列aの長さはわかるのではないでしょうか？もちろんアドレスaを他のポインタpに代入してしまうとpがポイントしているところの長さの情報は失われますが。個人的には自分がCで一からプログラムを書く場合はあまり変なバグを仕込んで困ったことはありませんが、他人のCのコードを見たりデバッグするのは苦痛ですね。
C言語、自由度が高くて良いよね。
あまり気にせずＣ使ってて結構あぶない使い方してたんだなって思った(小並感)
これ、昔似た様なことを試したことがありますが、実行されずにbus errorで停止しました。なぜだろう。
それはこの挙動が実装依存だからだと思います。環境によって挙動が変わって、多くの場合は動画のようになる、といった具合です
関係ないけど、めっちゃ大学のオンライン講義受けてる感覚になる動画（現役大学生並感）
Cしか知らないからこその驚きがあって面白かった
エラーを出す主体者が現代の高級言語とCでは違います。現代の高級言語はスクリプト言語なので動作時にチェックが走りますが、C言語でコンパイラオプションで違うって言ってるのはそもそもコンパイラオプションでビルドした実行ファイルが起動時に確保するメモリ領域です。gccなんかだと最適化レベルを下げるとメモリ領域を余分に確保するためにこの例のような範囲外のアクセスができますが、最適化オプションを上げると静的メモリの確保についてはだいぶ最適化されるので範囲外のアクセスはOSによって殺されます。
現代の高級言語がスクリプト言語であるというのは乱暴だと思います。例えばシステムプログラミング言語であるRustはスクリプト言語ではないですし、ここで挙げられてるGoもスクリプト言語ではありません。
画像処理系だとポインタの加算とかはよくやるかなー
初心者のころsegmentation fault 地獄だった思い出
範囲外のデータを読み書きして起こったバグってどうやって見つけるんだろう？確定的におかしな事が起こるとも思えないし、ランダムでバグるって最悪の事態に遭遇する気がするのですが。
はい、おっしゃるとおりの最悪の事態になります。エスパー能力を駆使してなんとかします。一言ではとちょっと説明しづらいですねテン
@@satlinuxtube5260 考えただけでも絶対にやりたくないバグとりだな。影響範囲も運次第ではシステムトラブルで起こりうる最悪を引きかねないし。
メモリ管理は初期化でPoolし、終了時にまとめてメモリ廃棄する考えでやるとバグが減りますね。経験則ですが、局所的に mallocで確保、廃棄を繰り返すと、コード量の増加に伴い、リークが増えますね。
その経験則はOS(エンジン)依存じゃないかなあ。リーク起こさないようスレッドに分けてた記憶があるよ。
@@MedakaNoBoo 確かにスレッド調停は必要ですね。
@@netbsdmania716 ＞……この動画では配列(情的割り当て)だからなあ。よく知らないけどGoってのは変数(?)を動的にとるのじゃないかな。そういう意味から、確保と廃棄を繰り返すところを危惧するって話ならあるだろうし判る気がするよ。
学部でC言語をはじめに習って、その後の講義を大体C言語でこなしていたので、専門分野で他の言語を使うときにＣ言語ライクな書き方をしてしまうのは情報工学徒あるあるだろうか。
競プロや研究などではC++のSTLにだいぶお世話になっています…(それでもdangling pointerやメモリリークは起きうるけど)やっぱり組み込み系はC++じゃなくてCを使わざるを得ないのかな？
GoってPascalっぽいですね。Cは配列の範囲外にアクセス出来ることが判ってて、態と構造体変数の複数の配列変数の塊のStructure{a[1,2,3], b[4,5,6], c[7,8,9]}のbやcの領域までaでアクセスしちゃえってことも出来ますね。可読性が悪くなるのでアルゴリズムの途中ではあまりやりませんけど。初期化の時だけとかね。aのforループ１個で全領域にHxFFを埋めるとか。
はえ〜すっごいわかりやすい…これが所謂メモリ管理が必要とされる所以ですかね？
懐かしいなC言語。配列の要素数は構造体にラッピングして使ってたな～。関数内ではポインタを動かせないように、ポインタ自体をconst引数にしたり初歩的なバグを出さないように書いてたな。もうちょい型安全な設計にして欲しかった。
大学のオンデマンド授業受けてる気分だ
ヒープオーバーを意識するのが苦手すぎて高級言語系の仕事に転職したから感慨深い内容でした😂Cの組み込みって開発の後半でメモリバグフリーズ原因発見に難航のパターン多発しがち💦欠陥言語とまでは言わないけれどC言語は使用する人を選ぶ認識です😇（ハードの知識が無い人間はやめたほうがいいってはっきり分かったんですよ😇）もう組み込み系には戻りたくないし、今のほうが楽だしお金もいいし偉そうに怒られないし（アセンブラやC言語使いは偏屈で意地悪な人も多かったなぁ…😭）…自分語り失礼しました！😭昔を思い出させる良い動画をありがとうございました！✨
C言語に詳しい先生、嫌味臭くて嫌いだった。ディスプレイ挟んでメールでやり取りするのが限界だった
40年 C/C++ で組込み系のコードを書いています。 C言語を使っていても実際は #define で配列のサイズを切って使うので説明の様な事は起きないですけどね。組込みでも C言語だけから C++ 言語も使える様になり、, とか使えば Java と同じ様にコードを書けて楽に成りました。元々電気科出身でハード設計もしていたし、永く組込みをやってしまうと他の業界へは移り難いです、Web系とかやりたくても呼んでくれないです。移れたのだったら羨ましいです。組込み系は何10年やっても変化が無くてつまらないです。
どうでしょう・・Int a, bは連続のアドレスにコンパイラが振ってくれれば良いですがアドレスpのインクリメントは危険ではありませんか？
昔、制御系（プロコン）のプログラムを作った事があります・・・。プロコンでは、独自のプログラム言語のコンパイラは厳格に構文チェックされエラーを取るのが大変でしたが、ある時期にC言語によるプログラミングによる”移植”をする事になり、C言語の真髄を知る良い経験をしました！！ただ、実際にデバックに入ると、コンパイラの構文チェックが甘いなという感じを持ちました、今はどうなんでしょうね・・・
警告とかはコンパイラ依存で、少なくとも昔に比べると今はかなり良くなったように思います
ポインタ p に対する p++ は、次の変数を指し示すだろうか？自分の感覚では、p +=4 とかじゃないのかなって思うんですけど。
たとえばintのポインタだとすると++でアドレスがひとつぶん(sizeof(int))進みます。4つ足すとsizeof(int)*4進みます。まあ配列外にいっちゃうと本来参照結果は未定義なんですが
これはPDP-11、VAX11マシンコードの名残ですよ。アドレスレジスタは8/16/32ビットを区別した体系でした。
「ここ十数年で生まれた言語」は「だいたいそう」と限定をしたのが気になります。・ここ十数年以降で生まれた言語でも少ないながらあるのでしょうか？・30年前から十数年前までの間の言語ではどうなのでしょうか？メモリ管理が必要なのって、アセンブラ, C, C++くらいしか知らないので、他にもいろいろあるなら教えてほしいです。
「だいたいそう」という予防線を張ったのは、マイナーな言語で自前でメモリ管理してるものがあると困るので、こう言いました。余計分かりにくい表現になったかもですね。ごめんなさい。たとえば20年ほど前に私が使っていたObject Pascalは自前でメモリ管理していました。最新版では違うかもですが
配列の範囲の話、昔のドラクエかなんかで、129 回逃げるコマンドを実行したら変なことが起こる、みたいな感じの裏技ってこう言うことなんだろうなっておもいました。
それ8bit符号あり整数じゃね？配列とは関係ないような…
昔はH/Wに依存したソフトを作ることが多かったから、ある程度H/Wを知った人がソフトを作ってたので、メモリに書き込まれている状態をイメージしてプログラムを書いてたんですよ。だから、配列を参照する別のポインタを敢えて作って別の配列として使ったり、switch文でbreakを入れずに次のcaseへわざと落としまくったりと、プログラマの技量というかセンスが問われる言語だったんですよ。ｗ
23:50 未来予測ができないのなら、現在をインクリメントすれば良いじゃない(C言語
こんな感じな言語だけど、構造体の代入演算子でのコピーができる事。（ANSI C）
古くはパスカル言語でも同様ですね配列に対するインデックス（指標）の範囲をチェックしてるのはパスカルの方チェックしないのでＣ言語は実行速度が速いという利点もある訳だが。
因みに、Goって、Object Pascalなの？
元々機械語（アセンブラ）から入ってるからCのポインタ概念は理解簡単だったなぁ。特に68000のアセンブラやってたら親和性高くて困らない。
C++やC#は？
goto C言語の世界
すみませんやらかしました面食らいました怒られました💦C言語辞典(技術評論社)みたいな、関数が中で何をしてるかの資料は必須なんですよね・・・
C言語を初めて見たとき、ちょっとアセンブラっぽいなと思ったなあ
C言語とC+++しか使ったことないからコレが常識だと思ってる今のところ業務で別言語を使うこともないしなあ
もしかして: C++
c+++とか脳細胞で核融合が起きそうw
組み込みではありませんが、PLCのラダー言語に比べれば、Cは高級なイメージがあります。
今はｃ言語って必修じゃないのか
いつの間に組込系はC言語使わなくなったの？
まあ、動画の中でも「アセンブリ言語」という単語が出てきましたが、この辺がわかってないとCはマトモに扱えないということでしょう。アセンブリ言語となれば当然、CPUの仕組みに関わってくるわけですからねぇ。レジスタ（アキュムレータ、インデックス、スタックポインタ、etc）だのフラグ（キャリーフラグ、ゼログラグ、etc）だのアドレス（0000H〜FFFFHとか）だの。
(今どきの)言語は共通動作環境(エミュレータ)のなかで動くので、メモリ管理の必要はない。C言語でも(パソコン、スマホなどでは)それらと同じ動作環境のなかで動くことから、メモリ管理にも意味が無かったりする。ただ、ロボットやら家電やハードウェア制御(俗に「組み込み系」)では、こうしたポインタの罠が普通なので神経をつかう。
動画ではデータベース上の値とメモリ上の値とを同列に例え話として扱っている。アクセス保護が違うんだが、まあ雰囲気だけなら間違いでもないかなあ。
結局、最後は TASM か Jusmin なんだよね(´ω`) by 昭和のおっさんです。
C言語は基本高級アセンブラ。21世紀以降に現れた言語は、メモリ管理しているのじゃないか？。ずいぶん昔は書いていていたけど、今は書きたくないなあ。
ポインタ好きすぎてWeb系でゲーム作るの辛い＾＾
ポケモン、セレクトバグはc言語だったから起きたのか？
ゲームボーイのプログラミングはCじゃなくてアセンブラだったらしいよ
配列を感じるバグを味わいたいならファミコンのFF3やるのがおすすめ。
gcは便利だと思うけど気持ち悪く感じてしまう、c好きのオッサンです…
cプラからでいい
ふふふふふ、そんなあなたには多重継承問題(菱形継承問題)をプレゼント。これがあったからC++はメジャーになりきれなかったんだと思う
@@Gransel 最近は Go とか Rust とか Class が無いのが流行りなので C++ でも使わないければ良いのでは、C++全部使える人はいないと思います。
C言語で一番驚いたのはarray[index]は内部的には*(array+index)でしかないからarray[index]はindex[array]でも参照できる、ってやつ。
わたしもびっくりしました。し、最初はなんでそうなるのか理解できなかったです
これ未だによく分かっていないのですが、なぜこのような仕様になってしまったのでしょうか…
@@143658906 二項演算子の＋は2つの項が可換だから。C言語の文法の対称的な美しさだと思います。
でも書き方によっては最適化が変わって動作速度に影響が出るんだよなぁ
ほえおもろ
DOS時代にCでプログラムしていると、自由にメモリアクセスして（もちろんよくぶっ飛ぶｗ）ハードを直接制御できたりして、目の前のパソコンを自分がすべて乗っ取った気分になって楽しかった気がします。VRAM領域に適当に値を書き込んだら画面上にゴミとして表示されたりｗ、コンピューターの基礎構造が近く感じられて勉強にもなりましたね。
楽しそう
こういう動画のコメントにはプログラマの体験談やプログラムがあるから勉強になるし読んでて面白い。
C言語から入った人間からすると、メモリ管理しない言語の方が不安がある。
Javaとかで原因が分からないエラーとかに当たると、ガベージコレクションとか疑う。
C++とかいうCの皮を被った全く別の化け物言語すこ
今現役でCの開発、コーディングをしていて、Cしかまともに使ったことが無い新人プログラマーだけど、これがここまで丁寧に説明されないとわからないくらい他の言語ではありえないって事実に逆にびっくりしてる
業務上mapファイルでメモリの配置やソフトでアセンブリ言語に変換後のコードを見てms以下の単位で高速化を見たことあるので、ここまでではないにしろ他の言語でもメモリ配置は大まかに管理してるものだと思ってました
Cは便利なアセンブラってイメージですね。DOSの頃の知人は標準ライブラリ使わずに、まんまアセンブラ代わりにプログラミングしてました。
図鑑にない変なポケモンを捕まえたりできた理由かもしれない。というか、ほぼ確定的にそう。
このコメントのおかげで何を言っているか理解できた
本当にありがとうございます
ぷにぷに あのバグの原因はまさにこれなんですよね・・・
アイテムや技の入れ替え裏技はポインタバグによるもの。
めちゃくちゃしっくりきた。ありがとう
教授みたいな声で聞いてて凄い安心する
C全然知らないんですが、こうやって特徴だけ教えてくれると楽しく勉強できるので良かったです
ポインタが難しいのは文法の設計と記号の使いまわしのせい
だと思う。
プログラミング学習はPython3から入った勢だけど、1年前に初めてC言語触った時は眩暈がしそうだった...
「こんな面倒くさい言語が何のために存在するのか」と......今は存在意義をﾁｮｯﾄﾀﾞｹ理解していると思います
言語単体を存在意義で考えると当然新しい言語の方が利便性が高く優れた点が多いのは間違いないですが、
その言語がいつ、何に使われているのか？ということを考えると、なぜ今現在も存在するのか理解できます
例えば自動車はC言語で書かれているプログラムがたくさんあります
なぜか？
それは今までの実績あるコードを捨てて、新たに書き直すなんてことはコストがかかるからしません
ほとんどがテストにとてつもなく膨大な時間と労力が費やされます
自動車はテストがアホみたいなにたくさんあってたった一行書き換えただけなのに数か月のプロジェクトとかあります
そのほとんどがテストです
実は Python の処理系で最もメジャーなものは C で書かれてるんですよね。現代的なプログラミング言語を縁の下で支えているのは、多くの場合 C 言語なのです。
@@kyoniti2681 ありがとう！
そういう意味で今もまだ使われている事もあるんですね！
ポインターの説明が分かりやすくて助かりました！
char s[6];
sprintf(s, “apple”);
s[5] = ‘!’;
printf(“%s”, s);
この実行結果を保証できないC言語。
解説：char型配列sに文字列“apple“を入れると、’e’の次の配列の要素はヌル文字が自動的に入る。
C言語ではヌル文字が来たら文字列の終端と見做しているので
ヌル文字が’!’に変わった途端文字列の終端がわからなくなり実行結果を保証できなくなる。
また
int *a;
a = 256;
*a = 1024;
とやるだけで一般保護例外でOSが落ちるプログラムを作れるのもC言語。
初めまして。僕の昔の失敗談ですが、ヌル文字でなくてstdio.hで宣言されているgetc()と同じところで定義されているEOFで困ったことが起きたことがありました。簡単な部分コードですが、以下のものが期待通り動く処理系と動かない処理系があったのです。
FILE *fp;
char c;
// fp をfopenし終えたものとする
while ((c=getc(fp)) != EOF) {
putchar(c);
}
何がまずかったかというと、char c; （←ここ訂正しました）のところで c が signed char になるか unsigned char になるかが処理系依存だったのです（大きなプログラムで異常を発見してからここに到達するまでに一晩徹夜しました）。いずれの場合もEOFは -1 と定義されていました。教訓として「getc のプロトタイプ宣言通り、getc の値を代入する先は int にするべきこと、またはどうしても char に代入したければ signed char とするべきこと」を得ました。他の言語でもそうですが、ある言語がどうこういうより、ライブラリのバージョンとか処理系依存性を気にすることが大切だと思いました。
（追記 本文中 char c; とするべきところを間違って int c; と書いていたので訂正しました。）
同じ経験しましたよ。POSIXが制定される前にRTOSにかかわりはじめ、今でいうスレッドセーフで無い！ソースにもげんなりしたことがあります。
初めてのプログラミング言語がC言語でよかった。
アセンブラはメモリアドレスも明示するからコードを書く人が挙動を理解しているけど、Cはメモリ空間の割当はコンパイラ任せなので、オーバーフローした配列の領域に何が入ってるかわからないから、アセンブラより危険ですね。
C言語の元は読み書きしやすいDEC アセンブラ MACRO11です。
DECのアセンブラのアドレッシングモードそのまま、というのがポインターです。
ポインターが意味しているものは、まさにメモリーのアドレスそのものでした。
Cやったあと、PDP-11のアセンブラやりましたが、アドレッシングモードがCと同じで楽だったです。VAX11に移っても楽だったですね。。。懐かしい。
@@suenucata6964 R1にアドレス入れて(R1)で中身にアクセス。でしたっけ。@R1なんてのも。スタックポインターはR6、-(R6)でパラメーター保存して、(R6)+で取り出す。
これ、--iとi++の原形。なので、Cはiの前にも後ろにも使えるから便利〜と感激した記憶があります。
@@QuadraPro そうそう！。インテル・モトローラもあわせてやっていて混乱しましたが。。。レジスタにまつわる流儀はその後ARMに継承された感じです。
pop-11のアセンブラだとレジスタ相対アドレッシングモードが非対称で R++と ---Rしか無かったので自然に C 言語でもそう書きます。
ミニコン時代にCを覚えました。その前には紙テープを切り貼りしFORTRAN3000で高級言語を勉強をした世代です。
昔のCはK&R仕様でコンパイラも大らか・・・「引数の数」が合わなくてもパスしていました。（VMS-C）処理系の制約で変数などの文字数制限などは当たり前。。。
メモリ節約のためにあらゆる技を使いましたが、現在では悪いこと？に使われるので墓場にまで持っていきます。RISCプロセッサが登場したころ、当時のコンパイラが生成するマシンコードはコンパクトで驚いた記憶があります。
当時汎用性を高める（かなり性能は落ちる）ソースの工夫がいろいろありましたが、現在のPythonに受け継がれています。コンストラクタ・デストラクタのアイディアも当時からありましたが、メモリーリークすると「ほぼ瞬時に」落ち、バグとなったので現在ほど危険視されなかったです。主記憶MByte級になり検査ツールが重要視されてきましたね。
ハード寄りのC言語等しか触れてこなかったので、近年の高級言語の利便性が分かりました。
組込み系なら製品の小型化、低コスト化、リアルタイム性などを考え、必要最低限のコンピュータ(マイコン等)を
高速動作させる必要が出てきます。
なのでオーバーヘッドが小さく高速動作するC言語を使用しているようです。
組み込みをVxWorks（というUNIX系OS）で昔からよくやってました。
昔はオールアセンブラでしたが（80386時代位まで）、今はブート時のコードがアセンブラ必須で（というか先ずVxWorksのポーティングしないと話にならない）
ファームもＣ＋＋で書くのが普通になってきてますね。
初学者向けプログラミング講義を受けたとき、初めてC言語を触ったが、絶対初学で習うような言語じゃないだろと思った。この動画を見て実際そうっぽくて安心した……配列の要素数を途中から増やせないとか嘘だろ？？って思ったし……
でもホントは他の言語では増えたときに全コピーしてくれるだけなんですよね
mallocで配列作ってreallocすれば要素数変えられますよ
アセンブラとかBASICみたいなメモリ直書き時代と比べると、充分初学者向けになってるんですよねぇ···
時代の流れって恐ろしい
最初にC++じゃなくてよかったと思うしかないですね。
本当に低レベル言語は奥が(闇が)深い
配列範囲外へのアクセスは未定義動作なので、仕様の上では任意の処理が実行されうるんですよね。
もちろん殆どの処理系は範囲外にそのままアクセスすると思いますが
c言語の特徴としてアセンブリ言語を呼び出せるというのがありますよね
面白いです。ありがとうございます。
C言語を始めて習った時はポインタの概念がなかなか理解できなかったのですが、アセンブラを知るとすんなり理解できて、先にアセンブラを教えてくれればよかったのに、と思いました。
興味深く拝見させていただきました。Cのメモリモデルに関わって色々面白いですね。9:56のところで「結構危険なところがあります」についてちょっと補足したいと思います。データの破壊を発生しかねないほか、そういった「out of bound」なアクセスが「undefined behavior」であり、コンパイラーが最適化することでコードを変形して違う意味になってしまう場合もあります。例えば、コードにない無限ループを生み出してしまうかもしれません。改めて、気をつけないと。
cは知ってるけどGOは初めて見たから異星人見てる気分やｗ 変数の後ろに:って新鮮だわ
組み込み系だとそもそもマイコンメーカーがC言語のコンパイラしか用意してないので仕方なくC言語使ってるという意識の人も多いかも。
個人の主観ではマイコンの各種機能使おうとするとレジスタをいじり倒すことになるのでメモリを直接操作できるC言語が色々と都合がいいのかなと思う。
まあ、CPUが変わると命令セットが違うので機械語もアセンブリ言語も変わってしまうのでその一つ上の水準になるC言語が一番組み込み屋さん的には使いやすいよねってだけの話でしょうけどね。
OSを作るような人たちだとさらにCPUモードとか例外レベルとかそういうCPUの仕様レベルの話が必要だからアセンブリ言語から逃れられないらしいけど…本当かどうかは知らない。
メモリを壊しながら進んで落ちた場合、その上書きした内容から壊した個所を予想しながらデバッグしてもんです。
COBOL→Cの後にVB6を使いましたが、どうやってメモリ管理してるんだ？という気持ちになりましたね。string型とか。
ポインタで面白いと思ったのは、関数のポインタも作れるっていう点ですね。いわゆるコールバック関数を使えるし、関数の配列というのも作れる。
変数aの値が格納されているメモリアドレスと、変数bが格納されているメモリアドレスは、必ず隣り合っているかは分からない。
配列a[1]とa[2]なら必ず隣り合うので、ポインタの演算する時は、だいたい配列と関係がある。
逆に、配列と関係無いところでポインタの演算は、しない方がバグが減る。
マルチプロセッサでなければ、配列でなくても結局は隣り合うので、それ前提にコーディングすることはあった。というかポインタは配列でなくリスト構造でつかう。あくまでも動画は比較するための無理やりな例示だから、これはこれでアリだと思う。
第一言語(?)がpythonで次の言語としてcを授業で習ったときは難しかったのを思い出しました
びっくりしたこと
・sprintf が文字列の変数代入に使われてること
・atoiが ASCII to Integer (文字列型から数値型への型変換)の略であること
・デバッグの時などのログ出力でも型を気にしなければいけないこと
・使われているメソッドの参照元を探すのが難しいこと(そもそもメソッドの中身を見に行かなければ分からない設計なのも悪いけど)
・try-catch機構が無いこと
java,python,typescriptとか触った後にやると発狂しかける
プログラマーとして仕事をやって初めて分かる恐ろしさ
Cさわりたく無くなった
PICみたいな、メモリーが1KB以下のマイコンを使っていると、おそらく将来的にもC（もしくはアッセンブラ）が最適。
高級言語は遅いとかメモリー食うと言うけど、それはつまり「電気を食う」ということで、
電池駆動やワイアレス給電、太陽電池給電のように、ギリギリの電力で動かすアプリケーションでは、致命的な欠点になる。
まあ、どんな言語使っても、パンチカードやマークシートでプログラム書いてた時代からすれば楽。
cobolとBASICしかやったことのない自分がC見るとプログラム短くてびっくりしました。変数の宣言もシンプル。
あと、ループの終了条件も、COBOLなら「Aになるまで」と定義するのが、Cは「Aにならない間」と定義するので、最初は混乱しました。あと、桁落ちの処理ってCOBOLだとあり得ないので、それもびっくり。
ポインタと配列が曖昧なのを悪用して、3次元配列に見せかけた3重ポインタ配列とか謎コード書いた記憶が💦
今はCが高級言語に含まれない事に驚いた。
これは口が滑った(テキストにも書いちゃってますが)ので反省しています。そもそも高級言語と低級言語というのが明確に定義されていない言葉なので安易に使わずに「アセンブリ言語といまどきのリッチな機能を持つ言語の間」くらいの言い方をすべきてした。
ネット黎明期にC言語を習っていたけど、すぐにC++とか出てきてさらにhtmlとかやらされたりで全部投げ捨てた記憶がある。
長いのでチャプター分けしてくれると🙏
shoutout to the youtube algorithm for recommending this to me when i don't speak japanese
プログラマーの掲示板みたいな所で、C言語は最も低級言語に近い高級言語と仰っている方がいらっしゃったのですが、実際そんな感じなのでしょうか？
はい、そんなかんじです
生産性の良いアセンブラみたいな感じですね。
PC用C言語と組込み用C言語は別物のように感じます。
前者はソフトウェア上でお膳立てされて他言語とそれほど違和感なく使える。
後者はハードウェアの構造・挙動の理解前提でないと使えない。
結局「CPUが何か」という部分が、他言語はPC前提でOS依存になってるから知らなくても動く。
…合ってます？
はい、おおむねそんなかんじです
配列のサイズについて。厳密にはCにおいても配列が定義されたスコープであればsizeof(a)のようにサイズを取ることができる。ただ他の関数に渡したときにはどうやっても配列はポインタになってしまうのでサイズが取れない。
ただし配列へのポインタという宣言ができてそこで配列のサイズを指定できる。それで配列を受け取るようにすると一応はサイズを取ることができるけど、関数の定義時にサイズを知ってなきゃならんのであんまり意味がない。つまりこういうこと。
$ cat a.c
#include
void func(char (* ap)[100]) { /* apは要素数100のcharの配列へのポインタ */
printf("%ld
", sizeof(*ap));
}
int main(void) {
char a[100];
func(&a);
return 0;
}
$ cc a.c && ./a.out
100
という結果が得られる。非常に重箱の隅をつついた話だし、全く知らなくてもCのプログラムはかけるので本当に要らない情報でしたw
配列の要素数はCだとsizeofで配列全体の大きさを一つ分の要素数でわるんだっけ
初めまして。僕はCやC++を長らく使っていた者ですが、興味深く拝見しました。他の方もコメントでおっしゃっていますが、自分でメモリ管理（あるいは配列の長さの管理）をするならするで、最後まで面倒見ないと気持ち悪いと思いました。少し気になったのですが、最初の要素5個からなるint型の配列aについて、C言語でもsizeof(a)を使えば配列aの長さはわかるのではないでしょうか？もちろんアドレスaを他のポインタpに代入してしまうとpがポイントしているところの長さの情報は失われますが。個人的には自分がCで一からプログラムを書く場合はあまり変なバグを仕込んで困ったことはありませんが、他人のCのコードを見たりデバッグするのは苦痛ですね。
C言語、自由度が高くて良いよね。
あまり気にせずＣ使ってて結構あぶない使い方してたんだなって思った(小並感)
これ、昔似た様なことを試したことがありますが、実行されずにbus errorで停止しました。
なぜだろう。
それはこの挙動が実装依存だからだと思います。環境によって挙動が変わって、多くの場合は動画のようになる、といった具合です
関係ないけど、めっちゃ大学のオンライン講義受けてる感覚になる動画（現役大学生並感）
Cしか知らないからこその驚きがあって面白かった
エラーを出す主体者が現代の高級言語とCでは違います。現代の高級言語はスクリプト言語なので動作時にチェックが走りますが、C言語でコンパイラオプションで違うって言ってるのはそもそもコンパイラオプションでビルドした実行ファイルが起動時に確保するメモリ領域です。gccなんかだと最適化レベルを下げるとメモリ領域を余分に確保するためにこの例のような範囲外のアクセスができますが、最適化オプションを上げると静的メモリの確保についてはだいぶ最適化されるので範囲外のアクセスはOSによって殺されます。
現代の高級言語がスクリプト言語であるというのは乱暴だと思います。例えばシステムプログラミング言語であるRustはスクリプト言語ではないですし、ここで挙げられてるGoもスクリプト言語ではありません。
画像処理系だとポインタの加算とかはよくやるかなー
初心者のころsegmentation fault 地獄だった思い出
範囲外のデータを読み書きして起こったバグってどうやって見つけるんだろう？
確定的におかしな事が起こるとも思えないし、ランダムでバグるって最悪の事態に遭遇する気がするのですが。
はい、おっしゃるとおりの最悪の事態になります。エスパー能力を駆使してなんとかします。一言ではとちょっと説明しづらいですねテン
@@satlinuxtube5260
考えただけでも絶対にやりたくないバグとりだな。
影響範囲も運次第ではシステムトラブルで起こりうる最悪を引きかねないし。
メモリ管理は初期化でPoolし、終了時にまとめてメモリ廃棄する考えでやるとバグが減りますね。経験則ですが、局所的に mallocで確保、廃棄を繰り返すと、コード量の増加に伴い、リークが増えますね。
その経験則はOS(エンジン)依存じゃないかなあ。リーク起こさないようスレッドに分けてた記憶があるよ。
@@MedakaNoBoo 確かにスレッド調停は必要ですね。
@@netbsdmania716 ＞……
この動画では配列(情的割り当て)だからなあ。よく知らないけどGoってのは変数(?)を動的にとるのじゃないかな。そういう意味から、確保と廃棄を繰り返すところを危惧するって話ならあるだろうし判る気がするよ。
学部でC言語をはじめに習って、その後の講義を大体C言語でこなしていたので、専門分野で他の言語を使うときにＣ言語ライクな書き方をしてしまうのは情報工学徒あるあるだろうか。
競プロや研究などではC++のSTLにだいぶお世話になっています…(それでもdangling pointerやメモリリークは起きうるけど)
やっぱり組み込み系はC++じゃなくてCを使わざるを得ないのかな？
GoってPascalっぽいですね。
Cは配列の範囲外にアクセス出来ることが判ってて、態と構造体変数の複数の配列変数の塊のStructure{a[1,2,3], b[4,5,6], c[7,8,9]}のbやcの領域までaでアクセスしちゃえってことも出来ますね。
可読性が悪くなるのでアルゴリズムの途中ではあまりやりませんけど。初期化の時だけとかね。aのforループ１個で全領域にHxFFを埋めるとか。
はえ〜すっごいわかりやすい…
これが所謂メモリ管理が必要とされる所以ですかね？
懐かしいなC言語。
配列の要素数は構造体にラッピングして使ってたな～。
関数内ではポインタを動かせないように、ポインタ自体をconst引数にしたり初歩的なバグを出さないように書いてたな。
もうちょい型安全な設計にして欲しかった。
大学のオンデマンド授業受けてる気分だ
ヒープオーバーを意識するのが苦手すぎて高級言語系の仕事に転職したから感慨深い内容でした😂
Cの組み込みって開発の後半でメモリバグフリーズ原因発見に難航のパターン多発しがち💦欠陥言語とまでは言わないけれどC言語は使用する人を選ぶ認識です😇
（ハードの知識が無い人間はやめたほうがいいってはっきり分かったんですよ😇）
もう組み込み系には戻りたくないし、今のほうが楽だしお金もいいし偉そうに怒られないし（アセンブラやC言語使いは偏屈で意地悪な人も多かったなぁ…😭）
…自分語り失礼しました！😭
昔を思い出させる良い動画をありがとうございました！✨
C言語に詳しい先生、嫌味臭くて嫌いだった。ディスプレイ挟んでメールでやり取りするのが限界だった
40年 C/C++ で組込み系のコードを書いています。 C言語を使っていても実際は #define で配列のサイズを切って使うので説明の様な事は起きないですけどね。
組込みでも C言語だけから C++ 言語も使える様になり、, とか使えば Java と同じ様にコードを書けて楽に成りました。
元々電気科出身でハード設計もしていたし、永く組込みをやってしまうと他の業界へは移り難いです、Web系とかやりたくても呼んでくれないです。
移れたのだったら羨ましいです。組込み系は何10年やっても変化が無くてつまらないです。
どうでしょう・・
Int a, bは連続のアドレスにコンパイラが振ってくれれば良いですが
アドレスpのインクリメントは危険ではありませんか？
昔、制御系（プロコン）のプログラムを作った事があります・・・。プロコンでは、独自のプログラム言語のコンパイラは厳格に構文チェックされエラーを取るのが大変でしたが、ある時期にC言語によるプログラミングによる”移植”をする事になり、C言語の真髄を知る良い経験をしました！！ただ、実際にデバックに入ると、コンパイラの構文チェックが甘いなという感じを持ちました、今はどうなんでしょうね・・・
警告とかはコンパイラ依存で、少なくとも昔に比べると今はかなり良くなったように思います
ポインタ p に対する p++ は、次の変数を指し示すだろうか？
自分の感覚では、p +=4 とかじゃないのかなって思うんですけど。
たとえばintのポインタだとすると++でアドレスがひとつぶん(sizeof(int))進みます。4つ足すとsizeof(int)*4進みます。まあ配列外にいっちゃうと本来参照結果は未定義なんですが
これはPDP-11、VAX11マシンコードの名残ですよ。アドレスレジスタは8/16/32ビットを区別した体系でした。
「ここ十数年で生まれた言語」は「だいたいそう」と限定をしたのが気になります。
・ここ十数年以降で生まれた言語でも少ないながらあるのでしょうか？
・30年前から十数年前までの間の言語ではどうなのでしょうか？
メモリ管理が必要なのって、アセンブラ, C, C++くらいしか知らないので、他にもいろいろあるなら教えてほしいです。
「だいたいそう」という予防線を張ったのは、マイナーな言語で自前でメモリ管理してるものがあると困るので、こう言いました。余計分かりにくい表現になったかもですね。ごめんなさい。
たとえば20年ほど前に私が使っていたObject Pascalは自前でメモリ管理していました。最新版では違うかもですが
配列の範囲の話、昔のドラクエかなんかで、129 回逃げるコマンドを実行したら変なことが起こる、みたいな感じの裏技ってこう言うことなんだろうなっておもいました。
それ8bit符号あり整数じゃね？
配列とは関係ないような…
昔はH/Wに依存したソフトを作ることが多かったから、ある程度H/Wを知った人がソフトを作ってたので、メモリに書き込まれている状態をイメージしてプログラムを書いてたんですよ。だから、配列を参照する別のポインタを敢えて作って別の配列として使ったり、switch文でbreakを入れずに次のcaseへわざと落としまくったりと、プログラマの技量というかセンスが問われる言語だったんですよ。ｗ
23:50 未来予測ができないのなら、現在をインクリメントすれば良いじゃない(C言語
こんな感じな言語だけど、構造体の代入演算子でのコピーができる事。（ANSI C）
古くはパスカル言語でも同様ですね
配列に対するインデックス（指標）の範囲をチェックしてるのはパスカルの方
チェックしないのでＣ言語は実行速度が速いという利点もある訳だが。
因みに、Goって、Object Pascalなの？
元々機械語（アセンブラ）から入ってるからCのポインタ概念は理解簡単だったなぁ。特に68000のアセンブラやってたら親和性高くて困らない。
C++やC#は？
goto C言語の世界
すみませんやらかしました面食らいました怒られました💦C言語辞典(技術評論社)みたいな、関数が中で何をしてるかの資料は必須なんですよね・・・
C言語を初めて見たとき、ちょっとアセンブラっぽいなと思ったなあ
C言語とC+++しか使ったことないからコレが常識だと思ってる
今のところ業務で別言語を使うこともないしなあ
もしかして: C++
c+++とか脳細胞で核融合が起きそうw
組み込みではありませんが、PLCのラダー言語に比べれば、Cは高級なイメージがあります。
今はｃ言語って必修じゃないのか
いつの間に組込系はC言語使わなくなったの？
まあ、動画の中でも「アセンブリ言語」という単語が出てきましたが、この辺がわかってないとCはマトモに扱えないということでしょう。
アセンブリ言語となれば当然、CPUの仕組みに関わってくるわけですからねぇ。
レジスタ（アキュムレータ、インデックス、スタックポインタ、etc）だのフラグ（キャリーフラグ、ゼログラグ、etc）だのアドレス（0000H〜FFFFHとか）だの。
(今どきの)言語は共通動作環境(エミュレータ)のなかで動くので、メモリ管理の必要はない。C言語でも(パソコン、スマホなどでは)それらと同じ動作環境のなかで動くことから、メモリ管理にも意味が無かったりする。ただ、ロボットやら家電やハードウェア制御(俗に「組み込み系」)では、こうしたポインタの罠が普通なので神経をつかう。
動画ではデータベース上の値とメモリ上の値とを同列に例え話として扱っている。アクセス保護が違うんだが、まあ雰囲気だけなら間違いでもないかなあ。
結局、最後は TASM か Jusmin なんだよね(´ω`)
by 昭和のおっさんです。
C言語は基本高級アセンブラ。21世紀以降に現れた言語は、メモリ管理しているのじゃないか？。ずいぶん昔は書いていていたけど、今は書きたくないなあ。
ポインタ好きすぎてWeb系でゲーム作るの辛い＾＾
ポケモン、セレクトバグはc言語だったから起きたのか？
ゲームボーイのプログラミングはCじゃなくてアセンブラだったらしいよ
配列を感じるバグを味わいたいならファミコンのFF3やるのがおすすめ。
gcは便利だと思うけど気持ち悪く感じてしまう、c好きのオッサンです…
cプラからでいい
ふふふふふ、そんなあなたには多重継承問題(菱形継承問題)をプレゼント。これがあったからC++はメジャーになりきれなかったんだと思う
@@Gransel 最近は Go とか Rust とか Class が無いのが流行りなので C++ でも使わないければ良いのでは、C++全部使える人はいないと思います。