Cú pháp cho dereferencing một con trỏ trong C (hoặc C++)

tôi đã kiểm tra đồng nghiệp trong mã như thế này trong C (cú pháp # 1):Cú pháp cho dereferencing một con trỏ trong C (hoặc C++)

(*(*(*p_member).p_member).p_member).member

Khi tôi hỏi ông tại sao ông không sử dụng -> (cú pháp # 2):

p_member->p_member->p_member->member

anh ấy thực sự bảo vệ rằng cú pháp # 2 phức tạp hơn # 1 ... Tôi đã thay đổi mã của anh ấy vì tôi phải sửa đổi và không đọc được, sau đó anh ta phát điên vì tôi thực sự chạm vào nó ...

Cú pháp nào cộng đồng SO thích gì? Cả hai đều hợp lệ, nhưng tôi thấy cú pháp # 2 dễ đọc hơn.

Tôi đang thiết lập trang này thành wiki cộng đồng do câu hỏi là chủ quan.

Nguồn

2009-04-28 paquetp

Bạn có nhầm lẫn về mức độ ưu tiên của * và. trong đoạn đầu tiên của bạn? –

Trong # 2, yếu tố cuối cùng, thành viên, cũng nên được truy cập bằng cách sử dụng -> – Trent

Thành thật mà nói, tôi thậm chí không xem xét chủ quan này. Với sự lựa chọn của ba nhà khai thác (bao gồm cả()) và một, bạn có thể đoán những gì tôi muốn chọn. – ojrac

Thuật ngữ kỹ thuật cho cú pháp số 1 là "các loại hạt".

Điều đó nói rằng, tôi sẽ lo lắng một chút về mã mà phải đi gián tiếp 3 lần quá.

Nguồn

2009-04-28 15:50:02

heheh ... hướng đối tượng là do mô hình miền được thể hiện bằng C. – paquetp

Hãy nghĩ đến việc sử dụng con trỏ tạm thời nếu bạn cần thực hiện điều này nhiều hơn: thingie_s * tp; ... tp = p_member-> p_member-> p_member; sau đó đi gián tiếp một lần thông qua tp. –

Ồ vâng, chắc chắn, tất nhiên ... đặc biệt là nếu bạn làm nó nhiều hơn một lần. – paquetp

Tôi sẽ mở cửa số 2, Monty! Chắc chắn nó khó khăn hơn để loại, nhưng nó rõ ràng hơn so với việc tìm ra các nhà khai thác dereference mà con trỏ.

Nguồn

2009-04-28 15:47:41

FYI - Monty = Monty Hall của "Hãy làm cho một thỏa thuận" nổi tiếng –

Tôi hy vọng đây là một trò đùa. –

Trong C++, tôi chắc chắn sẽ sử dụng ->, vì -> có thể bị quá tải.

Trong C tôi sẽ sử dụng -> vì nó dễ đọc hơn, nhanh hơn để nhập và ít bị lỗi hơn (hy vọng đồng nghiệp của bạn không bị lạc trong dấu ngoặc đơn!).

Nguồn

2009-04-28 15:49:03

Tôi nghĩ rằng quá tải là một cá trích đỏ ở đây. Trình lặp sẽ làm việc với p-> a hoặc (* p) .a. Sử dụng -> bởi vì nó dễ đọc hơn và dễ bị lỗi hơn rất nhiều. Hãy nhớ rằng * (p.a) và (* p) .a là hai thứ khác nhau, vì vậy bạn phải nhớ sử dụng (* p) .a, nhưng p-> a là đẹp và đơn giản. –

Trong toán tử lý thuyết *() và toán tử ->() có thể bị quá tải để làm những điều cực kỳ khác nhau ... hy vọng là không, mặc dù vậy. – ephemient

-> thường bị quá tải cho các con trỏ thông minh –

chủ quan huh?

Tôi cũng sẽ lấy số 2!

Nguồn

2009-04-28 15:49:13 toto

Biến thể thứ hai rõ ràng trông rõ ràng hơn. Lý do duy nhất để thích # 1 là trường hợp của một toán tử * và toán tử lạ -> quá tải khi # 1 có hiệu ứng thực sự khác với # 2.

Nguồn

2009-04-28 15:50:11 sharptooth

và nếu các toán tử đã bị quá tải sao cho chúng có hiệu ứng "thực sự khác", tác giả của mã đó cần phải được kéo ra sau và quay. – rmeador

quá tải các nhà khai thác này sẽ bị cấm trong các tiêu chuẩn mã hóa của bất kỳ dự án nào tôi làm việc. –

-1

Không 2.

Có nói rằng, không xúc phạm người bằng cách thay đổi mã của họ, đặc biệt là nếu nó là vấn đề về phong cách. Nó không đáng.

Nguồn

2009-04-28 15:56:04

Nếu tôi phải tìm ra một dòng mã nào nói thay vì đọc nó và tiếp tục di chuyển, đó là vấn đề chất lượng. Tôi sẽ thay đổi nó trong một nhịp tim. –

Vậy làm thế nào bạn có thể làm việc với những người khác có ý kiến khác nhau những gì có thể đọc được và những gì không? Tôi làm việc với 40 nhà phát triển khác (và thông minh!) Và khá nhiều người đều có ý tưởng của họ về cách mã nên được định dạng và những gì có thể đọc được. Nếu chúng ta bước vào nhau như thế, làm việc cùng nhau sẽ là địa ngục và chúng tôi sẽ không bao giờ làm được gì cả. –

Tôi nghĩ các tiêu chuẩn mã hóa sẽ phải được thỏa thuận. Có một cơ sở mã với hàng triệu phong cách mã hóa khác nhau là một cơn ác mộng tất cả của riêng nó. – jdizzle

Bạn cũng có thể thảo luận khái niệm về "quyền sở hữu mã" trong nhóm của bạn. Bạn đồng nghiệp không "sở hữu" mã, công ty làm. Do đó bất cứ ai làm việc cho công ty, với lý do chính đáng, có thể chỉnh sửa nó.

Nguồn

2009-04-28 16:01:07

Câu hỏi ở đây không phải là người sở hữu một cách hợp pháp mã, nhưng ai cần duy trì và gỡ lỗi một phần cụ thể của codebase. Nếu đó là đồng nghiệp, tôi nói mã nên nhìn theo cách anh ấy thích, ngay cả khi hầu hết chúng ta đều thích cách khác. –

Nếu bất cứ ai đọc điều này muốn phần còn lại của câu chuyện - anh ta bắt đầu đoạn mã, tôi phải "tích hợp" nó (thêm nó vào kiểm soát nguồn, đặt nó vào đúng quy trình, có quá trình gọi hàm của mình) ... 't làm việc, vì vậy tôi đã phải hoàn thành nó. – paquetp

Trong cuốn sách của tôi, nếu nó không hoạt động, anh ấy sẽ không phàn nàn về việc bạn thay đổi nó. Tất nhiên, cho rằng ông thích (* p). xây dựng trên ->, tôi không bị sốc rằng nó không hoạt động. –

Tôi nghĩ đồng nghiệp của bạn không có kinh nghiệm, một số loại neophobe, hoặc chỉ đơn giản là ol 'clueless. Bạn sẽ thấy rằng sự lựa chọn nhất trí là sử dụng cú pháp ->.

Nguồn

2009-04-28 16:01:30

Đó là những gì tôi mong đợi ... – paquetp

Tôi đang loại bỏ dấu ngoặc ở đây, nhưng hồi ức của tôi là logic cho sự tồn tại của toán tử -> trong C được giải thích trong ấn bản đầu tiên của K & R như (diễn giải): bởi vì nếu không bạn muốn phải nhập (*p).a do mức độ ưu tiên cần thiết của các toán tử * và ..

Để không sử dụng -> cho mục đích dự định của nó là các loại hạt.

Nguồn

2009-04-28 18:17:45 RBerteig

Đồng nghiệp xấu. Thay đổi đồng nghiệp.

Nguồn

2009-04-29 09:03:03

Tôi đã có trải nghiệm ở đâu "->" không được triển khai đúng cách trong một vài trình biên dịch ...vì vậy bình thường (* p) .a có nhiều khả năng hoạt động khi bạn có nhiều cấp độ lồng nhau.

Nguồn

2009-07-21 02:24:09

Cú pháp cho dereferencing một con trỏ trong C (hoặc C++)

Trả lời

Các vấn đề liên quan