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

■ このスレッドは過去ログ倉庫に格納されています
2022/05/10(火) 14:24:35.29ID:+9FnNLoT
この板はプログラムを作る人のための板です。
あらゆる質問はまず
スレ立てるまでもない質問はここで
スレにしてください。

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

【前スレ】
スレ立てるまでもない質問はここで 159匹目
https://mevius.5ch.net/test/read.cgi/tech/1644673480/
268デフォルトの名無しさん
垢版 |
2022/07/06(水) 11:48:52.42ID:MXaUuSJv
馬鹿にレスを与えないで下さい
馬鹿が居憑いてしまいます
2022/07/06(水) 13:34:25.61ID:PJvDCkI9
>>267
何も理解してなくても何か言った気になれる便利構文
2022/07/06(水) 20:01:10.31ID:dC6yewxo
>>266
彼のコードを見ているけれども、一般的な乗算に展開できるほどの抽象度が足りないですね
もっと汎用的に書かないのならば単なるオナニーですよね
少なくとも >>235 くらいには汎用的に書いてほしいのですけど‥‥

>>265
どこの URL の src.zip を圧縮解除すればコードが手に入るのか　****具体的に****　記述できますか？
2022/07/06(水) 22:26:45.95ID:6UOK9K5O
>>270
ファイル名は間違ってるかもしれないが、SDKのインストール先直下のディレクトリにzip(もしくはjar)としてライブラリのソースは入ってるのよ
2022/07/06(水) 22:32:35.76ID:6UOK9K5O
>>270
またEclipseとかIDEではソース中で使われてるBigIntegerとかから実装にジャンプするとzip中の対象ファイルがエディタで開かれる
2022/07/06(水) 22:39:05.29ID:6UOK9K5O
>>270
これは古いバージョンだけど
https://github.com/openjdk-mirror/jdk7u-jdk/blob/master/src/share/classes/java/math/BigDecimal.java
とか、GitHub にも置かれてる
2022/07/07(木) 02:33:54.03ID:/of+H6+2
こいつ有名な荒らしだから相手しない方が良いよ
不毛なことしか書けない人
2022/07/10(日) 15:25:18.55ID:QCQOT/0O
>>271
ちゃんとした情報を出してくださいね
そんないいかげんな情報では動く気にもなれないの、馬鹿
2022/07/10(日) 15:25:51.45ID:QCQOT/0O
>>272
エクリプスなんて使いたくないの、xyzzy でやる方法を教えてね
2022/07/10(日) 15:26:07.43ID:QCQOT/0O
>>273
新しいバージョンをお願いね
2022/07/10(日) 15:26:50.57ID:4uphdAWi
>>274
有名でもないし嵐でもないわ
2022/07/11(月) 17:40:53.28ID:RJHpoZJ0
>>277
コア技術でもないのに最新版を要求するクズっぷりに草
2022/07/12(火) 02:18:29.11ID:Ddw+6qP5
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.92ID:Ddw+6qP5
あと、論理的には問題ないように順序を交換してその項が消える場合は
順序を変えてもいいんですかね? とか
2022/07/12(火) 09:15:17.45ID:r0oulnz0
動作上の問題はない
最適化ガーとか言い出すド阿呆は居るかもしれない

