結局C++とRustってどっちが良いの？ 3traits
レス数が1000を超えています。これ以上書き込みはできません。
「C++の色々配慮してめんどくさい感じは好きだけど、実務になったらメモリ安全性とか考えて今後Rustに変わっていくんかな」
「うだうだ言ってないで仕事で必要なのをやればいいんだよ、趣味なら好きなのやればいい」
っていう雑談スレ。
前スレ: 結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/
関連スレ(マ板): Google&MS「バグの70%はC/C++。Rustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/ 板のルールが理解できない、プログラムがロクに書けない人たちのスレ
>>1死んどけ荒らしのクズ あらゆるところに関所がある
まるで江戸時代だ
裏山に抜け道を見付けて分け入っても
突然藪から棒に番人が現れる
ところがそんな番人も
unsafe印籠を魅せれば一撃で退散だ
unsafe万歳!!!
こんなことなら最初から
表通りでunsafe印籠を出しておけば良かったんだ
きっと番人たちも思っているはず
さっさと最初からunsafe印籠魅せやがれ
無駄な手間取らせやがって
こんなのがエコシステムとか失笑もの === 複製おじさん（通称複おじ）について ===
Rustスレを中心に活動し、2023年4月現在で1年以上ム板に住み着くRustacean。無自覚な荒らし。
Rustスレでは、基本的に他住民の意見を聞いて糧とすることなく、自らのコードが最善であると、ID変更自演を交えいつまでも主張し続ける。
同スレで「所有権が複製される」という違和感のある表現を、「違和感がある」とする他住民の意見をすべて否定してしつこく擁護し続けたことから、「複製おじさん」というあだ名が付けられた。
それ以外のム板スレでは、基本的に他住民の意見を聞いて糧とすることなく、Rustこそが最善であると、ID変更自演を交えいつまでも主張し続ける。
その基本戦術は、「GC言語は遅い」の一声でC/C++/Rust以外の言語を否定し、残ったC/C++は安全ではないので、Rustが最善であるとするもの。
しかしながら、Rust以外の言語に関しては、正当な批判を展開するのに十分な知識を持っているとは言いがたい。
本スレPart1では、C++の問題点を指摘しようとして多数の誤り・知識不足を露呈することとなった。特にしつこく食い下がったのが「動的ディスパッチ」に関する誤解である。
https://mevius.5ch.net/test/read.cgi/tech/1677286186/786-799（ID:Evbafc70とID:RiLc+pIfが複製おじさんであると考えられている）
要約すると、通常「条件分岐」と呼ばれるものを「動的ディスパッチ」と呼ぶのが正しいと主張し続けたのである。
常識的にはあり得ない誤解だが、提示されたC++のコードが自らの主張（C++にはパターンマッチが無い）に不都合であると感じたためか、C++のコードを正しく読み解くことができないにもかかわらず脊髄反射的に否定してしまい、その根拠として誤った論理をこじつけてしまったものと思われる。
ちなみにこの後、同種の誤解を持って書き込むID:wHEiYRW7（これはID使用歴的に複製おじさんとは考えにくい）に対して、正しい理解に基づく指摘を行う単発IDが複数出現するが、この中にも複製おじさんが多数含まれていると考えられている。
このように自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装うのも複製おじさんの特徴である。 Fooという型だけを別ファイルfoo.rsへ移してファイルを分けたくなったとする
もちろんそれは可能だが二つの方針に分かれる
その1
pub mod foo;
とする
つまり単にmod foo;とするのではなくpubを付けることで利用者がfooにアクセスできるようになる
さらにfoo.rsでFooにもpubが付いていれば
利用者はfoo::Fooまたは クレート名::foo::Fooという形で利用できる
その2
mod foo;
pub use foo::Foo;
とする
つまりfooは公開しない
しかしFooは公開したいのでfooの下ではなくトップでFooを公開する
この場もfoo.rsでFooにpubは必要
利用者はfoo::を付けずにFooまたは クレート名::Fooという形で利用できる
ようするにファイルを分けたときに
分けた形で公開するならその1
分けたことを隠蔽して公開するならその2 >>5
>自分の誤りを認識した場合、それを認める書き込みは決して行わず、別人の振りをして最初から正しく理解していた体を装う
図らずも昨晩今日のC言語スレでその現象が観測されました さらに型Fooのイテレータだけ別ファイルiter.rsに分けたくなったとする
その時はfoo/iter.rsというファイルにする
そしてfoo.rsの中でmod iter;とすればよい
分けたことを隠蔽するか公開するか>>6と同じ方針で望む
もし公開するならfoo::iter::Iterのようにパスが長くなる
それをメリットかデメリットかで決めればよい 次に>>6とは全く逆
ファイルを分けたくないけど
foo::Fooという形で公開したい時
その場合は
pub mod foo {
ここにFooの定義など
}
とすればよい
ファイルfoo.rsに分けたときと同じにできる
つまり
ファイルを分けるか分けないか
公開パスを分けるか分けないか
任意の組み合わせで自由に可能 かの御仁、ディスパッチのことになるとずいぶん熱くなってたよなあ
継承を廃止するのに必要だったからってわけだったみたいね さらに5つ目の方法
ファイルは分けなくて
mod foo{...}という形でfooは分けるけど
そのfooは見せない！
と一見すると矛盾した方針がある
その場合は>>6と>>10からのご推測の通り
mod foo {
ここにFooの定義など
}
pub use foo::Foo;
とすればよい
利用者は直接Fooまたはクレート名::Fooとして使える
しかしそれならば
mod foo{...}を使わずにそのまま直接Fooの定義を書いたのと同じじゃないか！
との疑問が湧く
ほぼその通りだが
この方法によりmod foo{...}の中は名前空間が分離されているため
他とのコードの分離もしっかりできる
もし外部との結合があれば
mod foo{...}の中で改めてその使用宣言が必要になる
逆に外部から使われるものはpub宣言が必要となる
mod foo{...}の中に敢えて入れることでそれら他との関係が明示させられる
つまりまとめると3つの自由度がある
・mod fooとして分けるかどうか
・それをfoo.rsとしてファイルに分けるかどうか
・そのfooを外部に見せるか隠蔽するか
それらを多段foo::bar::bazそれぞれ含めて自由に決めればよい >>12
Rustは継承を使わずに合成だが
動的ディスパッチ自体はほぼ変わらない
vtable部分が合成した各メソッドを含む一覧になる程度 ほとんどのmoduleは
自分の今のprojectから分離して別のcrateに移動しても
module内のpub関数はuse cratename;すればそのまま変更無しで参照出来るが
module内のmacroはuse cratename;するだけでは参照出来ない
#[macro_export] だけでは不十分でmoduleに
pub use macroname;
を書き足す必要がある >>9
ごめん
proc_macro が共存出来なかったって事だった
ていうか proc_macro が共存出来ないのは昔からだな ITの世界は短期決戦の世界。知名度がこんなに上がってるのに使用者数が1%未満
のRustには一般言語にまで普及する可能性はほぼ無い。 今までの蓄積ではなく、新しく書かれているコードの量ですら1%未満であることの
意味は、絶対に普及しない路線に入っていると言うことだ。 商品が売れない原因の9割は知名度不足だと言われているが、Rustは既に最高レベル
の知名度になった。なのに「売れてない」。それは商品自体に問題があると考え
なければならない。俺はRustが嫌いなので、それでいいと思っているが。 結論としてはRustはC++に比べるとファイル分轄が非常にめんどくさいと言うことだな
ルールが複雑でめんどくさい
言語仕様なのかcargoの仕様なのかしらないけどフォルダ構造が縛られるし… よくわからんけど自分でstruct沢山作ってcore/modelフォルダ作ってそこに全部突っ込んでフラットに使おうとすると障害があると
implをcore/implに突っ込もうとしても問題があると
それかそれを参照する何かを別に作らないといけないと
自由度が低い いやーさすがにC++に比べたらRustのが超シンプルなのでわかりやすい
C++のモジュール知っててRustのモジュールを理解出来ない人はいないと思う /struct、/impl、/traitみたいな分け方をしたかったのかぁ
できなくはないけどやめといたほうがいいんじゃないか したいんじゃなくてそれは仮に書いただけ
自由度が低いと言うことを示したかっただけ
ファイル名やフォルダ名が縛られたり
なんで自由度が低いのに顔を真っ赤にして自由度が高いと書くのか不明なんだけど 既存のC++のプロジェクトに書き足していくかたちでCargoとかが使われてるんだろ？
C/C++の作法に併せたRustのフォルダ構成の裏ルールがあるとしか思えない モジュール名とファイル名（パス）は↓みたいな書き方で一応切り離せるよ
ややこしくなるから基本使わないけど
#[path="platform/foo_windows.rs"]
mod foo;
自由度が高いってのはたぶん外面を維持したまま内装を変更しやすいって意味で使ってたと思う
（長文だったからちゃんと読んでない）
モジュールの構成は可視性に関わるからそこまで自由ではないと思う
全部にpubつければ自由になるけどそんな自由はいらない 自分が使ってる中ではC#が一番自由度が高い気がする
classの分割自由
名前空間の分割自由
プロジェクト内ではフォルダ空間自由
ファイル名自由 global usingと言うものが出来て各ファイルでusingもしなくて良くなった
これはいらない機能だと思うけど C#はまじめに使ったことないけど拡張メソッドとかいうのが自由すぎて若干引いた記憶がある
どこで何を足されるか分からない恐怖を感じた プロジェクト内のファイル位置も当然自由
一ファイルに複数の名前空間含めるのも自由 Rustがなぜファイル名やフォルダ名でモジュール固定になってるかと言えば
それしかモジュール位置を決定する仕組みがないから
ルートのコードからたどれる物しか名前を解決できないから
それが良くないんじゃないの？
>>35
既存のクラスすべてで必ず拡張されるわけじゃない
本当は拡張などしてなくてただのstaticメソッドだし
どこかそれを他で使われていてもそれをusingしなければ使えないから関係ない
usingしててもpublicじゃなければ見えないので影響はない proc_macro で黒魔術やりたい放題出来る様になりますた
おまいらのお蔭です本当にありがとうございますた
っていうか proc_macro::TokenStream と proc_macro2::TokenStream と
同時に使うと違うと判ってても混乱するな >>35
>どこで何を足されるか分からない恐怖を感じた
これは Rust の trait や後付けの impl にも同じ臭いを感じる 一応Rustのimplは型（trait）を定義したクレート内に制限かけてるけどそれでも気になる人はいるか
自由な場所で定義を足せるとどうしても散らかりやすくなる >>38
---- lib.rs 側 ----
use proc_macro::TokenStream;
use proc_macro2::TokenStream as PM2TS;
(略)
#[proc_macro]
pub fn mk_ts(_item: TokenStream) -> TokenStream {
let mut ts: PM2TS = PM2TS::new();
Ident::new("let", Span::call_site()).to_tokens(&mut ts);
Ident::new("x", Span::call_site()).to_tokens(&mut ts);
Punct::new('=', Spacing::Alone).to_tokens(&mut ts);
Literal::u8_suffixed(255u8).to_tokens(&mut ts);
Punct::new(';', Spacing::Alone).to_tokens(&mut ts);
ts.into()
}
---- main.rs 側 ----
fn main() {
mk_ts();
println!("{}", x);
}
これで実行は出来たけど TokenStream がぶつかってるのが気に入らない main.rs の方は
mk_ts!(); だった >>30
基本的に、JavaとC++は兄弟言語で、共通点がとても多い。
classの概念もほとんど同じだし、とても良く似ている。
一方、RustとC++は全く違う言語。 全く違うんだが 現状は C からの置換を目指さなきゃいけない
その辺りが フォルダ構成にも反映されてしまっている
当然だが マッチの箇所は プロログなどの方が近い 現にデコンストラクトによるパターンマッチはlispかhaskelくらいでしか見かけない 似てたら置き換えやすいけど、置き換える意味も薄まりそうだけどな 「みんなが使ってないものが使いたい」という心理を持っている人が一定数いて、
Rustはそういう人に受けてる可能性もある。 Microsoft「Windows 11がまもなくカーネル内でRustを用いて起動」
https://www.neowin.net/news/senior-microsoft-exec-says-windows-11-kernel-will-soon-be-booting-with-rust-inside/
BlueHat IL 2023 カンファレンスにおいて、マイクロソフトのエンタープライズおよび OS セキュリティ担当バイス プレジデントである David Weston が登壇し、
Windows セキュリティの進化について話し合い、最新の進歩と今後の道のりについての洞察を講演しました。
プレゼンテーションの中でWeston氏は、MicrosoftがWindowsカーネルの一部としてRustを使用して行ってきた進歩について説明しました。
いくつかの理由でこの言語に興味を持っており、そのうちの11つはRustが提供するメモリの安全性とセキュリティを中心にしています。
Weston氏は次のように述べています。
「おそらく今後数週間または数か月以内に、カーネルでRustを使用してWindowsが実際に起動することになりますが、これは本当にクールです。
ここでの基本的な目標は、これらの内部C ++データ型のいくつかをRustの同等のデータ型に変換することでした。」 前スレにも書いたけど、ブートローダってDOSアプリみたいなもんで、劇的に画期的じゃないんだよ
APIが早くRust化してほしい そうすれば、C++も恩恵を受ける マイクロソフトがわざわざC++を捨ててまでRustを採用するとはよっぽどのことだよな
Linuxの方は元からC++さえ排除してC言語だけの純血主義だったのにRustを採用し始めてる >>49
記事を読んだがブートローダーなんて書かれてなかった
Rustを使った場合のWindows OSのパフォーマンス比較でOffice apps使用の場合が出てくるからブートローダーの話ではないね 昔、マイクロソフトはわざわざJAVAを捨ててJ++を開発したんだよなあ これまで多数の言語が登場したけど求められてる条件はたった二つだけ
「C/C++と同等のパフォーマンスが出ること」
「C/C++の各種安全性の問題が解決されていること」
Rustが最初で唯一の言語 >>53
安全にするにはGC言語にするしかないと思われていたからね
Rustだけが勝者となった Rust以外でGC採用せずにメモリやリソースの後始末をちゃんとしてくれるよう設計された言語って何があるの？ お! GC君だ（この人が複製おじさん?）
GC君は他人のことを初心者呼ばわりするけど
技術的な話が全くできないんだよなぁ... >>50
$ tar xJf linux-6.3.1.tar.xz
$ find linux-6.3.1 -name *.c -o -name *.h | wc -l
55806
$ find linux-6.3.1 -name *.rs | wc -l
38
0.07%未満! 前回v6.2.1のとき37だったから1ファイルは増えてるね
何が増えたかは
$ diff -uNr <(cd linux-6.2.1; find . -name *.rs) <(cd linux-6.3.1; find . -name *.rs) >>52
JavaScriptをわざわざパクッてJscriptってのも作ったな
今やIEブラウザごと滅んだが
アップルとかソニーとか独自規格を作りたがる連中はいつの時代も迷惑 Rustはメモリリークには割と寛容なんだよね
野生の参照（ダングリングポインタ）は目の敵にするけど >>56
Rustしか現存しない
他に出てきそうにないため今後Rustの時代が続くのだろう >>45
>デコンストラクトによるパターンマッチ
聞かない用語ですねぇ～
デコンストラクト >>60
ヒモさえ付いてれば無駄遣いしてもOKみたいな RustってNimに対して何か優位なところはあるの? >>63
NimはGC言語
GCに頼らず済ませられる部分のみ使わないで済むというだけ >>56
間違い：メモリやリソースの後始末をちゃんとしてくれる
正解：メモリやリソースの後始末をちゃんとしてくれる(リーク除く) 基本GCでも充分な性能が出れば別にいいよ
最適化が必要なところだけ手動でやるのはRustも同じだから
手動ライフタイム管理とのトレードオフ >>69
RustはNimのような逃げをしていない点で全く異なるよね
NimはGC言語という点でも誰も異論はなく FactorはForthとLispの子みたいな動的型付け言語
ガベージコレクションあり GCの有無は指標になるけど、現状のC++の、なんでもかんでもヒープに置く習慣は、
GCとそんなかわらないんじゃ…と思わなくもなかったり C++はコンパクションが行えないので、GC付きのJavaのほうが速いのです
って言ってなかった？ 感覚的にはプリミティブでない単純なデータ（xyz座標とか）の配列を直接作れるかどうかがボーダーな気がする
ポインタの配列を作ってるようだとGCしなくてもGC言語
C#は微妙なライン
変なタイミングで大掃除始める問題もあるけどこっちを気にする機会は少ないような 結局、RustはC++より速くても、Javaよりは遅いってことですね もう少し待てはマイクロソフトがR++を出すと思うから
それまで待って >>76
Rustはスタックを多用する言語なのでJavaより速い >>80
スタック上のメモリ領域はCPUレジスタであるスタックポインタを足し算引き算するだけでメモリ確保と解放できるため最も速い >>81
CPUの仕組みを知っててそういう認識の人はいないと思いますよ >>81のスタックメモリ利用が一番速いで合ってるけど
スタックメモリは関数から戻ると自動的に開放されその部分は無効になっちゃう
そのため従来の言語ではスタックメモリの利用を抑え気味にすることでその問題を過剰に回避してた
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになったことが違いかな CPUのレジスタ利用が一番速いがレジスタ割り付けの最適化が非常に難しいので
スタックを使ってお茶を濁してる スタックメモリが主記憶と別の場所にあると思ってない？ もしかしてヒープは主記憶、スタックはプロセッサの中にあるとか思ってない？
いま検索中？ メモリの確保の仕方の違いでの速さの比較の話でレジスタの話を持ち出すのは違うでしょ
そしてレジスタの数は限界がありその退避先もスタックメモリですよ
スタックメモリに割り当てられた変数は最適化によりレジスタ割り当てが可能であればレジスタのみ利用になりますね
>>86
スタックメモリは単なるメインメインの一部にすぎません
しかしメモリ確保と解放が最も速いだけでなくメモリキャッシュに載る点でアクセスも速いです 頭のおかしい人間がずっと一般的な事実に基づかない頓珍漢な独自妄想理論を展開してる スタックを積極的に利用しているからrustがjavaより速いと言われて
納得する馬鹿はいないだろ
もっと根本的な理由があるだろと
javaはVMでスタックマシンをエミュレートしてるから遅い 通常はレジスタ一発で出来ることもわざわざスタックマシンでエミュレートしてるので遅い スタックメモリが確保の点でもキャッシュされてる点でも非常に速いのは常識
そのためGC言語であってもGoのようにまずはスタックメモリ利用を優先する
(他へ渡すときだけGC対象になるヒープを利用) >>95
Rustはそこからさらに一歩進めて他へ渡すときもスタックメモリを使えるように改善してますね
Rustはライフタイムの導入でスタックメモリを安全な範囲内の限界まで使えるようになりました 変な人大集合だね
それがrustよりjavaが速い理由だと思い込んで疑わない変な人たち おっと逆だ
それがjavaよりrustが速い理由だと思い込んで疑わない変な人たち C++とRustに比べればJavaは当然遅いしどうでもいい スタックってそんなでかくない、っていう世界もCの領域なんだよね
そんときの感覚を今でも引きずってる気はする
アプリケーションの起動時に、がつんとデカく確保しちゃえばいいんだろうけどね
なんとなく、ね >>103
Javaが一番速くて、少し遅れてRust、かなり離されてC++だろ >>95
いわゆるエスケープ解析と呼ばれているテクニックだな
スタックメモリ利用が断トツに速いのでできる限り使うようにする
GoだけでなくJava含めていくつかの言語で行われてるが適用に限界がある
単純には各ポインタのライフタイムが関数内に閉じてればスタックメモリを利用
他の関数に渡した時は確実に追い切れないので難しい
それを可能とするには言語自体がライフタイムをサポートする必要がある
それを実現したのがRustでありライフタイムを完全に追うことができて現在最強 RustよりJavaのほうが速くなることも多々あるけど
unsafeやarena使ったりして最適化すればJavaより遅い状況はなくなる
でもJavaもネイティブコンパイルできるようになってるから起動速度含めてシェルスクリプトの代わりに使えるくらいには十分速いよ ほとんどのベンチマークでRustが圧倒的に速い
自分でunsafeする必要なんかない JavaやGoより明らかに高い性能を得ようと思ったら面倒臭いRust特有の最適化が必要になるから
自分用のツールに速度目的でRustを使うのは生産性的におすすめしない
製品開発やそれに準ずるライブラリ開発であればRustも有り >>109
根拠なくそういうデマはよくないと思うよ
「面倒臭いRust特有の最適化が必要になる」なんて聞いたことも体験したこともない Javaはないわー
なんだかんだいって、Oracleのドル箱なんでしょ、あそこの法務はなめちゃだめだ＞＜ chatGTPのいい加減なときの答えみたいなレスが増えたな
しょうもない細部にこだわって全体を一切見ない
事実を使って嘘を作るようなレス >>114
> すべてを1つの言語Mojoで書く。
> Pythonを書くか、metalまでスケールダウンします。
> 多数の低レベルのAIハードウェアをプログラムします。
> C++ や CUDA は必要ありません。
挑発的だな
Pythonがベースの拡張で書きにくいことが確定だからどうでもいい Pythonが手になじんでる人には吉報かも
こりゃC++に流れ込んでくる日も近いね 逆になるべくC++でやって行きたいと思う人も大勢いるということを
分かってない。 名前からして ジョークじゃねえの
オースティンパワーズ デラックスで見たぞ これ Python使いだけど、全部自力で書きたい…みたいな
GC系言語にどんどん拡がっていくんじゃね >>106のエスケープ解析やライフタイムを本格的にやるのかな
C++を一気に超えてしまいそう 少しrustの仕組みを勉強してきた
いろいろと勉強になった
面白いからしったかさんを泳がしておこうｗ Pythonはインスタンスをヒープに置くことしかしていないが
スタックに置いて高速化するかもしれないのか LLVMとかあのへんに任せるんだろうから、できるようになりだしたらあっという間 GCの分だけRustの方がJavaよりも早いんじゃないの
一般論だけど GCって予測不能なだけで速いか速くないかとは関係ないのでは?
それよりJavaはプロセッサとの間に入るJavaマシンが律速段階なのでは? ネイティブコンパイルができるとからしいから、だいぶ速くなったんかしらんが
Java派のサイトでいいから資料示してくれ
>>111 のとおりで、触る気にはならん それこそJavaやるんならRustやる 多くの人たちが一つの問題を色んな言語を用いて実装することで各言語の実行速度比較例
https://pbs.twimg.com/media/EmYvG8aVkAMdfFG.jpg
AtCoderのABC182-E問題で提出された各プログラミング言語別の実行時間分布 c++の実装数の多さよ。
Rustの「実装しようとしてできなかった数」がどれくらいになるのか知りたいところ。 >>131
Rustは書きやすいから
世間での普及と比較して多数使われてるな
速度もRustとC++は並んで最高速
一般での普及指標も毎年ぐんぐん上昇しているからあとは時間の問題のみか C、C++、Rust の速度に関しては、fact checkが必要。
少なくとも、C や C++ は、高級アセンブラなのだから、最速のはず。
Rustに負ける可能性はゼロ。 「C++はRustより遅い」などと言っている人は、C++の標準ライブラリ(STL)
だけを使った場合に限定してしまっている。
C++は、アセンブラで書けることはほぼ何でも書けるし、Rustはそれを越える
ことは不可能なわけで、C++がRustより遅くなると言うのは論理的におかしい。 もし、「RustがC++よりどうしても速くなる例」があるとするならば、
Rustのコンパイラは、C言語ではかけない特殊なマシン語を出力できる
ようになっているということである。
しかし、RustのバックエンドはLLVMであり、C/C++ のコンパイラ clang の
バックエンドも LLVM であることから、なぜそのような現象が起きるかは
大いに疑問となる。LLVMはLLVMレベルで最適化を行なうことができるような
コンパイラが存在しているので、C++が吐いたコードを最適化しても、
なぜか、Rustが吐いたコードを最適化したものより遅くなってしまうと言う
ことが起きなければならないことになる。
しかし、C++は、高級アセンブラであり、アセンブラで書けることは特殊命令
以外は基本的に全て書ける。ということは、Rustは、そのような特殊命令を
出力しない限りは、C++に勝つことは不可能と言っても過言ではない。 いや、>>131 を見る限り、平均するとC++はPythonにすら負けてる 誰かがスタックメモリを使ってるからrustが早いと言ってるけどllvmレベルでは差がない
吐き出した中間コードみてもそんな特徴は特になかった いや、>>131 を見る限り、平均するとRustは最速 >>136
アセンブラに詳しくない人のために捕捉しておくと、特殊なマシン語の
例外(仲間はずれ)を除けば
「C言語の演算子は、アセンブラ(マシン語)の 1命令に一対一対応している」
とほぼ言える。なので、基本的に、マシン語を1命令ずつ書いていくのと
同じレベルでC言語はプログラム可能である。それに当てはまらないのは
CPUに依存したような「独特なマシン語」が存在している場合に限られる。
そして、コンピュータは、最終的には全てマシン語に置き換えられて実行され、
マシン語しか理解できない。
そして、C++は、C言語の演算子や機能は全て包含している。
ということは、C++は、特殊命令以外のマシン語を全て1命令ずつ記述できる、
ということである。
マシン語しか理解できないCPUに対して、C++は、あらゆる順序のマシン語を
ほぼ人間が思った通りの順序で書こうと思えば書けるのであるから、どうして、
C++が最速に成らないのだとしたら、非常に特殊な事態が起きていることになる。
その特殊な自体は、人間の手作業による最適化であると考えられている。 >>139
平均と言うが、C++は、Rustのsafeモードを越えられる。
逆に、Rustはsafeモードだけを使っていると、C++に絶対に勝てない状況が
存在すると何度も指摘されている。 >>139
それを見てもptyhon最速の人とC#最速の人が何をしたのかが気になるだけ >>140
「ほぼ」の意味を書いておく。
int x, y;
x = y;
と書くと、x,y をレジスタにとっていない場合は、
マシン語では、
mov eax,dword ptr [&y]
mov dword ptr [&x],eax
の2命令になり、基本的に1命令では書けない。
x,y がレジスタ、ebx, ecx にとられている場合は、
mov ebx,ecx
という1命令で書ける。
だから、x=y は、2命令になるときと1命令になるときが有る。
これが、「ほぼ」の意味である。 >>143
同様に、x += y; は、
x,y をレジスタにとっていない場合は、
マシン語では、
mov eax,dword ptr [&y]
add dword ptr [&x],eax
となり、
x,y がレジスタ、ebx, ecx にとられている場合は、
add ebx,ecx
という1命令で書ける。
だから、x += y は、やはり、2命令になるときと1命令になるときが有る。
「ほぼ 一対一対応」の意味は、このような意味で言っている。
C言語はどうしてもマシン語よりも粒度が大きいので、1命令に置き換える
事が出来ずに、2命令か3命令程度になってしまうことはある。 >>145
なお、Rustは、C言語よりさらに少し粒度が大きいことが多い。
C++は、C言語を包含するので、書こうと思えば、C言語と同じ粒度で書ける。 ながながとつまらないことを書いてるな
最適化でsimdを自動で使ってくれるベースがあればそっちが勝つわ >>146
[補足]
誤解なきように行っておくと、Rustも、= や、+= のような演算子の粒度は、
C言語と基本的に同じことが多いので、その部分に関しての両者に優劣の
差は無い。だから、RustはC/C++と同じ程度の速度が出ることがある。 >>147
基本を知らない人が誤解する可能性があるので書く必要があった。
C/C++がアセンブラ以外に負ける可能性はほぼ無いと言うことの
根拠を示した。 コンパイラは高速化では中間言語化が有効なケースが多い
llvmの最適化はそれで行われてる
rustは二種類の中間言語に変換されてバイトコードを出す
でも中間言語に寄らないヒューリスティックな最適化も存在してる
そちらは泥臭く研究が進められてそちらは今llvmより速いコードを吐き出している 「ほぼ」の意味が、よく誤解されているから、混乱が起きているようなのだ。
「ほぼ」というのは、>>143 や >>145 の意味においてである。
決して、曖昧な意味で言っているわけではない。 >>150
それでも、C/C++は、そのRust独自の最適化後のコードを手作業で書くことが
できるから、Rustに負ける可能性が「ほぼ」ない。
ここで、「ほぼ」の意味は、>>143 や >>145 の意味である。 エスケープ解析はjava一時期重点的に研究されて実装に取り込まれている
誰か天才的な人間が開発に来たんだろう
golangも後追いでエスケープ解析入れてるけどエスケープ解析をオンにすると速度が落ちるケースが多いらしい
開発者が愚鈍なのか想定ケースを外れてるのか不明 マシン語とは、mov,add,sub,mul,imul,div,idiv,cmp,jnz,jb, jbe, ja, jae,call,ret
の組み合わせでプログラムする方式である。
それは、C/C++ 言語で「ほぼ」一対一対応でかけてしまう。
なので、Rustがそれを越えることは「ほぼ」不可能。
「ほぼ」の意味は、>>143 や >>145 の意味。 >>154
マシン語プログラミングとは、
mov,add,sub,mul,imul,div,idiv,cmp,jnz,jb, jbe, ja, jae,call,ret
のような20個ほどの命令を組み合わせて書く書き方。
ところが、C言語では、少し粒度が大きくなってしまうが、それらの20個の
命令に対応する命令が存在している。つまり、C言語では、マシン語の
1～3命令の単位で命令を書くことが出来る。マシン語の1命令にならない
ケースは、レジスタが足りなくて本質的に1命令で書けない場合。 エスケープ解析が有効なシーンにあっても速度向上はわずか1%～2%ぐらいのレベルなので
誤差と言えば誤差 >>154
時代に取り残されてるな
まず大昔にレジスタ最大限活用最適化により1対1は崩れてる
さらにパイプライン最適化によって手書きアセンブリが敗北するようになってのがだいぶ昔の話
並行してキャッシュ最大限活用最適化によりスタック利用有利がさらに強まったり お互いに自分の強いと思う必殺技を叫んで殴り合ってる状態だな
映画館に行かずにこんなところで聖闘士星矢が見られるとは… 今は究極のパイプライン最適化により
生成された機械語と元のプログラミング言語は実行順序すら異なる
だから連投してるアホ>>155の書き込みは読む必要なし
memory orderingとかすら知らない低レベル いくらRustが独自の最適化しても、その最適化と同じことを
C++では書こうと思えば書けてしまうのだから、C++が負ける可能性
はない可能性がとても高いと言うこと。 >>160
そのレベルの最適化は、コンパイラの最後の段階であるところのLLVMレベル
で行なわれるから、Rustとclangで差が出ることは無い。
出るとしたら、LLVM最適化がたまたまその時には上手く最適化できなかっただけ。 >>162
厳密に言うと、「LLVMレベル」ではなく、それより
さらにマシン語に近いところのレベルの最適化。 まあ一番差が出るのは浮動小数ユニットの扱いだけどね。 >>162
同じLLVMを用いていても
C++よりRustが速くなった例はいくつか知られていて
それはRustの参照排他ルールによりLLVMに渡すことができる制御情報オプションが増えることで
LLVMによる最適化がRustの場合のみ生じることが原因のようです
つまりRustの言語仕様がC++より速くなるケースを生み出しています どんどん互いにいい技術をパクリあって向上したらいいだけだろ
今後AIによるコード研究が進むだろうし技術的境目はどんどんあいまいになってく
過疎板でお互いにペガサス流星拳を打ち合う必要もなくなる >>131
そもそもこのグラフが、何を測定したかの説明も無い。
事実である根拠も無い。
Rustだけ優秀な人がプログラムし、C++では、スクリプト言語上がりの
CPUやマシン語の基礎が分かってない人がプログラムしたのかもしれない。
それに、Rustは、必ず世界最強クラスの最適化バックエンドLLVMを使っている
のに対し、C++用のコンパイラは最適化がほとんど行なわれないような簡易
コンパイラも含まれる。 ていうか、シンプルにしか書けない(のが利点の)Rustに負けるC++の書きようが悪いって話
きれいに書こうなｗ >>131
「実行時間」というが、PICやAKI-H8、ラズパイPICO、安物Androidデバイス
と、Core i9 とでは全然違ってくる。
Rustは、32BIT 以上専用なのに対し、C++ は、8MHz(?) の 16BIT の
PIC マイコンでも使えるのだから、比較にならない。
C++は、安い低速CPUでも動くが、Rustは高級で豪華な CPU でしか動かない
ということだ。それがグラフに現れているだけだろう。 >>165
>それはRustの参照排他ルールによりLLVMに渡すことができる制御情報オプションが増えることで
>LLVMによる最適化がRustの場合のみ生じることが原因のようです
>つまりRustの言語仕様がC++より速くなるケースを生み出しています
その場合、C++でも、同じ「参照排他ルール」に従ってプログラムすれば、
LLVMは同じように最適化できるだろう。 >>167
>>169
atcoderは競技プログラムのプラットフォームで参加者がコード書いて提出
コンパイルも向こうでされてるので統一した環境ではあるかなとｗ >>171
だったら、外国では、C++には、レベルの低い人も参加したのに対して、
Rustはレベルの高い人だけが参加した可能性が高い。 atcoderは日本のサイトだよ
出題は英語で去れ店の？
rustは答えを出せる人間が少なく
低レベルコーダーが足切りされてる可能性が高い >>172
もう一つの可能性は、C++は歴史が長いから、古いCPUで測定された時の
実行時間が記録に残っているのに対し、Rustは、新しいCPUで測定された
記録しか存在して無いという不公平があるのかもしれない。 >>173
つまり、
「Rustは初心者向けではない」
「Rustは優秀な人が試している段階」
ということを示しているのかもしれない。 >>170
参照排他ルールに従うプログラミングをするだけでは最適化されません
言語コンパイラがLLVMへその指示を出さないとLLVMは最適化しないし出来ません
例えばLLVMのnoalias最適化指示の場合
Rustではプログラマーは何も指定しなくても言語仕様によりRustコンパイラが自動的にLLVMへ自動的に指示を出します
C言語の場合はrestrict修飾子が導入されているためプログラマーが自己責任で修飾すればCコンパイラがその指示を出すことが可能です
C++は言語仕様にないためプログラマーは指示できません (言語仕様を独自拡張しているコンパイラのみ可能)
以上のようにプログラマーが何も指示せずともLLVMで最適化が行われるRustが有利な現状です >>178
それは初めて知りました。
このスレで初めてまともな意見です。 C++の方が自由度が高いのだから遅く書くことを妨げない
一方でRustの自由度は低い
書いた人のレベルが如実に現れたってだけでは?
実際に最速は変わらない
Cの最速が遅いのはサンプルが少なかったから? でたらめを書く前によく見ろよ
グラフにatcode abc 182 e と書かれてるからその問題見て見たらいいだろ
abc = AtCoder Beginner Contest
2020-11-08(日) 21:00 ~ 2020-11-08(日) 22:40 (100分)
問題はAからFまであり後ろに行くほど難易度が高い
E問題を見ると再帰も使わないただのループ問題だからrustの有利なシーンはないと思う
制限時間があるからそこまでの問題で事実上足切りされた人が多いんだろ 通常通り書くとやはりpythonとかは遅くなると思う
速い回答出せた人もいると言うことは技術的に枝狩りできるシーンがあるんだろうな
atcoder知らない＝おじいちゃん C++でやった人は、単に個人の遊びとしてやっていただけなのに対し、
Rustでやった人は、Rustの力をこのスレで自慢するために最高の品質
のコードを書いた「バイアス」があった可能性を除外できない。 atcoderなんてやってるほど暇人じゃないから。 なんで1問だけで比べるのか
データ公開されてるよね？ それでこのスレでペガサス流星拳を撃ってるとｗ
その前におじいちゃんはe問題解けるのかなあ？ pythonでギリギリ問題解けるようなレベルの人間がc++やrustに移行できるとは思えない
c++やrustという言語で足切りされてる
でも今後はプログラマー不足が顕著になるのでpythonの利用が促進されると思うわ そもそも、「実験しなければ分からない」というのは物理や数学、コンピュータの
世界ではウソ。理論があるし、人間には想像力があるんだから、思考実験で
済む場合が多い。但し、アホな人は除く必要がある。 プログラムの最適化に詳しくてもプログラム自体出来ないなら本当に存在意義が不明なんだよな
○○が早いと言う人より目的時間内にコードを完成させる人が求められている
アセンブラが捨てられて高級言語が使われてる
生産性の向上が一番の問題
○○速くてスゲーと言うのは意味がない
知識があれば小学生にでも言える >>190
そこで不足している簡単なレベルかつPythonでできるようなことならば
類似サンプルも多数ネット上に転がっているせいでChatGPTが答えられる
だから従来は人員不足とされたその分野の人材は不要となった
C++/Rustで書かれる分野は少なくとも現状のAIは対応できない
特にインフラをAIが吐くコードに依存するのはリスクが高すぎるため人間の最後の砦として需要が残るだろう 小学生に○○流星拳と言う言葉を教える
何かあればそれを叫ばせるこれがこのスレで起こってる全てです AtCoderの良問は良問だぞ 俺は全然だけど
あんなもん要らねえｗｗｗとうそぶきつつ、こそっとやっとくと賢くなる >>172みたいに自分に都合の良い想定を平気で行う人間は
どういう大学出てるんだろうな
「可能性が高い」なんて学部生のレポートレベルでも書かないわ
そのへんのリテラシーなくクソレス書き散らしてるの恥ずかしくないのか 競技プログラミングってC++でやるもんでしょ
集まってくるやつのレベルもピンキリだよ >>131の各プログラミング言語の実行速度比較は実行環境が統一されてる点で信頼度が非常に高いと思う
さらに多数の人たちがコードを書いているためコードのせいで遅くなったりする要因も排除できてる
たまにあるベンチマーク比較でコードが下手なせいで言語によって左右されてるのも見かけるため 自分は触れたくないがpythonって存在は面白い
c++やrustには移れないのにpythonならできるって人が多い
今後c++やrustの研究が進んで実行速度が1%上がるとかそんなレベル
乾いたぞうきんを絞ってる
それだったらpythonをjava並みに引き上げるほうが社会的意義があると思う
pythonの有名ライブラリはc++で書かれてチューンされて実行速度は速い
個人が各部分のコードが遅くてもライブラリが速いならこれで十分
でもそれがc++ユーザーに反映されて利用が進んでいるとは言えない
一般の研究で利用はpythonに軸足が移ってる
今後も進むだろうし いや、どうみてもPython（PyPy3）書いてるやつらはヘタだな
C++のやつらと同じ程度の頭脳なら言語そのものの早さはともかく分布の形状が同じにならないとおかしい
Pythonだとベストのアルゴリズムを選べないんだろうか？
2500msまで行ってるのはC++しか無いがおそらくはタイムオーバーで失敗したやつもいる
この課題をクリアできたやつの統計だな
クリアできなかった人数もやっぱりC++とPythonが多いと思われる
単に利用者が多いからな 頭脳程度が同じだとすればPythonだと10000ms程度で解けるような尾の方が足きりされてるから分布がそう見えるだけなのか？
すると分布の形状はC++とは相似で、pythonではそれが拡大されただけになる だから知能レベルが低くてコーディングが下手な人間が書いても成果が残せるんならそっちの言語に注視したほうがいい
ある意味優秀だからさ
たまにライブラリレベルで回答できる問題もあるし正規表現で解決できる問題もある
優劣と言うより実現できるかどうかの世界 とするとC++とPythonの下位は全く同じアルゴリズムを使っているが、
C++の言語性能のおかげで2500msに収まっている
考えてることが同じ人間でそう変わるわけもない まともにプログラミングができる人ならばC++かRustもやるだろうしな
高速さと省メモリで他の言語とはまるで違う
このスレになぜかJavaのほうが速いと主張してる一匹いるが 効率の良いプログラムを書けない人はAI代替でいいから不要となるんじゃないか
C++とRustだけが残りそうだ e問題を見れば分かるけどおそらく出題内容をベタにそのままプログラムすると遅くなる
c++の人たちはそんなことはしてないと思う いいすぎかな
実際自分は解いてないで雰囲気で言ってるだけだから的外れかもしれない 後は手元でのコンパイル時間だろうか
gccとrustcでせいぜい100行200行のコード、コンパイル時間に差が出るとも思えないが
100倍も違ったらさすがに競技プログラミングでは忌避されるがそうじゃあないでしょう
そして書いてすぐ試せるとなるとpythonとかになる
にも関わらずRuby利用者がいないのは悲惨としか言いようがない 競プロに限らず無駄な効率悪いプログラムを書くプログラマーが溢れてる
そいつらで十分な分野はAIで置き換わるのたろう
ちゃんと考えて効率良いプログラムを書けるプログラマーならC++でもRustでも会得すぐだしな pythonは有名ライブラリ内でavx512使ってたりする
コードが寄贈されたりしてる あとはCargoと競技プログラミングの相性だろうか >>206
効率の良いプログラムもAIが書いてくれるようになる >>214
現在のAIの方式だとそれは無理だな
論理の理解がなく例えば素数すら列挙する以外に理解できない
足し算ですら桁が大きくなると間違える
抜本的な大発明が将来起きない限り見込みがないだろう >>131 みれば、平均したらRustのほうがC++より速いだろ
それどころか、平均したらC++はPythonにも負けてそうだぞ >>215
AtCoderの問題を解くような処理がプログラミングにおいて最もAIを活用できる分野だよ
広く知られたアルゴリズムの最適化なんてお手のもの >>220
競プロに興味はない
そんな話はしていない C++がウェブ界に進軍したら、お前らみんな無職だぞ
C++のパワーをまざまざと見せつけられ、しょんベンチビルと思うわ それにしてもPython速いな
中にRust入ってるのと違うやろな >>215
AIが理解できなくてもパターンみたいに学習するからできちゃうんじゃん
突飛な想像力が必要なのは無理だろうけど 工夫すれば１行分（＋電球とブロックの位置）の記憶だけで解けるのか
H,Wが1500以下でメモリ制限1024MBだとH＝~Wの確保も許容範囲だからそこで差がつきそう
解答者全体のレベルがよく分からないけどPythonにもガチ勢がいただけでしょ >>224
パターンはその通りで得意
しかしそこからの帰納法が無理
例えば素数を多数知っているがそこから素数の性質特徴を理解するのは無理
ただし学習として素数の性質特徴はわかるしプログラムも多数転がってるのでわかるだろう
でもそれじゃダメだ
未知のもの(初めてのもの)に対して出来ないといけない >>226
そういうことができるプログラマ以外いらなくなりそうだよね >>226
素数に関して突っ込んでいえば、素数の定義と素数の性質＝すべての自然数は素数の積で一意に表現できる、との間には大きなギャップがあるのに、それがあまり意識されていないのが問題 >>227
全く逆だよ
そういうことを差別化要素と捉えてるようなプログラマがいらなくなる
コモディティ化しやすい知識とそうでない知識の違い バイアスがあった可能性を否定できない っていうんなら逆方向も否定できないだろうに、なんでこのおじいちゃんは片方にだけ肩入れするん？
不自然ですよ 最大の問題は rustの利用者が何でこんなに少ないかだな
ただ これには複案があって おそらくは C ++から 移ってきたやつらがrustをやってると思われる
すると rustの標榜する モットーにも合致すると思われる もう出ている通りに この問題を最速で解く 機械語 は存在するので
あと疑うべきは 入出力のオーバーヘッドだけになる
メインのアルゴリズム やら ロジック やらが同じなら
遅くしている要因は 入出力だ >>232
しかし、SNSを見てると、好きな言語にRustを書いている人は、他の好きな言語と
して、JSやGo、Kotlinなどを挙げる傾向が強く、C++は全く書かれてない
ことが多い。 C++のほうが機能が多いので、使える人はC++を使うからだろ 機能の差の比較は難しいが
言語自体で様々な安全保証をするRustの機能が本質的に大きいかな C/C++の90%のコードが危険というような話は
9割が20年以上前に書かれているだけで
最近のマナーで書けば済む話では IT大手各社が揃って同じ判断をした
C++では無理なので新たなシステムからRustを採用
そしてRust Foundationを共同で立ち上げた
さらに既存のWindows、Linux、AndroidなどもRustの採用を開始 そんなこと言ったらJavaの採用も開始してるしC/C++なんか大昔から採用を開始してるだろ 非GC言語として絶対的な王道を確立したC++が存在するにも関わらず、
新たな部分からC++ではなくRustを採用し始めたことに重い意味があるのでしょう。
しかも競合ライバル同士が同じ判断をした点も非常に重い意味があるのでしょう。
そのため正しい判断をした可能性が極めて高いでしょう。 C++は死ぬべきだけど、後釜がRustでいいかはわからんわ
コストかけて置き換えるなら最高の言語がいいしな Rustの書きやすさは気に入ったね
次の言語はコンパイラが様々な保証をする点を押さえた上で、Rustが取り込めないような別の新たな画期的な機能を持たないといけない
他に芽が現状ないからこのままRustで進みそう この流れなら言える
cpp2を知らなかったなんて言えない 実際のところ、将来的に最適化はAIがやるようになって、要件定義と検証だけ人間がやるようになるんだろ。
設計自動化の流れだわな。
そうなってくると実装を人間がやる状況は限定されて、言語もIDLみたいになってくるかと。土方コーダーは全滅だな。
まぁ、c++はCOBOLみたいに過去資産メンテに、Rustはpostscriptみたいにバックエンドで生き残る可能性はあるけど。 >>244
AIにとっても機械語を直接吐くのは保守性が悪すぎる
一方で少なくとも当面は人間が検証できる既存のプログラミング言語になりそう
万が一の時の対応や問題把握のためにも既存の言語が良さそう
インフラは人間がある程度把握し続けないとAIに主導権を奪われかねない点でも同じ
使われる言語は自動的に色々と保証されるRustになるのかな 人命や経済損失に大きく関わるシステムは責任や論理的な信頼性の観点からAIに頼るのは無理そうだね。 AIはTDD（人間がテストコード書いてAIが実装コード書く）と相性いいかなって思ったけど
絶妙にテストケースだけパスするようなコード吐いてきそうで怖い
人間的な一般化パターンを学習すれば使えそうだけど現状だとコピペミキサーでしょ AIがどうとか関係無いはずなんだが
Rustのここがダメ！みたいなことを書くと必死でレスしてくれる人がいるから無限に話を脱線させることができるんだね .gitignore に Cargo.lock を入れてるのに
cargo publish すると Cargo.lock もうｐされる
github の方にはもちろんうｐされていない
cargo publish --allow-dirty は本気で要らないものまでうｐされるからこれはやってないのだが AIに書いてもらうプログラミング言語はC++かRustになるんだろうが、
C++でプログラムの本質でない部分の隙を残すよりも、
コンパイルが通れば静的にその部分が自動検証されるRustになるんだろうな >>251
バカだな
>>131の実行環境のマシンはプログラミング言語に依らず同一に決まってるだろ >>249
内部で呼ばれるcargo packageの仕様っぽいね
https://doc.rust-lang.org/cargo/commands/cargo-package.html
の2.でCargo.lockを含める条件が書かれてる
excludeで強引に外せるのかな >>234
C++使ってるけどC++が一番好きではない
どっちかというとCの方が好き Rustの検証や推論ってAIの役に立つか？というか役に立つようなAIを作るべきか？
それらもコンパイラではなくAIが判断するようにしたほうがよくないか？ 今話題になってるAIは緻密な整合性検証できるというよりも、人間の雑な問いに「らしい」答えを返してくれる感じだから、コンパイラ側の緻密な推論とかは引き続きやっていく必要あんじゃねえの。 >>259
それならAIが内部でRust的なツールを使ってチェックするだけでよくて、
Rustのコードを出力する必要はないんじゃね >>245
AIにRustのコード吐かせる理由なんて無いよね Rust急進派によると、rustcをパスするコードは自動的に与信できるらしいので 速度は、1%位の差になってくると、コンパイラの最適化能力に依存するが、
Rustはrustcの強力なLLVMを使っているのに、C++は、LLVMのclangを
使えばいいのになぜかgccを使っていたりするのもおかしい。 >>259 >>262
そうするとコードの安全性は人間かコンパイラが保証するしかないわけか
そうなるとAIに書いてもらうコードはRustしかないな >>263
llvmの方がgccより性能良くなった? >>264
仕様を自分で書く
仕様を満たしてるかどうかを確認するテストを機械に書かせる
テストが正しいがどうか人間がレビューする
テストをパスするコードを機械に書かせる
この繰り返し
機械にやらせてるところは今はベンダーに外注してる作業
抽象度が低くパターン化しやすい仕事ほど高い信頼度で機械化しやすい >>267
コーディングできない上流と設計できない下流の非効率なウォーターホール方式を続けるの？
テストさせられるほどの細かな設計まで自分でやるならコーディングもしてしまった方が早くない？ >>269
テストの粒度は上流から下流まで様々あるんだよ
テストさせられる==細かな設計とは限らない
ちなウォーターフォールね そんな上位の仕様を渡すだけで内部設計も何でも自動でやってくれるAIは当分来ない
学習して曖昧パターンで答えてくれる方のAIは論理的思考がまるでダメ
論理的な方のAIは厳密に指定し尽くさないと適当に補完してやってくれない
根本的に180度違うから融合の見通しもない 公開したcrateの要らなくなった古いバージョンとか消したくても消せないのか
githubよりタチが悪いな
他から参照してると仕方ないのが判るが
管理システムとして破綻してないかこれ >>268
gccとclangのどちらの最適化が優れているかは誰にも分からないので、
その影響をなくすためにも、rustc と 比較すべきは gcc ではなく、clang
ということになるわけです。なので、今後ベンチマークを取る際には、
rustc vs clang で行かないと意味が有りません。 そのように同じくLLVMを使ってコンパイルしても
>>178のように言語仕様が原因でC++が遅くなりRustが速くなる事例があるんだよな いくらC++が速いといっても、ちゃんと書かないと速度は出ない
当たり前の事実と向き合うべき時期が来ているようだなｗ プログラミングは能力差が激しいからな
C++を使おうが遅いプログラムが出来上がってしまう人たちも多いが本人自身はなかなか気付けない
Rustだとそれが顕著に出るのでわかりやすい
入門初期は仕方ないがその後もRustを難しいとか面倒とか言ってる人たちは能力の低いプログラマーだけ vec!とか使い捲ってると便利過ぎて
コピーされてるのか所有者移動してるのか意識してない人は遅くなりがち とフィボナッチイテレータより高度なプログラムが書けない人が申しております >>279
vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
値一つ指定でN個を初期化するにはClone以外に方法はない
まあClone回避パターンもありRustは完璧だ >vec!はベクタ初期化時のみに用いられるマクロにすぎずそんな問題はない
doubt
>値一つ指定でN個を初期化するにはClone以外に方法はない
doubt
>まあClone回避パターンもありRustは完璧だ
doubt
よくこんな短文で嘘ばかりかけるな 複オジにいちいち突っ込んでたらキリがないぞ
騙されそうな奴がいなければほっとけばいい オジ使いの人は否定はしても理由も正解も書かないからどっちが正しいのかいつもわからん オジオジ言ってる人は間違いも多いけど偶然あってるときもあるぞ
適当に聞き流しとけ プログラミング言語に使われる人になってはいけない
プログラミング言語を使える人になりなさい >>275
ですが、LLVMの最適化層は、メモリー領域が重なっているかどうかを解析する
機能も持っていますから、noaliasを明示的に付けなくても、最適化層が
自動的にnoalias相当の属性を付けてくれる場合も有り、そうなれば、
同じ程度に最適化されます。
C 言語の register 属性を付けなくても今のコンパイラは変数を自動的にレジスタ
に割り当てるのと似たようなことです。
飽くまでも補助情報です。 >>288
残念ながら一般的な場合にはその解析が不可能
そのためC言語はrestrictキーワードの指定の有無がそのまま最適化の有無に繋がる
このnoaliasによる最適化はベクトル化にも繋がるため実効果も大きい
Rustの可変参照は常にnoaliasとなりLLVMへその情報が伝わるため有利 >>289
>残念ながら一般的な場合にはその解析が不可能
一般的には難しいとされていますが、できる場合も有り、実際 LLVM
の最適化層は、解析を「しています」。 >>290
もちろんLLVMが解析で見つけ出すケースもゼロではないだろう
実際にはC言語でrestrict指定のコードを書くか否かで最適化の有無となっている現実が多々ある
つまり各言語はnoalias情報をLLVMへ渡したほうが確実に有利だ
C++は言語仕様にないが各コンパイラの独自拡張を使えば指定可能
もちろん無闇に指定してよいわけではなく確実にnoaliasと判断できる場合でないと動作不良を引き起こす
Rustは言語仕様によりデータ競合を起こさないよう可変参照が排他的になるため確実にnoaliasがLLVMに渡る >>291
C++でも、noalias をつけたLLVMを出力するコンパイラも有るかも知れません。
コンパイラの進化の問題です。 >>292
バグが見つかったのはLLVM側ね
Rustが常にnoaliasをLLVMへ指定してくるようになって
適用事例が増えてLLVMのバグが発覚できた感じ
そしてLLVM側がバグ改修中にRust側は一時的にnoaliasの指定をオフした話だね 重要なのは犯人捜しではなく
「可変参照は常にnoaliasとなり」は嘘だということです >>293
Cではプログラマーがrestrict指定した箇所だけコンパイラがLLVMへnoalias指定する
C++ではプログラマーがコンパイラ独自拡張__restrict指定した箇所だけLLVMへnoalias指定される
言語仕様によりC/C++コンパイラがnoaliasを自動付与することはできない
C/C++プログラマーが安全に適用できると判断した時だけ自己責任でrestrict指定することになる
Rustは言語仕様により常に安全に自動的にコンパイラがLLVMへnoalias指定する
そのためRustプログラマーは何もしなくてもnoaliasによる最適化の恩恵を受けることができる
これが根本的な違い コンパイラに撃墜されてるRustプログラマもいるから「何もしなくても」は言い過ぎだな >>295
現在はLLVMがバグ対応したため常にnoalias指定となる
もちろん意図的にバグ未対応の古いバージョンのLLVMを指定したときを除く
その場合にRustコンパイラはnoaliasを指定しないという安全な動作をする そんでいったい何nsec早くなるんですか？ってな
些細すぎる点です Rustならテキトー書いても速くなる…はさすがに夢見すぎだろう (やってないので)しらんけど おそらくだけど最適化が利いたとしてもベンチとかでは0.01%も速度は速くならないと思うけどな 普通にコードを書く限り一般的な速度は
c<c++<rust何だろ
でもそんなのにこだわって言語選ぶ意味はないよ 速度じゃないわな
実行時間だ
速度だと
c > c++ > rust >>300
Rustは適当に書いたらコンパイル通らない。 いうて、C++でinline、constexprやらテンプレートメタとかで実行時の処理効率を上げまくったらRustじゃ敵わないと思うんだけど、、
Rustでも似たようなこと出来るんだっけ？ >>305
Rustもできるよ
そもそもRustのconstはコンパイル時定数でC++のconstexprのこと
Rustの手続きマクロはRustコードの構文解析を入出力としてコンパイル時に実行生成するためC++より強力だね なるほどね
俺の全力のC++コードじゃRustには敵わないようだ >>299
>>301
noalias指定で劇的に速くなる例はC言語でrestrict修飾の有無の解説ページが多数あって詳しい
restrict指定がないとnoalias最適化ができずにベクタ化されずに遅くなる例なども出ている テキトーに書いてもコンパイルが通る言語に憧れるなあ 複雑なことを好き勝手に書けるのがC++だったけど、簡潔に書くことも求められるようになりそうだねえ
当初は複雑だったけど、やることが大体固まったものをrewriteするなら、
いまなら確かにrustがアツい 成果も目に見えると思う たぶんCでは力不足だしね lintだけでもいいから、smart c++とか名前を付けてRustもどきの強制フォーマットを作って欲しいわ。
Rustそのものは要らん。 Rust本スレもﾜｯﾁｮｲ無しのほうやめちまえばいいのにな
C++相談室はすんなり移行できてて羨ましい >>310
それならば静的型付けではない言語を選ぼう
ここは静的型付けのC++とRustのスレだからコンパイル時に可能な限りエラーを出す言語
>>315
その方向を求めるならばRustの方が優れているからC++にこだわる必要ないんじゃないかな
生産性の高いRustを使った方がメリット享受もたくさん crates.io にうｐして docs.rs の comment cover が
中々 100% に到達しないんだが
どこの comment が足りないって簡単に教えてくれるツールは？
local で docker 使えば判るもんなの？
あと「未 comment」数を減らした(=100%に近付けた)はずなのに
逆に%下がるケースもあるみたいで良く判らん lintにmissing_docs
https://doc.rust-lang.org/rustdoc/lints.html#missing_docs
があるけどデフォルトでallowになってるらしい
lib.rs（main.rs）に
#![warn(missing_docs)]
を足すかコマンドで↓を実行
cargo rustc -- -W missing-docs >>316
注意喚起テンプレとこの隔離スレが効いてるから本スレも平和 >>319
㌧クス
しかし足りない数(あと5ヶ所のはず)よりはるかに多い warning が出て来たでござる >>319
5ヶ所治して残りの warning 放置で 100% 達成出来ました！
ほんとうにありがとうございました！！！ C++だとdoxygenなど使うところが
Rustだと公式サポートされて色々と進んでいるのね win32kbase_rs.sys
win32kfull_rs.sys
って何?
ついでに名前が似た以下のファイルも
win32kbase.sys
win32kfull.sys ttps://japan.zdnet.com/article/35198420/ C++0xの暗黒時代を知らない世代が増えたんだろう >>317
上澄みだけ使うならライブラリも豊富だし悪くない。
本来なら、c++標準化団体がAccelerated C++みたいなのを用意してメンテナンスすべきだと思うけどなぁ。 デザパタ流行した時ほにゃららパターンのほとんどが理解できなかったけどそのうち理解しなくても何の問題もない事が判った
うんこうんこうんこー >>332
実務で今使ってるのは、state, proxy, singleton, factoryくらいかな。
あとは使ってないね。 近年の C + 人気は上の画像でも見ただろ
競技プログラミングだよ GoFのパターンはiteratorとかadapterも含めてるから多分無意識で使ってるよ
昔のforループはi++で回すのが普通だったし
JavaにIterator（foreach構文）が追加されたのが1.5くらいのはず 懐かしの 何とかの呼吸 ○の型 ほにゃらら！が沢山あるけど
使わないときは使わないと言うだけです Rustの呼吸 一の型 mut代入！
Rustの呼吸 二の型 シャドーイング！ それ現行コンテンツちゃうの? (初クール初回から録画だけして観てない C++コアガイドラインに従い、IDE組み込みのチェッカーを使う
これが一般的なスタイル
これだけであなたの悩みはすべて解決する カーネルのどのへんで使われてるんだろう
Linuxみたいに周辺部分からかな >>341
Rustの成果をC/C++に還流させるフェーズ どんどんやってくれ Microsoft Azure security evolution: Embrace secure multitenancy, Confidential Compute, and Rust
https://azure.microsoft.com/en-us/blog/microsoft-azure-security-evolution-embrace-secure-multitenancy-confidential-compute-and-rust/
Rust as the path forward over C/C++
Decades of vulnerabilities have proven how difficult it is to prevent memory-corrupting bugs when using C/C++. While garbage-collected languages like C# or Java have proven more resilient to these issues, there are scenarios where they cannot be used. For such cases, we’re betting on Rust as the alternative to C/C++. Rust is a modern language designed to compete with the performance C/C++, but with memory safety and thread safety guarantees built into the language. While we are not able to rewrite everything in Rust overnight, we’ve already adopted Rust in some of the most critical components of Azure’s infrastructure. We expect our adoption of Rust to expand substantially over time. マイクロソフト、Rust言語による開発を含む初めてのWindowsカーネルをInsiderプログラム参加者向けに提供開始
https://www.publickey1.jp/blog/23/_rustwindowsinsider.html
デバドラからか これを見ると、言語の移り変わり時期が来ると
一気に使われなくなって廃れていくんやな、、
https://m.youtube.com/watch?v=qQXXI5QFUfw コンパイラは何使っているんだろうね?
MSがllvmなんかつかうのかな? 新しいGC言語がどれだけ出て来ても
C++の天下は揺らがない
もしC++が転落するときが来るとすれば
C++の欠点を解決しつつ同等の性能を出せる新たな非GC言語が登場した時だけだ trait 内の fn は pub 付けていなくても
trait 自体が pub で定義されていたら
他の trait (というか上の trait を引き継いでいる) からでも参照出来るんだね Visual R++
Visual R#
しっくりこない R言語はもう別であるからRustがR++になる心配はない トリビア: トレイトメソッドに付くVisibilityは構文定義上だけは許されている https://doc.rust-lang.org/reference/items/traits.html#item-visibility
Trait items syntactically allow a Visibility annotation,
but this is rejected when the trait is validated. またひどい知ったかぶりしてる……
https://medaka.5ch.net/test/read.cgi/prog/1619943288/575
575 仕様書無しさん 2023/05/12(金) 15:53:45.02
C++のスマートポインタはRustで吸収され
・RustのCopy実装型 (使われる時は自動コピー)
・RustのCopy非実装型 (使われる時はムーブ) ← C++のunique_ptr
・RustのArc型 (atomic増減でスレッド間も利用可) ← C++のshared_ptr
・RustのRc型 (高速にスレッド内で利用可)
つまりunique_ptrの機能がRustでは標準で備わっている
さらにshared_ptrはArcでその軽量版Rcが追加
C++と異なり使い間違えるとコンパイルエラーで知らせてくれる
さらにRustは参照と可変参照の規則によりデータ競合をコンパイル時に防ぐ >>361
C++のunique_ptrとRustのBoxは対応しない
Boxはヒープ確保であり例えば以下でのnew int(123)部分にあたる
std::unique_ptr<int> foo(new int(123));
そしてunique_ptr自体にヒープ確保の機能はない 天下ねえ
天下って思われてると、むだに煽られるよねえ
C++サイコーｗｗｗ(大好き)とは思ってるけど 何故プログラミング言語が変わるのか
まずハードが変わる、当然命令セットも変わる、さりとてハードが変わるたんびに新しい言語を覚える、既存のソフト移植する、など不可能なのでここで一個
ソフトサイドで新しい考え方が出てくる、既存の考え方ではバグ出やすい、効率悪い、こう考える方がいいという新しいプログラミングに関する知見が出れば言語そのものの刷新に向かう圧力が出る
ここで一個
大別すればこの2段やろな
①高級言語
━━━━━━
②繋ぎレイヤ
━━━━━━
③アセンブラ
①、③は必然的な刷新圧力に応じてどんどん変わっていく、③は必然的に新しいハードが出るたびに、①は絶対ではないけどBasic, Perl, Java, Ruby, Python などなど概ね5～10年周期で変わってきた
しかし②のレイヤはほぼ半世紀近くC,C++の独壇場, MachとかObjectice Cとかあったけど結局消えていった
さてさてどうなるのか？
Windows, Linuxでは一部Rubyに置き換える試みがなされてるけどコレは本流の大きなにがれになるのか、あるいはやはりごく一時的なものでやはりC,C++の牙城は崩れないのか たった今あるソリューションがRustだから、切迫した更新需要にはRustが入ると思う
もうちょっとゆとりのあるものは、improved C/C++ でいいかなって感じじゃないかな
自分もその位置 >>362
make_unique知らないの？ 知ってて黙ってる？
それとも知ってたけどunique_ptrに属さないから駄目だって言いたいの？
というかその差異を認めたとしても、スコープを抜けるとき/ムーブされるときに内容の後始末とヒープの解放を行うという重要な共通点が依然としてあるし、
その点を無視してunique_ptr<T>を任意の非Copy型と対応付けようとするほうがよっぽど無理があると思うけどね lifetime の &'static と
global の static で
同じ名前になってるのはセンス無いな
Rust 界にも static おじさんは息衝いている なんかメチャクチャ書いたな
NeXT Stepとかはあくまで周辺プログラミング環境がobjective CだっただけでOS本体はMach kernelでそれはCとかでかかれてるから②のレイヤでC,C++に変わるものは四半世紀でてきていない
果たして本当にここにRustが食い込めるのかね、あるいは置き換わるなどということが本当に起こりうるものなのか >>373
そこはむしろRustの美学というか方針
Rustは予約キーワード類を最小とするために巧妙な使い回しと組み合わせを意図的にしている >>371
make_uniqueは複合の合わせ技だから、
unique_ptrのコンストラクタを見た方がよいね
引き数はnewで確保したポインタなどだから、
unique_ptrの構築前に別途ヒープ領域を確保済
一方でBoxの構築時はまだヒープ領域を確保しておらず、Boxがヒープ領域を確保
だから両者は決定的に違うんじゃないかな
さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね
スコープを抜けたときの処理や内部で持っているヒープ領域の解放については、
unique_ptrやBox以外でも行われる話だから、両者の共通点というよりもっと大きな範囲の共通点だね >>375
騙されないぞ
それじゃC++とおんなじじゃないかｗ >>373,375
staticはglobalスコープとは関係ない
lifetimeがstaticなだけなのでどっちも同じ意味
美学てｗ Copy非実装型とBoxとどちらがunique_ptrに近いかと言えば大多数の人はBoxだと言うだろうな
まあ言語が変われば1対1で対応しない機能があるのが普通なので
無理に対応づけようとするよりもそれぞれの違いを学んだほうがいいよ >>376
> さらにunique_ptrは空っぽの状態、つまりヒープ領域を伴わない状態が許されるのに対して、
> Boxは必ずヒープ領域を伴っていて、そこに値を必ず持っている、という重要な違いもあるね
だからBoxとunique_ptrは対応しないってんなら、Arcとshared_ptrを対応させるのはもっと間違ってるぞ Boxはボックス化つまりヒープに置くこと
C++で対応するのはnew BoxもZero Sized Type(ZST)だとheapを伴わないよね >>377
Rustは凄いと言ってる奴は、自分はRust使ってないからな Javaが出てきたとき
Javaすげぇぇ他の言語は駆逐される
PHPが出てきたとき
PHPすげぇぇ他の言語は駆逐される
何か出るたびそれを信仰し同じコトを繰り返すんだな 自分で作るじゃなく他所で作られたものを自慢をするというね
こういう言語そうだそれ以外の物でもそうだし >>384
結局どうなったかっていうと、PHPはサーバサイドのDSLとして落ち着いた
JavaはOracleが接収? した
立ち位置が減少したのは多分Perlだが、いまPerl使ってるって言っても殴る人はいない
(以上、すべて個人の感想)
今回は、LLVMの成熟により、様々な言語が2.0化しようとしてるみたい
わりと何ででも、安全に、高効率なプログラミングができる時代になるのかもしれない
Rustは、新しいbetter C のような気がしてきた
…けど、記述法がどうしても見慣れない(ｗ javaはIT企業ではある意味他言語をを駆逐したと思うわ
特殊なケースだけc++、ｖｂ使う
webのDSLでtypescript
地元（田舎）の求人見ると
java,C++が使える人かjs使える人の求人が99%だから… これでWindows、Linux、AndroidがRust採用かー rubyは使ってると殴られる言語だが
pythonはまだ大丈夫だな
phpやvbは死んでいい >>387
記述法が見慣れないのは
キミが関数型をやってないからじゃね 色んな言語やっている中で見比べて
Rustの記述法のほとんどの部分は
複数言語に見られるものかその平均に近い記述
>>387の見慣れない記述法とは何を指すのだろう ::も<type>もC++と同じだから連続してもそれほど違和感ない goの配列の指定はいまだに慣れないと言うかなんじゃこれだけど
rustは&mutとかライフタイムの指定をもっと独自のものにして欲しかった C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
構文の曖昧性を無くすために苦肉の策で生まれたのがあの悲しきお魚ちゃんなのですよ >>397
>C++構文定義上の最大の罪である山括弧ジェネリクスを引き継いでしまい
何が問題なのかな? < >は解釈の時若干邪魔なのかとは思うけど
ヒマだからANTLRで構文解析器でも作ってみようか >>401
typedefかっけーやん
#include <iostream>
using namespace std;
struct Hoge {
void hage () const {cout << "hage" << '\n';}
};
int main () {
typedef void (Hoge::*Mage) () const;
Hoge hoge;
Mage mage {&Hoge::hage};
(hoge.*mage) ();
return 0;
} 何かの言語でvector<vector<int>>の">>"の間にスペースが必要だった記憶があるけど
昔のC++だったかJavaだったか思い出せない
シフト演算子と相性悪いんだよね
どうやって解決したんだろ 次スレのスレタイはC++ Considered Harmfulにしよう >>402をtypedefなしで書くと逝っとるよな
- Mage mage {&Hoge::hage};
+ void (Hoge::*mage) () const {&Hoge::hage};
何でこんな記法にしたんだろ? 変数宣言と構文を共有することでパーサの実装量節約に一役買っているのです 俺は使える程には理解してるが人にはちょっと説明できん >>411
しばらく検索してみたけどソースが見当たらないので取り消します C/C++ は(関数ポインタのときを除いて)
hoge と &hoge と &&hoge と &&...&hoge は明確に区別されるけど
Rust だと区別されずにコンパイル通ってしまうケースもあるんだな
むしろ警告でも良いので出してくれればいいのに >>399
C++ の <Hoge> 入れ子で
<Hoge<Hoge>> とは書けなくて
<Hoge<Hoge> > と書くとちゃんと動く
だっさーと思った >>414
型で厳格に区別できるから使い間違えることや問題がおきることはなく
さらにfoo.barとfoo->barを一本化してfoo.barだけにしたRustが便利で合理的かな >>414
Rustでも区別されてるけど場所によってはDeref Coercionが働くから
区別されてないように見えるというだけ
https://doc.rust-lang.org/book/ch15-02-deref.html >>415
いつの話だよ。
C++11以降を知らんのか。 じゃあジェネリクスの記号を何にすればよかったのかの話は無いよね。
代替案が無いなら貶さない方がいいよ Box[T]
Box t
't box
(box t) 今さら代替案を出したってもう広まってるから無理だし、本気でこれを変えて「改善」になるなんて思ってる人はいないだろうが
C++の山かっこがC++11で改善されるまで長いことクソクソ言われてたのになぜRustは……ってだけのただの冗談だよ
本気にさせちゃったようですまないね Rustのジェネリックスの記法はこうこうこうだから美しい！マンセー！
って言わなきゃ話が続かないよ http://www.kmonos.net/alang/d/templates-revisited.html
クソクソ言われていた時代にRustと似た動機で作られたD言語はBox!(T)だったんだね
みんないろいろ考えるんだね～ > C++構文定義上の最大の罪である山括弧ジェネリクス
> C++の山かっこがC++11で改善されるまで長いことクソクソ言われてた
完全にコイツはエアプ
当時そんなとこに文句言ってるやつ見たこと無い
みんな真顔で「> >」隙間開けてたわ
指がオートマチックでスペース叩いてるはず
仕事やってりゃ色々クソなことはあるが
それを言語に転嫁するようなザコはここにはいないよね？ 「もう広まってる」とは言うがRustがわざわざ山かっこ<>をジェネリクス用に選んだ経緯とかはあるのか？
本当に惰性と流れで<>にしたの？
Dみたくa!(b,c)にしなかったのはなんでだ？
やっぱりDのa!(b,c)なる記法は純粋に見映えがダサくて、C++的なa<b,c>なやつはなぜかイケてる、ていうだけのことだろ https://soc.me/languages/stop-using-angle-brackets-for-generics.html
ここに書いてあることも一理あるけど
Goのようにsquare bracketでのインデックスアクセスを残したままFoo[T]にするのも微妙
unlimited look-aheadが必要だとしても実際にそんな長く先まで読む必要性なんてないので
読みやすさが勝るのならそれでいいと思う
ターボフィッシュはイケてないけど >>425
C++がだらしないから、こんだけRust勢に煽られてる、っては思ってるけどね
あまりに煽られて、一行もRust書いてないのに、併用する心の準備ができつつある
でもぜってえC++は捨てねえ、ぜってえにだｗｗｗ > 煽り勢 言語そのものを作ってるような人じゃなければ
あまり特定の言語に固執しないほうがいいよ
RustだろうがC++だろうがレゾンデートルに特定の言語を組み入れてる人は成長が止まりやすく老害化しやすいので自分が損するだけだから
所詮は使い分ける道具の一つ プログラミング言語をただの道具と言うやつは大抵無能 >>433
ただの道具とそうでない道具の違いは何？
定義を説明してみて 何か作るときに道具に拘る気持ちはめっちゃわかるけどなあ 道具によって成果物の品質が変わるのだからこだわるのは当たり前
ただの道具とか言うやつは安定してゴミを作るからそういう感覚がないのよ ここからは理論無用でレスできるのでスレが進むのか？ 作るものが複雑になると、普段から使ってよく理解している言語でないと
調べ物が多くなって効率が悪い。 問題領域の濃度と文法の濃度を考えれば、全ての用途で便利に使える万能言語なんてありえない。
言語には必ず得意領域と不得意領域があるんだから、問題領域に合わせて言語を選択・作成するのが望ましい。 If all you have is a hammer, everything looks like a nail.
>>437
宗教上の理由でﾜｯﾁｮｲスレに書けない人が荒れることを無限に書き込むから ちょっとしたスクリプトを書く程度で済むケースは、シェルスクリプトやスクリプト言語を使えば済むから対象外として、
がっちりプログラミングするならば、実行速度やメモリ使用量などのリソース、可読性や保守性を含めた開発効率などで、プログラミング言語を選びたい。
慣れれば大した手間増加にならないのだから、CPUメモリリソースや時間を考えると、C++とRustが選ばれるべきシーンは多そう。
C++とRustが忌避される理由は他言語より「難しい」「面倒」だけど、慣れてしまえば他の言語と大した違いはないわけだから。 目玉焼きに醤油を掛けるのかソースを掛けるのかマヨネーズ掛けるのか塩を掛けるのか
ぐらいのレベルがこの後30レスぐらい続くのかなあ？ 塩だろ。俺は邪道のアジシオだな
どんなターゲットにも合う。最悪、スイカにすら合う。
Cもそんな感じ。 >>433
道具を「ただの道具」にするかどうかは使い手の問題なんだよ
それがわかってない君は無能
そもそも>>432が「ただの道具」と言ってるように見えるようじゃ終わってるよ マンパワー依存の無能はさすがに苦笑
エンジニア向いてないよ笑 まあC++にもunsafe{ } は来てほしいけどね
統一的な方法がなかったので、今後Rustのやりかたが他言語にも波及するっしょ >>446
global deleteを無くすのと、参照渡しのライフタイム保証があればいいよ。 何か未知で不確実だとしてもただの道具ならその目的は既知だったりするでしょ
デストラクタの後で参照しないとか
デストラクタの後でデストラクタを呼ばないとか
だがメモリリークをあまり問題視しない件などは目的自体が変化してしまうから
ただの道具ではない >>447
Rust勢が言っているのは、Rustで書いたものは安全といって納品できる、ということなので、
ガイドライン チェッカとかじゃなく、言語にちゃんとunsafe{ } があるというのはモダン
何をもってsafeとするかには議論があったが、Rustがデファクトスタンダードになるなら、それを取り込めばいい
ひとつの夜明けは近い >成長が止まりやすく老害化しやすい
道具云々は↑これが図星で悔しかったんだろ
その後のレス見れば成長止まって老害化してる人だとよくわかる 当たり前だけど、攻撃力がレーゾンデートルになるよりは回避力か防御力のほうが
ダメージやストレスが少ない >>449
shared XOR mutableはちょっと面倒くさい。
せっかくスタックフレームベースなんだから、それ前提にもっと手軽にできないかなぁ。 >>453
値を変更する時にそれが他から参照されてるかはRust以外でも多少は意識してるはずだし
変更可能な状態で共有することに意味があるならRefCellとかCellに入れて共有すればいい
面倒といっても安全のための規約レベルでしょ
（違反するとコンパイラに殴られるからある意味手間が省ける） >>453
正確にはshared NAND mutable 所有と参照を区別しない場合は
参照が一つもない値の存在は許されない (循環参照が許されないとは言ってない) ので
むしろxorが正確である場合もあるかも >>457
それじゃ値について述べてるのか参照について述べてるのかそれとも型について述べてるのか曖昧すぎてルールとしては使い物にならない
主語と目的語を明確に意識してないと所有権複製の二の舞だよ ああ、C++では値と参照を区別するとかしないとか言うね
でも動詞を使いたくなったら「参照する」は正しいが「値する」はおかしい
だから値を所有する、値を参照するというのが良い C/C++の値に所有なんてあるのか
参照なら実体側の所有が誰か問題になるかも知れんが >>460
無い。
特に「所有」の一般的な概念に含まれる(他から制限を受けないという意味での)排他性・専有性は無い。 C++の参照がダングリングを引き起こす根本的原因は、
値の所有とその生存期間を参照に対してはっきりさせていないため？ use Hoge; と
extern crate Hoge; の違いが判ったわ
新しいとか古いとか言ってる人が以前居たけど嘘だったω 待て待て
そもそもC++でダングリングを起こしたことがない
Rustは言語仕様上関数でヒープまで消しちゃうから
仕組みがないとダングリングを起こしやすい
ダングリングはRust固有の持病 >>464
逆だよな
ダングリングポインタが生じるのはC++ >>464
関数でヒープを自動解放する仕組みすなわち自動的にデストラクタが呼ばれる仕組みはC++とRustで同じ デバッグビルドでよければ、結構重厚にチェックしてくれるんだけどね
リリースビルドでも一定程度チェックが残ってくれるようになれば、まだましになるか >>462
C++でも値に対する所有とライフタイムを明確にして参照のライフタイムがそれ以内に収まる枠組みにすればダングリングを防げるようになる Rustの知名度の上昇は、WasmのWASIのサンプルがCではなくRustで書かれている
ことにも起因するらしい。だから、Wasmで検索するとRustが出てきてしまう。
しかし、このことは、WASIの普及の足を引っ張るかも知れない。
なぜなら、C言語が基本だから。 >>468
「～でも～できるようにすれば～できる」
万能だねw 願望だから嘘だとか万能だから嘘だとかいう雑な説明は蛇足だな
説明しない自由があるべき
嘘でもいいから何か説明した方がマシというのは大嘘だ C++君はコンパイルでチェック出来るようになってから出直してきなさい 5ch見ない間に変なスレ立ってんじゃん
どっちが優勢なのこれ C++ってasync/awaitもまだstableではないんだな
大変だね GitHubとStack Overflowか
まあお世話になってるけどそれでランキング付けされてもなあ
5chのム板を集計してみてよ外人 Rust では || {} が
closure になるものとばかり思っていたが
関数ポインタとして扱われるケースもあるんだな
区別されてるということを学習した >>480
クロージャが関数ポインタに自動的にcoerceされてるだけでは？ pythonさんが無名関数を雑に実装したおかげで
雑な名前をつけるより無名のほうがいいという価値観がもうない map とかで
let e = hogemap.entry(hogeid).or_insert_with(|| Hoge::new());
は確かに便利なのですが
id が重複しないことはどうやって保証するの？
同じ id なら既存のに上書きは判らなくはないけど
それも禁止して上書き前に阻止したいときどう書く？ entryの時点でハッシュ計算と衝突時含めたエントリ探索済
つまりエントリが空か既存かの状態を持つのがentry
あとはその状態により既存のを返すか空ならinsertしてそれを返すのがor_insert_withなどのメソッド 紛らわしくてごめん
上書きというか
重複してたらシレっと既存のデータ魅せるんじゃなくて
let e = hogemap.entry(hogeid).or_insert_with(|| Hoge::new());
新規の場合しか登録出来ない？みたいな動きを期待しています それ新規の場合しか登録してないんだよ・・・
すでに同じキーがあった場合にどうしたいのか
もう少し望んでる仕様を日本語で明確にしてくれ Entryの結果で分岐させたいってことなら
そうすればいいと思うんだが こんな感じでいいのかな
Entryはmapの型に合わせて別途useする必要があるけど
use std::collections::hash_map::Entry; // HashMapの場合
match hogemap.entry(hogeid) {
Entry::Occupied(_) => {
// エラー返す？
}
Entry::Vacant(e) => {
e.insert(Hoge::new());
}
} >>476
この表ではCとC++を分けて書いてあるので、10位と7位になっているが、
「合算」して、C/C++ と捉えると、遥かに順位が上がって、
tiobeや日経では一位になっていた。但し、日経は「プロのプログラマ」限定
のランキング。 >>497
海外の掲示板でC++とJavaの投稿数はほぼ互角。
C#はそれらの2/3ほどだった。 >>497
>「合算」して、C/C++ と捉えると
この考え方が既にプロからかけ離れてるだろw
日経wなら納得だけど 混ぜたものh単にC++だし純粋なCを使ってる人はC++と区別してるだろ。 この板ですらC/C++とかいう表記好むやつおって頭痛いわ
CのこともC++のこともおそらく両方とも聞きかじり程度なんだろう C/C++ってのはCやC++という意味なので
グループ化して扱いたい文脈ならともかく
言語のランキングで異なる言語をまぜちゃダメでしょ 世界ランク1位のAIや世界ランク1位の法人は何人分なのかしら C++ってCを内包してるので異なる言語なのかっていうと
それはちょっと違う K&R CとC++98使えるから両方名乗ってもいいよね CとC++は人気シェア被ってるだろうから、単純に加算じゃいかんだろうなｗ
ちな、最強は…ってのの意味は、C++かRustかとかって言ってる間に、
世界最強はJavaScriptじゃねーか、まあ確かにｗｗ ってつもりだったよ
Rust流のメモリ管理がJavaScriptに流れ込んだら、どうなるかね >>502,503
二つは一緒でしょう？
私はね C++ コンパイラを通らない C は書く気がしなくなりました、いまや C コードを C++ コンパイラでコンパイルが通るか試すのが日課ですね
そりゃCでかくときはCの書き方で、C++ で書くときはC++の書き方で書きますが、C++ はCの上位互換であるように気をつけていますね >>505
＞C++ってCを内包している
べきで、C++ コンパイラを通せないCコードは書かないようにしてますね C/C++にダングリングは存在しない
C/C++は実体の無いものを参照出来る
もちろんポインタに代入して良い
アクセスさえしなければ問題は発生しない
問題を起こすのは馬鹿プログラマの責任
頭の良いプログラマは承知の上で使ってる C/C++って書くとき、どっちも生ポ世代の、息の長い人気言語、って意味かなあ
そこを踏まえてRustが生まれた
なによりCにunsafe{ } 追加待ったなしだと思う Cに来れば、C++に来るのも早いだろう
そんな流れを想像するに、またC/C++って書いたりする >>512
この一行一行に頭の悪さ出てるのスゲーな
釣りとして考えたら上出来だけど >>512
Google＆Microsoft「セキュリティバグの70%はC/C++のメモリ管理不備が原因。問題の起きないRustにする」
https://medaka.5ch.net/test/read.cgi/prog/1619943288/ 想像以上に、ダメ人間がC/C++系に動員されてたって証左だね 俺を含むｗ 片方の小手先の文法にばかり文句つけて反対側の長所は言えない
サンプルコードレベルしか理解できず書けないからそんなことしかできない
だからクソスレになるんだよここ >>517
小手先の文法のいちゃもんは、
「まあそんなこと言っても始まらないから着手してるけど、やっぱ慣れんなあ」みたいな愚痴だぞｗ 手続き型言語は基本的にはどれも大差はなく文法や言語仕様は慣れの問題しかないもんな
スクリプト的な使い方をするだけならどの言語でも良いと思う
ただし本格的にプログラミングするなら速さや省メモリが効いてくる
とはいえC++の仕様では静的解析に実行時解析デバッグでも>>515が残りうる 小手先の文法っていうと、「hoge/fuga/b.rs」モジュールを「hoge/a.rs」から触りたい時に
なんでいちいち「hoge/fuga.rs」作って、人間が「pub mod b」みたいなこと書かなきゃならないんだろ
b.rsの先頭にでもpubって書いとけば、単にa.rsで「mod fuga::b」とか書くだけで認識できるようにするんじゃあかんのか >>520
どの言語でもモジュールの目的は隠蔽にある
つまり必要となる最低限のものだけを外部に公開して他は内部構造として隠蔽するのがプログラミングの基礎
言語によって基本状態が何でも公開と何でも隠蔽があって後者は公開必要のあるものだけにpub等を付ける
そのモジュールfugaのサブモジュールbも同様で無指定ならばfugaの内部構造として隠蔽してくれる
公開したいならばRustではpubあるいは公開範囲を指示してpub (xxx)を付ける
例えばそのクレート内部だけに公開したいならばpub (crate)を付ける まともなプログラミングをしたことない人は隠蔽の重要性をなかなか理解しづらいかも
Rustのようにデフォルトがあらゆる隠蔽の言語の方が保守性の良いコードに導きやすいね デフォで不可視なのとか、パスとモジュール階層が対応してるのは文句なくて
パスと対応してるのに、いちいちpub modが並んでるだけのフォルダ名と同名ファイル「hoge/fuga.rs」作らないと
サブフォルダに切ったサブモジュールさわれないらしいのがウザいなあって思ったんだけど、今「hoge/a.rs」で
mod fuga {
pub mod b;
}
って書いたら普通にhoge/fuga/bを触れたんで、そもそもフォルダ分けてもfuga.rsなんて作る必要なかったんか？ 他のファイルからfuga.rs触らないならまあそうなのか
普通はやらないけど >>526
×fuga.rs
○fugaモジュール 他のファイルからはa::fuga::bとかでアクセスできるやろ
依存性や役割のまとまりに応じてモジュール階層を切ればいい >>525
そこは>>10と>>13に書かれてるように3つの自由度がある
ただし今回の場合はその対処でよいならばfugaというモジュール自体が本質的には不要なのだろう
fugaという名前空間を外に見せる必要がないならばaのサブモジュールとしてa/b.rsとするかhoge直下にhoge/b.rsとするところ ついにC#の時代がきた
AzureでChatGPTが動かせるサンプルが来たぞ
なんとjupyterでC#を動かしている
(python以外の言語も使えたのかよ)
そさてサンプルの豊富さと美しさよ
ここまできても無視してる奴らは本当に技術力が低いと思う
https://github.com/Azure-Samples/openai-dotnet-samples/blob/main/tweet-classifier.ipynb jupyterってjuliaとpythonとrの略なんですよMAUI君 >>530
Web APIだからどの言語でも使えるんだぞwww
MAUI君は技術力低過ぎて理解できないかもしれないが >>520
その仕様は許容範囲というか
むしろ余計なものを隠したい時に重宝すると思うが？ >>530
AOAI_KEYにSMS認証要らなくなってから来てください
いろいろとボトルネックはそこなので >>496
Occupied とか Vacant とか便所の扉でしか観たことなかったが
こんな使い方するんだな勉強になったわ C++でnewはヒープ領域にメモリを確保するけど
Rustのnewは可変サイズでなければスタック領域にメモリを確保しちゃうんだな >>538
C++と違ってRustのnewは言語仕様じゃなく
関数の慣習的な命名にしかすぎないので
メモリ確保がどう行われるかは関数の実装による 関数名がnewかどうかは自由だが
Selfを返すことになるのでそれは必ずスタック上に置かれる
Selfの中のフィールドなどがVecなどであれば間接的にヒープも使うことになるが
あくまでも間接利用であり直接のSelfの実体はスタック上となる
Selfをヒープ上に置きたいならば明示的にBoxで包めばよい
常にヒープ上に置く使い方のみをするならば
newという関数がSelfを返すのではなくBox<Self>を返す仕様にすることも可能 分数 みたいな 論理演算は昔からあったのに
Rustになって それが強化されたみたいに感じるのは
ただ単に ハードウェアの性能が上がったからじゃないの Rustは後でスタックにもヒープにも移動できるから
最初にどこに確保しようが関係ない
C/C++は合算の対価として、値の移動ができないCの仕様を守る
対価を支払ったのだから合算していい >>541
なんじゃそりゃ
C++のnewも返される値(ポインタ)はスタックに置かれる
Box<T>だってTはヒープでもBox<T>はスタック
さすがにそんな話をしてるわけではないと思うんだが >>544
インスタンスの値の話じゃないかな
C++だとnewしてヒープに置かれる
RustだとBox使わない限りスタックに置かれる >>545
それを言うなら「C++だとnew使わない限りスタックに置かれる」だろ >Selfを返すことになるのでそれは必ずスタック上に置かれる
C++のnewは「ポインタを返すことになるのでそれは必ずスタック上に置かれる」と言ってるのと同じ
以降の文もだけどポイントがズレてるってことわかんないかな RustのBox ＝ C++のnew
どちらもインスタンスをヒープで作ってそれを指すポインタを返す >>547
RustがSelfつまりインスタンスを返す時にポインタは返さない
つまりC++のnewとは異なる >>549
さらにズレたレスだね
しかも間違ってる >>543
C++でオブジェクトのmoveは値が移動するわけではないが
Rustでmoveは値がスタック⇔ヒープと移動することも必要なら可能だからか move等が無かった時代に書かれた仕様を現代の価値観で解釈するのは誤読と言われそうだが
C/C++は常習的にそれをやっていた
CのstructにはOOPの機能が無い・・・のではなく省略できることを書かなかっただけ
と解釈される どこかのタイミングで c++ → c+++ 辺りに解明白 int i {0};
cout << ++i++ << ' ' << i << '\n';
何と表示? >>551
C++のmoveは機能が非常に小さく限られてるのね .NET普通に使えるRust#欲しいかな
要らんな >>558
データがないんだよなあって言うだけならまあいいけど
データがない、ゆえに使いどころが (論理的に) ないと言ってはいけないよ
ほぼ死亡フラグに近い 社内でもRust化は検討してるけど、一番のネックはRustを使える人が集まらないことやね 言語のアシストがあるから、C++よりは安全といっても…習熟が要らないかっていったらまた別の話だしな まぁ実際“安全”って言ったって実際どうなんってよくわからんよな
ただ、マーケティング的に「今Rustってのが出てきました、Microsoftのwindowsも使い始めました、Linuxもです、これからはこういう安全性の高い言語で開発されたものがおすすめできます」というのは売りにはなるやろな
実際ほんとにどれほど安全なのかはわからんけど GCの使いどころを知るためにGCを追放してみた感がある
自分が絶対正しい的な動機がなくても、身の程をわきまえた上でGCをクビにする >>562
ゼロから習得スタートならば
C++よりRustがすっきりしていて習得しやすい
C色んな機能や概念を後付けしてきたC++との違い ソフトウェアの売り文句がその通りだった試しはないんだけどな トロッコ問題もそうなんよ
死者は1人または5人と断定して利点や欠点を皮算用させるけど
現実は0人だったり2人だったりする
問題文がその通りだった試しがないことを知っている人は問題文を否定する >>566
ほぼすべての人にとってはそうだ
しかし抽象化が進んでいるため一部のバカはRustなどの言語を理解できないようだ そういう具体性皆無の発言にいちいち反応してっからくだらん話になっていくんや バカには理解できない言語？
それは習得し易いとは言えないのでは 習得しやすさを基準にすると宗教に勝てないよ
習得しやすいが残酷な教義を信じて戦争したりするよ C,C++,Rustはそのあたりの機能も性能も同じ 勉強するときに参照するサンプルコードはぼぼCで書かれてるからね
3言語ともまだって人にはRustは選択肢にならんだろうね 言語を勉強するのが目的の人はRustかなと思う。
でも、通信やOSの仕組みが知りたかったら大体の本はCで書かれてるし、デザインパターンの勉強やゲームを作りたかったらC++で書かれている本が多い。
そういった先のことを勉強したい場合、Rustで実装されてることは少ないので、優先順位が下がってしまう。 Rustって何て読むのか知らないけど、なんかあまりカッコよく無いな。カッコで言語選ぶべきじゃないとは思うけどね。 >>575
Rustが宗教なんじゃないの？
Rust推しの人の言動みると宗教信者っぽいんだけど Rustを使える人で仮にCを知らない人がいたとしても
残るわずかな差分のC特有の仕様を勉強するには1日あれば十分
だから困ることはないだろう そもそもがCの文法レベルの勉強自体が8時間で終わるレベル マジか、じゃあC言語のエンジニアなんて8時間あれはどんどん量産できるんじゃん
最強じゃね？ >>581
(信者数の) 最大化問題を解いているような言動は宗教っぽい C言語の入門はどこまでなんだろ
個人的には連結リスト作るまで当たりじゃないかと C・C++はビルド周りが弱すぎる
CMake登場でちょっとはマシになったけど、それでもまだそんな普及してないしな autoconfとautomakeがありますが何か? 弱いのはWindowsでしょ
他人がビルドしたライブラリをリンクする仕組みがないから自分の負担が大き過ぎる
最近はLinux依存を躊躇しなくなってきてる ライブラリを簡単に探したり、依存関係勝手に解決してくれる仕組みがないのでゴミなんだよなぁ 色々使ってみるということは当然C++とRustどっちも習得するんだよな 仕事で必要な方にすれば？必要に迫られれば集中して学ぶからどんな言語でも習得するかと。 ライナスはピュアCでgit作ったんだよな
偉いわ
Cオンリーでマルチ文字列操作なんてしたくない pub const longlongnamehogehoge: i64 = 1;
pub const longlongnamehogehage: i64 = 2;
pub const longlongnamehagehage: i64 = 3;
みたいな定数があって
let fuga: i64 = なんか値; みたいな状況で
match fuga {
longlongnamehogehoge => { println!("oo"); },
longlongnamehogehage => { println!("oa"); },
longlongnamehagehage => { println!("aa"); },
longlongnamehagehoge => { println!("ao"); }, // 無いはず
_ => { println!("other"); }
}
って描いたときコンパイル時エラーを期待してたんだけど
完全スルーで成功されるんだがなんでだろ 事故解決しますた
gist
37751f7d9108e58dd16982f32a2b105f
match に any value って _ のことだけかと思ってたけど
使ってない変数名ならなんでも良いことが判りましたです あとこれでも実行出来てたのでどこにあるかの問題でもなかった
match fuga {
longlongnamehogehoge => { println!("oo"); },
longlongnamehagehoge => { println!("ao"); }, // 無いはず
longlongnamehogehage => { println!("oa"); },
longlongnamehagehage => { println!("aa"); },
_ => { println!("other"); }
} >>602
warning: unreachable pattern で気付くだろ Cでは定数を#defineやenumで定義することが多く
定数は大文字で変数は小文字
Rustのenumも大文字で始まるから通常は定数と変数を間違えない
問題は、#defineよりconstが優れているというのは嘘だったんじゃないかという いやまあそうなんだけど
match fuga {
longlongnamehogehoge => { println!("oo"); },
longlongnamehagehoge => { println!("ao"); },
longlongnamehogehage => { println!("oa"); },
longlongnamehagehage => { println!("aa"); },
}
longlongnamehagehoge が存在しない状態で
このコードって明らかにバグだと思うんだけど
正常系と看做される訳でωωωなんだかなーと思った次第 >>605
網羅性を保証するためにenumが存在している
enumを使わずに文句をつけているキチガイにしかみえない >>606
さすがに完全に同意
enumについてどう思ってんだろう >>605
それはfugaとlonglongをマッチさせてるわけじゃないぞ
マッチしたらfugaの値がlonglongに入るんだぞ 他の言語の
switch (id) {
case ID_A:
...
case ID_B:
...
}
と同じ感覚でmatch使っちゃっただけでしょ
キチガイ扱いはちょっとかわいそう > ωωωなんだかなー
じゃないよね？
理解して？
己の不勉強を自覚すら出来ないやつは誰？ 知らなかっただけなんだからそこまて責めんでもいいだろうに The Bookを含めてRust入門ドキュメントでは、
match式はenumを用いて説明しているよ
つまりenumを知らなかったとは思えないから、
意図的にenumを使わずに文句をつけているのか、
まさかenumを理解できなかったのかな 優劣の判断をしないほうがいいのは、相手がかわいそうだからというより
自分が安全な中立地帯に居座るためだ
中立を極めた者は、優れているとか役に立つとかいう概念を使わない >>605
前に知恵袋で見た血液型の問題だろ
そういうのってrustに向いてんの？ 「constはパターンになれない」とだけ言えばいい話なのに何をマウンティングしてるんだか match x {
1 => {...}
2 => {...}
_ => {...}
}
みたいなリテラル表記だと一応意図したとおりに動くから
const値に置き換えたら動かなくなるのはある意味トラップだな
慣れてくるとこのタイプの定数は最初からenum使うから気にならないけど >>615
constはパターンになれるよね？
>>616
置き換えても動くよね？ >>617
あらほんとだすまん
何かと勘違いしてたっぽい なんでさぁ
そんな半可通なのに知ったふうなこと言うの？
言わないと死ぬの？ constはpathパターンに入ってるんだな
identifierと同じ扱いだと思ってた >>619
しらんけど、ってsuffixをわすれただけだろ
しらんけどｗ RustのExpertをもっと敬えよ
「専門家への敬意の不足」を理由にプログラミング言語「Rust」のコアチームメンバーの一人が離脱、一体何が起きたのか - GIGAZINE
https://gigazine.net/news/20230529-rust-conf/ >>622
その記事に大雑把に書かれているように大した問題ではなく
・JT氏がC/C++専門家のジャンヘイド氏をRustConfの基調講演に招待した
・ところがジャンヘイド氏はブログで無知思い込みでRustを勘違い批判してしまっていた
・そのためRust側は不快感を持ち彼の基調講演を一般講演に格下げした
・格下げされたジャンヘイド氏が怒って講演をやめることにした
・彼を招待したJT氏も怒ってRustから去った
ただこれだけで技術的な話はなく何か意見が分かれて分裂したわけでもなく 大ごとだろ
人種の絡む内部構想と宗教戦争だよ
信者じゃないヤツはいくらでもパージしていい
キリスト教徒特有の異教徒排除・異教徒弾圧だ
「ガバナンス構造の設計を担当」っていう言葉の意味が宗教オンチな日本人にはおそらくはピンと来ないんだろう >>623
お前の倫理観どうなってんだよ
ちょっとヤバすぎるぞ >>623
記事を読む限り
・基調講演とすることは暫定リーダーシップグループの投票で決定
・基調講演をただの講演とすることに対する投票は行われていない
だから、暫定リーダーシップグループの一部メンバーによる暴走であり、グループの機能不全だろ。
本来ならこのような格下げを行った人間を罷免すべき話だと思うけど。これを「大した問題じゃない」というやつとは一緒に仕事したくないね。 そこだけ読んで推測した
JT氏ってののガバナンス(提案)を、Rustの幹部が蹴ったような話か
そら出ていくって言うかもね Rust布教を煩いと思ってた人は、「Rustも一枚岩ではない、とにかく成功の独占を許すな」と叩いてもいいし
Rust使ってる人は、今のRustがもう大手に採用されて済んでるから、それに乗ってればいいし
どっちにしても悪い話にはならないｗ >>627
格下げ要求がRustプロジェクトの総意かのように偽ってRustConfにプレッシャーかけ続けたのは暫定リーダーシップチームのメンバーではないっぽいよ まとめるとC++使いは嫉妬まみれのウンコってことか >>628 >>629
お前の読解力どうなってんだよ
ちょっとヤバすぎるぞ safe C++ が立ち遅れてて、やきもきしてるんだよ、それがRustの成功の独占につながってる
しっかりしろよってやつだ Rustのことをよく知らずに間違ったことをブログに書いちゃうような人をRustConfの基調講演に招待したJTがおかしいようにみえる
基調講演をする初の有色人種になるはずだったとJTが書いているが人種問題とは無関係だから不用意なことを書くべきじゃない
講演格下げ手続きに問題があるとはいえまずはそれを正常化すべき話であって放り出して辞めたJTに賛同できる点がない >>632
そいつは特殊学級の子だから
やさしくしてやれ 多分この一件以外でも問題のある人物だったか、揉めたりしてたんじゃない？そうじゃなきゃ講演の構成わざわざ変えさせたりしないと思うけどな >>634
なら格下げした人間を洗い出してリーダーシップチームから罷免して、不透明なプロセスをジャンヘイド氏に謝罪してから改めて基調講演を依頼だな。
リーダーシップチームが関係していないならなおさら謝罪すべきかと。 Rustの基礎的なことを知らずに批判的なブログを書いてしまったジャンヘイド氏を基調講演に招待する必要はない
ジャンヘイド氏が謝罪すれば一考の余地はあるかもしれない >>640
招聘するかどうかは論点じゃない
そんなこともわからないのか >>642
https://www.jntrnr.com/why-i-left-rust/
> 6. [...] as best as I understand it, because of the content of JeanHeyd's blog post on reflection in Rust.
オリジナルにはリンク貼ってないけど、「リフレクションに関する」JeanHeydのブログポストって書いてるから、その記事は違うのでは？
GIGAZINEの英語力を信頼してはいけないよ >>642
既知のUTF8に対してUTF8チェックをしない効率的なAPIを用意すべきだという主張をしている感じかな
JeanHeyd氏はstd::str::from_utf8_uncheckedを知らないのだろうか？ >>640
> Rustの基礎的なことを知らずに批判的なブログを書いてしまった
そこまでわかっているなら、ブログの批判的な部分を指摘してくれないかね。
本当に「基礎的なことを知らずに」書いたように読めるの？
でっち上げじゃないの？ >>646
第一にそんな主張は書いていないし
第二にそもそもこの記事はC/C++で使えるテキストエンコーディングライブラリの比較ですよ
比較対象に挙げられたencoding_cの裏にencoding_rsがいるので参考程度にRustに言及されてるってだけで
from_utf8_uncheckedでstr作ったところでそれC++にどう持ってくるのかと
文脈読めてないからそういうこと言っちゃうんだろうけど >>623
>無知思い込みでRustを勘違い批判
これ何？ https://blog.rust-lang.org/2023/05/29/RustConf.html
経緯は現在調査中だが、意志決定のプロセスに不透明さがあったことは認める
JeanHeydおよびRustコミュニティに謝罪します、だそうです >>650
責任のなすりつけあいになるかな。
あるいはこのままウヤムヤになるか。 >>623,634,636,640
Rust Leadership Councilは謝罪したようだが、お前らはどうだ？
特に>>623と>>640 結局、カスが出て行っただけ、Rustとしては願ったりかなったりって感じでおｋ? >>656
お前これ書いた奴だろ、良識の欠片もねえ全エンジニアの敵
結局C++とRustってどっちが良いの？ 2traits
https://mevius.5ch.net/test/read.cgi/tech/1680363777/604
604: デフォルトの名無しさん 2023/04/26(水) 16:48:15.43 ID:9EDgaMeS
月面着陸船が落っこちたそうだが
Rustで書いてれば成功したはず
それにしてもローバーは活躍出来ず流産乙 どう誤解されようとかまわんが、俺はもうC++でいいや派だぞ Rustの環境はC++と全然違うのでC++で練習できないし、ぶっつけ本番の方が安い
と言ったな、あれは全部嘘だ コストと不自由さを気にしなければ、インストラクター付き教習車は事故を起こしづらい。 二輪のヘルメットや四輪のシートベルトみたいなもんだな
導入前の人間からしたらウザくて仕方がない コストを気にしないんじゃないんだよ
数値化できないことを数値化するのは無駄な努力だと思ってるんだ
質素倹約と富豪の対立じゃなくてどっちも相手のことを浪費家だと思ってる シープラに既にどっぷり浸かった老兵はそりゃシープラがいいさ😔 長らく正直、スマポは甘えだと思ってた
いまや、スマポは許された 新技術に自身のポジションを脅かされると思って叩くのはよくあること バイリンガルのような掛け持ちは新技術じゃないが
一人で二票も三票も入れられたら人気投票データの権威が脅かされる 叩かれない限りほっとくんだけどな
自身の、っていうか、推しのポジションだね
推しだよ推し 付き合い長いんだ 開発効率の上昇がありがたいね
関数型言語の成果導入による短くわかりやすい記述面から
メモリ管理やデータ競合のバグや実行デバッグから解放されたことまで どうせまたdangling pointerが作れちゃうって話を長文で書くんだろ
もういいよ ライフタイムがないと関数から返そうとしている参照(ポインタ)が有効なスタッフ領域もしくは有効なヒープ領域を指していのかを保証できない >>677
草
入門書の最初のほうに書いてるような内容を
ひたすら繰り返し演説するのが好きなんよ彼はｗ 入門書の最初のほうに書いてるような内容を
入門書も読まずに聞いちゃう676みたいな初心者がいるからしゃーないやん RefCellからget_mut()したらどこかでget()したRefが生きてたせいでpanicしたということがあって
そのときはデバッガのお世話になって問題のget()してる場所を探すことができたんだが
実行デバッグから解放されたらしい>>672はもっといい方法を知っているんだろうか ×get()/get_mut()
○borrow()/borrow_mut()
でした clippyとかで多少拾えるだろうけど実行時チェックがpanicにならないようにするのはプログラマの責任
デバッグから解放されるなんて話は夢物語だが
デバッグしないとborrowとborrow_mutのlifetimeが分からない状態は見直した方が良い >>678
本当にそんな不自然な状況に頻繁に出くわして困ってるの?
設計おかしいんじゃないの? 常に問題なく設計できる人はRustでライフタイムを満たすことも容易
複雑になると混乱しうる場合はC++で穴の可能性が残るがRustならライフタイムのコンパイルエラーが検出され助かる
実際にMicrosoftやGoogleがその穴の頻出でセキュリティ脆弱性も招いていたと判断してライフタイムを用いるRustへ移行中 >>688
>>678
>ライフタイムがないと関数から返そうとしている参照(ポインタ)が有効なスタッフ領域もしくは有効なヒープ領域を指していのかを保証できない
スマポ返せばええだけちゃうの? >>688
>実際にMicrosoftやGoogleがその穴の頻出でセキュリティ脆弱性も招いていたと判断してライフタイムを用いるRustへ移行中
社内の好き者が試してるだけじゃないのん?
全ソースの何%くらいなんかな?
移行って書くと新規は全て感じがするがそれ誇大広告じゃ? >>689
スマポunique_ptrはカバーできる範囲が狭い
スタック上のインスタンスに対しては使えないためヒープ上のインスタンスと共通に扱えなくなる
部分領域に対しての扱いも同様 5/30の一連の流れは何事も無かったかのように平常運行に戻ってるの、ふてえ野郎だぜ Rust公式と自分の意見が違っているのが分かった瞬間急にｽﾝ……ってフェードアウトするの最高にダサかったよ >>691
C++でスタックのポインタ返しちゃいかんだろw
論外 FirefoxがプチフリするのはRustのせいじゃないのか？ >>694
スタック領域を指すポインタを返せないと不便で効率が悪くなるぞ 未だに未定義動作という不発弾を検出できない欠陥言語 スタック上を指すポインタを常に安全に返せるようになると
ヒープを使わずにスタック上だけで済ませられるケースが生じる
それは高速化に寄与する そもそもC++は関数でスタックのポインタを返してはいけない
それを
>>678
>ライフタイムがないと関数から返そうとしている参照(ポインタ)が有効なスタッフ領域もしくは有効なヒープ領域を指していのかを保証できない
ってのは支離滅裂な議論 C/C++では確かに以下の関数をエラーなく書けるが（警告は出るけどね）
これにエラーを出すことにどれだけの意味があるかな?
int *fun ()
{
int a;
return &a;
} Rustはライフタイムがあるからそういう返してはいけないポインタ(参照)はコンパイルエラーとなるし
たとえスタック領域を指すポインタであっても安全に返せる時はコンパイルが通って使えるね >>702
>Rustはライフタイムがあるからそういう返してはいけないポインタ(参照)はコンパイルエラーとなるし
C/C++で>>678のような間違いする人はいないから全く意味がないんだよ
頓珍漢なことを書かぬように
批判の前にはそれなりに批判対象も勉強し給え
（念の為に書いておくがライフタイムを否定するものではない） >>694
> C++でスタックのポインタ返しちゃいかんだろw
> 論外
普通に返すぞ >>703
その単純な例で間違える人はいないけど、
複雑に込み入った例で返してもよいポインタと返してはいけないポインタの判断を間違えることは起き得る
その発生がレアで運用時に発覚となると悲惨だ >>706
>複雑に込み入った例で返してもよいポインタと返してはいけないポインタの判断を間違えることは起き得る
絶対に間違えないと断じれる
ライフポイントが役立つのはそんなところじゃない 見事に単発ばっかりだけど
複おじはこの構図を「顔を真っ赤にしたC++信者に群がる勇敢なRust戦士たち」と見てもらえると本気で思っているのかな？ >>707
ライフタイムを指定する関数や構造体を書いたことないのか 自演じゃないならこっちでやってみてよ
ちょうどいい題材
C/C++のソースをRustへ全力で置き換えるスレ
https://mevius.5ch.net/test/read.cgi/tech/1681777958/ >>700
そんな制限はない
C++でもスタックのポインタを返してもよい >>712
どんなコードを言ってるのか分からんので書いてみて
もちろん>>701のようにコンパイルは通るけど
関数脱したら消滅するスタックのポインタ返して
どう実用するのかスゲー興味ある >>710
俺はRustは書かないよ
それともその「ライフタイムを指定する関数や構造体」ってのは
C++の話しかい?
よく分からんので簡単なコードで示してみて Rustを書かないやつが連投して暴れてるのかｗ
通りで無知なわけだ >>713
複おじはバカだがお前もお前で「スタック」が「現在の関数のスタックフレーム」以外も指すことにいい加減気付け スタック領域のポインタ返すってstatic変数のこと言ってんの？ >>716
C++に関して頓珍漢なことを書いていたら否定している
知らんことに関してはコメントしていない >>717
「現在の関数のスタックフレーム」以外のスタックって何なん?
知らんので教えて スタックからアドレスを取得して、それをスマポにしないのは、その段階でunsafeだろ >>722
スタックのインスタンスのアドレスはスマポには入らん
C++では参照型を使う
Rust的にはたぶんunsafeかな? >>720
典型的には呼び出し元のスタックフレーム、呼び出し元の呼び出し元のスタックフレーム、呼び出し元の……以下略
具体例で言うなら、strchr()にスタック上の文字列を渡したら帰ってくるのはスタックを指すポインタでしょうが
strchrのスタックフレームとして積まれた領域じゃなきゃ別にスタックを指すポインタを返すこと自体に問題はないのよ
分かったらもう黙っててくれ、例の自演君がつけあがるだけだから >>723
Rustの参照はsafe
常に有効な領域を指す >>724
なるほど関数呼び出し元のスタックね
しかし話の起点>>678に書かれているのは呼び出し先関数が返そうとしている
参照（ポインタ）の有効性をどう保証するかという話
一方で呼び出し元のスタックの有効性を保証すべきは呼び出し元で
呼び出し先が感知すべき内容ではないと思うが? >>725
参照のダングリングなんて起こらないけどね
ただしマルチスレッドだと起こり得るのでshared_ptrで指す
このくらいのことを出来ない輩がいるので
Rustの存在意義がある >>722
C++はそれをすることができない
スマポに格納できるのはヒープ領域を指すポインタのみ
Rustはスタック領域でもヒープ領域でも所有権を持つがC++はスタック領域で持てない rvalueとlvalueを理解しないものにC++は無理
Javaを使いなさい >>730
面白いけどtrivialだと思うね
しかしtrivialなので嵌るのかもしれない Win32APIはコールバックが多用されてて定型的な処理の1つなのにRustでは普通に書く方法がいまだにないように見えるのだが
こんなんでC++と張り合おうとするなよー 安全をうたうならJavaと張り合いなさい
最高速チャレンジに危険は付き物です 素人でもC++に匹敵する速度が出せます
もう熟練は必要ありません
↑
こんなこと言うやつは詐欺師
財布なくなってないか？
気をつけろ 結局 常に 迫りくるソフトウェア 危機に常に対応していかないと
言語の発展は青天井になる >>738
そんなリンク貼って恥ずかしくならないの？ってことなんだけど… 自分が作ったわけでもないものを貼ってドヤってるのは恥ずかしいかもしれない 公式サンプルすら見ずに文句を言ってた>>735が恥ずかしい 自演バレてないと思って懲りずに単発続けてるのはだいぶ恥ずかしいよ どっちかっていうと>>743が「ぽい」なと思っててお前はどうでもいいと思ってたんだけどな
調べもせず無知を晒す奴と言えば
GIGAZINEがねつ造したリンクに騙されて原文を調べずもせずに
Rustの将来の可能性を示してくれるかもしれなかった人を叩いてたのは恥ずかしかったねw cargoとかも嫌いなシステム。
パッケージシステムが嫌い。
メンドクサイ。 毎回変化するのが嫌なんですよ。
ダウンロードするバイト数も予め分かりませんし、インストールされるバージョンも
分かりませんし。
単に何かが使いたいだけなのに、使う段階になって勝手にネットからダウンロード
が始まり、コマンドが使える様になるまでに何十分も一時間も掛かることがあります。 勝手にダウンロードされることで、PC内に存在する色々なもののバージョンが
めちゃくちゃになります。
複雑すぎてメモすることも出来ません。
以前動いていたのに、今度やってみたら動かなくなってる。
Windowsだけだとそういうことはなかった。Linux文化(?)やオープンソース
文化なのか、よく分かりませんけど、もう、ストレージがいくら有っても
足りませんし、毎回毎回、動作不良を起こし、インストールし直す必要が
有ります。それでオープンソースは、サーバー以外では普及しないのかも。
PC内に同じファイル名のものが無数に存在してます。
クローズド文化ではそういうことは有りませんでした。 >>750
インストールされるバージョンは自分で指定するから全くわからないってことはない
(孫のバージョンは子が指定しているから気にする必要はない)
ちゃんと直接使うクレートのバージョン指定をしているか？
>>751
以前動いていたのに今度やってみたら動かなくなってる、は通常ありえない
もちろん後方互換性のないバージョンを使えば動かなくなるのは当たり前だ
ちゃんと直接使うクレートのバージョン指定をしているか？ 意見の古臭さと文章の幼さのギャップが凄い
タイムリーパーかな それにRustはオープンソースを前提にした開発環境なので、広告を収入源と
してない限り、ソフト企業では扱いにくい。
何もかもがソース公開する人や企業に有利で、ソース公開しない人や企業に
不利になるような構造になっている。 cargoの仕組みも、オンライン前提で、ソフトウェアを「みんなと共有」する
ことを前提にしているように思える。apt-get や pacman なんかも、みんな
同じ。それに対して Windows は、各社が各様に独立したバイナリで完結
するようにした文化なので、責任の所在がはっきりし、実力主義になっている。
Rustは、Linuxやgccなどと同じで、世界中で全体的に技術を向上させようと
するような思想を前提にしているように思える。
それは物理学や天文学、宇宙科学などの分野では良いことだと思うが、
ITや半導体の分野では問題ある。 >>756
何年もかけてそれやったら、ソース共有しまくっている人が数週間で同じものを
作って、馬鹿にする。
それがオープンソース文化。だから閉塞感が漂っている。 ・オープンソースを「人類の最良の最終目標」にする人達が大勢いる。
・それとは関係なく、トヨタなどのハードウェア産業の人やドコモなどの
通信基盤産業の人は、オープンソースが喜ばしい存在となる。
但し、自分のハード技術は企業秘密であり、そちらは守秘するのは当然の
権利だと彼らは思っている。
・よって、Rustは、トヨタやドコモなどが採用するが、ソフト自体を売りたい
企業は採用しにくい。 ただ、トヨタなどは、ハードウェア産業であり、時間の問題で衰退する。
オープンソースを礼賛していたのは、そういうった古い企業であり、
それらが衰退すると共に、クローズドソース文化が見直されていく
のではないか。
要は日本は古い形態の企業が多かったので、オープンソース信者が多かった。
それでITが遅れた。 Rustは、GPL感染しても、とにかく結果が出ればそれでよい、という文化である。
Rust自体が研究所か、公務員か、Googleから流れてきた資金でMoziillaがやって
いるのか、わけの分からん金の流れがあり、結局、他人の成功の足を引っ張る文化
がある。 たとえば、clangやLLVMでも、C/C++で書かれたものは、クローズド文化
なものに比べれば劣るが、インストールは有る程度簡単に行なえる
(但し、やはりオープンソースゆえの非常に沢山の困った混乱があるが。)。
ところが、Rust製のコマンド類はインストールするのも一苦労する。
とにかく、インストールできず、現実的に使い物にならない。 Rust製のアプリ作者は、ネットから連鎖的に依存関係がダウンロードされるのを
「かっこいい」と思っているらしい。
使う側にとってはただただメンドクサくて不便なだけなのに、それに気付かない。
「ネットから児童ダウンロードされる仕組みを使っている俺ってカッコいい」
的な価値観らしい。
ようは実用的なツールやアプリを作ることには全く興味が無く、なんとなく、
最先端な(??)仕組みを使っている俺ってカッコいい、的なよく分からない価値観
を持つ人がRustでプログラミングしたがっている。 >>755
Rustでコードを書いてもソースコードを公開するかどうかは自由
>>760
貴殿の話はプログラミング言語とは無関係な話ばかりだ
そして要点がわからない長文をダラダラ書くダメな典型例になっている >>764
「成果をみんなで共有しない」という思想は、プログラミング以上に大事。
目標とする思想が逆さまになっている集団が作った開発環境は、結局は
足を引っ張る存在となるので使い物にならない。 cargoも、「オンラインの悪いところ」を凝集したようなツールだ。
逆に、オンラインゲームは「オンラインの良いところ」を凝集している。
前者はただただ面倒なのに対し、後者は気軽。
同じネットを使っているのに、逆の結果となっている。
パッケージ管理ソフトは、その意味で経営戦略的な誤りである。 そもそも、開発環境とは作るための道具である。しかし、作ったものが売れないような
思想に基いているなら、道具が使い物になるはず無い。
そもそもそこでRustは間違ってる。
嬉しさだけを売っているなら、ソフト企業が使えるわけ無い。
だから、トヨタみたいなハードウェア企業やGoogleみたいな広告を収入源と
する企業にしか使われない。 作ったものを売りたかったら売ればよい
プログラミング言語とは無関係な話だ 要は相手の事を考えず、自分だけよければいい、というのがオープンソース思想
である。なぜなら、Rustを開発している人達がどこかから開発費が入ってくる
立場にある。しかし、Rustを道具として使う企業にすれば、作ったソフトから
何らかの方法で「マネタイズ」して開発費を回収しなければならない。
その意味で、オープンソースで作っているRust開発者には営利企業の気持ちが
分からないから、ニーズを理解できないから、「斜め横の」機能を付けてしまう
ことにも繋がっていく。
まず、自分がクローズドでそれ自体を売って手本を見せて、それに他の
営利企業も続くような状態にしなければ、Rustが反映する道は無かろう。 >>768
オープンソース思想で作られた道具で、売れるものを作ることは非常に難しい。
なぜなら、道具の作者が営利企業の気持ちが分かってないから。
オープンソース作者、つまり、普通の営利企業とは異なる収益構造、
または、単なる研究機関の人員の価値観で作っているから、営利企業の気持ちや
需要が全く分かって無い。その結果、需要と供給のミスマッチが起きる。 cargoの役割 = 「ネットを使っている俺ってカッコいい」&「時間が掛かり面倒」
ネットゲーム = 「気軽」&「複数人プレイ」
全然異なる。 何を主張したいのかさっぱりわからん
gccもclangもllvmもオープンソースだぞ オープンソース系ソフトは、サーバーサイド以外ではほとんど使われて無いと
言われている。 clangもgccよりはましかも知れないが、結局、無料で配って、販売することも
なく、研究費は Apple がハード(iPhoneなど)を売った金でまかなっている。
そのため、営利企業の気持ち側からず、「気が気かない代物」となり、
実際にはほとんど道具としては使われて無い。 >>762
Rustは他の言語と比べてインストールも最も簡単だろ
Rustの言語システム自体のインストールや更新などはrustupだけで済む
個々のアプリのインストールや開発などはcargoだけで済む
どちらも色んな入門ドキュメントの最初に書かれているから読め
>>766
cargoはオンラインでなくても使える
必要なものをcargo fetchで取得しておけば例えばcargo build --offlineとオフライン環境で使える ちょっとずれてるけど、cargoとか大げさ…って感じはする
この場合、vcpkgだのも同様
VS版のcmake本体がクソデカなのは、ダウンロード機能が付いてるせいだった気がする(←古い知見)が、
とにかく、己の身の丈に合ったツールサイズであってほしい
(C++派でありながら)clangのデカさにも内心ウンザリｗ 練習のためにcmakeに移行してるけど、
ちょっとしたもの作るのなら、nmakeか、もうcl /MD ... 一発でいいやって感じ
そんなだから、vscodeがこんだけ流行ってるけど、いまだになんだか馴染めない
エディタにウン十MBとかなんのぜいたくかな
手の込んだもの書いてないから、そんなワガママも通ってるんだけど、
そんなワガママも、処理系次第だが、C/C++は叶えてくれる >>778-779はなんで突然ズレてて入門者みたいなこといい出したん？
RustのこともC++のことも知らないんなら無理して書き込まなくていいんだよ？ 世の中にこんな異常者がいて同じ仕事をしてると思うとそら恐ろしくなる
こいつの作ったクローズドな製品が家族に取り憑きませんように Wasmのdwarf情報を見てみたくて
https://lib.rs/crates/dwarfdump-wasm
↑
こういうのを見つけたけど、rustc 環境がインストールされていることが必須
らしくて、cargo コマンドで
$ cargo install dwarfdump-wasm
としてインストールしなくてはならない。
これだと、バイナリ exe に直るという Rust のメリットが全く無い。
しかも、オンラインアプリ書庫の Vector みたいに、ウイルスチェックもされて無い
だろうから、危険だし。
せっかく、マシン語にまでコンパイルされる言語なのに、全く生かせておらず、
まるで、node.js, Ruby, Python の不便さをそのまま持ち込んだみたい。
だからオープンソースは駄目で、自分の立ち位置(position)を分かっていない。 複オジと同じでセルフエコチェンバー病を発症してるね
論理的思考力が弱すぎて物事を自分に都合のいいようにしか解釈できなくなってる 自分と思想が異なると異常者扱いしたりするのも、オープンソース勢(左翼)の
問題点。
Rustは、民主主義的でない。 結局、開発環境は、作ってる人の思想の影響を大きく受けている。
左翼が作ったものは、左翼受けがよいが、民主的ではないし、市場経済に合わない。
市場経済とは、良い物に投票し、悪いものには投票しない仕組みである。
左翼は、その仕組みを迂回し、良いかどうかを「国家主席」や学者代表が
勝手に決めてしまう仕組みである。 >>784
すぐ異常者とか素人とかなんとか言っちゃうのは複おじって呼ばれてる自演荒らし(>>5)なので
覚えておいていただけると一般Rustユーザとしては助かります しかも、cargo のサーバー、遅すぎない？
有りえないほど遅いんだけど。 ソースではなく、バイナリツールが欲しいだけなのに、ソースをダウンロード
させられる。SDGs に反し、世界中でどれだけ電気代と時間とストレージ(SSD/HDD)
とサーバー付加、ネットトラフィックの無駄になっていることか。 Rust製のdwarfdump-wasm という、C++ で書いていたら、クローズドソース系の
プログラマなら600KB、オープンソース系のプログラマなら、数MB で済む
程度のプログラムのダウンロードがまだ終わらない。
どうせ、今後、ダウンロード後も、あれが無いこれが無い、
Pythonのバージョンが合わない、node.js がない、など苦労が連続するだろう。 結局、ネットワークエラーで失敗した。
再インストールしようとしても失敗、cargo uninstall しようとしても失敗。
cargo clean しようとしても失敗。
そこで、手作業で .cargo フォルダ内のそれっぽい項目を削除して、
再度 cargo install してみている。
こういうとこなんですよ。 しかも、cargo の fetch のインジケータが、% 表示なのも馬鹿ですか？
ちゃんとバイト数で書けよ。
ダウンロード速度が遅いだけなのか、ダウンロードサイズが大きいのかの切り分け
が出来ない。
rust のターゲットは、低IQ者じゃないんだから。 昨日からのオープンソース批判の書き込みは
本人はRMSの自由ソフトウェア運動を知らんようだけども
運動への批判として的を射ていて面白い
RMSの思惑通り >>785
これはズレてるな
「伽藍とバザール」を記したエリック・レイモンドは右翼 >>789
実際、予想に漏れず、結局、駄目だった :
$ cargo install dwarfdump-wasm
Updating crates.io index
Downloaded dwarfdump-wasm v0.1.1
error: failed to parse manifest at `C:\Users\xxx\.cargo\registry\src\gith
ub.com-1ecc6299db9ec823\dwarfdump-wasm-0.1.1\Cargo.toml`
Caused by:
failed to parse the `edition` key
Caused by:
supported edition values are `2015` or `2018`, but `2021` is unknown
C:\Users\xxx\my_wasm_dwarf>
＞＞792
どうみても左翼なのに「自由(Free)」を掲げている訳だし、彼らは全体的に嘘つきなだけ。
1991年位から左翼の「失敗」が明らかになったから、彼らは左翼を自称できなくなった。 >>793
左翼は失敗理論である事が分かったため、左翼を名乗れなくなったからね。 >>794,795
日本で言っている「左翼」ってのはまた違うからね
現職の米国大統領はリベラル アメリカは、もともと奴隷の労働力で栄えた。
その後、奴隷制度が廃止されたが、スラム街が残った。
アメリカの最低賃金は、スラム街の人々の仕事のものとなったため、
最低賃金では安全に暮らすことが出来ない。
そのため、左翼的(社会主義的)思想は、喫緊の課題となった。 >>794
edition 2021がunknownっていつのcargo使ってるの……
rustup updateしてくれや >>798
したら直った。
しかし、勝手にインストールされたもののハズで、俺の感知の範囲外になる。
つまり、rustc の環境構築プログラム(?)のバグだろう。 >>758
フォークすれば良いのではないかな?
>>759
>・よって、Rustは、トヨタやドコモなどが採用するが、ソフト自体を売りたい
> 企業は採用しにくい。
バイナリだけ売ってソースを共有しないって行為がそもそものRMSの標的だからね
市場は変わりうるのだから（例えば音楽業界や出版業界）
市場がなくなったのであれば適応すべし >>801
あなたに言われる前にネットで調べて解決済みだった。 そもそも、オープンソース思想は自分の技術力の無さを隠すための手段だし、
「国家主席」にみとめられた人だけが「作る権利」を得て、国家主席の思うとおり
のものを作る、という思想だと思われる。 オープンソース思想は、上から目線。
ストールマンの場合、自分が MIT か何かの博士課程を出て、そこの親分に
認められたので、自分だけがコンパイラを作る権利があると本音では思ってる。
そして、それ以外の人は自分の作ったコンパイラを使えばよく、それ以外の
ものを使うことを許さない。
だから、無料にして使わせようとするが、実際には品質が悪いので誰も
使ってない。 だから、ほうっておけば誰も使わないが、うそつきなので、品質が高いという
ことをネットなどで言いまくる。ありとあらゆる嘘を付き、デタラメ情報を流布する。
その政治家などが結果騙されて、オープンソース思想を支援したりする。
そしていつのまにか、品質の悪いものしか残らない社会になって行っている。
それがIT企業に漂う閉塞間の原因の一つ。 >>803
フォークすりゃ良いのでは?
>>804,805
恐らく史上世界で最も使われてきたカーネルであるAndroidってgccでビルドしてるのでは?
恐らくは2番目に使われてきたiOSはclangなのでは?
品質悪いかな?
>>804
>ストールマンの場合、自分が MIT か何かの博士課程を出て、そこの親分に
>認められたので、自分だけがコンパイラを作る権利があると本音では思ってる。
>そして、それ以外の人は自分の作ったコンパイラを使えばよく、それ以外の
>ものを使うことを許さない。
彼は博士課程をドロップアウトした在野のハッカーだよ
権威主義と戦ってきた人物 ひょっとしてRustってフォークできないライセンスになってる? >>806
>権威主義と戦ってきた人物
大学の部屋を借りてると聞いたし、矛盾を感じるぞ。 そもそも、権威主義と対極にあるのが、ビルゲイツだと思うんだよ。
彼は、もともと頭がいいのでハーバードかどっかを入学していたが、
法律系かなんかの学科だったが、BASIC言語のインタプリタをマシン語で
作ってしまってそれを売ったことが始まりなんだから。
このように「良いものを作って売る」というのが一番民主的。
自分が良いと思っているだけで人々の支持を得られなければ売れないわけで、
売れたと言うことは本当に良いものだった可能性が高い。
ところが、gccは、一度も売ってないわけだから人々の支持投票を迂回
してしまっており、民主主義的とは言えない。 >>808
RMSが大学の部屋を借りているのかどうかは知らんが
大学の部屋を借りるのと権威主義の否定とは無関係では? >>809
>ところが、gccは、一度も売ってないわけだから人々の支持投票を迂回
>してしまっており、民主主義的とは言えない。
使われているってことは良いものだからなのでは?
良くないのなら使わなきゃ良いだけだから いずれにしても「昔のマネタイズは良かった」などと懐古せずに
現実の市場に適応しなきゃね rustcの作者の左翼思想が、rustcの言語仕様の中にも反映されている。
それは弱者救済だ。 本当に厄介なのは、ストールマンみたいな、本当は競争すれば負ける存在なのに、
競争から外れて寄付金などで永遠に存続し続けるような人。
成長した木は、光を遮るのでもっとポテンシャルはあるの芽を枯らしてしまう。
才能が無いんだから、市場から去るべきなのに、市場経済を迂回するので
去らす事が出来ない。
それが閉塞感の原因。 >>814
ルールが自分に不利だと我儘言わんと現実の市場に適応しな?
ここまでの書き込みで事実誤認が甚だしい部分が多々あるので
情報を収集し正しく見極めるよう努めることを助言したい >>815
オープンソースに市場なんて存在して無いよ。
競争迂回手段。 >>816
存在していないとあなたが判断するなら
そこで商売しなければ良いのではないかな? 権威にしがみつき、虎の威を借り、公務員様に補助金と研究費で生きていく
人生設計をし、競争を徹底的に迂回する。
相手はどうやっても競争にならない。 >>818
ルールが自分に不利だと我儘言わんと現実の市場に適応しな? >>817
民主主義なんだから、ペンの力でそのような存在をこの世から抹殺する方法も有る。 >>819
それで日本のIT企業で勝った人がひとりでもいないわけだから、社会に問題が
ある。 たとえば、独占企業は法律で禁止されているのは、どんなに工夫しても他の企業が
勝つことが出来ないからだ。
それと同じでオープンソースがあることで、あらゆる日本のIT企業が勝てない。 >>822
じゃ法律を変えてみたら? 賛同者が多ければ民主主義なので変えられるよ! Rustがファンドに買われて、安全に対する対価を支払って当然みたいなライセンスになればいいって話かな >>824
Rustってフォークできないライセンスなの?
フォークできればファンドに買われたRustについていく人は
いないんじゃないかな? >>823
まず、アメリカから独立することだね。
歴史的に、他国に軍隊を牛耳られている国で、経済がよくなった国は存在し無い。
オープンソースやWindowsが日本に都合が悪いなら、日本は拒絶しなければならない。
実際、中国は、コピー天国で、アメリカを無視して、Windowsのライセンスを
無視してコピーして使っている。だから強くなった。 アメリカに何言われても、無視し、著作権や特許を無視して、コピーしまくる、
この位にならなければ、日本はアメリカには勝てないだろう。
そして、その戦略を貫いているのが中国だ。
特許や著作権や先を進む国に有利なルールであり(先発有利)、コンピュータや
半導体を世界で最初に発明/製造したところのアメリカしか勝てなくなるのは
当然の帰結である。 >>826
あなたが>>820に書いたように民主主義なんだからペンの力で変えられるよ! >>829
特許や著作権など、アメリカの決めたルールはアメリカに圧倒的有利になっており、
不平等条約だ。 最初にやった人がとても永い間(というより新しい特許が作られるので
実際にはいつまでも)有利になるのが特許。
著作権も同様。強いものがいつまででも強い。
だから、アメリカだけが、ITでは世界で一人がちになってる。
そういう不平等ルールを世界中に強制してしまっている。 >>831
RMSは一貫してソフトウェア特許に反対してきた人物です
>著作権も同様。強いものがいつまででも強い。
これはサッパリ意味が分からない FirefoxがプチフリするのはRustのせいじゃないの？ いつか皆おじいちゃんになって似たようなことを言い出すのかもしれない
自分もいつか行くのかもしれないと思うと老後が怖い 人間としてのライフタイムが切れてる
脳の一部がライフタイムを越えたのにアクセスしてダングリング脳になってるんだな
皆こうなるんだと思うわ ほとんどのプログラミング言語がオープンソースなのに
Rustのみを叩いている点がよくわからない よくJavaでもやってろってネタにされるけど、Javaはオープンでありながら、Oracleが握ってるだろ
ああいうことがあるからねえ、気にならないと言ったらうそだな
Rustを叩くほどかといったらともかくだが お薬切れちゃったんやろな
２ちゃんでこういう一方的に演説するやつ山程見てきた >>840
Javaはヌル安全でないし
データ競合安全でもない オープンソース好きには、Linuxが優秀な人が使うOSで、Windowsが馬鹿が使うOS、
などと認識してる人が多いらしいが、その認識では人気ソフトは作れない。
rustcの作者もそういう認識だから駄目なんだ。 C/C++は歴史が長いのもあるけどかなり初期段階で仕様と実装が分かれていたから思想の偏りとか気にする事なく普及した
片や実装ありきの言語はメンテナのおかしな舵取りで容易に裏切られるという点で危うい
はたしてRustの向かう道は大丈夫か Rustも仕様が独立して提案され議論され決定される
オープンな場なので誰でも参加できる むしろ「オープンな場」というのが全てを駄目にする。 >>809
デタラメ言うなよ。
言語としてのBASICを最初に作ったのはゲイツじゃないし(ジョン・ケメニーとトーマス・カーツ)、BASIC自体もパブリックドメインだったから普及した。
嘘つきは存在自体邪悪だから、その主張に耳を傾けてはいけない。 BASICは昭和39年誕生
そこから多数生まれた亜種の一つをゲイツが昭和50年に作った アルテア用のBASICを実機も無いのに移植して納入したのが
ゲイツの最初の手柄だよ 皆老化するんです
そしたら >>847 みたいなことを言いだすんです
ゲイツは自分で作った売り物のAltairBASICがコンピュータークラブで大量に違法コピーされて使われるのこと怒って
ホビイストたちへの公開状と言うのを書いた
売り物を勝手にフリーウェアみたいに使われてる現状を嘆いてる オープンソース派の主張:
「ソースを公開しないとは何事か、けしからん」
消費者目線:
「買うという投票行動を誰もして無いのに、無料だから世に残ってる。
無料のオープンソースソフトのせいで、お気に入りだった
安くて良い商品が消えてしまった。」 >>852
米国著作権法でコンピュータプログラムが著作物とされたのは
1980年の改訂から
違法とは何法に違反してたのかな? >>853
価格に見合った品質のアドバンテージがないから消える
無料は無料同士で競争してるんだぜ？ >>855
無料の分際で、有料の商品に対して「価格に見合った」とはどの口が言う。 >>858
書簡は1976年だから著作権法では保護されない時代 >>856
無料のソフトに優る部分があれば消費者はその部分に対価を支払う
これが「価格に見合う」状態
ビジネスが成り立たないということは
無料のソフトに優る部分が対価を支払うほどにはなかったということ >>860
MITの博士課程といえば、日本の東大の博士課程みたいなもので、
そこの人が日夜作ったものが無料で配られてるんだぞ。 消えた安くて良い商品とやらがあったとして、消費者の多くが買わないせいで消えたわけだから、
消えたのを残念がってるのは消費者の中でも少数派よね >>861
そういうのを権威主義という
害悪しかもたらさない >>657
月へ行ったやつとは別だけど
昨日というか深夜よみうりか日テレでH3が爆破されるまでの流れを放送してた
リーダーっぽい人の振る舞いを観てると
やはり落ちるべくして落ちたんだなと確信した >>695
ffはOSが死ぬか自分が死ぬまでリソース返却しない糞ブラ >>735
fn fuga(hoge:Option<callback関数>) {
なんかする
match hoge {
None => なんかする,
Some(hoge) => hoge()
}
なんかする
}
で
fuga(Some(関数))やfuga(None)渡しが割と使える解決方法じゃないのかな 今時プチフリって…
ここで必死に罵り合ってる連中って5chやるのが精いっぱいのよぼよぼPC使ってそう >>769
>「斜め横の」機能を付けてしまう
ああこれは判るわω
うまい表現だ
>>788
>SDGs に反し、世界中でどれだけ電気代と時間とストレージ(SSD/HDD)
>とサーバー付加、ネットトラフィックの無駄
めっちゃ判りますωωω >>866
>SDGs に反し、世界中で～～の無駄になっていることか。
どこの世界線から来た異世界人ですか？
2018年ですら
世界のインターネットトラフィックの過半数を「映像視聴」が占めている
gigazine.net/news/20181003-global-internet-downstream/
と言われているのに。
また嘘つきかよ。 >>862
そうでもない。
たとえば、「システムセレクター」という安くて良いパーティションブートツール
が有って、LinuxとWindowsのマルチブートに重宝していたが、どっかの左翼が
Parted Magic なる使いにくいが同類の無料ソフトを公開したところ、
潰された。
しかも、LinuxもWindowsもパーティションやブート関係は変化が激しいため、
古いツールは危険で使えなくなった。
Parted Magicの使えることは使えるが、使い勝手が悪いし、途中で
コマンドラインを目でコピーして端末に入力しなければならない
工程が挟まっているので、だんだんとLinuxをインストールしなくなった。
これで、デスクトップLinuxは消えました。
つまり、オープンソース哲学は、せっかくあった商用ツールを潰したため
自ら衰退の道に入りましたとさ。 >>869
「塵も積もれば山となる」
それに、ネットトラフィック以外に貴重なSSDを食いつぶすことは変わらん。 せっかく、Linuxを応援するようなツールだったのに自ら潰した。
それが左翼的思想の帰結。 それにダウンロードとインストール、コンパイルしている時間の無駄。 >>870
本当に消費者が困ってるなら自分で開発して売ればいいじゃん
買ってもらえるんでしょ？ >>870
無知なだけではないか
Linux標準システムだけでツインブートにできる
>> 古いツールは危険で使えなくなった。
それなら消えても仕方ないだろ >>874
有名企業がやっていて、オープンソースのものより優れており、需要があっても
つぶれる、という現象が起きたんだから、同じことを他社がやってもまた
潰れるだろう。
経済と言うのは、ややこしくて、ギリギリのところでやっと採算を合わせてる
のに、左翼達は税金とかで対抗物を作ってしまい、そのギリギリ構造を壊してしまう。 >>873
コンパイル言語は全て同じ
そして各OSが取り込んだものやパッケージ化したものはバイナリが用意されているため各利用者がコンパイルする必要はない
これは使用プログラミング言語と全く関係ない話 >>875
>Linux標準システムだけでツインブートにできる
現実的には不可能。
大事なパソコンが壊れる。
左翼達は、実験的な遊び環境だと思って壊れてもいいと思ってるが、
99.9999% の人にとってそうはいかない。 >>877
バイナリだけが欲しいのに、ソースを勝手にダウンロードし、インストールされ、
勝手にコンパイルされ、勝手にインストールされてしまう、ということが
問題だと言っているんだ。 >>878
君が無知で勘違いしているだけだな
皆は安全に利用できている
いずれにせよプログラミング言語と無関係な話 >>879
無知すぎて話にならんな
パッケージ化されたものは自動でバイナリがダウンロードされて終わり
バイナリにパッケージ化されていないものは言語に関係なくOSに関係なくソースコードからコンパイルして終わり
当たり前の話で誰も困ってる人はいない >>876
でも消費者の大半は現状で問題ないと思ってるよ
もし問題なら議論が起きて政治が動いて規制されてるはずよね
つまり困ってるのは少数派だから何も変わらないってわけ 競争力が無かっただけのことを
ウジウジウジウジ言ったとして
何がどうなることでもない
その点をわかってないのはキッズ
泣いたらカーチャンが機嫌とってくれるキッズ 「競争力が無かった」
って、民業圧迫してる側が言うことか。 民間では、世界で一番競争力がソフトウェアが消えてなくなっている。
TOPですら消えているので、自然競争の結果ではない。 >>882
現状で問題ないと思ってる国民なんてほとんどいない。
どこの仮想世界の住人ですか。
アメリカは分断し、日本は先進国から後進国に移行してしまい、今後も
衰退国のままと予想されているのに。 >>886
OSSの是非という各論の話であって、総論に話をそらすなよ
OSSが問題だと言ってる消費者の割合を教えてくれ なんだろうな
あらゆるソフトウェアベンダが１からプロトコルスタックを実装する世界を望んでるんだろうか
このソフトとこのデバイスの組み合わせなら動くなんていう太古の不便さが復活するだけなのに 特定ベンダーが上から下まで作ってると
高コストにはなるが利便性や信頼性は高まるよ
今でもそういう世界もある 自動車とかそうだよね
自動車でToyota月例Updateなんて絶対に許されない
前から思ってるんだけどこの違いは何?
ソフトウェア産業の甘え? それとも他の要因? クローズドで厳密に管理された環境はそれなりの利点があるけど
一般ユーザ向けのサービスでそんな高コスト環境に付き合って開発なんてやってられない 全部を自分らで書くってこと？
死しかない
死屍累々のバグの山
セキュリティホールの谷
お金と時間が無限にあるか
お遊び程度のことなら別だけど >>894
少なくとも GAFAM は全部自分たちで書いているよ MSはOS周りはほぼフルスクラッチだろうけど他はどうだろうな
そのMSもオープンソース界隈にかなり歩み寄ってるし >>881
今回の例に挙げたツールの場合、そのバイナリだけが欲しくて
cargo install xxx
としても、ソースがダウンロードされてコンパイルされてバイナリが作成され、
そこにパスが通されたような動作になったようだけど。
ほとんどの人はバイナリしかいらないのに、オープンソース推進者の身勝手な
哲学理念で、ほとんど必ずソースまでダウンロードさせられてしまう。
また、機能がオプションスイッチで変更できず、ソースからビルドしなおす
ことを強制される事が多い。その場合、configureスクリプトに渡す
オプションスイッチでコンパイル時に#define マクロを1と0の切り替え
などでコンパイルし直される。
その結果、ストレージはわけの分からん亜種のバイナリとソースで埋め尽くされる。
なんという無駄。左翼が大好きなSDGsにまったくそぐわない。 今日日ストレージなんてクソ安いだろ？ケチケチすんな rustcの作者も左翼連中で、オープンソース礼賛者だから、rustcを使って
作られるアプリも、必ずソース公開圧力が掛かるだろう。
いつのまにか、ソースが無いと上手く動かなくされるとか、そういう風になる。
たとえば、伝統的なパソコン向けの C++ だとバイナリオンリーで動作して、
OSのバージョンが上がっても再コンパイル無しで動作するのが普通で、それが
常識。
ところが、rustcの場合、なんやかんやで、OSのバージョンが変わると
動かなくなるようなバイナリが出力されて、ソース公開して無いと
不利になるようになってしまうのではないか。そんな気がする。 >>902
そういうとこだよ。
感覚がずれていることに気付かない。まさにマルクスそのもの。 数多のプラットフォーム向けのバイナリを配布する義務がある主張してるのだろうか >>905
実質、Windowsしかないのに何言ってんだか。
100歩譲っても、Mac、Linux、Android、iOSくらいしかない。
左翼はめちゃくちゃ。自分達の威厳や権威が及ばないデファクトスタンダード
を認めたくない。 いいぞ
その調子でそいつをここに惹き付けておいてくれ 多くの現実主義者は、メンドクサイから Windows バイナリしか作らない。
それで顧客も困らない。
ところが、左翼は現状を変えたいから、「それでは公平性に反する」などと
わけの分からんことを言って、ソース公開を強制し、コンパイルは各自に任せる
ように仕向ける。そして、ストレージは常に無駄で一杯になり、地球は破壊される。
しかし、弱者である自分達を救ってもらうために、SDGsだ、などと唱える。
しかし、自分は他社に何も与えない。他者から奪うことだけを考えている。
オープンソースにすれば、自分は楽して、最高の便益を受けられる社会が来ると
思い込んでいる。ところが現実は、オープンにすればするほど、社会不安が
増大し、特に日本は何もすることが出来なくなり、将来は悲観的な未来像しか
描けなくなっている。
日本以外でも、先進国は、オープン化によって、何もすることが出来なくなってきている。 あなたが求めているものはフリーウェアなのではないか？
オープンソースソースはなにも強要していないでしょう
使用することを強要していないのだから >>909
ものではなく、自分がちゃんとやった場合にそれが認められる社会構造が大事なんだ。
オープンソースもフリーソフトもそれを崩す。 >>911
あなたオープンソースのツールを対価も払わずインストールしたのではないの？ >>912
そんなものを作った人が悪い。
つまり、オープンソースのソフトがあるから、商売が成り立たなくなり、
商用ソフトが作れなくなったんだから。
つまり、オープンソース・ムーブメントこそが、社会を壊した。
水源が枯渇した。そして今後も枯渇が進む。それが少子化であり、
日本の先進国からの離脱である。 >>913
オープンソースソースによって駆逐された商用ソフトってなにがあるの？
オープンソースを使っている商用ソフト、サービスはゴマンとあるけど、それはなくなっていいの？ 中国人は、安い中華製品が日本に入ってきていることについて、
「安い中国製品によって、先進国は恩恵を受けている」
などと言っている。しかし、現実には、日本人の大部分は、この安い中国製品
に悩まされている。
それと同じこと。 >>914
潰されたソフトは多い。マルチブート作成ソフトの「システムセレクター」、
C/C++言語コンパイラのTurboC とその会社のBorland。
Watcom C/C++コンパイラー。
>オープンソースを使っている商用ソフト、サービスはゴマンとあるけど、
>それはなくなっていいの？
いい。そんなソフトやサービスはどうでもいい。なくなればいい。
特になんとも思わない。 オープンソースソフトが無い状態で、どれだけのソフトやサービスを作れるか、
ということを競争すればいい。 >>918
その場合、他の掲示板が作られていただけ。 >>917
みんな独自のプログラミング言語を作るべきということなの？ >>920
昔は、オープンソースじゃなくても言語は統一されていた。
規格がオープンでも、設計図はクローズド。 今は人の心の無い哲学者のせいで設計図をオープンにする圧力が強まった結果、
言語は各社各様の規格がバラバラになった。
なぜなら、そうしないと生き残れなくなったから。
生き残りを書けた結果、各社各様の言語の百家騒乱状態になった。 >>921
それで、各々プログラミング言語を作るべきということ？ >>923
おのおの、といっても普通は企業だ。
一人で作れる人は特殊ケースで、ほとんど現れない。 >>924
あなた自身にはそれを実現する技術はあるの？ >>926
なるほど。
企業がオープンソースの使用をやめるのならWindowsもなくなるけど、そうすると作った商用ソフトはどこで動かすの？実質Windowsしかないのに。 >>927
何言ってますか。
言っていることがわかりませんが。 >>928
MicrosoftのエンジニアはOSSなしで開発することはできないですよ >>929
あなたはうそつきですね。出来ます。
むしろ、OSSなものが存在するため、最低限が上がってしまって仕方なくOSSを
使っている状態です。 さっさと政治につなげて規制かけりゃいいじゃん
あんたの崇高な理念のもとにならいくらでも賛同者が集まるでしょ
こんなとこで管巻いて何やってんだか >>930
30年退化してもいいからオープンソースを無くした方がエンジニアがハッピーになれるということ？ >>931
何をやっているのかと言えば、オープンソース潰しです。
オープンソース礼賛者がその独自理念を流布するのと同じことです。 >>932
退化させているのはオープンソース側なんですってば。
そんなものがなければ、もっと進化していました。絶対。 >>934
技術的には、何を退化させていて、そうでなかったらどう進化していたの？ オープンソースが無かったら
コンパイラ、開発環境、ライブラリ、実行ライセンスとかで
年間何十万も金とられて個人開発者なんて生まれなかっただろうな AWSの計算リソースを減らして料金を安く上げることには興味があります。
一方で、SDGsにもフェミニズムと同じくらい興味があります。 >>936
そんなことないですって。
オープンソースが無かったほうが、素晴らしい開発環境が出来ていました。
これは絶対。 >>935
オープンソースは、発想力が無い人が委員会などで規格を考えて、
それがはびこるしかない。 >>936
素晴らしいことと値段は別の話だぞ
素晴らしいものに対価を払うべきなら何十万もかかるのは当然だろう オープンソースは、ドーピング。
競争条件を勝手に変えてる。
実力が無いのに、表面的な記録は出てしまう。
スポーツ以上に深刻なのは、ドーピングして作られたソフトウェアは底が浅く、
アイデア力が無いと言うことだ。 スポーツより深刻なのは、オープンソースでドーピングした場合、
表面的に同じに見えても、根本的な頭の良さが違うため、それ以上の
成長が見込めないと言うことだ >>933
このスレを潰してるだけでワロタ
ほらもっと頑張れよ、毎秒レスしていけ
全板の全スレで演説しろ、ツイートしまくれ、動画を上げまくれ >>901
それはプログラミング言語と無関係な話
バイナリを用意するのは各OSのディストリビューションの役目
ソフトウェアの作者が無数にある全てOSのバージョンのバイナリを全て用意する必要はないし不可能 >>913
あなたが変革に適応できないだけにしか見えないよ >>942
>競争条件を勝手に変えてる。
競争条件が変わったんだから適応しな? 横から: そもそも、safe C++にこだわりたく、まだRustに移りたくない俺、適応の話は耳が痛いｗ 未定義動作をエラーに出来ない時点でsafeは無理じゃね 欲張っても仕方ないからさ、今の仕様でできる範囲でsafeを目指すんだ
そうこうしてる間に、C++が改善されるだろ
業務で使ってないからね 代わりに、だれも助けてくれないからさ ひとむかし前は二次方程式や三次方程式とかの解法もクローズドだったからな
みんな隠したがるんよ
数学はどうやって発展したか考えてみろ
オプソになってから発展しただろ 今のいろんな技術が積み上がった中で発展的な事するには
他の部分の作業コストを最小限にするのが良いのにドーピングとか言っちゃうのはなあ >>938
ほとんど同じ車輪をいつまでも再発明して消費者から金取りたい
って言ってるようにしか聞こえん 複オジ以上の狂気が暴れると本スレにやつが出張ってくる頻度が上がって迷惑だな >>933
フリーソフトウェア運動やオープンソースって著作権法に基づいているからね
>>931に言うように立法しなければ
いくら吠えてても法治国家では無意味だよ プログラミングを免許制にしろってのはありだと思うわ
自称無資格プログラマが多過ぎる
情報処理試験とかあるのに有名無実だろ >>945
>バイナリを用意するのは各OSのディストリビューションの役目
>ソフトウェアの作者が無数にある全てOSのバージョンのバイナリを全て用意する必要はないし不可能
何その化石の様な発想。
古代Unixの思想。
他人が作ったソフトウェアをOSの一部だと思ってる。 >>951
どうして、数学のような基礎理論とプログラミングを同一視したがるのか。
全く違うのに。
トヨタ自動車の設計図は公開されて無いが、十分に発展した。 >>946
変革というより、OSSは、中世の貴族システムに逆戻りしてるだけ。 >>947
OSSは奴隷システムなので、適応せずに、潰さなくてはならない。 アメリカもイギリスも古代ギリシャも、奴隷の上に成り立った文化。
同じことをOSSやGNUはやろうとしている。 >>962
アメリカでは最近社会主義革命が起きている、という噂が流れている。 >>950
いまだにアクセルとブレーキ踏み間違えて簡単に暴走する車ばかり
なにが
発展した(キリっ
だよ 「アメリカでは最近社会主義革命が起きている」
で検索しても、色々出てくる。
アメリカのミレニアム世代が、社会主義に好意的である、とか。 >>958
プログラミングは生産に資本を殆ど必要としない
最近はChatGPTみたいな資本を必要とする分野も出てきたけどね >>966
FSFやOSS推進者は中世に貴族だけが科学を発展させたのを現代に蘇らせようとしている。 >>967
だから庶民が成り上がるのに適していたのに、大学が補助金や研究費で
無料ソフトを配布する様になってしまった。 >>969
ソフトが無料で利用できるので利益を享受してるのではないかな?
学生なんて金ないので昔は開発環境手に入れるハードルは高かったが
今は安価に誰でもプログラミング開発環境を手に入れられる >>970
貴族は、補助金や国や大学からの研究費で質の悪いソフトを作って無料で配布
している人々。Mozillaもこれに属す。
奴隷は、仕方なくOSSを使って、OSSに貢献してしまう多くの人々。 >>972
>貴族は、補助金や国や大学からの研究費で質の悪いソフトを作って無料で配布
>している人々。Mozillaもこれに属す。
じゃおまいさんが質を改善して改善の対価を得れば良いのでは?
ビジネスモデルは最早変革したのだから
いつまでも過去のやり方に留まっていたらこの先生きのこれないよ >>973
質が悪いことはみんな分かっているが、しかし、質の良くても無料のものには勝てず、
潰されていく現実がある。 >>974
質が良い製品があると仮定して
無料のものとの質の差に見合う価格設定をしないからなのでは?
ぼったくり価格に消費者は見向きしないよ Mozillaが質悪いのは同意
バナナうんこ出たすっきり >>975
そんな風になって無い、経済は。
実際に潰れて行った実例があるだから。 >>977
>実際に潰れて行った実例があるだから。
対価を得るほどの製品でなかった
ボッタクリ価格だったので売れなかったのでは? >>978
マルチブートのシステムセレクターで検索。3980円くらいだったのに潰された。 >>979
無料のマルチブートのシステムセレクターに対する
そのマルチブートのシステムセレクターのアドバンテージに
3980円の価値がないと消費者が判断したから
売れなかったと考えないのはなぜ? そして、デスクトップ用にはLinuxを誰もインストールしなくなりましたとさ。 Linuxはそんな製品を必要とせずにWindowsとのマルチブートにできる >>984
危険を背負うならばな。銃社会のアメリカ風価値観ではそれでいいのかもしれないが。
また、ドーピングしてる側がシラフで戦っている側に説教すべきじゃない。 素のLinuxの場合、パーティションやブート構成が壊れても直すことは愚か、
見ることも出来ないはず。 OSSにはさんざん苦労させれてきた経験から、パーティション作業の様な危険なこと
を、OSSに任せるわけにはいかない。
今回のCargoの問題でも、こっちのせいにされた。
価値間の違いが大きすぎる。どうせディスクが壊れても、こっちのせいにされ、
貧乏のせいにされ、貧乏は能力のせいにされ、国籍のせいにされる。
日本に生まれたから白人よりも能力が無い、東京以外に生まれたから
東京の人より能力が無い、東京の人よりチャンスが無いのは、
おまえの父ちゃんが悪い、みたいな。 壊れないと思うが心配なら外部で
ブートできるように準備してからインストールすると良い >>989
OSSは怖いと言う経験法則がある。
問題が起きたら、必ずこちらのせいにされてきたので、OSSの人は、絶対に
自分達の問題ではないと持っており、だから、OSSは最高のシステムだと
思い込んでいる。つまり、絶対に非を認めないので、彼らの中では自分は
最高の技術力を持っていて最高の安全性を持っていると思い込んでいる。
しかし、実体はみんな知っているように、そうではない。 OSSは凡人で雑魚の集まりなゆえに、開発者数だけは多い。
そのため、凡人プログラマの中での支持は高い。
だからこそ、傷を舐めあい、絶対に自分達の非を認めない。
実態は、まともな企業に就職できない低能力のプログラマ集団である。 「OSSは悪質なのに消費者に選ばれて、そのせいで企業の良質な製品が潰れる」
↑
気が狂っとる そして、>>964 で流れ弾が当たったのでいっちょ噛み
オープンソースが成功するか、ではなく、成功したオープンソースはどんなか考えるようにしたい
俺のようなゴミカスにも、オープンソースは門戸を開いている >>988,989
メカ音痴なのは分かった
無理すんなw >>995
どうせ、着脱式のストレージを買えばいいだの思ってるんだろうて。
金ばっかり使って。 >>988
>OSSにはさんざん苦労させれてきた経験から、パーティション作業の様な危険なこと
>を、OSSに任せるわけにはいかない。
>>989
>OSSは怖いと言う経験法則がある。
お前さん個人の問題だよ
適応能力が低いのが原因だと思う
そういう生き方でも良いが人のせいにはするな
な？ このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 33日 14時間 58分 2秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
