จำนวนเต็มที่เชื่อไม่ได้ — ค่าเปลี่ยนห้าจุด และไม่มีจุดไหนแดง
คำถามของคอร์ส และคำตอบที่วัดได้
หัวข้อที่มีชื่อว่า “คำถามของคอร์ส และคำตอบที่วัดได้”คำถามเดียว คือค่าที่ถึงปลายทางยังเป็นค่าเดิมหรือไม่ · คำตอบวัดเป็นจำนวนเต็มล้วน
คำถามคือ ยอดออเดอร์กับ order id ที่เดินผ่านระบบ ยังเป็นค่าเดิมอยู่หรือเปล่า
สิ่งที่คนเดาถูกอยู่แล้วคือหลายภาษาตอบไม่เหมือนกัน สิ่งที่คนเดาไม่ถูกคือ ภาษาเดียว source เดียว ตอบไม่เหมือนกันเอง และทุกครั้งที่มันตอบผิด ไม่มีอะไรแดงสักอย่าง
rustc a.rs ให้รหัสออก 101 กับ panic ส่วน rustc -O a.rs ให้รหัสออก 0 กับ
4294967281 จาก source ชุดเดียวกัน เทสต์ของคุณรันฝั่งซ้าย ของจริงรันฝั่งขวา
ธีสิสของคอร์สจึงเป็นประโยคเดียว คือ ค่าจำนวนเต็มค่าหนึ่งเปลี่ยนได้ห้าจุดระหว่างทาง และทั้งห้าจุดเงียบ จุดที่บอกได้ว่ามันเปลี่ยนคือชนิดปลายทางกับธงที่คุณไม่ได้ตั้ง
ห้าจุดที่ค่าเปลี่ยน
หัวข้อที่มีชื่อว่า “ห้าจุดที่ค่าเปลี่ยน”ห้าหัวข้อนี้คือโครงของแปดบท และทุกบรรทัดข้างล่างเป็นค่าที่วัดมาแล้ว
- ตอนความกว้างหมด
10 - 25แบบ unsigned 32 bit ได้4294967281ที่ Rust Go และ Kotlin ส่วน Java กับ Node กับ Python ได้-15เพราะอ่าน bit ชุดเดิมคนละแบบ - ตอนหาค่าสัมบูรณ์
Math.absของInteger.MIN_VALUEคืน-2147483648โดยไม่มี exception ส่วนMath.absExactโยนArithmeticExceptionออกมา - ตอนหาร
-7 / 2ได้-3ที่สามภาษา-3.5ที่ Node และ-4ที่ Python · เศษของมันได้-1ที่สี่ภาษา และได้1ที่ Python ภาษาเดียว - ตอนทศนิยมกลืนมัน Node ตอบว่า
2**53 === 2**53+1เป็นtrue· จำนวนเต็ม สองค่าที่ต่างกันกลายเป็นค่าเดียวกัน โดยไม่มีสัญญาณใดออกมา - ตอนมันข้ามพรมแดนของการ parse
strconv.Atoiที่เกินช่วงคืน9223372036854775807พร้อม error ไม่ใช่คืน0· สำนวนn, _ :=จึงกลืน error แล้วเดินต่อด้วยค่าที่ใหญ่ที่สุดของชนิด
สวิตช์ที่คนเดาผิด
หัวข้อที่มีชื่อว่า “สวิตช์ที่คนเดาผิด”สรุปที่ติดปากคือ debug panic release wrap · การวัดบอกว่าไม่ใช่ทั้งสองอย่าง
ธงที่ตัดสินคือ -C overflow-checks และมันตั้งฉากกับการ optimize สนิท
rustc -O -C overflow-checks=on ยัง panic ที่รหัสออก 101 ทั้งที่ optimize แล้ว
ส่วน rustc -C overflow-checks=off ให้ 4294967281 ทั้งที่ไม่ได้ optimize เลย
debug กับ release เป็นผลพลอยได้ของค่าตั้งต้น ไม่ใช่กลไก และการเรียกมันว่ากลไก
คือสิ่งที่ทำให้คนมองหาสวิตช์ผิดตัวตอนของขึ้น production แล้วค่าไม่ตรง
กับดักอีกชั้นอยู่ที่การทดลองเอง ถ้าคุณเขียนค่าเป็น literal rustc ปฏิเสธตั้งแต่
compile ด้วย error: this arithmetic operation will overflow แล้วไม่มี binary ออกมา
ทั้งสองฝั่ง การทดลองที่ใช้ literal จึงรายงานว่าสองฝั่งตรงกัน โดยไม่ได้วัดอะไรเลย
สิ่งที่คอร์สนี้จงใจไม่ทำ
หัวข้อที่มีชื่อว่า “สิ่งที่คอร์สนี้จงใจไม่ทำ”ประกาศไว้ตรงนี้ เพื่อไม่ให้ใครอ่านจบแล้วเชื่อว่าได้ของที่คอร์สนี้ไม่ได้ให้
- ไม่วัดความเร็ว ทั้งคอร์สไม่มีหน่วยเวลาสักตัว หน่วยคือค่าจำนวนเต็มที่เขียนเป็น string รหัสออก ชื่อ class ของ exception และ diagnostic ของ compiler
- ไม่แตะ bit บนสาย คอร์ส สัญญาบนสาย เป็นเจ้าของ เรื่องนั้นทั้งเรื่อง คอร์สนี้เป็นเจ้าของการคำนวณกับพรมแดนของการ parse
- ไม่ทัวร์ API ของ
encoding/jsonstruct tag และDecoderเทียบUnmarshalเป็นของคอร์ส Go จากศูนย์ คอร์สนี้เป็นเจ้าของค่าที่หายไป - ไม่สอนชนิดของเงิน
MoneyกับBigDecimalเป็นของ บัญชีแยกประเภทของระบบชำระเงิน คอร์สนี้เป็นเจ้าของ การคำนวณบนค่านั้น ไม่ใช่ชนิดที่ห่อมันไว้ - ไม่แตะความกว้างของ column ใน database มันต้องใช้ PostgreSQL ซึ่งจะดัน probe ทั้งตัวออกไปนอก CI · ตัดออกตั้งแต่ตอนออกแบบ
ก่อนเริ่ม — สิ่งที่ควรมีมาก่อน
หัวข้อที่มีชื่อว่า “ก่อนเริ่ม — สิ่งที่ควรมีมาก่อน”อ่านห้าภาษาออกพอตามตัวอย่างสั้นๆ ได้ก็พอ ไม่ต้องรู้เรื่องการเข้ารหัสจำนวนเต็มมาก่อน
- อ่าน Rust Go และ Java ออก ระดับที่ตามตัวอย่างสิบบรรทัดได้ก็พอ ถ้ายังไม่ถึงตรงนั้น เริ่มที่ Rust จากศูนย์ Go จากศูนย์ หรือ Java จากศูนย์ ก่อน
- ไม่ต้องรู้จัก two’s complement มาก่อน บทที่ 3 อธิบายมันตอนที่มันโผล่ครั้งแรก
- ควรเคยเจอค่าที่ไม่ตรงกันระหว่างสอง service เพราะนั่นคืออาการที่คอร์สนี้อธิบายต้นเหตุ
- ต้องมี
rustcGo JDK 25 Node และ Python 3 เพราะทุกข้ออ้างมาจาก probe ที่คุณ รันเองได้ · ไม่ต้องมี Docker และไม่ต้องต่อเน็ต
เส้นทางการเรียน
หัวข้อที่มีชื่อว่า “เส้นทางการเรียน”แผนผังนี้เติมขึ้นเองเมื่อบทเรียนถูกเพิ่มเข้ามา