ในฐานะโปรแกรมเมอร์ C # เป็นเวลานานฉันเพิ่งได้เรียนรู้เพิ่มเติมเกี่ยวกับข้อดีของการได้มาซึ่งทรัพยากรคือการเริ่มต้น (RAII) โดยเฉพาะฉันได้ค้นพบว่าสำนวน C #:

using (var dbConn = new DbConnection(connStr)) {
    // do stuff with dbConn
}

มี C ++ ที่เทียบเท่า:

{
    DbConnection dbConn(connStr);
    // do stuff with dbConn
}

หมายความว่าการจดจำการใช้ทรัพยากรเช่นDbConnectionในusingบล็อกนั้นไม่จำเป็นใน C ++! สิ่งนี้ดูเหมือนจะเป็นข้อได้เปรียบที่สำคัญของ C ++ สิ่งนี้น่าเชื่อถือยิ่งขึ้นเมื่อคุณพิจารณาคลาสที่มีสมาชิกอินสแตนซ์ของประเภทDbConnectionตัวอย่างเช่น

class Foo {
    DbConnection dbConn;

    // ...
}

ใน C # ฉันจะต้องมีการใช้ Foo IDisposableเช่น:

class Foo : IDisposable {
    DbConnection dbConn;

    public void Dispose()
    {       
        dbConn.Dispose();
    }
}

และสิ่งที่แย่กว่านั้นคือผู้ใช้ทุกคนFooจะต้องจำไว้เพื่อใส่ไว้Fooในusingบล็อกเช่น:

   using (var foo = new Foo()) {
       // do stuff with "foo"
   }

ตอนนี้ดู C # และราก Java ของมันฉันสงสัย ... นักพัฒนา Java ไม่ได้ชื่นชมสิ่งที่พวกเขายอมแพ้เมื่อพวกเขาละทิ้งกองซ้อนเพื่อสนับสนุนกองดังนั้นจึงละทิ้ง RAII?

(ในทำนองเดียวกันStroustrupชื่นชมความสำคัญของ RAII อย่างเต็มที่หรือไม่)

ตอนนี้ดู C # และราก Java ของมันฉันสงสัย ... นักพัฒนา Java ไม่ได้ชื่นชมสิ่งที่พวกเขายอมแพ้เมื่อพวกเขาละทิ้งกองซ้อนเพื่อสนับสนุนกองดังนั้นจึงละทิ้ง RAII?

(ในทำนองเดียวกัน Stroustrup ชื่นชมความสำคัญของ RAII อย่างเต็มที่หรือไม่)

ฉันค่อนข้างมั่นใจว่า Gosling ไม่ได้รับความสำคัญของ RAII ในขณะที่เขาออกแบบ Java ในการสัมภาษณ์ของเขาเขามักจะพูดถึงเหตุผลในการออกจากยาชื่อสามัญและการใช้งานมากเกินไป แต่ไม่เคยพูดถึง destructic destructic และ RAII

ตลกพอแม้ Stroustrup ไม่ได้ตระหนักถึงความสำคัญของ destructic destructor ในขณะที่เขาออกแบบพวกเขา ฉันไม่สามารถหาคำพูดได้ แต่ถ้าคุณเป็นจริงคุณสามารถหาได้จากการสัมภาษณ์ของเขาที่นี่: http://www.stroustrup.com/interviews.html

ใช่นักออกแบบของ C # (และฉันแน่ใจว่า Java) ได้ตัดสินใจเป็นพิเศษเกี่ยวกับการสรุปที่แน่นอน ฉันถาม Anders Hejlsberg เกี่ยวกับเรื่องนี้หลายครั้งในช่วงปี 1999-2002

อย่างแรกความคิดเกี่ยวกับความหมายที่แตกต่างกันของวัตถุนั้นขึ้นอยู่กับว่า stack - based หรือ heap-based นั้นตรงกันข้ามกับเป้าหมายการออกแบบที่เป็นหนึ่งเดียวของทั้งสองภาษาซึ่งจะช่วยบรรเทาโปรแกรมเมอร์ของปัญหาดังกล่าว

