スレ立てるまでもない質問はここで 160匹目

**デフォルトの名無しさん** · 2022/05/10(火) 14:24:35.29

この板はプログラムを作る人のための板です。
あらゆる質問はまず
スレ立てるまでもない質問はここで
スレにしてください。

次スレは>>980が立てること

【前スレ】
スレ立てるまでもない質問はここで 159匹目
https://mevius.5ch.net/test/read.cgi/tech/1644673480/

**デフォルトの名無しさん** · 2022/07/05(火) 01:34:42.80

>>251
アルゴリズム名が知りたいね
筆算法なんてコンピュータで使われてないし

**デフォルトの名無しさん** · 2022/07/05(火) 02:23:33.79

不遜メソッド効きすぎｗｗｗ

**デフォルトの名無しさん** · 2022/07/05(火) 07:56:46.50

>>249
△知らないなら知りません
◎書けないなら書けません
∵>>235

**デフォルトの名無しさん** · 2022/07/05(火) 07:57:54.68

>>252
使われていますよ、整数演算をきちんとしたいのならそれしかないのでは？

**デフォルトの名無しさん** · 2022/07/05(火) 08:11:42.70

>>252
名前を知ってどうするの？
そこそこプログラム書いてりゃどんな方法なのかは分かるし、使われてないなんてアホなことも言うわけもないぞ。
多ワード乗除の基本中の基本であって、他にどうやるの？ってレベル。
2進数の掛け算とか、掛ける数分ループで足しちゃう人？

**デフォルトの名無しさん** · 2022/07/05(火) 13:49:08.28

>>256
アルゴリズムの名前を聞くのは
それについて調べるだけに決まってるだろｗ

おまえ、すでにあるアルゴリズムを
想像で再発明するんか？
アホやなぁ

**デフォルトの名無しさん** · 2022/07/05(火) 14:18:53.50

>>257
つべこべ言わず手を動かせよ。
いつも口ばっかりと言われてるだろ？

**デフォルトの名無しさん** · 2022/07/05(火) 15:13:51.38

「アルゴリズム筆算」を検索したら普通に見つかったこれ、面白かったよ。

超高速！多バイト長整数の計算手法

>>257
コードは書かねぇわ検索はしねぇわ、しょうもねーな

**デフォルトの名無しさん** · 2022/07/05(火) 15:24:20.46

宿題は宿題スレでやれ

**デフォルトの名無しさん** · 2022/07/05(火) 16:09:18.14

>>259
小数がね～だろ

**デフォルトの名無しさん** · 2022/07/05(火) 16:15:09.12

>>261
頭使う気が皆無というのがすげーな

**デフォルトの名無しさん** · 2022/07/05(火) 18:44:23.54

>>256
＞多ワード乗除の基本中の基本
その基本中の基本が自力では書けない人がほとんど、というのが、今の日本の計算機工学のお馬鹿さを如実に示していると思いますね
誰か >>235 の改良版を公開してくれませんでしょうかね、全然期待していないけど‥‥

**デフォルトの名無しさん** · 2022/07/05(火) 21:51:37.18

どうした？
散々 QZ に言いたい放題に言われ続けても実装が出せないのか？
馬鹿ばかりだな‥‥

**デフォルトの名無しさん** · 2022/07/06(水) 03:26:05.47

BigDecimal は src.zip を解凍すりゃソースが出てくるのに…

**デフォルトの名無しさん** · 2022/07/06(水) 04:04:41.36

なんか最近C++スレでも整数環上でのFFTも理解してないカスが暴れてるけど、このスレも同じノリになってきたな
なぜ？

**デフォルトの名無しさん** · 2022/07/06(水) 04:10:59.60

整数環上でのFFTを知ってる程度の人間が
マウント取ってるからじゃないですかねぇ

**デフォルトの名無しさん** · 2022/07/06(水) 11:48:52.42

馬鹿にレスを与えないで下さい
馬鹿が居憑いてしまいます

**デフォルトの名無しさん** · 2022/07/06(水) 13:34:25.61

>>267
何も理解してなくても何か言った気になれる便利構文

