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

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

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

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

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

**デフォルトの名無しさん** · 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がアホと言う結論

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

>>350
>>346で止めときゃ合ってたのに……（もしかして「是」の意味がわからなかった？）

OSのコマンドとして見るなら尚更cargoを持ち出すのは頓珍漢だろ

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

とりあえず>>340って実際にどんなことをしてるかちょっとだけ気になるんだけど
よかったら具体的な説明を

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

と思ったが、あれかな、valgrindとかでやることを自分でやるみたいな?
普通にそういうツールやライブラリに頼った方がいいような

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

>>352
今どきはOSのコマンドでビルドしないって言ってんだろ
いい加減OSの話忘れろよ
おまえだけだぞ

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

Rust Foundation Platinumに日本企業はない。中国企業はいる
日本は中国未満

**デフォルトの名無しさん** · 2022/07/15(金) 09:59:34.96

現時点でRustで構築されてるOSってある?
カーネルはLinuxでもいいけどそれより上の部分で

**デフォルトの名無しさん** · 2022/07/15(金) 10:57:19.78

Rustなんて結局流行らんでしょｗ
まぁ、スレ違いなのでしょーも無い事を語るなら別のスレにいけ

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

gitでマージしてコンフリクトしなかったファイルとコンフリクトしたファイルがあって
これをコミットする際、コンフリクトせずマージされたコミットとコンフリクト解消したコミットのように2つに分けたいのですが
どうやればいいのでしょうか

**デフォルトの名無しさん** · 2022/07/15(金) 12:11:03.83

単純にマージする前にブランチ切っていれば戻れるし好きに出来るのでは？

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

>>359
stageに上がった修正だけがcommitされるから、
コンフリクト解消前のstageをcommitした後に
コンフリクト解消してまたcommitすりゃいい

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

>>361
コンフリ解消前のをcommitするとコンフリ解決してないので
committing is not possible because you have unmerged files
とエラーが出てコミットできないんですが
コンフリしたファイルをそのままaddしてコミットしろってことでしょうか？

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

>>362
merge状態から抜ければcommitできるので、そうしてもいいし
コンフリクトしたファイルだけを元に戻してもいい

でも、どちらにせよビルドできない状態をcommitすることになるだろうから
ちゃんとコンフリクトを解消してからcommitした方がいいと思うけどなぁ
まあ、最初のやりたいことからは外れちゃうけど

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

>>357
これからは一つの言語で構成されるOSはなくなっていく

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

>>341
＞・まず手間も時間もムダ
ちょいちょいと 200 ステップくらいで簡単に実現できますよ、一晩で書けちゃいますよ

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

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

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

>>353
ヘッダ：https://ideone.com/E6J83P
本体：https://ideone.com/WpsIxp
一晩で即席に作ったけれども結構今でも役に立っていますね‥‥

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

リーク検出なんてVCは標準であるけど、他の環境にはないの？

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

>>363
コンフリしたファイルをHEADの内容で更新commitして
コンフリしたファイルを再度修正してそれをコンフリ解決としてコミットすれば
やりたいような感じのことができました
レスありがとうございました

**365** · 2022/07/16(土) 06:41:19.01

>>366
昔の bcc にもありました、ちょっとバグってたけれども
clang　ベースの今の bcc にあるかどうかはちょっとわかりませんね

**デフォルトの名無しさん** · 2022/07/16(土) 11:51:34.05

質問と言うかご意見をお聞かせください

daoパターンを調べていてトップに出てきたのがこれです
https://kanda-it-school-kensyu.com/java-jdbc-contents/jj_ch04/jj_0401/
気になったのは
selectIsbnAll、selectTitleAll、selectPriceAllが、内部で使うSQL文以外は全く共通の構造になっているということです
例えば受け取ったSQLを実行して結果を返す関数xxxを別に作る、上の3関数ではSQL文を作ってxxxに渡して呼び出す
そういう構造にするのはダメなんでしょうか

それとも重複させたほうがいい理由が何かあるのでしょうか。よろしくお願いします

**デフォルトの名無しさん** · 2022/07/16(土) 11:55:03.81

失礼しました。SQL文以外にも取得する列名も関数ごとに別ですね
まぁその場合でもxxxに列名を引数として追加すればいいのではと思いますが

**デフォルトの名無しさん** · 2022/07/16(土) 12:32:31.14

>>369
>そういう構造にするのはダメなんでしょうか

全く問題ないよ

**デフォルトの名無しさん** · 2022/07/16(土) 12:37:49.48

しいて言えば
他の開発者が重複させた状態でパターン認識してれば共通処理に切り出すと分かりにくくなるとか
すべてのDAOが依存する共通クラスができるのでその維持管理に少し手間がかかるとか
そういうデメリットはあるかもしれない

