Rust part13

**デフォルトの名無しさん** · 2021/11/07(日) 10:04:59.35

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

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

前スレ
Rust part12
https://mevius.5ch.net/test/read.cgi/tech/1629813327/

**デフォルトの名無しさん** · 2022/01/20(木) 13:39:18.98

>>637
Cell⇔RefCell は静的⇔動的の関係ではない
Cell⇔RefCell は直接⇔参照の関係
そのため余分にRefが付く

静的⇔動的の関係にあるのは
「&」⇔「RefCell::borrow()」)
「&mut」⇔「RefCell::borrow_mut()」

**デフォルトの名無しさん** · 2022/01/20(木) 13:52:05.11

>>639
少なくとも構造体の説明としては

https://doc.rust-lang.org/std/cell/struct.Cell.html
> A mutable memory location.

https://doc.rust-lang.org/std/cell/struct.RefCell.html
> A mutable memory location with dynamically checked borrow rules

↑のように書いてあるね
だから
SCell // A mutable memory location with statically checked borrow rules
DCell // A mutable memory location with dynamically checked borrow rules
こんなんでもよかったんじゃないかなぁと思ったがこれはこれで石投げられそう

**デフォルトの名無しさん** · 2022/01/20(木) 14:13:35.66

>>640
それは違う
間違った解釈で無関係な場所に「with statically checked borrow rules」を付けてはいけない

参照借用規則『multi readers xor single writer』に対して
以下が「静的チェック⇔動的チェック」の関係にある
静的チェック: multi「 &」xor single「&mut」
動的チェック: multi「RefCell::borrow()」xor single「RefCell::borrow_mut()」

一方でCellとRefCellの関係は
内部可変性が「直接書き換えOK」⇔「参照書き換えOK」の関係
だからCellに対してRef(参照)が付くRefCellという名前になっている
そして参照となるRefCellに対してのみ上述の参照借用規則が適用される

**デフォルトの名無しさん** · 2022/01/20(木) 14:23:25.93

>>641
なるほどね

https://doc.rust-lang.org/std/cell/struct.Cell.html#method.get_mut
> If you require interior mutability by reference,
> consider using RefCell which provides run-time checked mutable borrows through its borrow_mut method.

↑ここでもまずは「参照による内部可変性が必要な場合は」と先に来てるね
「実行時に動的に借用のチェックをさせたいという」のが動機だと俺勝手に思いこんでたけど
それは一番じゃないみたい

**デフォルトの名無しさん** · 2022/01/20(木) 14:32:46.88

>>635
Cell/RefCellと違ってBoxは分かりやすくていい名前だと思うぞ
Boxing/Unboxingは他の言語でも普通に使われてるよね？
旧名のOwned<T>や代替案のHeap<T>に比べると確実にいい

**デフォルトの名無しさん** · 2022/01/20(木) 14:45:20.72

Boxing/UnboxingはC#やJavaにもあるからBoxには全く違和感なかったけど
よく考えるとソースコード上にBoxという文字列が出現するのはRustだけかも？

**デフォルトの名無しさん** · 2022/01/20(木) 14:54:02.35

Scheme でも次の規格に Box が入ることになっている。
(既に導入している処理系も結構ある。)

**デフォルトの名無しさん** · 2022/01/20(木) 15:32:21.48

通常の型TやBox<T>などがSend+Syncである一方
Cell<T>とRefCell<T>は!Send+!Syncであることと引き換えに内部可変性を得ている
つまりmutではない参照の内部にあったとしても
「Cell<T>」は「mut T」のように成れて直接書き換え可能
「RefCell<T>」は「&mut T」を得られて参照書き換え可能
ここでCellとRefCellの違いは「&」すなわち「Ref」だからこの命名自体は分かりやすいと思う

**デフォルトの名無しさん** · 2022/01/20(木) 16:52:16.46