んだが、普通はnullだと異常ルートでreturnさせたりするから、空の判定を書くことが多いんじゃないかなという経験的感想
2022/07/12(火) 09:19:02.27ID:r0oulnz0
>>282
正常ルートをブロック化すると無駄なネストが増えちゃうから
俺ならそんなコード書かれてたらレビューで指摘する
2022/07/12(火) 09:22:53.29ID:ZUXbswHw
>>283
ブロック化というか、
if (str == null) return;
的なものを最初の方に置いておくってことじゃね。
2022/07/12(火) 09:23:28.92ID:ZUXbswHw
なんだ自己レスかよw
2022/07/12(火) 09:33:25.75ID:46BVSOic
kotlinにしてisNullOrEmptyにしないからそうなる
2022/07/12(火) 10:05:16.64ID:8furZaV3
twitter apiの質問ってここでいいですか？
2022/07/12(火) 11:10:56.86ID:oE4SglJp
最近の言語はnullを廃止して安全にした言語が増えてきたね
Rustなどのようにnullを無くして静的な型チェックでnull関係のミスをコンパイル時点で完全に防ぐ言語がオススメかな
2022/07/12(火) 12:27:47.36ID:cntCnL4D
変数を何千、何万という規模で使うようなプログラム作ってる人は
その何千以上の変数名を全部自分で考えて付けてるんですか？基本的に命名規則に従って
なにかしらの手抜き方法とかあるんですか？
290デフォルトの名無しさん
垢版 |
2022/07/12(火) 12:30:38.14ID:F2coDuKO
>>289
全部グローバル変数なら命名も大変だろうが、小さいスコープ内なら大変じゃないよ
2022/07/12(火) 12:49:34.65ID:lZD1gQnq
>>289
まともなプログラム＆言語ではグローバル変数を滅多に使わない
関数やクラスなどの中に閉じた変数を使うからその中で名前を区別できれば十分
その関数もグローバル関数はレアな存在でクラスなどのメソッド関数などにするのでそのクラスなどの中で名前を区別できれば十分
そのクラスなどもモジュールなどの中で名前を区別できれば十分
そのモジュールなどの名前は仮にぶつかっても使用を宣言する時に別名として採用できる言語が多いから名前がぶつかっても困ることはない
細かいところは各プログラミング言語によって色々と異なるけど概要としては以上の通り
2022/07/12(火) 13:54:30.96ID:bC3C9A55
グローバルおじさんが作ったVBSとか楽しすぎて辞めたくなるよな
2022/07/12(火) 14:13:34.28ID:0sH3rFaE
速度を優先するとグローバル変数も使いたくなりませんか
連続で呼ばれる関数で毎回変数宣言するよりもグローバル変数で一度定義しておけば
その負担をゼロにできるし
2022/07/12(火) 14:30:47.58ID:46BVSOic
そうですね。他にもmain関数一本で実装するのがモダンなやり方だと思いますよ
2022/07/12(火) 14:44:45.71ID:h7t7toC6
>>293
>速度を優先するとグローバル変数も使いたくなりませんか
既に定義済みの変数を利用したいケースは当然あるが
だからといってグローバル変数は使わない

>連続で呼ばれる関数で毎回変数宣言するよりもグローバル変数で一度定義しておけば
>その負担をゼロにできるし
それぞれサンプルコード書いてみたら？
もう少し具体的なアドバイスがもらえると思うよ
2022/07/12(火) 14:52:24.07ID:/TLAe8PW
>>293
宣言に伴う領域確保時に自動的に内容が初期化されるような処理系だったりポリシーだったりするとそうかもね。
C だと関数呼び出し時にその関数で使用する変数に充分なサイズのスタックフレームを確保するだけだから、コストなんてかからないよ。
スタックポインタを最初に一度ずらすだけだからね。
2022/07/12(火) 15:09:08.48ID:e6ywpCu7
>>293
グローバル変数は、いつ、どこから、誰が、どのように、アクセスするか不明であり、
一般的にはデータ競合を起こす可能性もあるため、その場合は対策として排他制御が必要となるなど、むしろ遅くなる可能性を招きかねない
グローバル変数はできる限り使わないのが通常のプログラミングの基本である
2022/07/12(火) 15:10:10.48ID:/ElrVE0y
>>289
命名の省力化よりも設計の質や可読性を高めることに意識を集中させたほうがいいぞ
その意識で1～2年もやれば手抜きというか命名コストを下げる方法も自然と身につく
2022/07/12(火) 15:17:54.87ID:ZWwvT0dn
速度は別としても、どうしても共有したデータを参照したい時は
グローバル変数も使わざるをえないのでは
2022/07/12(火) 15:31:37.13ID:6JujiSX5
js幼女だけどfsoやwshをグローバルにしている
2022/07/12(火) 15:33:54.63ID:46BVSOic
ローカルDBやファイルや設定ファイルなどはグローバル変数だから使うべきでない
2022/07/12(火) 15:39:37.31ID:0s4l2w4w
>>299
まずデータ共有のためにグローバル変数を用いるのは他に手段がない場合に限定されしかも以下の点に注意する必要か出て来ます
データを多者で共有するということは
その多者の関係によってはデータ競合が発生するため一般的には排他制御を行うことになります
2022/07/12(火) 15:55:20.39ID:Lr6lZRed
>>301
設定ファイル名は固定ならば変数ではなく定数であるからグローバル変数ではない
変わりうる時は引数や環境変数や設定ファイル等が出自となりこれもグローバル変数てはない
ファイルはファイル等のモジュールのオープン関数にファイル名やパスを指定して扱うからグローバル変数の要素はない
ローカルDBも同様でありグローバル変数を必要としない
まともなコードならばグローバル変数は出て来ない
2022/07/12(火) 16:11:36.31ID:XIWH5a4r
>>299
どの言語を前提に話してるの？
2022/07/12(火) 16:17:16.03ID:cntCnL4D
C#やJavaなんかで
2022/07/12(火) 16:40:13.27ID:3+lEMrqc
>>305
その2つともグローバル変数がそもそも機能的にないやろ
static classのstatic変数使う

