【悲報】プログラミングの大先生、嫌儲で激論レスバ どっちの勝ち？ [364799964]
■ このスレッドは過去ログ倉庫に格納されています
https://imgur.com/
55 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:33:50.22 ID:kq23qcgY0St.V
>>1
プログラム関連においてエラーが出て意味不明に思う場合
それは断じて英語が読めないからではない
プログラムの技術に関するスキルが足りてないからだ
例えばヒープとスタックに関する技術を知らん人が
スタックエラーを翻訳して読んだところで何が理解できるというのか？
この回答者も返事が間違っていて
英語を読めるように努力するのではなく
メモリやアドレスに関するIT技術を高めることがエラー対処になると言わなくちゃいけない
恐らくこの回答者の実力も大したことないと思うわ
60 番組の途中ですがアフィサイトへの転載は禁止です (中止W 078f-eAyv) 2023/02/14(火) 14:35:08.83 ID:YcwzkYpW0St.V
>>55
何のエラーか一切書かれてないのに良くそこまで妄想できるな
病気だろ
70 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:36:21.03 ID:kq23qcgY0St.V
>>60
エラーというのはメモリに関するものが基本だろ
おまえもプログラムなんて組んでないな
ちょっとした言葉で実力なんてバレちゃうんだよ
80 番組の途中ですがアフィサイトへの転載は禁止です (中止 Sd4a-XiwN) sage 2023/02/14(火) 14:37:45.23 ID:PwdsPRWrdSt.V BE:821322453-2BP(1000)
>>70
質問者と同じレベルだよ君は
87 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:38:50.72 ID:kq23qcgY0St.V
>>80
NULLにしたってアドレス参照不能から来てる
スタックもヒープも・・・とにかく
お前らなんぞがプログラミングを語るな
102 番組の途中ですがアフィサイトへの転載は禁止です (中止W 078f-eAyv) 2023/02/14(火) 14:41:18.21 ID:YcwzkYpW0St.V
>>87
スタックオーバーフローなんてCでもめったにあり得ないが頭大丈夫？
8ビットマイコンでもいじってんの？
まあ8ビットマイコンでもそんなエラーは出ないがな
Cにはスタックオーバーフローを予測する機能がないから
108 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:42:32.86 ID:kq23qcgY0St.V
>>102
例えば多重に継承してるのを禁止した言語である場合
エラーは何をもって判断してると思う？
116 番組の途中ですがアフィサイトへの転載は禁止です (中止W 078f-eAyv) 2023/02/14(火) 14:44:21.39 ID:YcwzkYpW0St.V
>>108
javaのことを言ってるのかな
インタープリタ言語ごときでメモリのエラーがーとか臍で茶が湧く
127 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:45:48.97 ID:kq23qcgY0St.V
>>116
ヒープに対するアドレスが重複してたらエラーを出すんだよ
メモリ以外の何物なのか、それ 以前ほぼ同じ話題がプログラム板のc++スレでやってたわ
同じ連中同士じゃないだろうな？ >>101
レスバ(粗探し)だから...
なお現実のIT系の職場もこんな感じなのが多い模様😭
AIより不親切 
ITスレは自分の作ったアプリとかレポジトリの一つも見せられない奴らばっかりだから見てもためにならないよ いまプログラミング勉強しながらウェブサービス作ってるんだけどなんかやる気起きない >>105
bingに聞きながらやれば勉強必要ないんじゃね 普通に使ってれば型変換のエラーとか構文のエラーとかじゃないの？
メモリは実行したときに動きおかしくなったり予期せぬメモリアクセスとか言って落ちるとかな気がする error:japanese discussion is occured brk(2)を使ったことがあるものだけが石を投げなさい 電池の液漏れだったかで長時間レスバしてたやつ思い出した こういうの見るとITって営業の方がストレス溜まるんだろうな どんなソースか知らずにエラーコードについて喧嘩する
どっちも素人 つか、コーダーがエンジニアでもなんでもない単なる作業員だってことがよくわかるわ。 くだらねえｗ
ドキュメント読んで解決出来なければエラーメッセージをコピってググれば済む話 >>117
俺様がみんなの質問に全部答えるスレ
みたいなもんかw kqの人なんかプログラミング関係のスレにちょいちょい現れるよ。理解してない事について無理やり知ったかしてるから支離滅裂で見てて面白い
マスコットみたいなもん エラーなんてよく読まずにエラーの出た場所でステップ実行します ITマンってやっぱおかしいわ
機械に脳壊されてるやろ 嫌儲でレスバしてる時点でどっちも負けだよ勝ちなんてない 英語読めなきゃそもそも解決の入り口に立てないので話にならないです
どの程度できないのか >>124
日本って先進国の中では圧倒的にITマン少ない訳だが
その理屈で行くと日本ってマシな国ってことか 知識があるのはID:YcwzkYpW0St.V
ただ、あまりヒープだなんだって言うのはもともとの問題に関係ないと思う
プログラミングしててエラーメッセージは英語が多いのは間違いなくて、簡単な英語は読めたほうがいい
ただ、英語が完璧である必要はなくて、多少理解できるなら後はプログラミング知識が重要になってくる メモリどうこう言い出すのはC言語習いたてか組込みバカ
もうそういう時代じゃないんだ 本スレ敵対者が山形大の人の書き込みだと思い込む糖質おじさんも参戦してて草 ケンモジって10～20年ぐらい前の情報をずっと語ってるの多いし スタックオーバーフローって再起ルーチンをあんまり考えずに作ると割と容易に起こり得るよね 55 番組の途中ですがアフィサイトへの転載は禁止です (中止 0a56-D0vN) 2023/02/14(火) 14:33:50.22 ID:kq23qcgY0St.V
>>1
プログラム関連においてエラーが出て意味不明に思う場合
それは断じて英語が読めないからではない
プログラムの技術に関するスキルが足りてないからだ
例えばヒープとスタックに関する技術を知らん人が
スタックエラーを翻訳して読んだところで何が理解できるというのか？
↑
こいつの負け
なんでかと言うと、この大元の質問者は 「私は英語も読めませんし、だから理解できないのです」ってはっきり書いてるから
おわり 実際、Windowsの日本語エラーを見て
対応出来るかどうか
日本語を勉強しても無駄だろ？ スタックの仕組みなんてみんな知ってる
オーバーバッファランとかクラッキングでよくやる あほらし
どっちも必須スキルだろうに
ご飯を食べる能力と呼吸をする能力どっちをとるか？
なんてくだらんバトルしてるようなもの ケンモ・ブラッディ・ヴァレンタインて感じ
かっけえ🤩 >>103
生産性の低いアスペ自閉症の日本人らしい職場だね >>43
レスバトルの勝敗を判定できるAIか、すげえ需要ありそうだな メモリ操作ミス、メモリ管理ミスをゼロにするために
C/C++からRustへの以降があちこちで少しずつ始まりつつあるな 英語が読めるかどうかが重要かどうかって話なのかね
英語の話からどんどん話が深くなっているようだけど
英語なんてこの場合おまけ程度だとは思うけどね >>50
ちょっとしたのはallocaだな
自動で解放してくれるし >>132
その底辺大の統合失調のひとなんか反応してたぞ
本人居ないと思って好き放題書いてたら
中卒がどうこう言い出したのが底辺大の統合失調
ちなみにそのひとは統合失調を糖質とかく糖尿病の患者さんでもあるw alloca関数は昔のPC用C言語には入ってなくて
アセンブラやインラインアセンブラで
スタック操作のマクロ書いてたなぁ
その割にあんま使わなかったけど あとmalloc系はシステムコールのオーバーヘッドが大きいから、大きなメモリブロックを先に確保してその内側で自前のメモリ管理をする手法もあったな
ガベージコレクションを使う言語や
リアルタイム性能が要求される処理で使う手法 Rustは積極的に可能ならスタック上にメモリ確保してくれるからCで普通にヒープアロケーションしてるよりも速い
あとRustはスタック上でもヒープ上でも自動メモリ解放だから楽で間違いがない 某システムでRustベースのページ記述用マクロを使ってるけど、ループ構文無しで悲惨な感じ まあコンパイルすれば安全軽量動作というのが売りの言語を使ったマクロだから、停止性が必ずしも保証されなくなるループは取り去ったんだろうけどところがどっこい再帰は書けちゃうから何を考えてその仕様にしたのかよくわからん >>150
結果(エラーメッセージ)から原因(プログラムミス等)を突き止める逆向き思考が必要だから、コンパイラや言語処理系のエラー検出やエラーメッセージの癖に慣れないとちょっと難しいのかもね
大昔の日本製のコンパイラで、構文エラーがあってもある程度推測修正してしまう処理系があって
でもどう推測修正するのか挙動が謎で
エラーメッセージがエラー箇所と違う場所に出て使い物にならなかった >>156
普通ツール類の話でC製とわざわざ言わないように
そこでRust製と言う必要ある？
そのツールの仕様の話であってC製かRust製かは関係ないよね 英語の知識とプログラミングの知識どちらがエラーログの解釈に必要かと言われれば誰がどう考えても圧倒的にプログラミングの知識だろうね IT系のスレって絶対レスバ大好きエンジニアくん湧くよね C#とjavaとjavascriptくらいしかやらんから、こいつら何言ってるのかさっぱりわからん
普段スタックとヒープなんて意識せんからな
あと、どうでもいいけど、当たり前のようにcatch握りつぶしまってるコードがあって
エラーが出ててもエラーにならないという訳わからない糞システム思い出した >>159
Rustに興味ないから調べてないけど
マクロ部分はRust言語の使い回しだと思う 結局匿名掲示板で何か話が深まるには
それ相応の知能を持った人が揃う必要があって
それができない人が来ちゃうと本スレみたいな泥試合に
なるのだと今思った >>163
ヒープのスタックは基本中の基本だから
もしプログラミングに今後力を入れるつもりがあるなら
基本知識として勉強しておいた方がいい
逆にこれまで20年間と同様に知ったかぶりピエロとして人生を全うするつもりなら、今のまま無知なまま死ねばいいと思う ヒープのスタック→ヒープとスタック
スタックを知らないのはまあどうしようもない無知として
ヒープはただのメモリ確保領域を、スタックと対比する時の表現だから
ピエロくんのように意固地になる必要は全くない
こんなレベルの低い話でスレを2つも立てるのは
頭が悪すぎる 逆にコンピュータプログラムの動作を理解する時に
・スタックを介したルーチン呼び出し
・メモリ確保領域
の二つをきちんとイメージする事なく
プログラムの挙動を理解するのは
かなり無理のある事柄だから
そこのイメージが曖昧な人は
実際にはほとんど何もできない口先だけのひと
と判断して良いと思う
物理系でもそっくりなタイプのニセ科学者がいる
その人は物理を理解する時に頭の中に物理モデルを組み立てる習慣がなく、当然数学的モデルもなく
全て文字ベースの記号処理で理解しようとしているので
全く話が噛み合わない
そんな欠陥は在学中にすぐわかる筈なのに
それを通してしまった指導教官氏の見識が疑われる >>121
なんかしったかおじさんいるよね、azureだかAWSだかすら知らないのにIT系を名乗るおじさん
無職が語ってる感じだと思ってる >>169
設定ミスで大量課金されるのが怖くて AWS 全然
使ってなく文字情報だけで DOP のバッジもらった
自分は、なんていうおじさんになるのだろうか。 >>171
それは普通に詳しい大先生じゃん
なんかクラウドとかサーバーの概念がおかしくて「azureなんてしらねえよ」みたいな事言ってたおじさんがいたんだよな >>163
C#でヒープ意識したことないとか余程簡単なプログラムしか作ったことないんだろうな 求められるのはエラー発生時のタイムロスが少なく自走出来る人材のみ
エラーの理屈をｇｄｇｄ語る奴なんて現場に全く必要ない
そういうのは学生時代にやる事か、新人にパワハラ仕掛ける2年目のイキり雑魚 「現場」はレベルが低いから
院卒以上は研究開発部門に行くべき ヒープ＆スタック議論は自演だね
内容的にただの基礎知識なのに
どっちもまともな説明を避けて煽り合いをしているのは
どっちも基礎知識の欠落したお客さん 上にChatGPTとのやり取りを貼ってる人が居るけど
「ヒープはインスタンスですかリンクですか」
と言う質問自体が支離滅裂な統合失調作文だから
それがおかしいと気付かない時点で
自演確定
普通の人は、質問が狂っている人の
自演フレーム議論に関わっても時間の無駄だから
レスは付けないし、それに関するウォッチスレなど立てない ちなみに上で職場名の出ている統合失調患者が
物理実験講義を担当した時の騒動の記録があるけれど
この人自体、自分の専門分野をわかりやすく親切に
学生に教えた形跡はなくて、出欠確認を雑談でスルーして
大トラブルを起こし職場異動になった前科持ち
前科持ちになって心を入れ替えて、教育を真剣に
やっているという話は聞かなくて
学生の間ではブログにで学生への敵意剥き出しの
罵詈雑言を書いているキチガイという定評 >>2を見ると二人とも間違ってるよな
片方は「ヒープといえばインスタンス」
もう片方は「ヒープといえばリンカ」
リンカから見たらヒープ領域は様々なメモリセクションの一つに過ぎず
そしてヒープ領域はリンク後の動的な使用がメイン
インスタンスはクラスなど含む型という概念に対してその値を入れるメモリ実体に過ぎず
インスタンスはヒープ上にもスタック上にも確保できて両者で特性が異なる
例えば関数の中でスタック上に確保すればそこからの呼び出し子孫関数でも使えるが関数を戻った先の親関数では当然使えない
一方でヒープ上でインスタンスを確保すれば関数を戻った先の親関数でも使えるがヒープ上の確保コストに加えて解放義務と解放コストがスタックと異なり余分に必要となる
だからヒープといえば対立するスタックとの使い分けが最重要 >>1
>>53
国内最大のマッチングアプリ「ペアーズの統計」
男の年齢別人気会員の割合は26歳-37歳で高い(ピーク32歳）
女の年齢別人気会員の割合は20歳-29歳で高い(ピーク26歳)
https://i.imgur.com/AqqkzYb.png
これこそがフェミニストが大発狂する男女の適齢期の違いである
男の年齢は女のそれのマイナス7歳～8歳（市場価値は女の20歳＝男の28歳、女の30歳＝男の38歳、女の40歳＝男の48歳...）
厚生労働省「人口動態統計」による2015年に結婚した夫婦の年齢差
夫が11歳以上年上 … 6.9%
妻が11歳以上年上 … 0.8%
夫が年上 … 57.6%
妻が年上 … 24.2%
https://i.imgur.com/XvVzKgM.png >>44
配列やインスタンス等はヒープよりもスタック上に置いたほうが圧倒的に速い(＝確保コストも解放義務も解放コストもない)
だから呼び出し元に戻る前に、そのインスタンスや配列を使い終える分は、スタック上に確保するのが正確
逆にいえば呼び出し元に渡す必要がある時や動的にサイズが増え得る時のみヒープ領域で確保する
もちろん呼び出し元に返す場合でも、呼び出し元ががスタックに領域を確保してくれていればヒープの利用を減らせてさらに速くできる そもそもコンピュータ自体がメモリに対して出し入れするだけの機械と考えれば間違いではない気もする >>180>>184
その話は何度か出てると思うけど合ってるね
そうやってまともな人が書き込みするたびに
婆婚活コピペが貼られたり
何も理解していない人の戯言が書かれるのは
20年前から変わらない匿名掲示板愚民だね より正確な議論をするには
・スタックとヒープの速度比較(圧倒的に速いという表現は具体性に欠ける)
・ヒープ上のオブジェクトは呼び出し元に返すだけが目的ではなくて、他のオブジェクトやデータ構造に参照されて
その参照点の個数がゼロになったタイミングでガベージコレクションで回収するのが一般的用法
とかその他必要だけど、匿名掲示板で上の書き込みを見て要約を書くだけの文書処理マシンの人にそれを要求するのは無理だね
物理でいうところの物理モデル、プログラミングでいうところのプログラミングモデルを頭の中で組み立てる能力の欠落した人は何十年経っても、文章の羅列でしか物事を理解できない で、逆に物事を何でも文章として理解しようとする人は
その理解の構造が自然言語や漠然としたイメージに強く依存してしまって
本来扱うべき物理モデルやプログラミングモデルを理解していないが故の間違いや勘違い、応用力の欠如を今後も毎日繰り返す人生を送ることになるのだろう
それが発達障害であることにいつになったら気付いて
いつになったらその初心者の壁を乗り越えるのか 
>>159
実際Rustのマクロはクソだからしょうがない
扱う構造体を正確に把握してmatch文書いて分岐させるのを繰り返しまくらないといけないし
簡単な処理でも目的の要素までたどり着くまで時間かかりすぎ
文字列として扱って正規表現で調べてサクッとやらせてくれりゃいいだけの処理とかでも、いちいちパースしなきゃいけない
ループに関しても、パースしてからループはできるけど >>187
具体的にといっても、スタック領域はスタックポインタの加減算で確保と解放できるから圧倒的に速い、で終わり
ヒープ領域はその管理コストが確保でも開放でも大きなコストとなる
もちろんGC言語ならガベージコレクションという巨大な負荷ビッグイベントがある
だからヒープを使っていても非GC言語の方が圧倒的に速い
あともう一つ
他のオブジェクトやデータ構造に参照されていることは、呼び出し元に戻る時点でまだ利用中であり解放できない、つまり呼び出し元あるいは呼び出し先へ、それら含めて間接的に渡していると概念的に解釈できる
つまり概念的にヒープ解放義務と一緒に渡した捉えることができる
じゃあその概念的に渡されたヒープ解放義務をどう処理するか？でプログラミング言語は大きく3つに分かれる
(1) GC言語はヒープ解放義務を全てガベージコレクションに押し付けちゃうため楽だが遅い
(2) C言語などはプログラマーがそのヒープ解放義務を管理していて手動で解放するためミスも生じうるが速い
(3) Rustはヒープ解放義務の管理を静的にコンパイル時点で確定し全てを自動的に解放するため楽で安全で速い >>189
Rustならserdeを使えば自動的にシリアライズもパースもしてくれる
正規表現もregexを使えば自動的にマッチングしてくれる
さらに様々な自動的に楽にできるクレートが色々あるからそれらを使えるしもちろん自作もできる >>190
具体的にってのは
・インストラクションとメモリウエイトを加算したクロック数の最良/平均/最悪想定の概算比較と
・もう一つ、モデルとして妥当なプログラムにおける
メモリ確保/開放のクロック数が全体に占める割合(パーセンテージ)
の話ね
それが具体的にできない人は、能書きを暗記して書くだけで実計算のできないひとと区別できない
後半に関しては、動的言語と静的言語の相違に過ぎない話だからくどくど説明する話ではない。
＃相手の力量を見極めずに丸暗記した文章情報を
#書き立てるだけのつまらない人と判明して苦笑
#(匿名掲示板はそのレベルの人がやっとこだよね
# かつてのム板のようなリアルなエキスパートは
#嫌儲ではまず見かけない) 話は変わるけど、嫌儲に突然Rustのエヴァンジェリストみたいな人が出現した理由は何なんだっけ
この匿名掲示板もRust言語を一部採用し始めたんだっけ
若い人の熱意は認める >>187
むしろ、エラーと言えばヒープという
特殊な発想に驚きだわ😁 >>192
インストラクションやクロック数に踏み込む必要はない
「スタック領域の確保と解放はスタックポインタの加減算のみだから圧倒的に速い」で終わり
そしてヒープは確保と解放にコストがかかる「ヒープ領域は可能な限りできるだけ利用を避ける」が基本
例えばGC言語であるGoであっても、スタック上に確保しても大丈夫な時は自動的にスタック上に確保する戦略を取っている 関数呼び出しの時間的スコープに存在期間が限定される
スタック上に確保したインスタンスを
異なる時間的スコープのオブジェクトから
継続的に参照するには…
案1. スタック上のインスタンスをヒープ/インスタンス割当てメモリ上にコピーして、その参照ポインタを呼び出し側にも反映させる(ダブルポインタ等)
案2. Plasma言語タイプの、個々のインスタンスにスレッド(個別スタック+実行点)を割り当てて、インスタンス間のインタラクションをスレッド間通信として実装(必要な場合のみ、ただしオーバーヘッド大)
等あるけどその話ではないみたいね。
単に関数の時間的スコープの間のみ存在するインスタンスを
スタック上にとって、そのインスタンスに関する操作は
スタック常に存在する範囲に限定して
それを超える範囲は明示的にヒープ上にコピーを作る戦略かな
あんま興味ない >>195
うんうん、きみが情報科学の基本を抑えていない野良プログラマだから強弁で済ますんだろうけど
そんなれべるのひととかいわしたくないよ
おしまい 相変わらずレベル低いなぁ
インストラクション数なんて大雑把な過程で積み上げて
メモリ確保/開放の全体に占める割合なんて過去文献の統計数値を持ってくればいいのに
それを読んでないから強弁しかできないのって
高校生の議論みたいで和んだわ >>194
その話はしてないから他の子と遊んでてね🤣 とりあえず嫌儲で朝から丸暗記勉強の成果発表をしちゃう人は、具体的に数字を書けと言われた時に強弁して誤魔化す癖は直したほうがいい
そんな下らない強弁に時間を費やす人間は、
言い訳ばかりで具体的成果で相手を納得させる
スキルがないようにしか見えない
こんな当たり前の話を何度強弁しても
上位スキルの人にとっては下らない話にしか見えない事を理解しようぜ callocとmallocと独自メモリ管理のメリット/デメリット比較とか性能評価とか
DDJ誌の35年くらい前の記事の内容だけど
その程度の内容を具体的に示せない人が
匿名掲示板に流れてくるとは
なんかかわいそうな気持ちになる ■ このスレッドは過去ログ倉庫に格納されています