>>644
むしろJava等にあるからこそ戸惑ったわ
既にあるBoxing/Unboxingへの理解に対して
Rustでは突如構造体としてBoxだもん

**デフォルトの名無しさん** · 2022/01/20(木) 23:14:12.74

まあBox と名前を合わせてBoxCellとか逆にBoxをRefにするかした方が統一的な名前づけだったとは思う。

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

>>648
Box<T>はヒープ上にTの場所を確保してそこを指し示します
Cell<T>はヒープ上かどうかは無関係で例えば>>636の使用例では全てスタック上
したがって「Boxと名前を合わせてBoxCellとか」はおかしいです

TとCell<T>はメモリ上の格納場所も実体も同じです
つまりCellとは内部可変性という特性を与え示していると考えたほうがわかりやすいでしょう
RefCell<T>も同様ですがこちらは参照借用規則の実行時チェックのためのborrowフラグが余分に確保されます

もうひとつの「BoxをRefにするかした方が統一的な名前づけだったとは思う」もおかしいです
refは参照(reference)の略としてあちこちで使われておりヒープ上かどうかは無関係ですが
Box<T>はあくまでもTがヒープ上にあることが主眼です

余談ですがこの関係でRefといえばstd::cell::Refという構造体があり
これはRefCell::borrow()が返す型として直接意識することはなく使われています
ちなみにRefCell::borrow_mut()が返す型はstd::cell::RefMutです

**デフォルトの名無しさん** · 2022/01/21(金) 10:40:22.86

何も分かってねーなこいつ。
なぜBoxにするか、なぜRefCellにするかってのは要するに構造体のサイズを決定できない場合を想定してるわけよ。
スタックにそういういう動的にサイズが異なる実体をおくことも最近のコンパイラではないこともないが、通常はヒープに置くわ。
文字通りしか考えないで実際の使い方なんか一切考えないやつってのが丸わかりになるって意味では
分かってなさそうなやつにこの辺りについて問いただすってのは割と良いかも。

**デフォルトの名無しさん** · 2022/01/21(金) 11:50:08.61

皆の言ってることがよくわからん
そもそもBoxとRefCellって対比させるようなものか？

**デフォルトの名無しさん** · 2022/01/21(金) 12:13:07.97

T -- Box<T>
Cell<T> -- RefCell<T>
って普通に考えれば対比させると思うけど。

**デフォルトの名無しさん** · 2022/01/21(金) 13:03:50.49

RefCell<T>はTへのrefが作れるCell (実行時にborrow checkする)
TとBox<T>はborrowに関しては同じ振る舞いでデータの場所がヒープか否かの違い
全然関係性違うと思うんだけど

**デフォルトの名無しさん** · 2022/01/21(金) 16:26:46.26

>>653と>>649は合っている
>>650は間違っている
BoxとRefCellには共通点も類似性も関係性も何もない

**デフォルトの名無しさん** · 2022/01/21(金) 16:43:50.31

「所有権の複製」がおかしいってことは納得言ってくれたん？ｗ

**デフォルトの名無しさん** · 2022/01/21(金) 23:30:48.05

表現の問題だけど別にいいんじゃね？

**デフォルトの名無しさん** · 2022/01/22(土) 00:49:37.07

ダメです
明らかにおかしい
ポインタ渡しと参照渡しを間違えてるくらいにはおかしい

**デフォルトの名無しさん** · 2022/01/22(土) 01:05:08.77

それは解釈のレイヤの問題。
JIS の情報処理用語の定義では参照呼び (参照渡しという言葉は定義がないが実質的に同じだろう) はオブジェクトの場所を渡すことと定義されていて、
ポインタという形で場所を渡すのも参照呼びの一種ということになる。
言語仕様の話をしているところで異なるレイヤが混ざるのはおかしくはあるが、
実例を示そうとしたり、逆に抽象的に説明しようとしたりすると境界が曖昧になることはある。