ประการที่สองแม้ว่าคุณจะรับทราบว่ามีข้อได้เปรียบ แต่ก็มีความซับซ้อนในการนำไปใช้และความไร้ประสิทธิภาพที่เกี่ยวข้องกับการทำหนังสือ คุณไม่สามารถจริงๆใส่วัตถุสแต็คเหมือนในสแต็คในภาษาที่มีการจัดการที่ คุณเหลือที่จะพูดว่า "ความหมายเหมือนกอง" และมุ่งมั่นที่จะทำงานที่สำคัญ (ประเภทค่ายากพอคิดเกี่ยวกับวัตถุที่เป็นตัวอย่างของคลาสที่ซับซ้อนโดยมีการอ้างอิงเข้ามาและกลับเข้าไปในหน่วยความจำที่มีการจัดการ)

ด้วยเหตุนี้คุณจึงไม่ต้องการการสรุปขั้นสุดท้ายที่กำหนดไว้สำหรับทุกวัตถุในระบบการเขียนโปรแกรมโดยที่ "(เกือบ) ทุกอย่างเป็นวัตถุ" ดังนั้นคุณจึงไม่ต้องแนะนำชนิดของไวยากรณ์โปรแกรมเมอร์ควบคุมบางอย่างเพื่อแยกวัตถุปกติติดตามจากที่หนึ่งที่มีการสรุปกำหนด

ใน C # คุณมีusingคำหลักซึ่งมาช้าในการออกแบบสิ่งที่กลายเป็น C # 1.0 IDisposableสิ่งทั้งหมดนั้นค่อนข้างน่าสยดสยองและสิ่งหนึ่งที่น่าสงสัยว่ามันจะสง่างามกว่าถ้าได้usingทำงานกับไวยากรณ์ C + destructor ที่~ทำเครื่องหมายคลาสเหล่านั้นซึ่งIDisposableรูปแบบจานหม้อไอน้ำสามารถใช้งานได้โดยอัตโนมัติหรือไม่

โปรดทราบว่า Java ได้รับการพัฒนาในปี 1991-1995 เมื่อ C ++ เป็นภาษาที่แตกต่างกันมาก ข้อยกเว้น (ซึ่งจำเป็นต้องมี RAII ) และแม่แบบ (ซึ่งทำให้ง่ายต่อการใช้ตัวชี้สมาร์ท) เป็นคุณสมบัติ "ที่แปลกใหม่" โปรแกรมเมอร์ C ++ ส่วนใหญ่มาจาก C และถูกใช้เพื่อจัดการหน่วยความจำด้วยตนเอง

ดังนั้นฉันสงสัยว่าผู้พัฒนาของ Java จงใจตัดสินใจละทิ้ง RAII อย่างไรก็ตามมันเป็นการตัดสินใจโดยเจตนาสำหรับ Java ที่จะชอบซีแมนทิกส์อ้างอิงแทนที่จะเป็นซีแมนทิกส์ตามตัวอักษร การทำลายล้างที่กำหนดได้ยากที่จะนำไปใช้ในภาษาอ้างอิงความหมาย

เหตุใดจึงต้องใช้ซีแมนทิกส์อ้างอิงแทนซีแมนทิกส์คุณค่า

เพราะมันทำให้ภาษามากง่าย

• ไม่จำเป็นต้องมีความแตกต่างระหว่างประโยคไม่เป็นFooและFoo*หรือระหว่างและfoo.barfoo->bar
• ไม่จำเป็นสำหรับการมอบหมายที่มากเกินไปเมื่อการมอบหมายทั้งหมดทำสำเนาตัวชี้
• ไม่จำเป็นต้องใช้ตัวสร้างสำเนา ( บางครั้งจำเป็นต้องมีฟังก์ชั่นการคัดลอกอย่างชัดเจนเช่นclone()วัตถุจำนวนมากไม่จำเป็นต้องคัดลอกตัวอย่างเช่นไม่สามารถเปลี่ยนได้)
• ไม่จำเป็นต้องประกาศตัวprivateสร้างสำเนาและoperator=ทำให้คลาสไม่สามารถคัดลอกได้ หากคุณไม่ต้องการคัดลอกวัตถุของคลาสคุณเพียงแค่ไม่เขียนฟังก์ชันเพื่อคัดลอก
• ไม่จำเป็นต้องใช้swapฟังก์ชั่น (ยกเว้นว่าคุณกำลังเขียนชุดคำสั่งการเรียงลำดับ)
• ไม่จำเป็นต้องใช้สำหรับการอ้างอิงค่าของ C ++ 0x-style
• ไม่จำเป็นต้องมี (N) RVO
• ไม่มีปัญหาการตัด
• คอมไพเลอร์สามารถกำหนดโครงร่างของวัตถุได้ง่ายขึ้นเนื่องจากการอ้างอิงมีขนาดคงที่

