結局C++とRustってどっちが良いの？ 4traits

**デフォルトの名無しさん** · 2023/06/06(火) 19:13:06.15

「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」

っていう雑談スレ。

前スレ: 結局C++とRustってどっちが良いの？ 3traits
https://mevius.5ch.net/test/read.cgi/tech/1683154196/

関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/

**デフォルトの名無しさん** · 2023/06/10(土) 09:22:24.69

>>85
>ミスはたいていリリース前に発覚するが

だがリリースできないよりできたほうがいいんだわw
バグはあとから改修すればなんとかなる場合が99%
リリース遅延よりよっぽどまし出すことが肝心
その意味でrustは生産性は高くない
てかさ. 商用のRustコンパイラどんだけあるのさw
特に組込で商用のrustコンパイラ挙げてくれ
IARあたりがコード品質の高いrustコンパイラ出してからでもまったく遅くない

**デフォルトの名無しさん** · 2023/06/10(土) 09:23:43.81

>>88
>でも、プロジェクトって一人じゃないからね

それをいうならRust熟練のプログラマどんだけ居るのさww

**デフォルトの名無しさん** · 2023/06/10(土) 09:27:25.53

>>85
開発効率の高さとリリース時の穴の少なさでRustが圧倒的に有利だな

**デフォルトの名無しさん** · 2023/06/10(土) 09:31:21.58

>>91
コンパイラがないのにか?ww

**デフォルトの名無しさん** · 2023/06/10(土) 09:31:27.19

大手が採用するっていったんだから、>>89-90 のあたりは、目途がついたんだろ

効率の高さってのはなんなんだ

**デフォルトの名無しさん** · 2023/06/10(土) 09:33:28.40

>>93
コード生産効率
単位時間に何行書けるかって話だ
あとになってバッファオーバーランエラーなんか判明しても構わないから

**デフォルトの名無しさん** · 2023/06/10(土) 09:40:31.77

>>93
大手?
MSがrust使うっていうのも一部だけだろ
だったら最低VSでRustサポートしてから言ってくれ

大体チップメーカがまともなrustコンパイラをリリースした話は聞いてない
チップメーカーはC/C++コンパイラはチップと同様要視してるがrustはまだまだ眼中にない
Intelがrustコンパイラ出したら考えるわww

**デフォルトの名無しさん** · 2023/06/10(土) 09:45:42.46

>>93
誇大広告

**デフォルトの名無しさん** · 2023/06/10(土) 09:49:29.33

所有権あたり, rustの機能をC++がパクってるんだろ?
だったらrust風にC++で書くように機能制限して書かせてほぼ事足りるんじゃねーの?
Lintかコンパイル時ウオーニングで

PC上で実験的にコード書いてるならいざしらず
商用のコンパイラでrustコンパイラが存在しないのに何言っても絵に書いた餅

**デフォルトの名無しさん** · 2023/06/10(土) 10:10:09.37

>>89
一理ある

**デフォルトの名無しさん** · 2023/06/10(土) 10:16:36.13

Rustは商用で使うもんじゃないんだろ

**デフォルトの名無しさん** · 2023/06/10(土) 10:17:11.38

このスレ見るとC++erの知能の低さにビックリするな
5ch特有の事象ならいいんだが

**デフォルトの名無しさん** · 2023/06/10(土) 10:26:39.71

知能というか知識と経験が無いだけでしょう
慣れるとC++もRustもコードを書く速さはほとんど変わらない
ただし以下の差が致命的に大きい
メモリ管理やデータ競合でミスがあった時にコンパイル時にわかるRust
実行するまでわからないか実行してもレアケースは気付けないC++

**デフォルトの名無しさん** · 2023/06/10(土) 10:34:05.91

>>100
>>101
お前らがまともな商売したことないだけだろw
レアケースなら気づかなくていいんだよww
ホスピタルグレードやらNASAやらならいざしらずだ
現実をしらないww

**デフォルトの名無しさん** · 2023/06/10(土) 10:36:28.03

>>99

すくなくともチップメーカ謹製のrustが出なきゃ話にならんしな
cudaあたりにしてもさww

