it-swarm-vi.com

phôi kiểu c hoặc phôi kiểu c ++

Vì vậy, những gì bạn sử dụng?

int anInt = (int)aFloat;

hoặc là

int anInt = static_cast<int>(aFloat);
// and its brethren

Và, quan trọng hơn, tại sao?

21
bastibe

Trước tiên, hãy hiểu rằng những dòng đó không tương đương .

int* anInt = (int*)aFloat; // is equivalent to

int* anInt = reinterpret_cast<int*>(aFloat); 

Điều đang xảy ra ở đây là lập trình viên đang yêu cầu trình biên dịch làm bất cứ điều gì có thể để tạo dàn diễn viên.

Sự khác biệt rất quan trọng vì sử dụng static_cast sẽ chỉ yêu cầu loại cơ sở "an toàn" để chuyển đổi sang, trong đó reinterpret_cast sẽ chuyển đổi thành bất cứ thứ gì, có thể chỉ bằng cách ánh xạ bố cục bộ nhớ mong muốn qua bộ nhớ của đối tượng đã cho.

Vì vậy, vì "bộ lọc" không giống nhau, nên sử dụng cast cụ thể sẽ rõ ràng và an toàn hơn so với sử dụng cast C, nếu bạn dựa vào trình biên dịch (hoặc impl impl. Nếu bạn sử dụng Dynamic_cast) để cho bạn biết bạn đã làm gì sai , bằng cách tránh C cast và reinterepret_cast.

Bây giờ điều này đã rõ ràng hơn, có một điều khác: static_cast, reinterpret_cast, const_cast và Dynamic_cast dễ dàng tìm kiếm hơn .

Và điểm cuối cùng: chúng xấu xí . Đó là muốn. Mã lỗi tiềm ẩn, mùi mã, "thủ thuật" rõ ràng có thể tạo ra lỗi, dễ theo dõi hơn khi liên quan đến giao diện xấu. Mã xấu phải xấu .

Đó là "theo thiết kế". Và điều đó cho phép nhà phát triển biết nơi anh ta có thể làm mọi việc tốt hơn (bằng cách hoàn toàn tránh diễn xuất, nếu không thực sự cần thiết) và nơi nó ổn nhưng nó được "ghi lại" trong mã bằng cách "đánh dấu" nó là xấu xí.

Một lý do thứ yếu để giới thiệu dàn diễn viên theo phong cách mới là dàn diễn viên kiểu C rất khó nhận ra trong một chương trình. Ví dụ: bạn không thể thuận tiện tìm kiếm các diễn viên bằng trình chỉnh sửa thông thường hoặc bộ xử lý Word. Điều này gần như vô hình của các diễn viên kiểu C đặc biệt đáng tiếc vì chúng rất có khả năng gây tổn hại. Một thao tác xấu nên có dạng cú pháp xấu. Quan sát đó là một phần lý do để chọn cú pháp cho các kiểu phôi mới. Một lý do nữa là các phôi kiểu mới khớp với ký hiệu mẫu, để các lập trình viên có thể viết các phôi của riêng họ, đặc biệt là các phôi được kiểm tra trong thời gian chạy.

Có lẽ, vì static_cast rất xấu và quá khó để nhập, bạn có nhiều khả năng suy nghĩ hai lần trước khi sử dụng một? Điều đó sẽ tốt, bởi vì các diễn viên thực sự hầu như có thể tránh được trong C++ hiện đại.

Nguồn: Bjarne Stroustrup (người tạo C++)

47
Klaim

Các diễn viên C++ bị hạn chế hơn (vì vậy hãy thể hiện ý định của bạn tốt hơn và làm cho việc xem lại mã dễ dàng hơn, v.v.). Chúng cũng dễ dàng hơn để tìm kiếm, nếu bạn cần.

37
Bruce Stephens

Tùy chọn C: dàn diễn viên "C++ - style", vì nó không thể phân biệt được với một công trình:

int anInt = int(aFloat);

hoặc thậm chí:

int anInt(aFloat);

Ngoài ra, ngoài những trường hợp tầm thường với nguyên thủy, được hiểu rõ, tôi thích sử dụng x_cast <> s hơn các kiểu phôi C. Có ba lý do tại sao:

  • Họ định nghĩa hẹp hơn hoạt động mà lập trình viên đang cố gắng thực hiện.

  • Họ có thể thực hiện các hành động mà phôi kiểu C không thể (đặc biệt là trong trường hợp của Dynamic_cast <>, có thể truyền chéo qua các nhánh của chuỗi đa thừa kế).

  • Họ là xấu xí. Họ lớn tiếng tuyên bố rằng các lập trình viên đang làm việc chống lại hệ thống loại. Trong trường hợp này, đó là một điều tốt .

13
Kaz Dragon