C#ならnamespaceを切って、使う側で明示的にインポート
2022/07/12(火) 17:07:57.77ID:MOqUyrHS
>>289
変数や関数は台帳で管理する
F00001、F00002みたいな名前にしておけば悩む必要はない
なおF00100以下の番号は、前々社長など
会社の偉い人に割り当てられている
その関数は伝説となっており誰も手を付けてはいけないことになっている
2022/07/12(火) 17:28:55.51ID:46BVSOic
アセンブラとか変数どころかアドレスの番地やろ
2022/07/12(火) 18:28:32.11ID:6GTnP78T
レジスタ名は変数に含まれますか？
2022/07/12(火) 18:28:36.82ID:jEv45P7P
10 GOTO 10
2022/07/12(火) 19:27:13.54ID:JaplqMKV
コンストラクタの引数とフィールド変数は毎回困るわ
this着けて回避してるけど未だに嫌だわ
C#はprivateフィールド変数にアンダースコア付けるように成ったらしいから良くなったけどjavaはコンストラクタだけthis付きだわ
2022/07/12(火) 21:28:56.55ID:/TLAe8PW
>>305
そんなにパフォーマンスにこだわりたいなら、とりあえず C で書いたら？
なんでもグローバルに置くなんてことをしなくても、変数確保のコストをごっそり下げられるよ。
2022/07/12(火) 22:36:21.49ID:pP2wLD3a
最近はRustのようにグローバル変数を持たない言語も増えているね
2022/07/13(水) 02:51:31.38ID:o1nk5rBa
「〇〇の言語では」という話は、既存のコードを直す場合には残念ながら無効
新規のコードだって普通は言語縛りがあったりする
事件は現場で起きている
315デフォルトの名無しさん
垢版 |
2022/07/13(水) 03:10:40.16ID:dyEYJovX
>>307
実際そういうソース見たことあるわ
グローバル変数名がみんなそういう番号なのな
で、関数はほとんど関数ポインタの配列に入ってて、添字頼りで呼び出す、、、
しかもコメントはほぼ皆無、あったとしても「なぜかこうしないと動かない」的な独り言

きっと天才が作ったんだろう、俺には解析できなかったよ
2022/07/13(水) 21:10:40.45ID:nyVCJ4Fn
OSがLinux・unixでは昔makeを使ってたと思います
今は何が主流なんですか？
2022/07/13(水) 21:14:50.95ID:sjYFKueX
make
2022/07/13(水) 21:29:01.08ID:H8j4+v2o
cmake
2022/07/14(木) 00:38:53.58ID:rMT+3vzc
Makefileなんか使わない
ソースコードはCファイル一つでできている
2022/07/14(木) 00:54:33.55ID:3dKE35ki
>>316
最近はCとほぼ同速度が出るのに自動メモリ解放で安全に楽できるRustで書くことが増えたから
makeに相当するのはcargoかな
ライブラリのバージョン管理や自動ダウンロードなど含めて何でもしてくれる
2022/07/14(木) 02:45:06.09ID:o4Ti2hmk
ポケモンの交換は途中で電源を消してもポケモンの増殖や消滅が起こりませんが、どのようになってるのでしょうか
2022/07/14(木) 03:58:54.48ID:rMT+3vzc
起こるようだが？
ちゃんとトランザクション処理してないのか？
2022/07/14(木) 05:44:56.23ID:1pn/MEr2
>>320
意味わかんねー
それは本当に「主流」か？？？
cargoでパッケージをインストールするのがデフォルトなディストリなんてあるか？
テメーが覚えたてのこと言いたいだけなんじゃないかと

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

もっと言うとメモリの管理で苦労したくないという浅い浅い動機ならC++でできる限りSTLでプログラミングした方が圧倒的に導入のコストが低く済むという事実
ま、「いや組み込みを想定するとSTLなんて使えないから～」とか訳の分からん擁護に走る奴が出てくるのは目に見えてるがな
2022/07/14(木) 06:25:21.21ID:oyqdoYCa
>>323
例えばLinux開発陣営も
失敗言語C++を採用しませんでしたが
成功言語Rustは採用したように
言語としての優劣は明確となっています