**デフォルトの名無しさん** · 2023/06/10(土) 10:50:29.46

unsafeだらけのRustに何が判るω

**デフォルトの名無しさん** · 2023/06/10(土) 10:55:54.11

それそれ
抜け穴用意しといて
というか用意せざるを得ないわけで
ありがたがってる時点でおめでたすぎるやろ

一般製品において, めったに出ないエラー or fault は
ユーザーをテスタにすればいいってこともわかってないんだよなおこちゃまは ♥

**デフォルトの名無しさん** · 2023/06/10(土) 11:10:22.43

>>104
これが本当なら、PMの責任

C++から来たなら、unsafeの限局化は頼まれなくたってやるもんだと思うが

**デフォルトの名無しさん** · 2023/06/10(土) 11:12:31.11

cでも商用コンパイラとgccあたりじゃコード品質最悪なんよな
せいぜい規格遵守しただけの教育用途
元ルネサスの香取裕二の解説見てよーわかったわ
そこらへんgccだとソースコード見てくれって話なんだろうが,
どれだけコンパイラのソースコート見て理解してるユーザが居るのか?っていうね
商用に使える品質にはるかに及ばないコード品質なのに
レアケースのバグに有利とかもうわけわかってねぇんだろなコイツ

**デフォルトの名無しさん** · 2023/06/10(土) 11:14:04.07

>>106
その前にrust使った商用コード書いてないだろが
お前とこrust使った製品リリースしてるのかよww

**デフォルトの名無しさん** · 2023/06/10(土) 11:23:12.59

>>108
たぶん誤解されてるな俺は「C++で十分」派
Rustの成果をC++が貪欲に取り込めばいいと思ってる

MSはブートローダとなんだったかのテキスト処理あたりからRust化してみるらしいぞ
がっつりテストを持ってれば、そういうことにも挑戦できるんだろう

**デフォルトの名無しさん** · 2023/06/10(土) 11:26:02.89

>>107
詳しく!

**デフォルトの名無しさん** · 2023/06/10(土) 12:08:27.34

c++はコンパイルエラーで間違ってる場所を正確に指してこないからなあ
pythonもそうだったけど今かなり正確になって来た

**デフォルトの名無しさん** · 2023/06/10(土) 12:33:50.07

>>111
それはコンパイラによるのでは?
g++ + emacsでエラー箇所に正確にカーソル飛ぶよ

**デフォルトの名無しさん** · 2023/06/10(土) 12:40:54.80

g++はひどいよ
clangはマシ

**デフォルトの名無しさん** · 2023/06/10(土) 12:59:32.61

>>113
clagの方が良いのかは使ってないか分からんが
g++ + emacsでエラー箇所に正確にカーソル飛ぶよ
俺の場合はemacsが読んでいるので快適なんだが
人間のおまいさんは冗長で読めてない?

**デフォルトの名無しさん** · 2023/06/10(土) 13:24:02.11

>>107
>cでも商用コンパイラとgccあたりじゃコード品質最悪なんよな
どういう意味？
「商用コンパイラは別としてgccあたりじゃコード品質最悪なんよな」
のこと？

**デフォルトの名無しさん** · 2023/06/10(土) 13:27:34.50

gccはLinuxカーネルのビルドに使われているのだが...
ということは史上恐らく最も普及しているOSであろう
Androidカーネルも

**デフォルトの名無しさん** · 2023/06/10(土) 13:49:10.78

>>115
自分は
商用コンパイラとGCCともに仕様満たしてるだけでろくでもないもんだと取った
そもそも文章がおかしいので何度も読み返した

**デフォルトの名無しさん** · 2023/06/10(土) 14:01:14.28

gccは最初のCバージョンが継ぎ足し継ぎ足しで30年ぐらい使われて
C++バージョンになってから10年経ってるはず

その間の仕様変遷を見るとウンコになってても不思議じゃない

**デフォルトの名無しさん** · 2023/06/10(土) 14:17:35.17

>>118
Initial release: March 22, 1987; 36 years ago

**デフォルトの名無しさん** · 2023/06/10(土) 14:20:47.41