**デフォルトの名無しさん** · 2022/07/06(水) 20:01:10.31

>>266
彼のコードを見ているけれども、一般的な乗算に展開できるほどの抽象度が足りないですね
もっと汎用的に書かないのならば単なるオナニーですよね
少なくとも >>235 くらいには汎用的に書いてほしいのですけど‥‥

>>265
どこの URL の src.zip を圧縮解除すればコードが手に入るのか　****具体的に****　記述できますか？

**デフォルトの名無しさん** · 2022/07/06(水) 22:26:45.95

>>270
ファイル名は間違ってるかもしれないが、SDKのインストール先直下のディレクトリにzip(もしくはjar)としてライブラリのソースは入ってるのよ

**デフォルトの名無しさん** · 2022/07/06(水) 22:32:35.76

>>270
またEclipseとかIDEではソース中で使われてるBigIntegerとかから実装にジャンプするとzip中の対象ファイルがエディタで開かれる

**デフォルトの名無しさん** · 2022/07/06(水) 22:39:05.29

>>270
これは古いバージョンだけど
https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/math/BigDecimal.java
とか、GitHub にも置かれてる

**デフォルトの名無しさん** · 2022/07/07(木) 02:33:54.03

こいつ有名な荒らしだから相手しない方が良いよ
不毛なことしか書けない人

**デフォルトの名無しさん** · 2022/07/10(日) 15:25:18.55

>>271
ちゃんとした情報を出してくださいね
そんないいかげんな情報では動く気にもなれないの、馬鹿

**デフォルトの名無しさん** · 2022/07/10(日) 15:25:51.45

>>272
エクリプスなんて使いたくないの、xyzzy でやる方法を教えてね

**デフォルトの名無しさん** · 2022/07/10(日) 15:26:07.43

>>273
新しいバージョンをお願いね

**デフォルトの名無しさん** · 2022/07/10(日) 15:26:50.57

>>274
有名でもないし嵐でもないわ

**デフォルトの名無しさん** · 2022/07/11(月) 17:40:53.28

>>277
コア技術でもないのに最新版を要求するクズっぷりに草

**デフォルトの名無しさん** · 2022/07/12(火) 02:18:29.11

Javaで「文字列がヌルも含めた空文字である」を評価するとき、例えば
if (str == null || str.isEmpty()) としますよね? でこれは短絡評価によりstrがnullのときは
str.isEmpty()は評価されないのでNPEは発生しないと。
ここから質問ですが、これの否定式を作る場合に、単純にドモルガンを適用して
if (str != null && !str.isEmpty()) でいいですよね?

一般的に元の式が短絡評価込みで問題ない場合、単にそれの否定をとったりしても
問題は生じない、ですよね? というか単純に否定の式を書くべきですよね?（どこかで順序
を変えてはいけない）というか
if (!(str == null || str.isEmpty())) が無難かもしれないですが、場合によってはバラして
簡略化したいですよね? そのとき項の順序さえ変えなければあとは論理法則を適用して
変形していいですよね? というか

**デフォルトの名無しさん** · 2022/07/12(火) 02:24:55.92

あと、論理的には問題ないように順序を交換してその項が消える場合は
順序を変えてもいいんですかね? とか

**デフォルトの名無しさん** · 2022/07/12(火) 09:15:17.45

動作上の問題はない
最適化ガーとか言い出すド阿呆は居るかもしれない

んだが、普通はnullだと異常ルートでreturnさせたりするから、空の判定を書くことが多いんじゃないかなという経験的感想

**デフォルトの名無しさん** · 2022/07/12(火) 09:19:02.27

>>282
正常ルートをブロック化すると無駄なネストが増えちゃうから
俺ならそんなコード書かれてたらレビューで指摘する

**デフォルトの名無しさん** · 2022/07/12(火) 09:22:53.29

>>283
ブロック化というか、
if (str == null) return;
的なものを最初の方に置いておくってことじゃね。

**デフォルトの名無しさん** · 2022/07/12(火) 09:23:28.92

なんだ自己レスかよw

**デフォルトの名無しさん** · 2022/07/12(火) 09:33:25.75