今までの蓄積の差がC++の優位点です
今後は時間とともにC++が相対的に衰退していくのでしょう
2022/07/14(木) 06:27:36.20ID:TLMV+xKA
>>314
そのような合理性に乏しい判断が生産性の低下と各リスクの上昇を招く

>>323
ttps://foundation.rust-lang.org/members/
気をつければ問題などと言う認識は時代遅れっすよ
2022/07/14(木) 08:16:34.89ID:rMT+3vzc
>>323
> cargoでパッケージをインストールするのがデフォルトなディストリなんてあるか？
なんでデフォルトじゃなきゃいかんの？
2022/07/14(木) 12:11:36.28ID:LBvA3Hcq
Ruby では、Rake, Thor みたいなタスクランナーを使う
2022/07/14(木) 12:46:07.15ID:nOsE2mRf
>>325
「メモリ管理に苦労したくないだけならSTLを積極的に使うことにすれば済む」というのを「気をつければ問題ない」と読んだなら文盲かSTLが何か知らないということになる
組み込み等のSTLが使えないような背景を勝手に想定してるなら話にならない

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


>>326
論点のすり替えであって、「Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流か」という問いに何ら答えていない
（もちろんこれはただの反語表現であって、答えるまでもなく>>320は頓珍漢なのだが）
2022/07/14(木) 14:00:51.16ID:/zRfdjTa
>>323
C++がクソ言語だと理解できていない時点であかんやん
メモリ解放の話に限定したとしてもC++ではプログラマーのミスで解放忘れ、多重解放、解放済みエリア利用などのコードとなってしまってもC++コンパイラはそれらを通してしまう
複雑化すれば人間のミスが入り込むことは避けられないため現実にバグやセキュリティの穴をC++は生んできた
現在はそれらのミスを起こしたコードをコンパイラが検出して通さず指摘してくれるRustが登場したのだからC++は着実に退場していくだろう
2022/07/14(木) 14:39:49.64ID:lnbsEUJQ
退場するまでなんとしても生きねば…… ゴホゴホ……
2022/07/14(木) 14:50:50.28ID:nOsE2mRf
>>329
自己流あるいはアンチパターンにはまってわけわかんないことしてるくらいなら (問題によっては) STLを使えば良いだろっていう指摘なんだが、
> メモリ解放の話に限定したとしてもC++ではプログラマーのミスで解放忘れ、多重解放、解放済みエリア利用など
なんでこんなことになるのか
2022/07/14(木) 15:45:39.13ID:rMT+3vzc
>>328
> 論点のすり替えであって、「Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流か」という問いに何ら答えていない

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

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

なんで自分の意見を相手に聞くかな？ｗ
自分の意見は、自分から言えば良いんだよ。
2022/07/14(木) 15:47:01.75ID:rMT+3vzc
相手に自分の主張を言わせることで
「勝った気になる」というテクニックに名前ついてない？
2022/07/14(木) 16:35:58.76ID:31/iZkCN
>>331
なぜそれら致命的な欠陥のあるC++を勧めるのか？
他に解決手段が無かった昔はC++が次善手として使われてきたのは仕方ないとしても現在は避けることが可能なのだから
2022/07/14(木) 19:50:08.27ID:JGI4j5iF
ふう、なんとか致命傷で助かった
2022/07/14(木) 21:11:03.19ID:CzfIePPh
お前はすでに死んでいる
2022/07/14(木) 22:27:22.85ID:9htlvmL8
>>320
＞ライブラリのバージョン管理や自動ダウンロード

これ、すごく嫌なんですが、オプションでオフにすることはできますか？
2022/07/14(木) 22:28:41.63ID:9htlvmL8
>>329
＞解放忘れ、多重解放
これはデバッグ用にラッパをかませれば、すぐにわかりますよ
工夫がたりないんじゃないですか？
2022/07/14(木) 22:38:35.64ID:iypcPR5q
>>388
工夫とはPOSIXコマンドだけで何とかすること
依存しているものが使えなくなったら動かなくなる
2022/07/14(木) 23:58:11.93ID:U+xK/jUV
>>339
あのね、ラッパは自分で書くの
malloc(), free() をラッパでくるんでおいて、解放忘れや二重解放を検出すればいいわｋでしょう？

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