gccとくらべうる商用コンパイラってインテルのことを指すのだろうけど
数値計算の分野以外では使われてないし
数値計算もpythonで良くなったので既存のゴミコード使ってるような会社以外は必要ない

**デフォルトの名無しさん** · 2023/06/10(土) 14:24:39.89

しかし、各種物理シミュレータや、気象シミュレータで、Python なんて使い
たくなぞ。

**デフォルトの名無しさん** · 2023/06/10(土) 14:25:10.78

Python 使うメリットが無いから。

**デフォルトの名無しさん** · 2023/06/10(土) 14:31:14.05

アカデミアでのパイソンの普及は
まずグラフのライブラリの充実が貢献したのかな?
最近ではAI関連のライブラリやサンプルコードの充実が
効いてそうだけど
Rustも頑張ってくれ

**デフォルトの名無しさん** · 2023/06/10(土) 14:34:53.62

既存資産を使いまわせないから使わないだけで
速度的にはもはやpythonで良い
GPU使いたい場合もライブラリでカバーできるし
ちな富岳も富士通が頑張ってカリカリにチューニングされたpython使えるようにした

**デフォルトの名無しさん** · 2023/06/10(土) 14:38:15.83

パイソンってコンパイラあったと思うけど流行ってないの?
流行ってないなら何で?

**デフォルトの名無しさん** · 2023/06/10(土) 14:39:27.76

ちな俺の会社ではモジュールはrust使って書いてるのだがそれを使うユーザーの人たちはみんなpython
だからpyo3というrustをpython拡張モジュールにするライブラリを使っておる
これで開発者はrust、ユーザーはpythonという夢のような仕組みが簡単に実現できるようになった
C++の利点のinteropすらrustの前ではオワコンとなった

**デフォルトの名無しさん** · 2023/06/10(土) 14:41:54.63

pythonはスクリプトに毛が生えたレベルの用途に便利
ライブラリはC++で作ってもいいからパーツをくみ上げる最後のコーディングはpythonレベルでいいんだろう
学習時間も短いんで優秀
万人のためのプログラム言語

だからここで書かれるような批判とはかみ合わない

**デフォルトの名無しさん** · 2023/06/10(土) 14:43:04.43

pyo3とやらはC/C++に比べてどう優れてるの?

**デフォルトの名無しさん** · 2023/06/10(土) 14:45:09.31

本屋の言語の棚の半分ぐらいがpythonとかおかしいんだけどなあ

**デフォルトの名無しさん** · 2023/06/10(土) 14:48:20.22

>>129
本を必要とする層は他のプログラム経験がない層だと思う
パイソンに総取りされているってことだね

**デフォルトの名無しさん** · 2023/06/10(土) 14:53:14.67

>>128
pythonモジュールからrustのモジュールを簡単にインポートできる
感覚としてはpybindに似てるかな
pybindがあるからC++使ってたのだけどもう必要ない

**デフォルトの名無しさん** · 2023/06/10(土) 15:37:41.65

C++は、20年後でも割とそのままコンパイルできて動作する可能性が高いが、
Rustは難しいだろうな。特に crate (library) とかが。

**デフォルトの名無しさん** · 2023/06/10(土) 15:40:16.20

pythonもバージョン違いによる動作が不安定。
ツールを使いたいだけなのに、背後でPythonやJava、Lua、node.js などが
勝手に動き出し、途中でエラーになって終わるこっとが多い。
そして、新しすぎる Python でも駄目。適切なバージョンが有る。
また、それをインストールすることで、また別のアプリや開発環境が
動作しなくなる。
rustcも似たような感じがする。cargoもLLVMも。

**デフォルトの名無しさん** · 2023/06/10(土) 15:42:53.72

そして、Docker使えなどと、こちらに負担を強要してくる。
その Dockerも仕組みを理解するのが人悶着有るだろう。
また、node.js 自体が変なバージョン管理システムを持っており、それが
また大変。ディレクトリ構造が変になって、後から元に戻すのに一苦労する。
それに比べると、商用コンパイラはとてもシンプルで、環境を元に戻すのは
比較的楽。