**デフォルトの名無しさん** · 2022/01/22(土) 19:22:08.25

じゃああなたはポインタ渡しと参照渡しを間違えてもいいよ

**デフォルトの名無しさん** · 2022/01/22(土) 19:59:43.90

>>658
ポインタ渡しと参照渡しが同じなら、nullptrを渡すのと同じことを参照渡しでどうやるか教えてくれ。

**デフォルトの名無しさん** · 2022/01/22(土) 20:05:58.29

>>657
参照渡しじゃなくてダブルポインタの方だろ。

**デフォルトの名無しさん** · 2022/01/22(土) 20:32:06.98

ポインタ渡しっていう用語も使わないでほしい
ポインタ型の時に特別なもんでもなんでもなく
他の場合と同じcall by valueなのだから

**デフォルトの名無しさん** · 2022/01/22(土) 20:53:17.10

rustにおいて参照渡しと言ったらどういう意味になるんだろうか

**デフォルトの名無しさん** · 2022/01/22(土) 22:32:38.62

>>657
そんなレベルじゃないだろw
「値の参照外し」くらいのありえねーやつだぞ

**デフォルトの名無しさん** · 2022/01/22(土) 23:03:41.04

>>663
&Tを渡すこと

**デフォルトの名無しさん** · 2022/01/22(土) 23:09:33.04

>>654
>BoxとRefCellには共通点も類似性も関係性も何もない
そうそう、何の共通点も類似性も関係性もないのに
The BookではBoxとRefCellを対比させてどういうケースにどっちを使うかわざわざ解説してるんだよなぁ
何の共通点も類似性も関係性も無いにも関わらずw

**デフォルトの名無しさん** · 2022/01/22(土) 23:45:04.56

>>666
マジでその二つは関連も類似も何もない
大きく分類してもBoxはスマートポインタの一種だが
RefCellはスマートポインタではなく内部可変性という性質の指定のみ

**デフォルトの名無しさん** · 2022/01/23(日) 00:16:51.00

>>666
https://doc.rust-lang.org/book/ch15-05-interior-mutability.html
https://doc.rust-jp.rs/book-ja/ch15-05-interior-mutability.html
ここのこと？

**デフォルトの名無しさん** · 2022/01/23(日) 01:50:05.66

clippy様がvoldemort typeを説明せよと仰せなのだが
もしかして、名前を言ってはいけないあの人のことをご存じない？

>>668
そこはinterior mutabilityの前提としてborrowing rulesを
おさらいするためにBoxを出してるだけだから違うだろ。
多義的なオレオレ用語が多くて質は悪いけど
the bookに意味もなくBoxとRefCellを登場させてる章なんてなかったと思う。

**デフォルトの名無しさん** · 2022/01/23(日) 09:58:49.85

なんでわざわざ自演するのかね？

**デフォルトの名無しさん** · 2022/01/23(日) 10:23:00.27

それが仲介おじの悪癖なんよ

**デフォルトの名無しさん** · 2022/01/23(日) 14:04:42.46

病気だな
病名は知らんけど

**デフォルトの名無しさん** · 2022/01/23(日) 15:19:04.05

rust勉強しはじめたばかり、C,C++はだいぶ昔少し経験がある程度

Cとかじゃ、constなpointerは、変数自体がconstと、指ししめす対象自体がconstである場合があり
const T * const p;
みたいな宣言があったが

Rustはデフォルトでイミュータブルなのはわかるけど、mutを付けると、変数自体も指し示す対象もmutableになってしまう？

let mut v = vec![1, 2, 3];
v.push(2);
v = vec![4,5,6];

どっちか一方を禁止する方法とかあるのですか？

**デフォルトの名無しさん** · 2022/01/23(日) 17:38:28.44

C上がりのヤツって意味のないところにconst付けがち
関数の引数にconst DWORD vとか

**デフォルトの名無しさん** · 2022/01/23(日) 19:54:52.69