kotlinにしてisNullOrEmptyにしないからそうなる

**デフォルトの名無しさん** · 2022/07/12(火) 10:05:16.64

twitter apiの質問ってここでいいですか？

**デフォルトの名無しさん** · 2022/07/12(火) 11:10:56.86

最近の言語はnullを廃止して安全にした言語が増えてきたね
Rustなどのようにnullを無くして静的な型チェックでnull関係のミスをコンパイル時点で完全に防ぐ言語がオススメかな

**デフォルトの名無しさん** · 2022/07/12(火) 12:27:47.36

変数を何千、何万という規模で使うようなプログラム作ってる人は
その何千以上の変数名を全部自分で考えて付けてるんですか？基本的に命名規則に従って
なにかしらの手抜き方法とかあるんですか？

**デフォルトの名無しさん** · 2022/07/12(火) 12:30:38.14

>>289
全部グローバル変数なら命名も大変だろうが、小さいスコープ内なら大変じゃないよ

**デフォルトの名無しさん** · 2022/07/12(火) 12:49:34.65

>>289
まともなプログラム＆言語ではグローバル変数を滅多に使わない
関数やクラスなどの中に閉じた変数を使うからその中で名前を区別できれば十分
その関数もグローバル関数はレアな存在でクラスなどのメソッド関数などにするのでそのクラスなどの中で名前を区別できれば十分
そのクラスなどもモジュールなどの中で名前を区別できれば十分
そのモジュールなどの名前は仮にぶつかっても使用を宣言する時に別名として採用できる言語が多いから名前がぶつかっても困ることはない
細かいところは各プログラミング言語によって色々と異なるけど概要としては以上の通り

**デフォルトの名無しさん** · 2022/07/12(火) 13:54:30.96

グローバルおじさんが作ったVBSとか楽しすぎて辞めたくなるよな

**デフォルトの名無しさん** · 2022/07/12(火) 14:13:34.28

速度を優先するとグローバル変数も使いたくなりませんか
連続で呼ばれる関数で毎回変数宣言するよりもグローバル変数で一度定義しておけば
その負担をゼロにできるし

**デフォルトの名無しさん** · 2022/07/12(火) 14:30:47.58

そうですね。他にもmain関数一本で実装するのがモダンなやり方だと思いますよ

**デフォルトの名無しさん** · 2022/07/12(火) 14:44:45.71

>>293
>速度を優先するとグローバル変数も使いたくなりませんか
既に定義済みの変数を利用したいケースは当然あるが
だからといってグローバル変数は使わない

>連続で呼ばれる関数で毎回変数宣言するよりもグローバル変数で一度定義しておけば
>その負担をゼロにできるし
それぞれサンプルコード書いてみたら？
もう少し具体的なアドバイスがもらえると思うよ

**デフォルトの名無しさん** · 2022/07/12(火) 14:52:24.07

>>293
宣言に伴う領域確保時に自動的に内容が初期化されるような処理系だったりポリシーだったりするとそうかもね。
C だと関数呼び出し時にその関数で使用する変数に充分なサイズのスタックフレームを確保するだけだから、コストなんてかからないよ。
スタックポインタを最初に一度ずらすだけだからね。

**デフォルトの名無しさん** · 2022/07/12(火) 15:09:08.48

>>293
グローバル変数は、いつ、どこから、誰が、どのように、アクセスするか不明であり、
一般的にはデータ競合を起こす可能性もあるため、その場合は対策として排他制御が必要となるなど、むしろ遅くなる可能性を招きかねない
グローバル変数はできる限り使わないのが通常のプログラミングの基本である

**デフォルトの名無しさん** · 2022/07/12(火) 15:10:10.48

>>289
命名の省力化よりも設計の質や可読性を高めることに意識を集中させたほうがいいぞ
その意識で1～2年もやれば手抜きというか命名コストを下げる方法も自然と身につく

**デフォルトの名無しさん** · 2022/07/12(火) 15:17:54.87

速度は別としても、どうしても共有したデータを参照したい時は
グローバル変数も使わざるをえないのでは