なんでこんな工夫もできないの？馬鹿なの？
2022/07/15(金) 01:34:39.13ID:GD18JH44
>>340
そんな前近代的なことをしている人がいて驚く
・まず手間も時間もムダ
・その作業も漏れなくミスなくすることを保証できない
・実行しないと何も判明しない
・レアケースに露見するミスはレアケースが来るまでわからないまま
様々な点で問題が多すぎる

C/C++を捨ててRustへ移行すれば
・コードに問題があればコンパイラが通さず問題点を指摘してくれる
・つまりチェックは人手でやる必要なくコンパイラにより完全自動
・コンパイルが通れば安全性が保証される
・つまり実行前に静的に問題がないことを確定できる
・使われなくなった時点で即座に自動的にメモリ解放されるためC/C++で手動で最善にメモリ解放した時と同様に高速
このようにRustへ移行すれば問題が解決する
2022/07/15(金) 01:41:41.27ID:Ck4HswxJ
>>340
解放忘れは機械的にはプロセス終了時点まで分からないと思うけど、プロセス終了時にその領域の情報はどうやって報告するの？
未解放メモリの全部のポインタをどこかに覚えておく？
そして、どこからの malloc で確保されたメモリなのかはどうやって管理する？
他にも new や delete はどうするのとか。
そのノウハウは聞いておきたい。
2022/07/15(金) 04:34:16.20ID:H/wtb5p/
>>332
> どうせ主流ではないと言いたいんでしょ？
イエス
反語表現の意味を調べよう
（中高で習うそんなに難しくはない概念だし、注意してみると日常生活の中でもよく使われているので、勉強しておくことを勧める）


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


> なんで自分の意見を相手に聞くかな？ｗ
> 自分の意見は、自分から言えば良いんだよ。
言ってるんだよなあ
まあこの先日本語をもっと勉強することでいずれ理解できるようになると思う
頑張って
2022/07/15(金) 04:37:28.40ID:H/wtb5p/
>>334
勧めていません
ただし、低レベルプログラミングが必要な場面でないのに「C++はメモリの解放が～」とか言ってるのは誤謬でしかないし、標準ライブラリで提供されてる範囲内で簡単に解決できると示しているだけ
2022/07/15(金) 04:40:39.28ID:H/wtb5p/
>>340はヤバいね
これなら思考停止でRust使ってた方が良い

今自分でmalloc、free、new、deleteしなきゃいけない場面なんて特定の領域を除いて存在しないでしょっていう話だから
2022/07/15(金) 04:43:52.51ID:GD18JH44
>>343
その件もmakeでやってた前近代的な方法を根本的に見直し捨て去ることで
全く新たなcargoというエコシステムが作られてそれ単独でmakeやその類似を必要とせずに動作しているわけだから
makeの代わりの新たなものという位置付けも一つの見方であると思われる
2022/07/15(金) 04:44:34.45ID:nNsZOfDm
>>343
だから、Rustのcargoが本当にLinux・UNIXにおけるパッケージ管理の主流じゃないから何？
OSの仕事はあくまでOSのパッケージの管理であって
プログラミング環境のライブラリの管理じゃないんだよ
あんたcargoの役目を理解してなさすぎｗ
2022/07/15(金) 05:21:48.13ID:tRnFuWaP
>>344
その後半の「標準ライブラリで提供されてる範囲内で簡単に解決できる」は二重にダウト
標準ライブラリの範囲内でも解放忘れや多重解放などは起こり得る
さらに標準ライブラリの範囲内のみで解決できるとはかきらない
したがって標準ライブラリを持ち出すことに何の意味もない
2022/07/15(金) 05:25:05.82ID:H/wtb5p/
>>346
ていう話なら是

>>347
ええ。ですから>>316に対してcargoとか言い出すのは頓珍漢なのですよ
私と反対のことを言いたいばかりに元々がどんな話だったかすっかりお忘れになられているようで、本当に気の毒ですがもう少し日本語のお勉強に真剣になられた方が良いです
2022/07/15(金) 05:39:30.79ID:nNsZOfDm
>>349
はぁ（苦笑）

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

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

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

ここまで丁寧に教えないと理解しないんだろうな
2022/07/15(金) 05:44:04.50ID:nNsZOfDm
makeの代わりに何を使う？って話なんだからcargoは間違いじゃない