>>673
どういうことをしたいのかによるけど
let x = Vec![...];
let mut y = &x;
みたいにすればyは再代入可能だけどxやvecの中身は変更不可になる

**デフォルトの名無しさん** · 2022/01/23(日) 20:02:24.55

末尾oとかWとかで荒らしてるやつ回線なんだ？亡霊か？

**デフォルトの名無しさん** · 2022/01/23(日) 20:58:37.79

えっ、一人二役まだ続けるのか

**デフォルトの名無しさん** · 2022/01/23(日) 22:45:59.41

お前Lはないだろ

**デフォルトの名無しさん** · 2022/01/23(日) 23:46:00.51

ちなみにRustでのconstとはコンパイル時点で定数(どんな複雑な型でもよい)であること
プログラミング言語によってはconstなのに実行時に決まる値(がその後変化しないこと、つまり単なるimmutable)を意味しているので意味の差に注意

**デフォルトの名無しさん** · 2022/01/23(日) 23:59:31.12

>>674
Rustでは関数の引数にconstはないな
ジェネリクスとしてのパラメータにはconstがありこちらは便利

**デフォルトの名無しさん** · 2022/01/24(月) 00:27:06.65

>>675
ありがとうございます。
やりたいことは、だいたい同じですけど、少し違って
v.push(2)か再代入のv= vec![4,5,6];のどちらかを禁じたいでしたけど
あなたの投稿みて考えて

let v = &mut vec![1, 2, 3];
v.push(2);
//v = vec![4, 5, 6]; エラーになる

で一応できました。
でも再代入可能で、中身変更不可にｖをする方法は思い浮かびませんでした。
675のようにして、vからｙに代入したらyはそうなりますが。

**デフォルトの名無しさん** · 2022/01/26(水) 20:11:49.47

すまんが、Replit使って学習してるんだけどさ
たまたま海外勢の動画見たら、同じReplitのはずなのに波線の指摘とかコード補完とか効いててびっくりしたわ
https://www.youtube.com/watch?v=MsocPEZBd-M
うちではこんなのならないんだけど・・・・やり方わかる人いたら教えてくれんかな？

**デフォルトの名無しさん** · 2022/01/26(水) 22:40:12.84

Repl.itは、リンターやデバッガーからサードパーティのパッケージ、ホスティング、デプロイまで、

すべてを備えた、ブラウザー内の完全な共同クラウド開発環境です

**デフォルトの名無しさん** · 2022/01/27(木) 14:52:35.89

プログラミングRustの第2版の訳書出たんだな

**デフォルトの名無しさん** · 2022/01/27(木) 17:03:59.04

**デフォルトの名無しさん** · 2022/01/30(日) 18:39:19.14

Rustはゼロ除算はコンパイルエラーになるの？

**デフォルトの名無しさん** · 2022/01/30(日) 18:46:47.93

const文脈ならコンパイルエラーになったはず

**デフォルトの名無しさん** · 2022/01/30(日) 19:13:28.33

コンパイル時に判明しないゼロ除算やオーバーフロー除算 ex. -128_i8 / -1_i8 はpanicとなるので
それが困る場合はchecked_div()を使えばOption型が返りNoneとなる

**デフォルトの名無しさん** · 2022/01/30(日) 20:48:51.55

>>688
ほんとだ、定数式じゃなくてもエラーになるんだね
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=78efbd7a2e6ac42c15da2cfb0d11485f

即値じゃなくてもエラーにしてくれてある程度賢そう
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2021&gist=381372577a28207f3a37bc007ac6e29c

**デフォルトの名無しさん** · 2022/01/30(日) 21:12:48.50

const fn divide(x:i32, y:i32) ->i32 {
x / y
}

let x = divide(1, 0); //panic
const y: i32 = divide(1, 0); //compile error

**デフォルトの名無しさん** · 2022/01/31(月) 00:45:03.08