**デフォルトの名無しさん** · 2022/07/12(火) 15:31:37.13

js幼女だけどfsoやwshをグローバルにしている

**デフォルトの名無しさん** · 2022/07/12(火) 15:33:54.63

ローカルDBやファイルや設定ファイルなどはグローバル変数だから使うべきでない

**デフォルトの名無しさん** · 2022/07/12(火) 15:39:37.31

>>299
まずデータ共有のためにグローバル変数を用いるのは他に手段がない場合に限定されしかも以下の点に注意する必要か出て来ます
データを多者で共有するということは
その多者の関係によってはデータ競合が発生するため一般的には排他制御を行うことになります

**デフォルトの名無しさん** · 2022/07/12(火) 15:55:20.39

>>301
設定ファイル名は固定ならば変数ではなく定数であるからグローバル変数ではない
変わりうる時は引数や環境変数や設定ファイル等が出自となりこれもグローバル変数てはない
ファイルはファイル等のモジュールのオープン関数にファイル名やパスを指定して扱うからグローバル変数の要素はない
ローカルDBも同様でありグローバル変数を必要としない
まともなコードならばグローバル変数は出て来ない

**デフォルトの名無しさん** · 2022/07/12(火) 16:11:36.31

>>299
どの言語を前提に話してるの？

**デフォルトの名無しさん** · 2022/07/12(火) 16:17:16.03

C#やJavaなんかで

**デフォルトの名無しさん** · 2022/07/12(火) 16:40:13.27

>>305
その2つともグローバル変数がそもそも機能的にないやろ
static classのstatic変数使う

C#ならnamespaceを切って、使う側で明示的にインポート

**デフォルトの名無しさん** · 2022/07/12(火) 17:07:57.77

>>289
変数や関数は台帳で管理する
F00001、F00002みたいな名前にしておけば悩む必要はない
なおF00100以下の番号は、前々社長など
会社の偉い人に割り当てられている
その関数は伝説となっており誰も手を付けてはいけないことになっている

**デフォルトの名無しさん** · 2022/07/12(火) 17:28:55.51

アセンブラとか変数どころかアドレスの番地やろ

**デフォルトの名無しさん** · 2022/07/12(火) 18:28:32.11

レジスタ名は変数に含まれますか？

**デフォルトの名無しさん** · 2022/07/12(火) 18:28:36.82

10 GOTO 10

**デフォルトの名無しさん** · 2022/07/12(火) 19:27:13.54

コンストラクタの引数とフィールド変数は毎回困るわ
this着けて回避してるけど未だに嫌だわ
C#はprivateフィールド変数にアンダースコア付けるように成ったらしいから良くなったけどjavaはコンストラクタだけthis付きだわ

**デフォルトの名無しさん** · 2022/07/12(火) 21:28:56.55

>>305
そんなにパフォーマンスにこだわりたいなら、とりあえず C で書いたら？
なんでもグローバルに置くなんてことをしなくても、変数確保のコストをごっそり下げられるよ。

**デフォルトの名無しさん** · 2022/07/12(火) 22:36:21.49

最近はRustのようにグローバル変数を持たない言語も増えているね

**デフォルトの名無しさん** · 2022/07/13(水) 02:51:31.38

「〇〇の言語では」という話は、既存のコードを直す場合には残念ながら無効
新規のコードだって普通は言語縛りがあったりする
事件は現場で起きている

**デフォルトの名無しさん** · 2022/07/13(水) 03:10:40.16

>>307
実際そういうソース見たことあるわ
グローバル変数名がみんなそういう番号なのな
で、関数はほとんど関数ポインタの配列に入ってて、添字頼りで呼び出す、、、
しかもコメントはほぼ皆無、あったとしても「なぜかこうしないと動かない」的な独り言

きっと天才が作ったんだろう、俺には解析できなかったよ

**デフォルトの名無しさん** · 2022/07/13(水) 21:10:40.45

OSがLinux・unixでは昔makeを使ってたと思います
今は何が主流なんですか？

**デフォルトの名無しさん** · 2022/07/13(水) 21:14:50.95