ข้อเสียเปรียบหลักในการอ้างอิงความหมายคือเมื่อทุกวัตถุอาจมีหลายอ้างอิงถึงมันจะยากที่จะรู้เมื่อจะลบมัน คุณสวยมากมีที่จะมีการจัดการหน่วยความจำอัตโนมัติ

Java เลือกใช้ตัวรวบรวมขยะที่ไม่ได้กำหนดค่า

GC ไม่สามารถกำหนดได้หรือไม่

ใช่มันสามารถ ตัวอย่างเช่นการใช้งาน C ของPythonใช้การนับการอ้างอิง และต่อมาได้เพิ่มการติดตาม GC เพื่อจัดการกับขยะที่เป็นวงจรที่ refcounts ล้มเหลว

แต่การนับใหม่นั้นไม่มีประสิทธิภาพอย่างน่ากลัว รอบ CPU จำนวนมากที่ใช้ปรับปรุงการนับ ยิ่งแย่ลงในสภาพแวดล้อมแบบมัลติเธรด (เช่น Java ชนิดที่ถูกออกแบบมาสำหรับ) ซึ่งการอัพเดทเหล่านั้นจำเป็นต้องซิงโครไนซ์ ดีกว่ามากในการใช้ตัวเก็บขยะ nullจนกว่าคุณจะต้องเปลี่ยนไปใช้ตัวรวบรวมขยะตัวอื่น

คุณสามารถพูดได้ว่า Java เลือกที่จะเพิ่มประสิทธิภาพกรณีทั่วไป (หน่วยความจำ) ที่ค่าใช้จ่ายของทรัพยากรที่ไม่สามารถเข้ากันได้เช่นไฟล์และซ็อกเก็ต วันนี้ในแง่ของการยอมรับของ RAII ใน C ++ นี่อาจดูเหมือนเป็นทางเลือกที่ผิด แต่จำไว้ว่าผู้ชมเป้าหมายส่วนใหญ่สำหรับ Java คือโปรแกรมเมอร์ C (หรือ "C with classes") ซึ่งถูกใช้เพื่อปิดสิ่งเหล่านี้อย่างชัดเจน

แต่สิ่งที่เกี่ยวกับ C ++ / CLI "วัตถุสแต็ก"?

พวกเขากำลังเพียงน้ำตาลประโยคสำหรับDispose ( ลิงค์เดิม ) มากเช่น C using# อย่างไรก็ตามมันไม่ได้แก้ปัญหาทั่วไปของการทำลายล้างที่กำหนดขึ้นเนื่องจากคุณสามารถสร้างแบบไม่ระบุชื่อgcnew FileStream("filename.ext")และ C ++ / CLI จะไม่กำจัดมันโดยอัตโนมัติ

Java7 แนะนำสิ่งที่คล้ายกับ C # using: คำชี้แจงลองกับทรัพยากร

tryคำสั่งที่ประกาศหนึ่งหรือมากกว่าทรัพยากร ทรัพยากรเป็นวัตถุที่จะต้องปิดโปรแกรมหลังจากเสร็จสิ้นกับมัน tryคำสั่งเมื่อใช้ทรัพยากรเพื่อให้แน่ใจว่าแต่ละทรัพยากรปิดท้ายของคำสั่ง วัตถุใด ๆ ที่ใช้java.lang.AutoCloseableซึ่งรวมถึงวัตถุทั้งหมดที่ใช้งานjava.io.Closeableสามารถใช้เป็นทรัพยากร ...

ดังนั้นฉันคิดว่าพวกเขาอาจไม่เลือกที่จะไม่ใช้งาน RAII หรือเปลี่ยนใจในขณะเดียวกัน