**デフォルトの名無しさん** · 2022/07/16(土) 14:05:36.11

Java のJDBC って、何十年前の話なの？

Ruby on Rails では、Active Record というO/R マッパーで全自動。
こんなコーディングを見た事がない

**デフォルトの名無しさん** · 2022/07/16(土) 15:47:30.46

markdownってなにが便利なの？
見る人にわざわざViewerをインストールしてもらわなきゃいけないの

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/16(土) 16:12:32.42

>>374
HTMLよりも文法が簡単で、わかりやすい。
テキストベースでGitと相性が良い。
markdownが書ければ本も出版できる。

**デフォルトの名無しさん** · 2022/07/16(土) 17:00:15.16

本を出版できるかどうかは関係ないでしょ
書く内容があれば、markdownがかけなくても出版は出来るでしょうし。

整形されたものを見るためには、ブラウザ側の準備とかも必要ですし
○○をインストールすれば、綺麗に見えますよ
なんていってもそんなの面倒といわれるのがオチですよね

**デフォルトの名無しさん** · 2022/07/16(土) 17:08:33.25

ブラウザ等が必要なのはHTMLやTextileも同じ
それらに比べてプレーンテキストでの視認性は良い

**デフォルトの名無しさん** · 2022/07/16(土) 20:25:35.05

gitと相性良いってのは本当にでかい
未だにword/excelをSVN管理してるところの多さよ

**デフォルトの名無しさん** · 2022/07/17(日) 08:58:42.91

音楽を流すプログラムを公開する時、著作権の問題を回避するため、曲データそのものは省いた状態で公開したい。
でもデモというかサンプルとして、そのデータのシーケンスの様子を youtube で公開して、ようするにそれを見ればデータを再現できるわけだけど、
そういう公開の仕方で著作権の問題は出そう？
公開したいものの主体としてはシーケンサの方ではあるけど、その曲を入れたくて作ったという側面がある。
もちろん使う人がお好きなデータを入れられる。

**デフォルトの名無しさん** · 2022/07/17(日) 18:48:28.79

仕事中に転職予定のプログラミングの勉強をしたいのだけど
いい方法はないかしら？
今の仕事中はときどきアイドル時間があってわりと勉強できそうだけど
周りにチームリーダーやまじめ君がいてPCをのぞきこまれてそれを見つかるのはまずい。

**デフォルトの名無しさん** · 2022/07/17(日) 19:38:41.12

スマホPDFでみれば

**デフォルトの名無しさん** · 2022/07/17(日) 19:51:05.43

>>381
それもなかなか難しいんですよ。
理想はPCで仕事してるふりしてPCの小領域に勉強のためのWebサイトを開くみたいな。

**デフォルトの名無しさん** · 2022/07/17(日) 19:53:22.97

PC介すと検閲に引っかかるとかないの？

**デフォルトの名無しさん** · 2022/07/17(日) 20:52:28.23

えー要約すると仕事中に仕事と全く関係なくて見つかるのもまずいことしようとしてるんだけどいい方法ありませんか

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/17(日) 21:13:42.26

通信URLが監視されてたら何してもばれる。

それでもやりたいならWin+D

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/17(日) 21:21:33.73

「ボスが来た」で検索すると、そういうツールが見つかるよ。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/17(日) 21:22:16.77

通信内容も隠蔽したいならテザリングするといいよ。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/17(日) 21:26:39.21

内部通告は社会の正義だからね。がんばってね。

**蟻人間** ◆T6xkBnTXz7B0 · 2022/07/17(日) 21:41:58.23

今ならメガネ型の端末やコンタクトレンズみたいな端末があるって。
それでネットサーフィンできるよ。

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

などと自宅警備員が言っており

**デフォルトの名無しさん** · 2022/07/18(月) 02:41:01.00

その言語の研修に行かせてもらえば？

**デフォルトの名無しさん** · 2022/07/18(月) 09:09:17.65

UMLとかどこ行っても潰しの効く技術を勉強しといたら？
特に最下流なゴミ案件だと設計ドキュメント無かったりするから、それを作ってますと言い訳

**デフォルトの名無しさん** · 2022/07/18(月) 10:38:54.88

OSSのライブラリって設計ドキュメントとかなかったりするよね
OSSの開発には参加できない低レベル人材ということだよね

**デフォルトの名無しさん** · 2022/07/18(月) 12:40:49.12

設計資料の無いプログラムなんて、何の価値も無いでしょ
個人が趣味やってるようなものなら話しは別だけど
会社で仕事としてやってるなら、ソースだけなんてありえない。

そこらに建ってるビルで設計図ないビルなんて無いだろ
犬小屋つくるのとはわけがちがう

**デフォルトの名無しさん** · 2022/07/18(月) 12:47:50.22