make

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/13(水) 21:29:01.08

cmake

**デフォルトの名無しさん** · 2022/07/14(木) 00:38:53.58

Makefileなんか使わない
ソースコードはCファイル一つでできている

**デフォルトの名無しさん** · 2022/07/14(木) 00:54:33.55

>>316
最近はCとほぼ同速度が出るのに自動メモリ解放で安全に楽できるRustで書くことが増えたから
makeに相当するのはcargoかな
ライブラリのバージョン管理や自動ダウンロードなど含めて何でもしてくれる

**デフォルトの名無しさん** · 2022/07/14(木) 02:45:06.09

ポケモンの交換は途中で電源を消してもポケモンの増殖や消滅が起こりませんが、どのようになってるのでしょうか

**デフォルトの名無しさん** · 2022/07/14(木) 03:58:54.48

起こるようだが？
ちゃんとトランザクション処理してないのか？

**デフォルトの名無しさん** · 2022/07/14(木) 05:44:56.23

>>320
意味わかんねー
それは本当に「主流」か？？？
cargoでパッケージをインストールするのがデフォルトなディストリなんてあるか？
テメーが覚えたてのこと言いたいだけなんじゃないかと

あとソフトウェア開発の現場では「自動メモリ解放で安全に楽できる」新言語よりもただ単に枯れてるからというだけの理由でC/C++が優先されることが非常に多いということを理解してないように思う

もっと言うとメモリの管理で苦労したくないという浅い浅い動機ならC++でできる限りSTLでプログラミングした方が圧倒的に導入のコストが低く済むという事実
ま、「いや組み込みを想定するとSTLなんて使えないから～」とか訳の分からん擁護に走る奴が出てくるのは目に見えてるがな

**デフォルトの名無しさん** · 2022/07/14(木) 06:25:21.21

>>323
例えばLinux開発陣営も
失敗言語C++を採用しませんでしたが
成功言語Rustは採用したように
言語としての優劣は明確となっています

今までの蓄積の差がC++の優位点です
今後は時間とともにC++が相対的に衰退していくのでしょう

**デフォルトの名無しさん** · 2022/07/14(木) 06:27:36.20

>>314
そのような合理性に乏しい判断が生産性の低下と各リスクの上昇を招く

>>323
ttps://foundation.rust-lang.org/members/
気をつければ問題などと言う認識は時代遅れっすよ

**デフォルトの名無しさん** · 2022/07/14(木) 08:16:34.89

>>323
> cargoでパッケージをインストールするのがデフォルトなディストリなんてあるか？
なんでデフォルトじゃなきゃいかんの？

**デフォルトの名無しさん** · 2022/07/14(木) 12:11:36.28

Ruby では、Rake, Thor みたいなタスクランナーを使う

**デフォルトの名無しさん** · 2022/07/14(木) 12:46:07.15

>>325
「メモリ管理に苦労したくないだけならSTLを積極的に使うことにすれば済む」というのを「気をつければ問題ない」と読んだなら文盲かSTLが何か知らないということになる
組み込み等のSTLが使えないような背景を勝手に想定してるなら話にならない

「メモリ管理に苦労したくない」以外にも山程Rustに良いところがあるのは当然認めている

>>326
論点のすり替えであって、「Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流か」という問いに何ら答えていない
（もちろんこれはただの反語表現であって、答えるまでもなく>>320は頓珍漢なのだが）

**デフォルトの名無しさん** · 2022/07/14(木) 14:00:51.16

>>323
C++がクソ言語だと理解できていない時点であかんやん
メモリ解放の話に限定したとしてもC++ではプログラマーのミスで解放忘れ、多重解放、解放済みエリア利用などのコードとなってしまってもC++コンパイラはそれらを通してしまう
複雑化すれば人間のミスが入り込むことは避けられないため現実にバグやセキュリティの穴をC++は生んできた
現在はそれらのミスを起こしたコードをコンパイラが検出して通さず指摘してくれるRustが登場したのだからC++は着実に退場していくだろう

**デフォルトの名無しさん** · 2022/07/14(木) 14:39:49.64