Java จงใจไม่มีวัตถุตาม stack (aka ค่าวัตถุ -) สิ่งเหล่านี้จำเป็นต้องมีวัตถุที่ถูกทำลายโดยอัตโนมัติในตอนท้ายของวิธีการเช่นนั้น

เนื่องจากสิ่งนี้และความจริงที่ว่า Java เก็บขยะการสรุปที่กำหนดขึ้นจึงเป็นไปไม่ได้มากขึ้นหรือน้อยลง(เช่นถ้าวัตถุ "ท้องถิ่น" ของฉันถูกอ้างอิงถึงที่อื่นแล้วเมื่อวิธีการสิ้นสุดเราไม่ต้องการให้มันถูกทำลาย ) .

อย่างไรก็ตามนี่เป็นสิ่งที่ดีกับพวกเราส่วนใหญ่เพราะแทบจะไม่จำเป็นต้องมีการสรุปที่กำหนดแน่นอนยกเว้นเมื่อมีการโต้ตอบกับทรัพยากรดั้งเดิม (C ++)!

เหตุใด Java จึงไม่มีวัตถุแบบกองซ้อน

(นอกเหนือจากดั้งเดิม .. )

เนื่องจากวัตถุแบบกองซ้อนมีความหมายที่แตกต่างจากการอ้างอิงแบบกอง ลองนึกภาพโค้ดต่อไปนี้ใน C ++; มันทำอะไร?

return myObject;

• ถ้าmyObjectเป็นวัตถุที่ใช้สแต็คในท้องถิ่นตัวคัดลอกคอนสตรัคเตอร์จะถูกเรียก (ถ้าผลลัพธ์ถูกกำหนดให้กับบางสิ่ง)
• ถ้าmyObjectเป็นออบเจ็กต์ที่ใช้โลคัลและเราส่งคืนการอ้างอิงผลลัพธ์จะไม่ได้กำหนด
• ถ้าmyObjectเป็นวัตถุสมาชิก / โกลบอลตัวสร้างสำเนาจะถูกเรียก (ถ้าผลลัพธ์ถูกกำหนดให้กับบางสิ่ง)
• ถ้าmyObjectเป็นวัตถุสมาชิก / ส่วนกลางและเราส่งคืนการอ้างอิงการอ้างอิงจะถูกส่งคืน
• ถ้าmyObjectเป็นตัวชี้ไปยังวัตถุที่ใช้สแต็คท้องถิ่นผลที่ได้คือไม่ได้กำหนด
• ถ้าmyObjectเป็นตัวชี้ไปยังวัตถุสมาชิก / ทั่วโลกตัวชี้นั้นจะถูกส่งกลับ
• ถ้าmyObjectเป็นตัวชี้ไปยังวัตถุที่ใช้ฮีปตัวชี้นั้นจะถูกส่งกลับ

ตอนนี้รหัสเดียวกันทำอะไรใน Java?

return myObject;

• การอ้างอิงถึงmyObjectถูกส่งคืน ไม่สำคัญว่าตัวแปรนั้นจะเป็นแบบโลคัลสมาชิกหรือโกลบอล และไม่มีวัตถุหรือกรณีตัวชี้สแต็คที่ต้องกังวลเกี่ยวกับ

ดังกล่าวข้างต้นแสดงให้เห็นว่าทำไมวัตถุสแต็คที่ใช้เป็นเรื่องธรรมดามากเกิดข้อผิดพลาดในการเขียนโปรแกรมภาษา C ++ ด้วยเหตุนี้นักออกแบบ Java จึงนำพวกเขาออกไป และหากไม่มีพวกเขาจะไม่มีประโยชน์ในการใช้ RAII ใน Java

คำอธิบายหลุมของคุณusingไม่สมบูรณ์ พิจารณาปัญหาต่อไปนี้:

interface Bar {
    ...
}
class Foo : Bar, IDisposable {
    ...
}

Bar b = new Foo();

// Where's the Dispose?

ในความคิดของฉันการไม่มีทั้ง RAII และ GC เป็นความคิดที่ไม่ดี เมื่อมันมาถึงการปิดไฟล์ใน Java มันmalloc()และที่free()นั่น

ฉันแก่แล้ว ฉันเคยไปที่นั่นและเห็นมันและกระแทกหัวของฉันเกี่ยวกับเรื่องนี้หลายครั้ง