**デフォルトの名無しさん** · 2023/06/10(土) 15:45:52.02

cargoとかの仕組みを理解するのも大変だ。
manifest的なファイルとか、makefileの代わりになるファイルとか。
そして学んだと思ったら、半年後には、cargo はもう古い、今度は busgo だとか
言われて老害、などといわれる。
automakeだ、Ninjaだ、cmakeだ、ごちゃごちゃしすぎてる。
学び損だ。

**デフォルトの名無しさん** · 2023/06/10(土) 15:49:45.09

ネットだと、pythonは2系と 3系の違いだけで済むかのように見えてしまうが、
実際には、3.2 と 3.6 の違いでもエラーが起きる。
そして、「新しいものをインストールすれば済む」というような生易しいもの
ではない。
Javaも、1.7 系と 1.8 系の違いで、Android で大問題が起きる。
ところが、これも新しくすれば解決と言う問題では無い。
新しくすると、別の問題が起きてしまう。
そして、そのことに膨大な時間をとられ、自分のプログラミングのロジックを
考えている時間はほとんどなくなる。

**デフォルトの名無しさん** · 2023/06/10(土) 15:51:07.08

>>132
少しは勉強してから書いた方がいいよ

**デフォルトの名無しさん** · 2023/06/10(土) 15:54:14.02

rustも公式サイトのドキュメントが不十分だし、また、日本語翻訳版は、
全く理解できない言葉で書かれている。
そして、書かれている情報が古く、現状と合わなくなっていることが多い。
そして、非常に広範囲に渡って知りたい情報が載ってない。
たとえば、マクロ、unsafe、ライフタイム修飾、実際のマシン語
バイナリレベルでの内部データ構造などの情報が大幅に欠如している。
そして、すぐに仕様が変更され、物凄く勉強したのに、無効化され、
老害扱いされる。だから、深く使おうとすると必然的に老害扱い
されるので、表面的にだけ使用するサンプルの様な短いプログラム
している人だけが賞賛されるような事態となる。

**デフォルトの名無しさん** · 2023/06/10(土) 15:55:40.45

>>137
オープンソース関連は、プライドが高い人が多く、自分の比を決して認めない。
「すみませんでした、直します」
見たいな態度を決してとらない。
また、「それは古い、新しいバージョンでは直っているかも」などと指摘されるが、
実際には全く直って無い事が 100%。

**デフォルトの名無しさん** · 2023/06/10(土) 15:58:04.61

あ！適応できないおじさんだ！

**デフォルトの名無しさん** · 2023/06/10(土) 16:02:39.97

>>140
ほら。
crateに関数が揃っているような分野のサンプルプログラムみたいな短い
プログラムを書いて、「ほら凄いでしょ」みたいなことをやってる人が
SNSでよく見かける。でも、ソースを見てみると、本人が書いている
部分は簡単に出来ることを長々と書いているだけ。
本質的には、crateに、たまたま、丁度良い関数が用意されていたからできているだけ。
また、日本は広いので、たまたま上手く行く人がいる。
大部分の人はやりたいことに対する解決策がcrateでは見出せず、結果が出なくても、
SNSなどではそれを知る事が出来ない。
crateにあるものは簡単だが、自分でやろうとする突然めんどくさくなるだろう、
Rustは。

**デフォルトの名無しさん** · 2023/06/10(土) 16:06:25.93

C++に固執してる人は時代遅れのおじいさんしかいなくなってるみたいだな

**デフォルトの名無しさん** · 2023/06/10(土) 16:09:47.88

一緒にするな

**デフォルトの名無しさん** · 2023/06/10(土) 16:23:05.59

あんたは何か一つでも出来ることがあるのか

**デフォルトの名無しさん** · 2023/06/10(土) 16:36:23.23

あの、与えられたものを黙って使いなさいと言われる感は、確かに苦手だね
与えられたものを理解して使いなさいと躾けられてきたし

**デフォルトの名無しさん** · 2023/06/10(土) 18:00:16.89