退場するまでなんとしても生きねば…… ゴホゴホ……

**デフォルトの名無しさん** · 2022/07/14(木) 14:50:50.28

>>329
自己流あるいはアンチパターンにはまってわけわかんないことしてるくらいなら (問題によっては) STLを使えば良いだろっていう指摘なんだが、
> メモリ解放の話に限定したとしてもC++ではプログラマーのミスで解放忘れ、多重解放、解放済みエリア利用など
なんでこんなことになるのか

**デフォルトの名無しさん** · 2022/07/14(木) 15:45:39.13

>>328
> 論点のすり替えであって、「Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流か」という問いに何ら答えていない

Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流かどうかを聞いてなんの意味があるの？
どうせ主流ではないと言いたいんでしょ？

主流ではないから○○だみたいに、
その先を説明してよ

なんで自分の意見を相手に聞くかな？ｗ
自分の意見は、自分から言えば良いんだよ。

**デフォルトの名無しさん** · 2022/07/14(木) 15:47:01.75

相手に自分の主張を言わせることで
「勝った気になる」というテクニックに名前ついてない？

**デフォルトの名無しさん** · 2022/07/14(木) 16:35:58.76

>>331
なぜそれら致命的な欠陥のあるC++を勧めるのか？
他に解決手段が無かった昔はC++が次善手として使われてきたのは仕方ないとしても現在は避けることが可能なのだから

**デフォルトの名無しさん** · 2022/07/14(木) 19:50:08.27

ふう、なんとか致命傷で助かった

**デフォルトの名無しさん** · 2022/07/14(木) 21:11:03.19

お前はすでに死んでいる

**デフォルトの名無しさん** · 2022/07/14(木) 22:27:22.85

>>320
＞ライブラリのバージョン管理や自動ダウンロード

これ、すごく嫌なんですが、オプションでオフにすることはできますか？

**デフォルトの名無しさん** · 2022/07/14(木) 22:28:41.63

>>329
＞解放忘れ、多重解放
これはデバッグ用にラッパをかませれば、すぐにわかりますよ
工夫がたりないんじゃないですか？

**デフォルトの名無しさん** · 2022/07/14(木) 22:38:35.64

>>388
工夫とはPOSIXコマンドだけで何とかすること
依存しているものが使えなくなったら動かなくなる

**デフォルトの名無しさん** · 2022/07/14(木) 23:58:11.93

>>339
あのね、ラッパは自分で書くの
malloc(), free() をラッパでくるんでおいて、解放忘れや二重解放を検出すればいいわｋでしょう？

＞解放済みエリア利用
すなわち、前世バグは、解放時にラッパで乱数を書き込んでおけばいい
本番ではラッパをはずすように #ifdef しておけばいいだけの話でしょう

なんでこんな工夫もできないの？馬鹿なの？

**デフォルトの名無しさん** · 2022/07/15(金) 01:34:39.13

>>340
そんな前近代的なことをしている人がいて驚く
・まず手間も時間もムダ
・その作業も漏れなくミスなくすることを保証できない
・実行しないと何も判明しない
・レアケースに露見するミスはレアケースが来るまでわからないまま
様々な点で問題が多すぎる

C/C++を捨ててRustへ移行すれば
・コードに問題があればコンパイラが通さず問題点を指摘してくれる
・つまりチェックは人手でやる必要なくコンパイラにより完全自動
・コンパイルが通れば安全性が保証される
・つまり実行前に静的に問題がないことを確定できる
・使われなくなった時点で即座に自動的にメモリ解放されるためC/C++で手動で最善にメモリ解放した時と同様に高速
このようにRustへ移行すれば問題が解決する

**デフォルトの名無しさん** · 2022/07/15(金) 01:41:41.27

>>340
解放忘れは機械的にはプロセス終了時点まで分からないと思うけど、プロセス終了時にその領域の情報はどうやって報告するの？
未解放メモリの全部のポインタをどこかに覚えておく？
そして、どこからの malloc で確保されたメモリなのかはどうやって管理する？
他にも new や delete はどうするのとか。
そのノウハウは聞いておきたい。