ฉันอยู่ที่การประชุมที่ Hursley Park ที่ซึ่งเด็ก ๆ ไอบีเอ็มบอกเราว่าภาษาจาวาใหม่นี้ยอดเยี่ยมแค่มีคนถามว่า ... ทำไมไม่มีตัวทำลายสำหรับวัตถุเหล่านี้ เขาไม่ได้หมายถึงสิ่งที่เรารู้ว่าเป็นผู้ทำลายล้างใน C ++ แต่ก็ไม่มีผู้เข้ารอบสุดท้าย (หรือมีผู้เข้ารอบสุดท้าย แต่โดยทั่วไปแล้วพวกเขาไม่ได้ทำงาน) นี่คือวิธีย้อนกลับไปและเราตัดสินใจว่า Java เป็นภาษาของเล่นสักหน่อย ณ จุดนั้น

ตอนนี้พวกเขาเพิ่ม Finalisers ให้กับสเป็คภาษา

แน่นอนว่าต่อมาทุกคนได้รับคำสั่งไม่ให้นำผู้เข้ารอบสุดท้ายเข้ามาในวัตถุเพราะมันทำให้ GC ช้าลงอย่างมาก (เนื่องจากไม่เพียง แต่ต้องล็อคฮีป แต่ย้ายวัตถุที่จะเสร็จสิ้นไปยังพื้นที่ชั่วคราวเนื่องจากวิธีการเหล่านี้ไม่สามารถเรียกได้ว่า GC ได้หยุดแอปชั่วคราวจากการทำงาน แต่จะเรียกทันทีก่อนหน้าถัดไป รอบ GC) (และที่แย่กว่านั้นบางครั้งผู้เข้ารอบจะไม่ถูกเรียกเลยเมื่อแอปปิดตัวลงลองนึกภาพว่าคุณไม่ได้ปิดการจัดการไฟล์เลย)

จากนั้นเรามี C # และฉันจำฟอรัมสนทนาใน MSDN ที่เราบอกว่าภาษา C # ใหม่นี้วิเศษเพียงใด มีคนถามว่าทำไมไม่มีการสรุปที่แน่นอนและเด็กชาย MS บอกเราว่าเราไม่ต้องการสิ่งนั้นแล้วบอกเราว่าเราต้องเปลี่ยนวิธีการออกแบบแอพของเราแล้วบอกเราว่า GC น่าทึ่งแค่ไหนและแอปเก่าทั้งหมดของเราเป็นอย่างไร ขยะและไม่เคยทำงานเพราะการอ้างอิงแบบวงกลมทั้งหมด จากนั้นพวกเขายุบตัวลงเพื่อกดดันและบอกกับเราว่าพวกเขาได้เพิ่มรูปแบบ IDispose นี้ให้กับสเป็คที่เราสามารถใช้ได้ ฉันคิดว่ามันค่อนข้างกลับไปสู่การจัดการหน่วยความจำด้วยตนเองสำหรับเราในแอป C # ณ จุดนั้น

แน่นอนเด็กชาย MS ค้นพบในภายหลังว่าสิ่งที่พวกเขาบอกกับเราคือ ... พวกเขาทำให้ IDispose มากกว่าอินเทอร์เฟซมาตรฐานและเพิ่มคำสั่งการใช้ในภายหลัง w00t! พวกเขาตระหนักดีว่าการกำหนดขั้นสุดท้ายแบบกำหนดแน่นอนนั้นเป็นสิ่งที่ขาดหายไปจากภาษา แน่นอนคุณยังต้องจำไว้ว่าให้ใส่มันทุกที่ดังนั้นมันยังคงเป็นคู่มือเล็กน้อย แต่จะดีกว่า