反対意見が出た場合に、新しいということを根拠に、古い言語を指示する人を
老人扱いするのは狡猾でずる賢い。英語に訳すと clever としか訳せないかも
知れないが。単に clever という意味ではなく、ずるい、悪い、意地悪い、
不公平、などの意味を持っているのでここを見ている外国人は注意。

**デフォルトの名無しさん** · 2023/06/10(土) 18:02:48.96

>>133
流石に言ってることおかしいよ
まあC絡みのバイナリパッケージ入れるときに依存関係で躓くことがあるのは初心者ならあり得るが

**デフォルトの名無しさん** · 2023/06/10(土) 18:09:40.89

>>147
現実にそうなってるんだからしょうがないじゃない。
今までの個人的経験に基いたら、そうなる。
どんなに反対されても、経験してしまったんだから。
だから、100円ショップで100円のイヤホン買って音質が最悪だったから、
多分、他の電気製品やボールペンもそうかもしれないと思って買わないのと同じ。
顧客は、体験から学んでしまうので、普段からの出来事がとても重要。
粗悪品を使わされた店は信用ががた落ちになる。挨拶がしっかりしてる店は
なぜかリピーターが多く、潰れない、と言われている。
それと同じ。今までの態度や商品の出来具合、品質、嘘があったこと、トラブルが多かったこと
などで、顧客はオープンソースにそういうイメージを抱くのは当然の権利。

**デフォルトの名無しさん** · 2023/06/10(土) 18:11:57.76

オープンソースもピンキリだしねえ

でもアレルギーはもったいないぞ
法人が資源を注ぎ込んでるプロジェクトもある
利用しない手はない

ピンキリだけどねｗ

**デフォルトの名無しさん** · 2023/06/10(土) 18:14:02.71

>>149
clangも、重要な部分に不具合がある。
簡単にはリンクが出来ないとか。
不可能ではないが、やり方が書いておらず、自分で試しまくって見つけた。
オープンソースはいつもそう。
そして、次のバージョンでまた変化し、せっかく見つけた対処法も無効化されて
しまう。

**デフォルトの名無しさん** · 2023/06/10(土) 18:17:16.74

>>132
Rustのcrateのversion管理とコンパイラのedition管理は秀逸なので
現在コンパイルできて動いているならば何年後でもコンパイルできて動く

**デフォルトの名無しさん** · 2023/06/10(土) 18:18:26.99

よくあるのは、配布する人が、配布し忘れている何かがあるのではないか。
これはとても難しい問題で、その人の環境では、他の人には存在し無い
ディレクトリにパスが通っていて、その中に重要な何かが置いてあったり、
何らかの configuration file が、デフォルト状態ではなかったりするため、
その人の環境では上手く行き、何の問題も無い。
しかし、配布する際、そのすべてを配布できて無いので、クリーンインストール
した人は、不具合が起きる。
オープンソースは、AppleやGoogleがやっていても、このようなことがよく起きる。
恐らく、ツールや設定ファイルが大量にありすぎるからでは無いか。
しかも、赤の他人が作ったものなので、全貌を把握できない。
改造されてしまったものが流布されているので、原作者でさえ、何が
どうなってるか分かって無い。

**デフォルトの名無しさん** · 2023/06/10(土) 18:22:03.75

>>151
信用出来ない。それは、今までの経験に反する。
Rustだけがその例外だとは信じられない。
しかも、10年経ってみないと答えが出ない。
そんな重要なことは、今までの人生経験から推定するしかない。
オープンソース関係者の言うことほど信用できないものは無い。
中国と同じような感じ。
実際、github のいいねや、寄付は、多くは中国からもたらされている聞いている。
中国企業は、中国共産党から補助金を得ており、それを github に寄付しているの
だろう。中国共産党は今でも社会主義を目指すと言っているので、github や
オープンソースの寄付運動は、中国共産党(左翼の総本山)が行なっている。

**デフォルトの名無しさん** · 2023/06/10(土) 18:24:59.81

unsafeってキーワードは失敗じゃないの
rustではほんとは使っちゃダメってことでしょ
unsafe連発の成果物見て萎えちゃった
せめてunsafe無しでGUIプログラミングできてから出直してきてよね