makeの話なのにOSのパッケージ管理ツールってなんだよ？とかいいだしてる>>323がアホと言う結論
2022/07/15(金) 06:06:48.38ID:H/wtb5p/
>>350
>>346で止めときゃ合ってたのに……（もしかして「是」の意味がわからなかった？）

OSのコマンドとして見るなら尚更cargoを持ち出すのは頓珍漢だろ
2022/07/15(金) 07:03:07.90ID:LI/vBnI5
とりあえず>>340って実際にどんなことをしてるかちょっとだけ気になるんだけど
よかったら具体的な説明を
2022/07/15(金) 07:08:23.44ID:LI/vBnI5
と思ったが、あれかな、valgrindとかでやることを自分でやるみたいな?
普通にそういうツールやライブラリに頼った方がいいような
2022/07/15(金) 07:28:20.56ID:45o+VwAU
>>352
今どきはOSのコマンドでビルドしないって言ってんだろ
いい加減OSの話忘れろよ
おまえだけだぞ
2022/07/15(金) 08:15:46.31ID:uLC7CBw4
Rust Foundation Platinumに日本企業はない。中国企業はいる
日本は中国未満
2022/07/15(金) 09:59:34.96ID:TA6nqc+L
現時点でRustで構築されてるOSってある?
カーネルはLinuxでもいいけどそれより上の部分で
2022/07/15(金) 10:57:19.78ID:lF4sBNwn
Rustなんて結局流行らんでしょｗ
まぁ、スレ違いなのでしょーも無い事を語るなら別のスレにいけ
2022/07/15(金) 11:39:33.98ID:YErsqPqr
gitでマージしてコンフリクトしなかったファイルとコンフリクトしたファイルがあって
これをコミットする際、コンフリクトせずマージされたコミットとコンフリクト解消したコミットのように2つに分けたいのですが
どうやればいいのでしょうか
2022/07/15(金) 12:11:03.83ID:lF4sBNwn
単純にマージする前にブランチ切っていれば戻れるし好きに出来るのでは？
361デフォルトの名無しさん
垢版 |
2022/07/15(金) 12:12:45.10ID:YXwn0a1o
>>359
stageに上がった修正だけがcommitされるから、
コンフリクト解消前のstageをcommitした後に
コンフリクト解消してまたcommitすりゃいい
2022/07/15(金) 12:44:10.41ID:YErsqPqr
>>361
コンフリ解消前のをcommitするとコンフリ解決してないので
committing is not possible because you have unmerged files
とエラーが出てコミットできないんですが
コンフリしたファイルをそのままaddしてコミットしろってことでしょうか？
363デフォルトの名無しさん
垢版 |
2022/07/15(金) 15:05:45.09ID:oyGbt8u5
>>362
merge状態から抜ければcommitできるので、そうしてもいいし
コンフリクトしたファイルだけを元に戻してもいい

でも、どちらにせよビルドできない状態をcommitすることになるだろうから
ちゃんとコンフリクトを解消してからcommitした方がいいと思うけどなぁ
まあ、最初のやりたいことからは外れちゃうけど
2022/07/15(金) 15:18:15.30ID:UMF7Eduu
>>357
これからは一つの言語で構成されるOSはなくなっていく
2022/07/15(金) 21:04:15.70ID:knkavBW6
>>341
＞・まず手間も時間もムダ
ちょいちょいと 200 ステップくらいで簡単に実現できますよ、一晩で書けちゃいますよ

＞・その作業も漏れなくミスなくすることを保証できない
＞・実行しないと何も判明しない
何もしないよりはましでしょうね、簡単なラッパを置くだけでケアレスミスは弾けますね、やったことなければわからないでしょうが

>>342
末尾に解放忘れを列挙する関数を置けばいいだけですよ、リリース時には #ifdef で無効にするようなものでね

>>345
私は別に rust を否定しているわけではないですよ
指摘された問題点はちょいちょいとラッパを書くだけで割と簡単に弾けるのに、というだけですね

>>353
ヘッダ：https://ideone.com/E6J83P
本体：https://ideone.com/WpsIxp
一晩で即席に作ったけれども結構今でも役に立っていますね‥‥
2022/07/15(金) 21:41:31.38ID:0WMM6JpG
リーク検出なんてVCは標準であるけど、他の環境にはないの？
2022/07/15(金) 21:52:23.36ID:YErsqPqr
>>363
コンフリしたファイルをHEADの内容で更新commitして
コンフリしたファイルを再度修正してそれをコンフリ解決としてコミットすれば
やりたいような感じのことができました
レスありがとうございました
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況