>>690
定数式の文脈でゼロ除算起きるとコンパイルエラーになるのはある意味当然だと思うんだけど
そうじゃないところでエラーになるのが意外だった
デバッグビルドでもMIRの最適化とかで定数畳み込みみたいなことやってるのかな

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

>>691
Rustではconst fnな関数を使ってconstな定数を作ることができる
つまりコンパイラがその定数を算出するためコンパイル時点で判明する

**デフォルトの名無しさん** · 2022/01/31(月) 10:25:13.89

とあるデータフォーマットを扱うライブラリを作っています。
一定形式のレコードが連続で書き込まれて最後には終端レコードが書き込まれるという単純な形式です。
Rust 上でもレコードを追加するのと終端処理のふたつのメソッドがあるだけです。
要は ↓ のように使えるライブラリだということです。

let mut file = File::create("file.hoge").unwrap();
Hoge::new(&mut file).add_entry("string1")?.add_entry("string2")?.finish();

このとき
・終端処理は必ずしたい
・終端処理はエラーの可能性もあり、それは捕捉したい (ので drop でさせられない)
という制約を静的に表現できるでしょうか？

現状では終端処理のメソッドが実行されたときにフラグを立てておいて
drop 内でそのフラグを検査するという形にしています。
可能ならコンパイル時に発見できるようにしたいです。

**デフォルトの名無しさん** · 2022/01/31(月) 11:02:40.38

エラーを捕捉したいことをデストラクタに任せない
つまりそのような終端処理はdropされる前に終える
例えばBufWriter利用時も終える時は明示的にflushを呼ぶ
そしてflushはResultを返しエラーが判明する

**デフォルトの名無しさん** · 2022/01/31(月) 11:32:28.54

finishの呼び忘れを静的に捕捉したいということだからflushの例では不十分かな
add_entryの戻り値型の暗黙のdropを防げばいいけど、そういった機能はまだない（RFCにはあるけど進んではない）

https://users.rust-lang.org/t/prevent-drop-at-compile-time/20508
このスレッドではdropの実装に存在しないC FFI呼び出しを書いておいて、リンクエラーとして捕捉する方法が提案されているね

**デフォルトの名無しさん** · 2022/01/31(月) 11:35:46.57

>>694
それを制約として表現できるか (終端処理をしていないときにエラーになるように制約を書けるか) という質問をしてる。
つまり出来ないってこと？

**デフォルトの名無しさん** · 2022/01/31(月) 11:53:47.47

>>695
それは残念。

言語の機能として用意されてないまわりくどい方法を使うと
エラーメッセージがよくわからん (本来の問題とは違う内容が出てくる) ことになりがちだし、
使うときに unsafe や forget をいちいち書いてもらわなきゃならないのは
ライブラリとして提供するときにはちょっと汚すぎるなぁ。

**デフォルトの名無しさん** · 2022/01/31(月) 12:37:43.75

PhantomType的な？

**デフォルトの名無しさん** · 2022/01/31(月) 12:39:21.72

エラーメッセージがよくわからん事になりがちだからNGか

**デフォルトの名無しさん** · 2022/01/31(月) 12:47:03.61

>>696
なるほど
コンパイラは解析してdropさせるべき位置を把握しているから
そこへ至る全ての経路上で例えばFinalize trait実装型はそのメソッドfinalize()を呼んでいないとコンパイルエラーとなる
というような制約をするFinalize trait
が存在していれば要望を満たす？

**デフォルトの名無しさん** · 2022/01/31(月) 13:15:16.14

>>692
非const fnについての話なんだけど

**デフォルトの名無しさん** · 2022/02/01(火) 18:21:42.44

amazon primeの記事経由でegui見てみたが結構いいな
ネイティブで試してみたが充分実用レベル

**デフォルトの名無しさん** · 2022/02/01(火) 21:04:57.74