**デフォルトの名無しさん** · 2023/06/10(土) 18:32:14.35

オープンソース系のソフトは、sysroot だったり、勝手にパスを検索してしまっ
たりする。また、影響を与える環境変数が非常に多いため、動作が不安定になる。
gcc のリンカの ld にしても、余計な検索を非常に多くしてしまう。
たとえば、-lxxx としていすると、libxxx.a だけでなく、xxx.lib, xxx.a, など
非常に多品種な物を検索する。しかも、検索する場所も非常に多い。
これは非常に危険で、脆弱性と不安定をもたらす。
絶対にリンクしてはいけないバージョンを勝手に探し出してきてリンクしてしまったり、
配布もとの人が想定して無いものが実際にはリンクされていて、それが
顧客のクリーン環境では存在して無いから不具合が出たりする。
バージョン違いや環境違い、CPU違いのライブラリが勝手にリンクされてしまい、
不具合になったりもする。
厳密性が無いから、不安定。
世界中の設計指針の異なる無数の人が書いたソースなので、コード規約が守られて
無いため、grep 検索しても不具合のもたらしそうな箇所を見つけ出すことが出来ない。
そのため、いつまで経っても、潜在的な不具合原因が入ったままとなる。
ツールの中に「パスっぽい文字列」が固定で入っていると不安定要因になるなので、
grep検索して特定して削除しようかと思っても、上手く検索に引っかからないので
誰も修正できない。

**デフォルトの名無しさん** · 2023/06/10(土) 19:23:40.48

>>154
こんなことが罷り通ってるんなら、真にunsafe{ } を使いこなしているのは、C++ってことにじきになるなあｗｗｗ
(この目で見てないので)しらんけど

たぶん、C++から行った奴じゃないな

**デフォルトの名無しさん** · 2023/06/10(土) 19:32:24.13

>>154
二つ誤解している
unsafeは人間が安全性を保証しなければいけないブロック
それ以外の部分はsafeとなりコンパイラが安全性を保証してくれる
unsafeはほとんどの場合でメインのプログラムには出て来ずにモジュールやクレートの中に閉じ込めて用いる
仮にunsafeを使っても局所的に閉じ込めることによって人間が安全性を保証しなければいけない部分を極小化する
とはいえ自分でunsafeコード書かなければいけなくなることは特殊な機構やFFI作成など滅多にない
たいていは標準ライブラリや既存クレートを用いて自分はsafeなコードを書くだけで済む

次にGUIについても同じでunsafeは必要なく実際にunsafeを使わずにGUIを使うことができている
ただし上述したようにGUIに限らず一般的に自分でFFI作成となると話は別
FFIの相手先はRustによる安全性の保証が及ばないため当然unsafeとなる
したがって一般的にFFI部分はそのコードのみunsafeを使うがそのモジュール利用者はunsafeを使わずに済むように作る
その利用者である一般のプログラマはunsafeを使う必要はない
ただし論理的にsafeなインターフェースのみを提供できないものに対するFFIのみunsafeなインターフェースが剥き出しとなる
そのようなunsafe剥き出しなFFI利用者のみunsafeの使用が必須となる

**デフォルトの名無しさん** · 2023/06/10(土) 19:42:44.71

pythonは比較的簡単にいろいろなバージョンのすみわけができる仕組みが充実してる方だと思うけどな…

**デフォルトの名無しさん** · 2023/06/10(土) 19:52:04.05

自分もあと20年ぐらいしたらこんなダメなおじいさんになってしまうんかな

**デフォルトの名無しさん** · 2023/06/10(土) 20:22:53.97

>>155
前段リンカーの検索パスは設定可能
コンピュータなので勝手にリンクする訳などなく
設定されたルールに基づいてリンクされる
なぜ自分が使い方を知らないだけだと考えないのだろうか?
随分と傲慢な人だね

後段設計指針はプロジェクトごとにある
ちゃんとレビューしてるプロジェクトもあれば
質の悪いプロジェクトがあるのも事実
淘汰圧が掛かるから重要度が高いものから淘汰されていく