**デフォルトの名無しさん** · 2022/07/15(金) 04:34:16.20

>>332
> どうせ主流ではないと言いたいんでしょ？
イエス
反語表現の意味を調べよう
（中高で習うそんなに難しくはない概念だし、注意してみると日常生活の中でもよく使われているので、勉強しておくことを勧める）

> 主流ではないから○○だみたいに、
> その先を説明してよ
ホワァイ？
元々>>320が頓珍漢な回答をしているのを指摘しただけなので、そこで終わってる話
頓珍漢に輪をかけたレスがその後も相次いでいるので驚いているが

> なんで自分の意見を相手に聞くかな？ｗ
> 自分の意見は、自分から言えば良いんだよ。
言ってるんだよなあ
まあこの先日本語をもっと勉強することでいずれ理解できるようになると思う
頑張って

**デフォルトの名無しさん** · 2022/07/15(金) 04:37:28.40

>>334
勧めていません
ただし、低レベルプログラミングが必要な場面でないのに「C++はメモリの解放が～」とか言ってるのは誤謬でしかないし、標準ライブラリで提供されてる範囲内で簡単に解決できると示しているだけ

**デフォルトの名無しさん** · 2022/07/15(金) 04:40:39.28

>>340はヤバいね
これなら思考停止でRust使ってた方が良い

今自分でmalloc、free、new、deleteしなきゃいけない場面なんて特定の領域を除いて存在しないでしょっていう話だから

**デフォルトの名無しさん** · 2022/07/15(金) 04:43:52.51

>>343
その件もmakeでやってた前近代的な方法を根本的に見直し捨て去ることで
全く新たなcargoというエコシステムが作られてそれ単独でmakeやその類似を必要とせずに動作しているわけだから
makeの代わりの新たなものという位置付けも一つの見方であると思われる

**デフォルトの名無しさん** · 2022/07/15(金) 04:44:34.45

>>343
だから、Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流じゃないから何？
OSの仕事はあくまでOSのパッケージの管理であって
プログラミング環境のライブラリの管理じゃないんだよ
あんたcargoの役目を理解してなさすぎｗ

**デフォルトの名無しさん** · 2022/07/15(金) 05:21:48.13

>>344
その後半の「標準ライブラリで提供されてる範囲内で簡単に解決できる」は二重にダウト
標準ライブラリの範囲内でも解放忘れや多重解放などは起こり得る
さらに標準ライブラリの範囲内のみで解決できるとはかきらない
したがって標準ライブラリを持ち出すことに何の意味もない

**デフォルトの名無しさん** · 2022/07/15(金) 05:25:05.82

>>346
ていう話なら是

>>347
ええ。ですから>>316に対してcargoとか言い出すのは頓珍漢なのですよ
私と反対のことを言いたいばかりに元々がどんな話だったかすっかりお忘れになられているようで、本当に気の毒ですがもう少し日本語のお勉強に真剣になられた方が良いです

**デフォルトの名無しさん** · 2022/07/15(金) 05:39:30.79

>>349
はぁ（苦笑）

あのねぇ、makeはね、OSのコマンドなの。UNIXの中に含まれてるから。
でね、makeっていうのはビルドツールなわけ。
昔のunixにはパッケージ管理ツールなんてなかったのから
ビルドするしかなかったの

今はビルドツールにOSのコマンドを使わなくなってきてるの
cargoはプログラム専用のパッケージ管理ツール兼ビルドツールなわけ

つまりね、
・パッケージを使う場合はOSのパッケージ管理ツールを使う
・しかしパッケージ管理ツールは、make、ビルドツールのことじゃあない
・今の話はmakeの代わりに何を使うって話
・makeの代わりはcargoや各言語のビルドツールなわけ
おまえはmakeをパッケージ管理ツールだと勘違いしてる

ここまで丁寧に教えないと理解しないんだろうな

**デフォルトの名無しさん** · 2022/07/15(金) 05:44:04.50

makeの代わりに何を使う？って話なんだからcargoは間違いじゃない

makeの話なのにOSのパッケージ管理ツールってなんだよ？とかいいだしてる>>323がアホと言う結論