แล้วทำไมพวกเขาถึงทำเมื่อพวกเขาสามารถใช้ซีแมนทิกส์สไตล์ที่ใช้ในแต่ละช่วงบล็อกตั้งแต่เริ่มต้น อาจมีประสิทธิภาพ แต่ฉันชอบที่จะคิดว่าพวกเขาไม่ได้ตระหนักถึง เช่นเดียวกับในที่สุดพวกเขาก็ตระหนักว่าคุณยังคงต้องการตัวชี้อัจฉริยะใน. NET (google SafeHandle) พวกเขาคิดว่า GC จะแก้ปัญหาทั้งหมดได้จริง พวกเขาลืมว่าวัตถุเป็นมากกว่าหน่วยความจำและ GC นั้นถูกออกแบบมาเพื่อจัดการกับหน่วยความจำเป็นหลัก พวกเขาสับสนกับแนวคิดที่ว่า GC จะจัดการเรื่องนี้และลืมว่าคุณใส่สิ่งอื่นเข้าไปในนั้นวัตถุไม่ได้เป็นเพียงแค่หน่วยความจำที่ไม่สำคัญถ้าคุณไม่ลบออกไปซักพัก

แต่ฉันก็คิดว่าการขาดวิธีการสุดท้ายใน Java ดั้งเดิมนั้นมีมากกว่านั้น - วัตถุที่คุณสร้างล้วนเกี่ยวกับความทรงจำและถ้าคุณต้องการลบอย่างอื่น (เช่นตัวจัดการ DB หรือซ็อกเก็ตหรืออะไรก็ตาม) ) แล้วคุณคาดว่าจะทำด้วยตนเอง

จำไว้ว่า Java ถูกออกแบบมาสำหรับสภาพแวดล้อมแบบฝังตัวที่ผู้คนเคยเขียนโค้ด C พร้อมกับการจัดสรรด้วยตนเองจำนวนมากดังนั้นการไม่มีระบบอัตโนมัติฟรีจึงไม่เป็นปัญหามากนัก - พวกเขาไม่เคยทำมาก่อนดังนั้นทำไมคุณต้องใช้ Java? ปัญหาไม่ได้เกี่ยวอะไรกับเธรดหรือสแต็ค / ฮีปอาจเป็นเพียงแค่การจัดสรรหน่วยความจำ โดยรวมแล้วคำสั่งลอง / สุดท้ายน่าจะเป็นสถานที่ที่ดีกว่าในการจัดการทรัพยากรที่ไม่ใช่หน่วยความจำ

ดังนั้น IMHO วิธีที่. NET คัดลอกข้อบกพร่องที่ใหญ่ที่สุดของ Java ก็คือจุดอ่อนที่ยิ่งใหญ่ที่สุด .NET ควรเป็น C ++ ที่ดีกว่าไม่ใช่ Java ที่ดีกว่า

Bruce Eckel ผู้แต่ง "Thinking in Java" และ "Thinking in C ++" และสมาชิกของคณะกรรมการมาตรฐาน C ++ มีความเห็นว่าในหลาย ๆ พื้นที่ (ไม่ใช่แค่ RAII) Gosling และทีม Java ไม่ได้ทำสิ่งเหล่านี้ การบ้าน.

... เพื่อให้เข้าใจว่าภาษานั้นมีทั้งที่ไม่พึงประสงค์และซับซ้อนได้อย่างไรและได้รับการออกแบบมาอย่างดีในเวลาเดียวกันคุณต้องคำนึงถึงการตัดสินใจออกแบบเบื้องต้นที่ทุกอย่างในภาษา C ++ จะแขวน: เข้ากันได้กับ C. Stroustrup ตัดสินใจ - และถูกต้อง มันจะปรากฏขึ้น - วิธีที่จะทำให้มวลของโปรแกรมเมอร์ C ย้ายไปที่วัตถุคือทำให้การย้ายโปร่งใส: เพื่อให้พวกเขารวบรวมรหัส C ของพวกเขาไม่เปลี่ยนแปลงภายใต้ C ++ นี่เป็นข้อ จำกัด อย่างมากและเป็นจุดแข็งที่สุดของ C ++ เสมอ ... และความหายนะ มันคือสิ่งที่ทำให้ C ++ ประสบความสำเร็จอย่างที่เคยเป็นมาและมีความซับซ้อนอย่างที่เป็นอยู่