Tôi có một vài quy tắc về phôi kiểu C/C++:

  1. Không áp dụng một const phải luôn luôn sử dụng const_cast. Vì lý do rõ ràng. Đáng buồn thay, quy tắc của tôi về việc không áp dụng một const khiến bàn phím vươn lên và phá vỡ ngón tay của lập trình viên đã không được chấp thuận.
  2. Bất kỳ shenanigans kiểu thao tác bit nào mà các lập trình viên nhận được khi xuống kim loại đều nên sử dụng reinterpret_cast. Đây thực sự là loại diễn viên mà C không có: giả vờ các bit của số nguyên này thực sự là các bit của float. Điều này tránh sự khó chịu như (int)(*(int*)(&floatVar)).
  3. Nếu bạn gõ từ "dynamic_cast ", dừng và đánh giá lại hệ thống phân cấp và thiết kế lớp đa hình của bạn. Tiếp tục đánh giá lại thiết kế phân cấp lớp của bạn cho đến khi bạn có thể xóa những từ đó.
  4. Đừng bận tâm với static_cast.

Lý do đằng sau # 4 chỉ đơn giản là nó không quan trọng. Các trường hợp không phù hợp với các quy tắc khác là rõ ràng hoặc thực sự ở mức độ thấp. Một chuyển đổi được hiểu rõ về các loại đơn giản như int-to-float không cần cú pháp đặc biệt. Và nếu bạn đang ở trong lòng sâu thẳm, xấu xí của một cái gì đó, thì, bạn đang chìm trong ruột sâu, xấu xí của một cái gì đó. Không cần phải chú ý đến thực tế rằng "ở đây có rồng", vì răng, móng vuốt và lửa đã cho đi rất nhiều.

7
Nicol Bolas

Nếu viết mã trong C sử dụng một C đúc. Nếu viết bằng C++, hãy sử dụng diễn viên C++.

Trong khi hầu hết các lần truyền đều phá vỡ sự an toàn của loại phù hợp, thì các C++ lại bị hạn chế nhiều hơn và do đó, bạn sẽ không an toàn hơn một chút so với khi sử dụng một C đúc.

Tôi có thể chịu đựng được ai đó bằng cách sử dụng (T *) NULL để buộc quá tải ...

7
CashCow

Như các bài viết ở trên lưu ý, diễn viên C++ (tĩnh) an toàn hơn một chút trong thực tế.

Có thể là thông minh để tìm kiếm thêm một số thông tin về các loại đúc khác nhau và chuyên nghiệp và khuyết điểm của họ.

Chỉ để có thêm một nền tảng về lý do tại sao. .

http://en.wikipedia.org/wiki/Static_cast

http://en.wikipedia.org/wiki/Docate_cast

http://en.wikipedia.org/wiki/Reinterpret_cast

4
the JinX

Nó thực sự phụ thuộc vào ngôn ngữ mà tôi đang làm việc với, vì bạn biết họ nói gì: Ở Rome nói tiếng La Mã. Vì vậy, nếu tôi lập trình bằng C, tôi cố gắng sử dụng các tính năng C ở mức tối đa, nhưng nếu tôi lập trình ở C++, tôi sẽ tiếp tục và sử dụng các tính năng C++ ở mức tối đa, ngay cả khi một số người không thích cách tiếp cận đó vì họ nói rằng nó làm cho mã "ít di động hơn", tôi nói rằng tôi không quan tâm, tôi đang ở trong C++ và lập trình trong C++ và tôi cần một trình biên dịch tương thích hoàn toàn với C++ để biên dịch mã, nếu không tôi sẽ làm việc với một cái gì đó khác ở nơi đầu tiên.

3
Coyote21

static_cast vv được phát minh vì các vấn đề với phôi kiểu C khi được sử dụng trong các mẫu. Nếu bạn đang viết một mẫu hoặc nếu sau đó mã của bạn có thể được chuyển đổi thành một mẫu, thì nên sử dụng các kiểu phôi C++. Lý do là bởi vì kiểu phôi C++ thể hiện ý định tốt hơn, vì vậy họ sẽ đưa ra kết quả mong đợi trong trường hợp phôi kiểu C sẽ làm sai (đưa ra các loại cụ thể làm tham số mẫu).

Ngoài ra, tôi nói rằng hãy sử dụng các kiểu kiểu C++ nếu bạn có một vấn đề cụ thể cần chúng - Dynamic_cast là phổ biến nhất, nhưng thậm chí đó có lẽ không phải là chuyện thường ngày.

Bất cứ điều gì khác, và một kiểu diễn viên C có thể ít lộn xộn hơn và giúp dễ đọc hơn, hoặc có thể không phụ thuộc vào mức độ quen thuộc của người đọc với phong cách diễn viên ngày nay. Nó không thực sự quan trọng trong quan điểm của tôi, chủ yếu là một sở thích cá nhân, mặc dù đừng ngạc nhiên nếu một số người không thích phong cách C.

Lưu ý cuối cùng - nếu bạn cần quá nhiều diễn viên đến mức đây là một vấn đề lớn, có lẽ bạn đã làm sai điều gì khác. Có một số trường hợp ngoại lệ trong một số trường hợp, nhưng hầu hết các mã cấp cao không cần nhiều phôi (nếu có).

3
Steve314