設計図は保守のために必要なのであって開発のための設計図は不要

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

会社に入れば分かるよ
学生さんがお遊びで書いてるようなおもちゃコードとはダンチレベチだから

**デフォルトの名無しさん** · 2022/07/18(月) 13:25:28.89

OSSはわかる人が参加するものであって
企業内の製品は誰でもわかるようにしなければいけない
設計あるなしは要否によっても決まるもの、という位置付けに変化した

**デフォルトの名無しさん** · 2022/07/18(月) 13:28:37.05

会社でコード書いてるのなんて高卒とか専卒のやつらだろ
大学でちゃんとコード書いてる学生さんの方が上だよ

**デフォルトの名無しさん** · 2022/07/18(月) 13:34:29.85

なぜか学歴の話しになってて草草草
頭の悪い人って物事を別の方向に捉えて勝手に結論付けるよね

**デフォルトの名無しさん** · 2022/07/18(月) 14:19:10.39

N□□セキュアとかの仕事ですら、設計ドキュメント無かったぜ

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

ビルは完全にウォーターフォールでしか開発できないからな
途中で改善点など見つけても後戻りできない
そこがソフトウェア開発と建築との違いで何度でも試行錯誤してブラッシュアップできるのがソフトウェアの良いところなのに
混同して考えているという時点でセンスないし向いてないから別の業界に転職した方が良いよ

**デフォルトの名無しさん** · 2022/07/18(月) 15:03:52.33

設計ドキュメントの作成・維持・読んで理解するのに要するコスト・時間と
設計ドキュメントなしにコードを読んで設計を理解するのに要するコスト・時間を状況に応じて比較して考えればいいよ

設計するやつとコード書くやつが分かれてたり
コードだけからだと設計を読み取るのに時間がかかったり
そもそもコードを読めない・読まない人が設計を理解する必要があったり
多くのソフトウェアやシステムは後者のコストが著しく高くなる環境のほうが一般的

設計するやつとコード書くやつが同じでユーザーもコードを読む前提のソフトウェアやシステムはどちらかといえば例外的

**デフォルトの名無しさん** · 2022/07/18(月) 15:52:41.75

>>394
オープンソースのソフトウェアに分厚い設計資料はありますか？

**デフォルトの名無しさん** · 2022/07/18(月) 16:11:52.15

>>403
オープンソースには分かるやつしか参加しないから、ソースコードを別の言葉で書き直したような設計書ならいらないんだよね。
企業は人員の 9割が無能だから、そいつらのための仕事として設計書作成作業を設けてるだけ。
んで 9割の連中がその設計書を見ながら作った動かないコードは、残りの 1割の連中が設計書など見ずに動くように書き直す。
だから設計書と製品が解離する。

**デフォルトの名無しさん** · 2022/07/18(月) 17:54:35.48

>>404
オープンソースに分厚い設計資料がないのだったら、本質的に企業の仕事においても不要でしょうね、偉い人にはどうしてそんなことがわからないのでしょうか？

**デフォルトの名無しさん** · 2022/07/18(月) 18:01:12.19

製作者がいなくなったとき、

オープンソースは引き継げる能力のあるやつが引き継ぐ、いなければいつか消えるのみ
会社は他に能力のあるやつがいなくても、誰かに引き継がせなきゃいけない。放置は許されない

**デフォルトの名無しさん** · 2022/07/18(月) 18:20:16.09

>>396
せやな。Linuxぐらいの設計書は必要

**デフォルトの名無しさん** · 2022/07/18(月) 19:30:18.00

>>406
製作者がいなくなる状況を生成した、それが会社側の失敗なのでは？
ドキュメントなんて所詮、参考でしかなく、結局はコードを読むしかない、偉い人にはそれがわからないのでは？

**デフォルトの名無しさん** · 2022/07/18(月) 20:03:26.47

書類なんざ所詮管理手段の一つ。結果が伴わなければ意味ない
書類の作成を目的化するような会社じゃビジネスは上手くいかないだろうね

**デフォルトの名無しさん** · 2022/07/19(火) 00:29:30.95

ダメなプロジェクトや仕事は設計ドキュメントが先にある

良いプロジェクトや仕事は様々なレベルでそれぞれ試しに作っては壊したり比較したりやり直したり
システムアーキテクチャレベルで固まってきてもデータ構造やらAPI相当やらはリファクタリングでどんどん良いものへ変化
そして最後に設計ドキュメントに相当するものをきちんと作る

**デフォルトの名無しさん** · 2022/07/19(火) 02:32:32.91

エクセルのデータを読み込んで加工して手元のmysqlに書き込むプログラムがあるのですが
プログラムで書き込むのと sql fileに書き出してコマンドで実行する方式のどっちがいいでしょうか?