นอกจากนี้ยังหลอกนักออกแบบ Java ที่ไม่เข้าใจ C ++ ดีพอ ตัวอย่างเช่นพวกเขาคิดว่าการใช้งานเกินกำลังนั้นยากเกินกว่าที่โปรแกรมเมอร์จะใช้อย่างถูกต้อง ซึ่งโดยทั่วไปแล้วเป็นจริงใน C ++ เนื่องจาก C ++ มีทั้งการจัดสรรสแต็กและการจัดสรรฮีปและคุณต้องโอเวอร์โหลดโอเปอเรเตอร์ของคุณเพื่อจัดการกับทุกสถานการณ์และไม่ทำให้หน่วยความจำรั่ว ยากแน่นอน อย่างไรก็ตาม Java มีกลไกการจัดสรรหน่วยเก็บข้อมูลเดียวและตัวรวบรวมขยะซึ่งทำให้ผู้ปฏิบัติงานโอเวอร์โหลดเล็กน้อย - ดังที่แสดงใน C # (แต่ได้ถูกแสดงใน Python ซึ่งมี Java ไว้ล่วงหน้าแล้ว) แต่หลายปีที่ผ่านมาสายงานบางส่วนจากทีมจาวาคือ "การใช้งานมากเกินไปซับซ้อนเกินไป" การตัดสินใจนี้และอื่น ๆ อีกมากมายที่ใครบางคนไม่ได้ทำอย่างชัดเจน '

มีตัวอย่างอื่นอีกมากมาย ต้องมีการรวมเอาไว้ด้วยเพื่อให้ได้ประสิทธิภาพ คำตอบที่ถูกต้องคือการยึดมั่นกับ "ทุกอย่างเป็นวัตถุ" และจัดทำประตูดักเพื่อทำกิจกรรมระดับล่างเมื่อต้องการประสิทธิภาพ (สิ่งนี้จะช่วยให้เทคโนโลยีฮอตสปอตสามารถทำให้สิ่งต่าง ๆ มีประสิทธิภาพมากขึ้น มี). โอ้และความจริงที่ว่าคุณไม่สามารถใช้ตัวประมวลผลเลขทศนิยมได้โดยตรงเพื่อคำนวณฟังก์ชันยอดเยี่ยม (มันทำในซอฟต์แวร์แทน) ฉันเขียนเกี่ยวกับปัญหาเช่นนี้ให้มากที่สุดเท่าที่จะทำได้และคำตอบที่ฉันได้ยินมักจะเป็นการตอบโต้ที่ซ้ำซากกับผลกระทบที่ว่า "นี่คือวิธีของจาวา"