GCは標準からは消えたけどライブラリでやればいいってかつてこのスレで言われたことがあるのだが、GCライブラリのデファクトスタンダードってどれだ

**デフォルトの名無しさん** · 2022/02/01(火) 21:52:48.48

>>703
デファクトなんてあるわけないじゃん
マークスイープGCするならRust使う意味ないんだから

**デフォルトの名無しさん** · 2022/02/01(火) 22:04:01.37

>>704
いや一部だけGC欲しい時は普通にあるからそれは言い過ぎ

**デフォルトの名無しさん** · 2022/02/01(火) 22:51:54.30

クッソ身につまされる記事があったので共有する
https://dystroy.org/blog/how-not-to-learn-rust

**デフォルトの名無しさん** · 2022/02/01(火) 23:11:34.83

>>706
これはいい記事だな
次からテンプレ入り希望

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

>>702
eguiは毎回60fpsで全画面を描き直すことで差分描き直しを避けて簡単にしてるようだけど
省力化したい方針と合わないや
ゲーム向き？

>>705
GC使ってもRustのRAIIを無くせるわけじゃないから
そういう時はVecに入れて使って
あとは任意のタイミングで未使用の要素の区画を再利用という感じにしてる

>>706
Rustは各種bookを読んであとはstd docとreference見ながら
コンパイルエラーの通り直すだけで何とかなるから書かれている通りだね
付け加えると基本要素については覚えていないメソッドのために回り道しがちなので
Option Result slice str Iteratorあたりの全メソッドは一通り認識しておくといいかな

**デフォルトの名無しさん** · 2022/02/02(水) 10:20:38.88

複製おじは自分では何とかなってると思ってるのか

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

🐜蟻型蜂🐝はポジティブシンギング🤯だから

**デフォルトの名無しさん** · 2022/02/02(水) 18:24:25.46

>>706
>Mistake 3 : Start by implementing a graph based algorithm
その通りだとは思うけどRustと相性の良いアルゴリズム集的なのは欲しいとも思う

**デフォルトの名無しさん** · 2022/02/02(水) 19:18:50.51

>>711
汎用データ構造の大部分を使うな、という話になりそうだからなぁ。
スタックとキューくらいは楽に使えるのかね。

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

dynや lifetime heavyは失敗しながら学ぶのでいいと思う
普通の人はしばらくやってれば気づくから

**デフォルトの名無しさん** · 2022/02/02(水) 20:34:19.12

deny(rust_2018_idioms)はガチのマジでオススメです

**デフォルトの名無しさん** · 2022/02/02(水) 22:05:12.51

データ構造が大事なんだって言われながら育ってきた身としちゃあ辛い話じゃねえか

自分で作らなけりゃいいんだな！ってslab_tree使って
「ある条件に合致した子ノードから、ルートまでの値をリストで取り出す」
みたいな処理を書こうとしたら怒られるんだよな。
node_ref.parent() : &Self<T> -> Option<NodeRef<T>
っていう型なもんだから、次々に親をたどるために
while Some(parent) = node.parent() { node = parent; ...}
みたいな処理書くと、当然怒られる。

何とか抜け道無いかって探したら、node自身じゃなくてそのIDを使えばよかったんだけど、
いつも抜け道があるとは思えない。辛い。

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

Rustで普通にやってるとスレッドセーフを強いられるから制約がキツくなるんだよね

**デフォルトの名無しさん** · 2022/02/02(水) 22:41:53.47

大昔からの単純なポインタ相互参照だと
ダングリングポインタ・多重解放・解放忘れなどが全く存在しないことを検証すべき範囲が一般的には広くなりすぎる
もし狭い範囲に閉じ込められるケースならば閉じ込めた中でunsafeを用いたとしても効率的な型を提供すればよい
標準ライブラリにあるヒープを用いる型は全てそのようにして作られている