**デフォルトの名無しさん** · 2022/07/19(火) 11:20:13.57

>>411
どういう観点で比較したいの？

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

C,C++の勉強してListの構造を学んで疑問に思ったのですが
Javaなどでメモリ飛び飛びで作られたListが存在するときにGCが発生したら完全整列するのでしょうか？それとも要素毎に空いたメモリに再配置されるのでしょうか？
前者なら遅くなるなぁ？と、後者で動いてる？
まぁわかったところでGCなのでやりようがないかもですが、考え方だけでも知っておきたいです

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

>>413
後者
GC言語に限らずリンクリストは非常に非効率なデータ構造であり、動的配列よりもリンクリストの方が適している状況は極めて稀である
Cで実装しやすいから教科書に出てくるだけ

**デフォルトの名無しさん** · 2022/07/21(木) 15:10:02.66

>>414
ありがとうございます
やはり後者ですか
List使った処理を追加したら遅くなりまして
もう一度コードの見直ししてみます

**デフォルトの名無しさん** · 2022/07/22(金) 21:00:16.41

アセンブラスレがなかったのでこちらのスレで失礼します。
学校でH8/300Hのマイコン学習をしています。
どうしてもわからないことがあり質問させてただきます。

HEW 生成ファイル補足説明（H8S、H8/300）
https://www.renesas.com/us/ja/document/man/735601
の３ページ目、リセット関数に関してです。

.SECTION PResetPRG,CODE,LOCATE=H'0400
_PowerON_Reset:
SLEEP
.SECTION $VECT0,DATA,LOCATE=H'0000
.DATA.L _PowerON_Reset
.END

上記のコードは実行してもただSLEEPするだけ、ということは理解できています。

コードの読み方を調べているうちに、
上記コードで定義されているPResetPRGのH'0400と、$VECT0のH'0000は、
ディフォで生成される設定に合わせているということは理解できたのですが、
じゃあ、なんでわざわざ宣言するんでしょうか？
ネットや書籍で調べまくっているのですが、掘り下げた説明に出会えず、
これがピンとこないせいか、授業の内容もいまいちピンときません。
まだLEDをピカらせるといった初歩的なことをしているだけですが、
リセット関数はどのコードにも冒頭部分に記述されています。
しかし初期設定部分ということもあってかコピペで済ましており、
学校の人も誰もこの記述の具体的な説明を含む読み方ができません。

どなたか日本語訳的な感じで読み替えてもらえないでしょうか？
よろしくおねがしいます。

**デフォルトの名無しさん** · 2022/07/22(金) 21:56:20.98

アセンブラというかハードの知識が足りてないんじゃね？
ベクタテーブルで調べてごらん。

**デフォルトの名無しさん** · 2022/07/22(金) 21:57:59.77

h8なんて知らん素人だけどさ
このCPUはリセットされると0番地の内容をプログラムカウンタに設定して
そこから実行を開始するっぽい
で、今回はH'0000番地にVECT0という名前をつけて
内容はH'0400
H'0400番地にPResetPRGという名前をつけて
内容はSLEEP命令
この名前とかアドレスはその開発環境のデフォルトなんでしょ

**デフォルトの名無しさん** · 2022/07/22(金) 22:31:54.54

>>416
>じゃあ、なんでわざわざ宣言するんでしょうか？
この回答は「PResetPRGのアドレスは変更可能だから」かな

**416** · 2022/07/22(金) 23:10:59.57

>>417->>419
ありがとうございます。書き込み後も調べ続けておりました。

>>417
一応イメージは掴んでいるつもりですが、改めて勉強してみます。
リセット時や割り込み時の処理の仕方だと認識しています。
自分はたぶんsection宣言の読み方や使い方がわかっていない気がします。

>>418
ありがとうございます。レス読んで思い出しました。
このリセット関数については、最初は先生に質問したのですが、
「0000の中に0400が入っているんだよ」と言われ、その時はわかった気になったのですが、
帰宅後に調べ直したらまたわからなくなり、今回の質問に至ったという経緯でした。

わかる
・このCPUはリセットされると0番地から実行を開始する
・名前とかアドレスはデフォルトのやつをそのまま使っている
・H'0000番地にVECT0という名前をつけている。
・H'0400番地にPResetPRGという名前をつけている。

わからない１
・H'0000番地の中にH'0400が入っているについて、その入れる処理は、どこがそうなっているんですか？
私の理解では「番地に名前をつけて、コードかデータの種類を指定しただけど、入れる処理はしていない」です。

わからない２
・.DATA.L _PowerON_Reset　はプログラムを「_PowerON_Reset」からスタートする動作だと
教わりましたが、この記述でなんでそうなるかがわからないです。

>>419
ありがとうございます。そういうもんですか・・・そこは飲み込みます。