**デフォルトの名無しさん** · 2023/06/10(土) 20:27:27.72

>>160
gcc系はこっちの意図に反して、勝手にやってしまう傾向があるように感じるんだよ。
自分勝手と言うか。パソコン文化、Windows文化、個人向けコンピュータ文化
を知らないことも原因かも知れない。おかしいことがあっても誰も訂正しない。
自己主張が強すぎる。

**デフォルトの名無しさん** · 2023/06/10(土) 20:31:29.16

>>155
>配布もとの人が想定して無いものが実際にはリンクされていて、それが
>顧客のクリーン環境では存在して無いから不具合が出たりする。
Docker嫌ならstatic linkすりゃ良いだけでは?

**デフォルトの名無しさん** · 2023/06/10(土) 20:33:35.95

老害といわれようが、俺が今まで経験した限り、商用コンパイラは安定性が高く、
こちらの意図した通りの動作をしてくれる傾向があるが、gcc も clang も
おかしな動作が多い。極端にコンパイル速度が遅いこともあるし。
それに、途中までは動くが、実際の

**デフォルトの名無しさん** · 2023/06/10(土) 20:35:56.68

>>163
#手が滑った。
それに、clang なども途中までは動くが、実際の exe ファイルまでは作れないことが
多かった。不可能ではないが、結果的に必要なものをたまたま見つけたのが数年後。
それまでは exe ファイルが作成できなかった。
それに比べ、商用コンパイラでこんな自体は経験したことが無い。

**デフォルトの名無しさん** · 2023/06/10(土) 20:37:09.15

>>161
>gcc系はこっちの意図に反して、勝手にやってしまう傾向があるように感じるんだよ。
それはgccのルールをユーザが学ぶべきだろうw

>パソコン文化、Windows文化、個人向けコンピュータ文化を知らないことも原因かも知れない。
UNIXの文化というか作法はWinwosより古くからあるもの
UNIXを使うのなら使う人が学ぶべきことがら
あなたは使わない方が良いと思うけどもね

**デフォルトの名無しさん** · 2023/06/10(土) 20:38:42.11

>>164
他の人が出来ていて自分が出来ていないのなら原因はどこにあるのでしょうか?

**デフォルトの名無しさん** · 2023/06/10(土) 20:38:52.63

>>162
完成品ではなく、開発環境なので、こっちはこっちでリンクされるわけだから、
そういう問題ではない。コンパイラ作者が開発環境をテストする際、テストアプリ
にリンクするライブラリや設定ファイルが、クリーンインストール環境とは
異なっている場合があり、それが不具合の原因かも知れないと言うこと。
コンパイラ作者は、問題ないと思っているが、分かりにくい問題が潜んで
しまっている。
色々な商用コンパイラを使ってきたガ、こんなことは無かった。

**デフォルトの名無しさん** · 2023/06/10(土) 20:39:43.60

>>166
実は他の人も出来て無い。
オープンソース系は、なぜか出来て無いのに出来ていると嘘付く人が多い。
本当に出来て無いのだ。

**デフォルトの名無しさん** · 2023/06/10(土) 20:44:44.71

gccもclangもc++専用コンパイラじゃなくて多言語に対応した仕組みになってるからコンパイルが遅くても当然だよ
前段で各言語の処理して汎用の中間コードにして（必要なら他の中間言語にまた変える）そこから最適化を数段挟んで最適化して出力してる

**デフォルトの名無しさん** · 2023/06/10(土) 20:46:40.11

>>167
何書いてるのか分かりにくいが
おまいさんがある開発環境を整えようと思ってできなかった
その原因は作者にあると言いたい?

>>168
>オープンソース系は、なぜか出来て無いのに出来ていると嘘付く人が多い。
何のためにwww

**デフォルトの名無しさん** · 2023/06/10(土) 20:49:42.17

>>163
モジュール化して分散コンパイルすると良いよ
PCの台数あるならdistccとか導入するとかも良い

**デフォルトの名無しさん** · 2023/06/10(土) 20:52:18.83

>>135
何年も経ってるのにいまだにcargoを超えるものが出てきてないのが現実だよ