เมื่อฉันเขียนเกี่ยวกับวิธีการออกแบบ generics ที่ไม่ดีฉันได้รับคำตอบเดียวกันพร้อมกับ "เราต้องย้อนกลับเข้ากันได้กับการตัดสินใจก่อนหน้านี้ (ไม่ดี) ใน Java" เมื่อเร็ว ๆ นี้ผู้คนจำนวนมากขึ้นได้รับประสบการณ์มากพอกับ Generics เพื่อดูว่าพวกเขาใช้งานยากจริง ๆ - จริง ๆ แล้วเทมเพลต C ++ นั้นมีประสิทธิภาพและสอดคล้องกันมากขึ้น (และใช้งานง่ายกว่ามาก ผู้คนยังคงให้ความสำคัญอย่างจริงจัง - สิ่งที่จะเป็นประโยชน์ แต่จะไม่ทำให้คนส่วนใหญ่ตกอยู่ในการออกแบบที่พิการด้วยข้อ จำกัด ที่บังคับด้วยตนเอง

รายการไปยังจุดที่น่าเบื่อเพียง ...

เหตุผลที่ดีที่สุดนั้นง่ายกว่าคำตอบส่วนใหญ่ที่นี่

คุณไม่สามารถส่งวัตถุที่จัดสรรสแต็กไปยังเธรดอื่นได้

หยุดและคิดเกี่ยวกับสิ่งนั้น คิดอยู่เสมอ .... ตอนนี้ C ++ ไม่มีหัวข้อเมื่อทุกคนมีความกระตือรือร้นใน RAII แม้แต่ Erlang (ฮีปแยกกันต่อเธรด) ก็ยังไม่ดีเมื่อคุณผ่านวัตถุมากเกินไป C ++ มีรูปแบบหน่วยความจำใน C ++ 2011 เท่านั้น ตอนนี้คุณเกือบจะสามารถมีเหตุผลเกี่ยวกับการเกิดพร้อมกันใน C ++ โดยไม่ต้องอ้างถึง "เอกสาร" ของคอมไพเลอร์ของคุณ

Java ได้รับการออกแบบจาก (เกือบ) วันที่หนึ่งสำหรับหลายกระทู้

ฉันยังได้รับสำเนาของ "ภาษาการเขียนโปรแกรม C ++" ที่ Stroustrup ยืนยันกับฉันว่าฉันไม่ต้องการเธรด

เหตุผลที่เจ็บปวดที่สองคือการหลีกเลี่ยงการแบ่ง

ใน C ++ คุณใช้คุณสมบัติภาษาระดับล่างและวัตถุประสงค์ทั่วไป (destructors ที่เรียกโดยอัตโนมัติบนสแต็กออบเจ็กต์) เพื่อนำไปใช้ระดับสูงกว่า (RAII) และวิธีนี้เป็นสิ่งที่ C # / Java folks ดูเหมือนจะไม่เป็น รักเกินไป พวกเขาต้องการออกแบบเครื่องมือระดับสูงเฉพาะสำหรับความต้องการเฉพาะและมอบให้โปรแกรมเมอร์ที่สร้างขึ้นเป็นภาษา ปัญหาเกี่ยวกับเครื่องมือเฉพาะเหล่านี้คือพวกเขาไม่สามารถปรับแต่งได้ (ส่วนหนึ่งเป็นสิ่งที่ทำให้พวกเขาเรียนรู้ได้ง่าย) เมื่อสร้างจากบล็อกขนาดเล็กการแก้ปัญหาที่ดีกว่าอาจมาพร้อมกับเวลาในขณะที่ถ้าคุณมีสิ่งก่อสร้างในระดับสูงเท่านั้นมันมีโอกาสน้อยกว่า

ดังนั้นใช่ฉันคิดว่า (ฉันไม่ได้อยู่ที่นั่นจริงๆ ... ) มันเป็นการตัดสินใจที่รัดกุมโดยมีเป้าหมายในการทำให้ภาษาง่ายต่อการหยิบ แต่ในความคิดของฉันมันเป็นการตัดสินใจที่ไม่ดี จากนั้นอีกครั้งฉันมักชอบปรัชญา C ++ ที่ให้โอกาสโปรแกรมเมอร์ที่จะม้วนตัวเองดังนั้นฉันจึงค่อนข้างเอนเอียง

คุณเรียกค่าคร่าวๆที่เทียบเท่ากับค่านี้ใน C # ด้วยDisposeวิธีการ Java finalizeนอกจากนี้ยังมี หมายเหตุ: ฉันตระหนักว่าการสรุปสุดท้ายของ Java นั้นไม่ได้กำหนดและแตกต่างจากDisposeฉันกำลังชี้ให้เห็นว่าพวกเขาทั้งสองมีวิธีการทำความสะอาดทรัพยากรควบคู่ไปกับ GC

ถ้าสิ่งใดกลายเป็นความเจ็บปวดมากกว่าเพราะวัตถุต้องถูกทำลายทางร่างกาย ในภาษาระดับสูงกว่าเช่น C # และ Java เราขึ้นอยู่กับตัวรวบรวมขยะเพื่อล้างข้อมูลเมื่อไม่มีการอ้างอิงอีกต่อไป ไม่มีการรับประกันดังกล่าวว่าวัตถุ DBConnection ใน C ++ ไม่ได้มีการอ้างอิงหลอกลวงหรือตัวชี้ไปที่มัน

ใช่โค้ด C ++ สามารถอ่านได้ง่ายขึ้น แต่อาจเป็นฝันร้ายในการดีบักเนื่องจากขอบเขตและข้อ จำกัด ที่ภาษาเช่น Java วางกฎไว้เพื่อกำจัดข้อผิดพลาดที่รุนแรงขึ้นและยากขึ้นรวมถึงป้องกันนักพัฒนามือใหม่จากข้อผิดพลาดทั่วไปทั่วไป

บางทีมันอาจเป็นเพราะความชอบบางอย่างเช่นพลังงานระดับต่ำ, การควบคุมและความบริสุทธิ์ของ C ++ ที่คนอื่นอย่างฉันชอบภาษาแซนด์บ็อกซ์มากกว่าที่ชัดเจนกว่า