**デフォルトの名無しさん** · 2022/02/03(木) 23:00:23.96

>>684
今それ読んでる
出版物だけあって日本語の質はずっといい

**デフォルトの名無しさん** · 2022/02/03(木) 23:17:16.89

Craterについて教えてください

**デフォルトの名無しさん** · 2022/02/04(金) 00:50:00.86

>>718
もしかしてThe Bookの勝手訳の質と比べてる？

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

>>720
勝手訳というのがなにを指すのか不明だけどオリジナルのThe Bookからリンクされている日本語訳のことであればそれと比べている

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

そんなのを見るのは極初期だけで些細な話
その後はdoc.rust-lang.orgとdocs.rsしか見ないのだから

**デフォルトの名無しさん** · 2022/02/05(土) 13:22:14.88

その極初期の人が見る和訳の質の話をしてるんだろ

**デフォルトの名無しさん** · 2022/02/05(土) 14:41:30.63

あれは害悪レベルの訳だから初期でも見ない方がいいよ
ここでよくおかしなレスしてる人もあれの影響なんじゃないか？

**デフォルトの名無しさん** · 2022/02/05(土) 15:12:20.92

どうせ>>722のドキュメント見ないと先へ進めないしほとんどは中学生でもわかる平易な英語
日本語訳の質にこだわるような低レベルのやつはほっとけばいい

**デフォルトの名無しさん** · 2022/02/05(土) 15:52:33.91

Mistake 2 : Dive in without looking at the book

**デフォルトの名無しさん** · 2022/02/05(土) 15:59:05.92

>>726
まさにそれで最初は日本語訳でもいいがその後にthe bookを直接見るべき
そしてどの英単語でどう表現されているかを掴めば日本語訳がどうかに関わらず先へ進める

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

>>727
言ってること変わってますけど

**デフォルトの名無しさん** · 2022/02/05(土) 16:03:52.79

一貫してるぞ
日本語訳の質にこだわるような低レベルのやつはほっとけばいい
これしか主張していない

**デフォルトの名無しさん** · 2022/02/05(土) 16:09:07.88

そこ以外の文章はポエムか何かだったの？

**デフォルトの名無しさん** · 2022/02/05(土) 16:22:12.93

じゃあ和訳の質を話題にしている低レベルの人同士の会話はほっとけばいいのにｗ

**デフォルトの名無しさん** · 2022/02/05(土) 17:02:52.76

日本語イラネ言っている人は技術資料が英語でも
日本語でも生産性が変わらない人なんだよね？
アメリカの仕事でもした方が稼げるんじゃない？

**デフォルトの名無しさん** · 2022/02/05(土) 17:05:29.47

和訳の質にこだわってる人たちも唯一役に立つチャンスがあるよ
それは和訳の改善案を提案して質の向上に貢献すること
しかし和訳の質にこだわってるここの人たちは批判だけで提案がないから残念な人たち

**デフォルトの名無しさん** · 2022/02/05(土) 17:15:34.64

和訳の質にこだわっている人たちの質にこだわっている人は何の役にたつの？

**デフォルトの名無しさん** · 2022/02/05(土) 17:36:04.99

どこの食堂が美味いか話しているところに割り込んで、
不味い方を立て直してこいと言うくらいナンセンス。

**デフォルトの名無しさん** · 2022/02/05(土) 17:36:55.75

>>725
その結果、所有権を複製しちゃったんでしょw

**デフォルトの名無しさん** · 2022/02/05(土) 17:58:18.58

とはいえ元の話は
無料の炊き出しがレストランより不味い
みたいな話なのでそりゃそうだろうとしか
誰もがオライリーを気軽に買えるわけでもないし
それぞれ意味はあるだろう

**デフォルトの名無しさん** · 2022/02/05(土) 18:14:45.46

ざんねんながら悪文どころか誤訳だらけで無料の炊き出しよりひどいのがままあるのが技術書の世界