Là một lập trình viên C # lâu năm, gần đây tôi đã đến để tìm hiểu thêm về những lợi thế của việc mua lại tài nguyên (RAII). Cụ thể, tôi đã phát hiện ra rằng thành ngữ C #:

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

có tương đương C ++:

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

có nghĩa là việc nhớ kèm theo việc sử dụng các tài nguyên như DbConnectiontrong một usingkhối là không cần thiết trong C ++! Đây dường như là một lợi thế lớn của C ++. Điều này thậm chí còn thuyết phục hơn khi bạn xem xét một lớp có một thành viên thể hiện của loại DbConnection, ví dụ

class Foo {
    DbConnection dbConn;

    // ...
}

Trong C # tôi sẽ cần phải thực hiện Foo IDisposablenhư sau:

class Foo : IDisposable {
    DbConnection dbConn;

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

và điều tồi tệ hơn, mọi người dùng Foosẽ cần phải nhớ gửi kèm theo Foomột usingkhối, như:

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

Bây giờ nhìn vào C # và nguồn gốc Java của nó, tôi tự hỏi ... các nhà phát triển của Java có hoàn toàn đánh giá cao những gì họ đã từ bỏ khi họ từ bỏ ngăn xếp có lợi cho đống, do đó từ bỏ RAII không?

(Tương tự, Stroustrup có đánh giá đầy đủ ý nghĩa của RAII không?)

Bây giờ nhìn vào C # và nguồn gốc Java của nó, tôi tự hỏi ... các nhà phát triển của Java có hoàn toàn đánh giá cao những gì họ đã từ bỏ khi họ từ bỏ ngăn xếp có lợi cho đống, do đó từ bỏ RAII không?

(Tương tự, Stroustrup có đánh giá đầy đủ ý nghĩa của RAII không?)

Tôi khá chắc chắn rằng Gosling đã không nhận được tầm quan trọng của RAII tại thời điểm anh ta thiết kế Java. Trong các cuộc phỏng vấn của mình, ông thường nói về những lý do để loại bỏ thuốc generic và quá tải toán tử, nhưng không bao giờ đề cập đến các hàm hủy xác định và RAII.

Hài hước lắm, ngay cả Stroustrup cũng không nhận thức được tầm quan trọng của những kẻ hủy diệt xác định tại thời điểm ông thiết kế chúng. Tôi không thể tìm thấy trích dẫn, nhưng nếu bạn thực sự thích nó, bạn có thể tìm thấy nó trong số các cuộc phỏng vấn của anh ấy ở đây: http://www.stroustrup.com/interviews.html

Có, các nhà thiết kế của C # (và, tôi chắc chắn, Java) đã quyết định cụ thể chống lại quyết toán quyết định. Tôi đã hỏi Anders Hejlsberg về điều này nhiều lần vào khoảng năm 1999-2002.

Đầu tiên, ý tưởng về ngữ nghĩa khác nhau cho một đối tượng dựa trên việc dựa trên ngăn xếp hay đống của nó chắc chắn phản lại mục tiêu thiết kế thống nhất của cả hai ngôn ngữ, nhằm giải quyết các lập trình viên về các vấn đề chính xác như vậy.

Thứ hai, ngay cả khi bạn thừa nhận rằng có những lợi thế, có những phức tạp triển khai và sự thiếu hiệu quả đáng kể liên quan đến việc giữ sổ sách. Bạn thực sự không thể đặt các đối tượng giống như ngăn xếp lên ngăn xếp bằng ngôn ngữ được quản lý. Bạn chỉ còn cách nói "ngữ nghĩa giống như ngăn xếp" và cam kết thực hiện công việc quan trọng (các loại giá trị đã đủ khó, hãy nghĩ về một đối tượng là một thể hiện của một lớp phức tạp, với các tham chiếu đến và quay trở lại vào bộ nhớ được quản lý).

Do đó, bạn không muốn hoàn thiện xác định trên mọi đối tượng trong một hệ thống lập trình trong đó "(hầu hết) mọi thứ là một đối tượng". Vì vậy, bạn đừng có để giới thiệu một số loại cú pháp lập trình điều khiển để tách một đối tượng thường-theo dõi từ một trong đó có quyết toán xác định.

Trong C #, bạn có usingtừ khóa, xuất hiện khá muộn trong thiết kế của cái đã trở thành C # 1.0. Toàn bộ IDisposableđiều này khá tồi tệ, và người ta tự hỏi liệu nó có thanh lịch hơn khi usinglàm việc với cú pháp hàm hủy C ++ ~đánh dấu các lớp mà IDisposablemô hình tấm nồi hơi có thể được áp dụng tự động không?

Hãy nhớ rằng Java đã được phát triển vào năm 1991-1995 khi C ++ là một ngôn ngữ khác. Các ngoại lệ (khiến RAII trở nên cần thiết ) và các mẫu (giúp dễ dàng thực hiện các con trỏ thông minh hơn) là các tính năng "mới mẻ". Hầu hết các lập trình viên C ++ đã đến từ C và đã quen với việc quản lý bộ nhớ thủ công.

Vì vậy, tôi nghi ngờ rằng các nhà phát triển của Java đã cố tình quyết định từ bỏ RAII. Tuy nhiên, đó là một quyết định có chủ ý cho Java để thích ngữ nghĩa tham chiếu thay vì ngữ nghĩa giá trị. Phá hủy xác định là khó thực hiện trong một ngôn ngữ ngữ nghĩa tham khảo.

Vậy tại sao sử dụng ngữ nghĩa tham khảo thay vì ngữ nghĩa giá trị?

Bởi vì nó làm cho ngôn ngữ đơn giản hơn rất nhiều .

• Không cần phân biệt cú pháp giữa Foovà Foo*hoặc giữa foo.barvà foo->bar.
• Không cần gán quá tải, khi tất cả các nhiệm vụ thực hiện là sao chép một con trỏ.
• Không cần cho các nhà xây dựng sao chép. ( Đôi khi cần một chức năng sao chép rõ ràng như clone(). Nhiều đối tượng không cần phải sao chép. Ví dụ: bất biến không.)
• Không cần phải khai báo các hàm tạo privatesao chép và operator=làm cho một lớp không thể sao chép được . Nếu bạn không muốn các đối tượng của một lớp được sao chép, bạn chỉ không viết một hàm để sao chép nó.
• Không cần cho các swapchức năng. (Trừ khi bạn đang viết một thói quen sắp xếp.)
• Không cần tham khảo giá trị kiểu C ++ 0x.
• Không cần cho (N) RVO.
• Không có vấn đề cắt lát.
• Trình biên dịch xác định bố cục đối tượng dễ dàng hơn vì các tham chiếu có kích thước cố định.

Nhược điểm chính của ngữ nghĩa tham chiếu là khi mọi đối tượng có khả năng có nhiều tham chiếu đến nó, sẽ khó biết khi nào nên xóa nó. Bạn khá nhiều phải có quản lý bộ nhớ tự động.

Java đã chọn sử dụng một trình thu gom rác không xác định.

Không thể xác định được GC?

Vâng, nó có thể. Ví dụ, việc triển khai C của Python sử dụng tính tham chiếu. Và sau đó đã thêm dấu vết GC để xử lý rác theo chu kỳ trong đó việc đếm không thành công.

Nhưng việc đếm tiền là không hiệu quả khủng khiếp. Rất nhiều chu kỳ CPU dành để cập nhật số lượng. Thậm chí tệ hơn trong môi trường đa luồng (như loại Java được thiết kế cho) nơi các bản cập nhật đó cần được đồng bộ hóa. Tốt hơn nhiều để sử dụng trình thu gom rác null cho đến khi bạn cần chuyển sang một trình thu thập khác.

Bạn có thể nói rằng Java đã chọn tối ưu hóa trường hợp phổ biến (bộ nhớ) với chi phí cho các tài nguyên không bị nhiễm nấm như các tệp và ổ cắm. Ngày nay, trong bối cảnh việc áp dụng RAII trong C ++, điều này có vẻ như là sự lựa chọn sai lầm. Nhưng hãy nhớ rằng phần lớn đối tượng mục tiêu cho Java là các lập trình viên C (hoặc "C với các lớp"), những người đã quen với việc đóng những thứ này một cách rõ ràng.

Nhưng những gì về "đối tượng ngăn xếp" C ++ / CLI?

Chúng chỉ là đường cú pháp choDispose ( liên kết ban đầu ), giống như C # using. Tuy nhiên, nó không giải quyết được vấn đề chung về phá hủy xác định, bởi vì bạn có thể tạo một ẩn danh gcnew FileStream("filename.ext")và C ++ / CLI sẽ không tự động Loại bỏ nó.

Java7 đã giới thiệu một cái gì đó tương tự như C # using: Tuyên bố thử tài nguyên

một trytuyên bố tuyên bố một hoặc nhiều tài nguyên. Một tài nguyên là một đối tượng phải được đóng lại sau khi chương trình kết thúc với nó. Câu lệnh try-with-resource đảm bảo rằng mỗi tài nguyên được đóng ở cuối câu lệnh. Bất kỳ đối tượng nào thực hiện java.lang.AutoCloseable, bao gồm tất cả các đối tượng triển khai java.io.Closeable, có thể được sử dụng làm tài nguyên ...

Vì vậy, tôi đoán rằng họ đã không chủ ý chọn không thực hiện RAII hoặc họ đã thay đổi ý định trong khi đó.

Java cố ý không có các đối tượng dựa trên ngăn xếp (còn gọi là các đối tượng giá trị). Đây là những điều cần thiết để có đối tượng tự động hủy ở cuối phương thức như thế.

Bởi vì điều này và thực tế là Java được thu gom rác, việc hoàn thiện xác định ít nhiều không thể xảy ra (ví dụ: Nếu đối tượng "cục bộ" của tôi trở thành tham chiếu ở nơi nào khác thì sao? ) .

Tuy nhiên, điều này tốt với hầu hết chúng ta, bởi vì hầu như không bao giờ cần phải hoàn thiện xác định, ngoại trừ khi tương tác với tài nguyên bản địa (C ++)!

Tại sao Java không có các đối tượng dựa trên ngăn xếp?

(Khác với nguyên thủy ..)

Bởi vì các đối tượng dựa trên ngăn xếp có ngữ nghĩa khác với các tham chiếu dựa trên heap. Hãy tưởng tượng đoạn mã sau trong C ++; nó làm gì?

return myObject;

• Nếu myObjectlà một đối tượng dựa trên ngăn xếp cục bộ, hàm tạo sao chép được gọi (nếu kết quả được gán cho một cái gì đó).
• Nếu myObjectlà một đối tượng dựa trên ngăn xếp cục bộ và chúng tôi đang trả về một tham chiếu, kết quả không được xác định.
• Nếu myObjectlà một thành viên / đối tượng toàn cầu, hàm tạo sao chép được gọi (nếu kết quả được gán cho một cái gì đó).
• Nếu myObjectlà một thành viên / đối tượng toàn cầu và chúng tôi đang trả lại một tham chiếu, thì tham chiếu được trả về.
• Nếu myObjectlà một con trỏ tới một đối tượng dựa trên ngăn xếp cục bộ, kết quả không được xác định.
• Nếu myObjectlà một con trỏ tới một đối tượng thành viên / toàn cầu, con trỏ đó được trả về.
• Nếu myObjectlà một con trỏ tới một đối tượng dựa trên heap, con trỏ đó được trả về.

Bây giờ mã tương tự làm gì trong Java?

return myObject;

• Các tài liệu tham khảo myObjectđược trả lại. Không thành vấn đề nếu biến là cục bộ, thành viên hoặc toàn cầu; và không có đối tượng dựa trên ngăn xếp hoặc trường hợp con trỏ phải lo lắng.

Những điều trên cho thấy tại sao các đối tượng dựa trên ngăn xếp là nguyên nhân rất phổ biến gây ra lỗi lập trình trong C ++. Do đó, các nhà thiết kế Java đã đưa họ ra ngoài; và không có chúng, không có điểm nào trong việc sử dụng RAII trong Java.

Mô tả của bạn về các lỗ của usingkhông đầy đủ. Hãy xem xét vấn đề sau:

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

Bar b = new Foo();

// Where's the Dispose?

Theo tôi, không có cả RAII và GC là một ý tưởng tồi. Khi nói đến việc đóng các tệp trong Java, nó malloc()và free()ở đằng kia.

Tôi khá già Tôi đã ở đó và nhìn thấy nó và đập đầu tôi về nó nhiều lần.

Tôi đã có mặt tại một hội nghị ở Công viên Hursley nơi các chàng trai IBM đang nói với chúng tôi rằng ngôn ngữ Java hoàn toàn mới này tuyệt vời như thế nào, chỉ có ai đó hỏi ... tại sao không có kẻ hủy diệt cho các đối tượng này. Anh ta không có nghĩa là thứ mà chúng ta biết là kẻ hủy diệt trong C ++, nhưng cũng không có người quyết định (hoặc nó có người hoàn thiện nhưng về cơ bản họ không hoạt động). Đây là cách quay trở lại và chúng tôi quyết định Java là một chút ngôn ngữ đồ chơi vào thời điểm đó.

bây giờ họ đã thêm Người quyết định vào đặc tả ngôn ngữ và Java đã thấy một số thông qua.

Tất nhiên, sau đó mọi người được khuyên không nên đưa những người vào chung kết vào đối tượng của họ vì điều đó làm chậm quá trình GC xuống rất nhiều. (vì nó không chỉ khóa heap mà còn di chuyển các đối tượng sắp hoàn thành sang khu vực tạm thời, vì các phương thức này không thể được gọi vì GC đã tạm dừng ứng dụng chạy. Thay vào đó, chúng sẽ được gọi ngay trước khi tiếp theo Chu trình GC) (và tệ hơn, đôi khi trình hoàn thiện sẽ không bao giờ được gọi khi ứng dụng ngừng hoạt động. Hãy tưởng tượng không có tệp xử lý của bạn đóng, bao giờ)

Sau đó, chúng tôi đã có C #, và tôi nhớ diễn đàn thảo luận về MSDN nơi chúng tôi được cho biết ngôn ngữ C # mới này tuyệt vời như thế nào. Có người hỏi tại sao không có quyết toán quyết định và các chàng trai MS nói với chúng tôi rằng chúng tôi không cần những thứ như thế nào, sau đó nói với chúng tôi rằng chúng tôi cần thay đổi cách thiết kế ứng dụng, sau đó cho chúng tôi biết GC tuyệt vời như thế nào và tất cả các ứng dụng cũ của chúng tôi như thế nào rác và không bao giờ làm việc vì tất cả các tài liệu tham khảo thông tư. Sau đó, họ trích dẫn để gây áp lực và nói với chúng tôi rằng họ đã thêm mẫu IDispose này vào thông số kỹ thuật mà chúng tôi có thể sử dụng. Tôi nghĩ rằng đó là khá nhiều trở lại để quản lý bộ nhớ thủ công cho chúng tôi trong các ứng dụng C # tại thời điểm đó.

Tất nhiên, các chàng trai MS sau đó phát hiện ra rằng tất cả những gì họ đã nói với chúng tôi là ... tốt, họ đã tạo ra IDispose nhiều hơn một chút so với chỉ một giao diện tiêu chuẩn và sau đó thêm vào câu lệnh sử dụng. W00t! Rốt cuộc, họ nhận ra rằng quyết toán cuối cùng là thứ gì đó còn thiếu từ ngôn ngữ. Tất nhiên, bạn vẫn phải nhớ đặt nó ở mọi nơi, vì vậy nó vẫn hơi thủ công, nhưng tốt hơn.

Vậy tại sao họ lại làm điều đó khi họ có thể có ngữ nghĩa sử dụng kiểu tự động được đặt trên mỗi khối phạm vi ngay từ đầu? Có lẽ là hiệu quả, nhưng tôi muốn nghĩ rằng họ chỉ không nhận ra. Giống như cuối cùng họ nhận ra bạn vẫn cần con trỏ thông minh trong .NET (google SafeHandle), họ nghĩ rằng GC thực sự sẽ giải quyết tất cả các vấn đề. Họ quên rằng một đối tượng không chỉ là bộ nhớ và mà GC được thiết kế chủ yếu để xử lý việc quản lý bộ nhớ. họ bị cuốn vào ý tưởng rằng GC sẽ xử lý việc này và quên rằng bạn đặt những thứ khác vào đó, một đối tượng không chỉ là một đốm bộ nhớ không thành vấn đề nếu bạn không xóa nó trong một thời gian.

Nhưng tôi cũng nghĩ rằng việc thiếu một phương thức hoàn thiện trong Java ban đầu có nhiều hơn một chút - rằng các đối tượng bạn tạo ra đều là về bộ nhớ và nếu bạn muốn xóa một cái gì đó khác (như tay cầm DB hoặc ổ cắm hoặc bất cứ thứ gì ) sau đó bạn đã được dự kiến ​​sẽ làm điều đó bằng tay .

Hãy nhớ rằng Java được thiết kế cho các môi trường nhúng, nơi mọi người đã quen viết mã C với nhiều phân bổ thủ công, vì vậy việc không có tự động miễn phí không phải là vấn đề - họ chưa bao giờ làm điều đó trước đây, vậy tại sao bạn lại cần nó trong Java? Vấn đề không liên quan gì đến các chủ đề, hoặc stack / heap, có lẽ nó chỉ ở đó để phân bổ bộ nhớ (và do đó phân bổ lại) dễ dàng hơn một chút. Trong tất cả, câu lệnh try / cuối cùng có lẽ là một nơi tốt hơn để xử lý các tài nguyên không có bộ nhớ.

Vì vậy, IMHO, cách .NET đơn giản sao chép lỗ hổng lớn nhất của Java là điểm yếu lớn nhất của nó. .NET nên là một C ++ tốt hơn, không phải là một Java tốt hơn.

Bruce Eckel, tác giả của "Thinking in Java" và "Thinking in C ++" và là thành viên của Ủy ban Tiêu chuẩn C ++, cho rằng, trong nhiều lĩnh vực (không chỉ RAII), Gosling và nhóm Java đã không làm bài tập về nhà.

... Để hiểu làm thế nào ngôn ngữ có thể vừa khó chịu vừa phức tạp, đồng thời được thiết kế tốt, bạn phải ghi nhớ quyết định thiết kế chính mà mọi thứ trong C ++ đều treo: khả năng tương thích với C. Stroustrup đã quyết định - và đúng như vậy , nó sẽ xuất hiện - rằng cách để khiến cho khối lượng lập trình viên C di chuyển đến các đối tượng là làm cho việc di chuyển trở nên trong suốt: cho phép họ biên dịch mã C của họ không thay đổi trong C ++. Đây là một hạn chế rất lớn và luôn là thế mạnh lớn nhất của C ++ ... và là nguyên nhân chính của nó. Đó là những gì làm cho C ++ thành công như nó vốn có, và phức tạp như nó vốn có.

Nó cũng đánh lừa các nhà thiết kế Java, những người không hiểu rõ về C ++. Ví dụ, họ nghĩ rằng quá tải toán tử là quá khó để lập trình viên sử dụng đúng cách. Điều này về cơ bản là đúng trong C ++, vì C ++ có cả phân bổ ngăn xếp và phân bổ heap và bạn phải quá tải các toán tử của mình để xử lý tất cả các tình huống và không gây rò rỉ bộ nhớ. Khó thực sự. Tuy nhiên, Java có một cơ chế phân bổ lưu trữ duy nhất và trình thu gom rác, khiến cho toán tử quá tải tầm thường - như đã được trình bày trong C # (nhưng đã được hiển thị trong Python, trước Java). Nhưng trong nhiều năm, dòng một phần từ nhóm Java là "Quá tải toán tử quá phức tạp". Điều này và nhiều quyết định khác mà một người rõ ràng đã không '

Có rất nhiều ví dụ khác. Nguyên thủy "phải được đưa vào cho hiệu quả." Câu trả lời đúng là giữ đúng với "mọi thứ là một đối tượng" và cung cấp một cánh cửa bẫy để thực hiện các hoạt động cấp thấp hơn khi cần hiệu quả (điều này cũng sẽ cho phép các công nghệ hotspot làm cho mọi thứ hiệu quả hơn, vì cuối cùng chúng sẽ có). Ồ, và thực tế là bạn không thể sử dụng trực tiếp bộ xử lý dấu phẩy động để tính toán các hàm siêu việt (thay vào đó nó được thực hiện trong phần mềm). Tôi đã viết về những vấn đề như thế này nhiều nhất có thể, và câu trả lời tôi nghe được luôn là một câu trả lời mang tính chất taut cho hiệu ứng "đây là cách Java".

Khi tôi viết về việc các tướng được thiết kế tệ đến mức nào, tôi cũng nhận được phản hồi tương tự, cùng với "chúng ta phải tương thích ngược với các quyết định (xấu) trước đây được đưa ra trong Java". Gần đây ngày càng có nhiều người có đủ kinh nghiệm với Generics để thấy rằng chúng thực sự rất khó sử dụng - thực sự, các mẫu C ++ mạnh mẽ và nhất quán hơn nhiều (và giờ đây dễ sử dụng hơn khi các thông báo lỗi trình biên dịch có thể chấp nhận được). Mọi người thậm chí đã thực hiện việc thống nhất một cách nghiêm túc - điều gì đó sẽ hữu ích nhưng sẽ không đặt nhiều vấn đề vào một thiết kế bị tê liệt bởi những ràng buộc tự áp đặt.

Danh sách đi đến điểm thật tẻ nhạt ...

Lý do tốt nhất là đơn giản hơn nhiều so với hầu hết các câu trả lời ở đây.

Bạn không thể chuyển các đối tượng được phân bổ ngăn xếp cho các chủ đề khác.

Dừng lại và suy nghĩ về điều đó. Hãy tiếp tục suy nghĩ .... Bây giờ C ++ không có chủ đề khi mọi người rất quan tâm đến RAII. Ngay cả Erlang (heaps riêng cho mỗi luồng) cũng bị lỗi khi bạn vượt qua quá nhiều đối tượng xung quanh. C ++ chỉ có một mô hình bộ nhớ trong C ++ 2011; bây giờ bạn gần như có thể suy luận về sự tương tranh trong C ++ mà không cần phải tham khảo "tài liệu" của nhà biên dịch.

Java được thiết kế từ (gần như) ngày một cho nhiều luồng.

Tôi vẫn còn có bản sao cũ của "Ngôn ngữ lập trình C ++" nơi Stroustrup đảm bảo với tôi rằng tôi sẽ không cần các chủ đề.

Lý do đau đớn thứ hai là để tránh cắt lát.

Trong C ++, bạn sử dụng các tính năng ngôn ngữ cấp thấp hơn, đa mục đích hơn (các hàm hủy tự động được gọi trên các đối tượng dựa trên ngăn xếp) để triển khai một cấp độ cao hơn (RAII) và cách tiếp cận này là thứ mà mọi người C # / Java dường như không có quá thích Họ muốn thiết kế các công cụ cấp cao cụ thể cho các nhu cầu cụ thể và cung cấp chúng cho các lập trình viên sẵn sàng, được tích hợp vào ngôn ngữ. Vấn đề với các công cụ cụ thể như vậy là chúng thường không thể tùy chỉnh (một phần đó là điều khiến chúng rất dễ học). Khi xây dựng từ các khối nhỏ hơn, một giải pháp tốt hơn có thể xuất hiện theo thời gian, trong khi nếu bạn chỉ có các cấu trúc tích hợp cao cấp, thì điều này ít có khả năng.

Vì vậy, vâng, tôi nghĩ (tôi thực sự không ở đó ...) đó là một quyết định khó hiểu, với mục tiêu làm cho các ngôn ngữ dễ tiếp thu hơn, nhưng theo tôi, đó là một quyết định tồi. Sau đó, một lần nữa, tôi thường thích triết lý cho người lập trình C ++, một cơ hội để tự tung ra triết lý của riêng họ, vì vậy tôi hơi thiên vị.

Bạn đã gọi ra phần thô tương đương với điều này trong C # với Disposephương thức. Java cũng có finalize. LƯU Ý: Tôi nhận thấy rằng quyết toán của Java là không xác định và khác với Dispose, tôi chỉ chỉ ra rằng cả hai đều có một phương pháp làm sạch tài nguyên cùng với GC.

Nếu bất cứ điều gì C ++ trở nên đau đớn hơn bởi vì một đối tượng phải bị phá hủy về mặt vật lý. Trong các ngôn ngữ cấp cao hơn như C # và Java, chúng tôi phụ thuộc vào trình thu gom rác để dọn sạch khi không còn tham chiếu đến nó. Không có gì đảm bảo rằng đối tượng DBConnection trong C ++ không có các tham chiếu hoặc con trỏ giả mạo đối với nó.

Có, mã C ++ có thể trực quan hơn để đọc nhưng có thể là cơn ác mộng để gỡ lỗi vì các ranh giới và giới hạn mà các ngôn ngữ như Java đưa ra đã loại trừ một số lỗi khó khăn và nghiêm trọng hơn cũng như bảo vệ các nhà phát triển khác khỏi các lỗi tân binh thông thường.

Có lẽ nó tùy thuộc vào sở thích, một số như sức mạnh, sự kiểm soát và độ tinh khiết của C ++ ở mức độ thấp, nơi những người khác giống như tôi thích một ngôn ngữ hộp cát rõ ràng hơn nhiều.