**デフォルトの名無しさん** · 2023/06/10(土) 20:53:27.65

>>167
あ！わかった
Winowsと同じ要領だと思って
ディストリ配布の公式バイナリ以外を
よく考えずにインストールして
必要なライブラリのバージョンが合わずに
動かんかったパターンだな

**デフォルトの名無しさん** · 2023/06/10(土) 20:54:32.51

>>136
まずOSのパッケージマネージャでほとんどのバージョンはインストールできる
それでほぼ困らないし組織で使うならバージョンを固定するのが当然
どうしてもバージョン縛りがあるならdockerで動かせばよろしい
それも嫌ならvenvもある
それすら嫌ならcondaに引きこもる手もある

**デフォルトの名無しさん** · 2023/06/10(土) 20:58:47.61

pythonはパッケージマネージャを使えばバイナリ自体が違う名前でインストールされる
だから既存の環境がぶっ壊れることはない
もちろん手動で入れるとその限りではないから
ちゃんと理解してる人でないとできないし既存の環境を"上書き保存"してしまう可能性はある
まずパッケージマネージャを使うことを徹底すべき
alternativeコマンドを使えばデフォルトのpythonコマンドで使うバージョンを固定できる
これでほぼ環境問題は無くなった

**デフォルトの名無しさん** · 2023/06/10(土) 21:01:11.95

これ加えてvenvを使えばインストールするモジュールも固定できる
これで何がダメだというのか？
この辺の知識を調べるのは面倒ではあるが一回調べてしまえば何も困らない

**デフォルトの名無しさん** · 2023/06/10(土) 21:02:30.66

少し前にあった非常にダメな時期にかじったんじゃないかなと

**デフォルトの名無しさん** · 2023/06/10(土) 21:03:38.89

pythonに限らずLinuxに野良パッケージ入れるときは
$HOME以下のサブディレクトリにstow使って入れると良いよ
決してroot権限を使うべからず

**デフォルトの名無しさん** · 2023/06/10(土) 21:05:10.87

WindowsであってもWSL2を使えばほぼ同じではないのかな？

**デフォルトの名無しさん** · 2023/06/10(土) 21:06:02.68

お爺さんが言ってるのはcygwinやMinGWでclangがうまく動かないとかそんな話じゃないかと
それで動くexeを吐かないと言って憤慨してるとしてもう～んという感想しかない

**デフォルトの名無しさん** · 2023/06/10(土) 21:09:25.45

pythonが仮想環境の構築に取り組んだおかげで他の言語もいろいろと恩恵にあずかれているはず
パッケージの仕組みもいろんなところへ波及したと思う

**デフォルトの名無しさん** · 2023/06/10(土) 21:20:41.24

pythonのpipがゴミと言ってる人をよく見かけるが
cargoと比べると論外なだけでvenvなどと組み合わせれば十分手厚くて要件は満たしてると思うけどね

**デフォルトの名無しさん** · 2023/06/10(土) 21:51:38.11

>>135
Rustを使えばcargoだけを覚えればよいから簡単で楽でおすすめだよ
色んな言語の中でも最も良い環境の一つ

**デフォルトの名無しさん** · 2023/06/10(土) 22:03:52.12

C++erは、オーバスペックなものも好きくないんだよ
職務では、指定されたものを指定されたように使うんだけどさ、自分用はね

**デフォルトの名無しさん** · 2023/06/10(土) 22:03:52.50

>>135を見ても適応能力が低いんだな
若くなさそうなので適応能力が低下するのも無理はなかろうが
周りが悪いと当たり散らすのは良くない

**デフォルトの名無しさん** · 2023/06/10(土) 22:07:14.56

老人だから新しいものを覚えられないんだろうな
もう引退しろよ

**デフォルトの名無しさん** · 2023/06/10(土) 22:21:25.81

ある程度普及したり評価された後にパッケージやモジュールの仕組みを変えるのは容易ではない
でも結構最近はあるよな…

**デフォルトの名無しさん** · 2023/06/10(土) 22:21:57.78

>>182
いやいやww