Tại sao nhiều hàm trả về cấu trúc trong C, thực sự trả về con trỏ cho cấu trúc?

Lợi thế của việc trả về một con trỏ cho một cấu trúc trái ngược với trả về toàn bộ cấu trúc trong returncâu lệnh của hàm là gì?

Tôi đang nói về các hàm như fopenvà các hàm cấp thấp khác nhưng có lẽ có các hàm cấp cao hơn cũng trả về các con trỏ cho các cấu trúc.

Tôi tin rằng đây là một sự lựa chọn thiết kế nhiều hơn là một câu hỏi lập trình và tôi tò mò muốn biết thêm về những lợi thế và bất lợi của hai phương pháp.

Một trong những lý do tôi nghĩ rằng đó sẽ là một lợi thế để trả về một con trỏ cho một cấu trúc là để có thể nói dễ dàng hơn nếu hàm bị lỗi bằng cách trả về NULLcon trỏ.

Trả lại một cấu trúc đầy đủNULL sẽ khó hơn tôi cho rằng hoặc kém hiệu quả hơn. Đây có phải là một lý do hợp lệ?

Có một số lý do thực tế tại sao các hàm như fopencon trỏ trả về thay vì các thể structloại:

1. Bạn muốn ẩn đại diện của structloại từ người dùng;
2. Bạn đang phân bổ một đối tượng một cách linh hoạt;
3. Bạn đang đề cập đến một thể hiện của một đối tượng thông qua nhiều tham chiếu;

Trong trường hợp các loại như FILE *, đó là vì bạn không muốn tiết lộ chi tiết về đại diện của loại đó cho người dùng - một FILE *đối tượng đóng vai trò là một tay cầm mờ đục và bạn chỉ chuyển giao xử lý đó cho các thói quen I / O khác nhau (và FILEthường là thực hiện như một structloại, nó không có được).

Vì vậy, bạn có thể hiển thị một loại không đầy đủ struct trong một tiêu đề ở đâu đó:

typedef struct __some_internal_stream_implementation FILE;

Mặc dù bạn không thể khai báo một thể hiện của một loại không đầy đủ, bạn có thể khai báo một con trỏ tới nó. Vì vậy, tôi có thể tạo ra một FILE *và gán cho nó qua fopen, freopen, vv, nhưng tôi không thể trực tiếp thao tác các đối tượng mà nó trỏ tới.

Cũng có khả fopennăng là hàm đang phân bổ động một FILEđối tượng, sử dụng mallochoặc tương tự. Trong trường hợp đó, nó có ý nghĩa để trả về một con trỏ.

Cuối cùng, có thể bạn đang lưu trữ một loại trạng thái nào đó trong một structđối tượng và bạn cần làm cho trạng thái đó khả dụng ở một số nơi khác nhau. Nếu bạn trả về các thể hiện của structloại, các thể hiện đó sẽ là các đối tượng riêng biệt trong bộ nhớ với nhau và cuối cùng sẽ không đồng bộ. Bằng cách trả về một con trỏ tới một đối tượng, mọi người đều tham chiếu đến cùng một đối tượng.

Có hai cách "trả lại một cấu trúc." Bạn có thể trả về một bản sao của dữ liệu hoặc bạn có thể trả lại một tham chiếu (con trỏ) cho nó. Nói chung, nên trả lại (và chuyển xung quanh) một con trỏ, vì một vài lý do.

Đầu tiên, sao chép một cấu trúc tốn nhiều thời gian CPU hơn so với sao chép một con trỏ. Nếu đây là điều mà mã của bạn làm thường xuyên, nó có thể gây ra sự khác biệt hiệu suất đáng chú ý.

Thứ hai, cho dù bạn có sao chép một con trỏ xung quanh bao nhiêu lần đi chăng nữa thì nó vẫn chỉ vào cùng một cấu trúc trong bộ nhớ. Tất cả các sửa đổi cho nó sẽ được phản ánh trên cùng một cấu trúc. Nhưng nếu bạn sao chép chính cấu trúc đó và sau đó thực hiện sửa đổi, thay đổi chỉ hiển thị trên bản sao đó . Bất kỳ mã nào giữ một bản sao khác sẽ không thấy sự thay đổi. Đôi khi, rất hiếm khi, đây là những gì bạn muốn, nhưng hầu hết thời gian là không, và nó có thể gây ra lỗi nếu bạn làm sai.

Ngoài các câu trả lời khác, đôi khi trả lại một giá trị nhỏ struct bằng giá trị là đáng giá. Ví dụ: người ta có thể trả về một cặp dữ liệu và một số mã lỗi (hoặc thành công) liên quan đến dữ liệu đó.

Để lấy một ví dụ, fopenchỉ trả về một dữ liệu (đã mở FILE*) và trong trường hợp có lỗi, đưa ra mã lỗi thông qua biến errnogiả toàn cầu. Nhưng có lẽ tốt hơn là trả về một structtrong hai thành viên: FILE*xử lý và mã lỗi (sẽ được đặt nếu xử lý tệp là NULL). Vì lý do lịch sử, đây không phải là trường hợp (và lỗi được báo cáo trên errnotoàn cầu, mà ngày nay là một vĩ mô).

Lưu ý rằng ngôn ngữ Go có một ký hiệu đẹp để trả về hai (hoặc một vài) giá trị.

Cũng lưu ý rằng trên Linux / x86-64, ABI và các quy ước gọi (xem trang x86-psABI ) chỉ định rằng một structtrong hai thành viên vô hướng (ví dụ: một con trỏ và một số nguyên hoặc hai con trỏ hoặc hai số nguyên) được trả về qua hai thanh ghi (và điều này rất hiệu quả và không đi qua bộ nhớ).

Vì vậy, trong mã C mới, việc trả về một C nhỏ structcó thể dễ đọc hơn, thân thiện với luồng hơn và hiệu quả hơn.

Bạn đang đi đúng hướng

Cả hai lý do bạn đề cập đều hợp lệ:

Một trong những lý do tôi nghĩ rằng đó sẽ là một lợi thế để trả về một con trỏ cho cấu trúc là để có thể nói dễ dàng hơn nếu hàm bị lỗi bằng cách trả về con trỏ NULL.

Trả lại một cấu trúc ĐẦY ĐỦ là NULL sẽ khó hơn tôi cho rằng hoặc kém hiệu quả hơn. Đây có phải là một lý do hợp lệ?

Nếu bạn có một kết cấu (ví dụ) ở đâu đó trong bộ nhớ và bạn muốn tham chiếu kết cấu đó ở một vài nơi trong chương trình của mình; Sẽ không khôn ngoan khi tạo một bản sao mỗi khi bạn muốn tham khảo nó. Thay vào đó, nếu bạn chỉ cần vượt qua một con trỏ để tham chiếu kết cấu, chương trình của bạn sẽ chạy nhanh hơn nhiều.

Lý do lớn nhất là phân bổ bộ nhớ động. Thông thường, khi một chương trình được biên dịch, bạn không chắc chắn chính xác mình cần bao nhiêu bộ nhớ cho các cấu trúc dữ liệu nhất định. Khi điều này xảy ra, lượng bộ nhớ bạn cần sử dụng sẽ được xác định khi chạy. Bạn có thể yêu cầu bộ nhớ bằng cách sử dụng 'malloc' và sau đó giải phóng nó khi bạn kết thúc sử dụng 'miễn phí'.

Một ví dụ điển hình của việc này là đọc từ một tệp được chỉ định bởi người dùng. Trong trường hợp này, bạn không biết tệp có thể lớn đến mức nào khi bạn biên dịch chương trình. Bạn chỉ có thể tìm ra bao nhiêu bộ nhớ bạn cần khi chương trình thực sự đang chạy.

Cả malloc và con trỏ trở lại miễn phí đến các vị trí trong bộ nhớ. Vì vậy, các hàm sử dụng phân bổ bộ nhớ động sẽ đưa con trỏ trở lại nơi chúng đã tạo cấu trúc của chúng trong bộ nhớ.

Ngoài ra, trong các bình luận tôi thấy rằng có một câu hỏi là liệu bạn có thể trả về một cấu trúc từ một hàm không. Bạn thực sự có thể làm điều này. Sau đây nên làm việc:

struct s1 {
   int integer;
};

struct s1 f(struct s1 input){
   struct s1 returnValue = xinput
   return returnValue;
}

int main(void){
   struct s1 a = { 42 };
   struct s1 b= f(a);

   return 0;
}

Một cái gì đó giống như FILE*không thực sự là một con trỏ đến một cấu trúc liên quan đến mã máy khách, mà thay vào đó là một dạng định danh mờ được liên kết với một số thực thể khác như một tệp. Khi một chương trình gọi fopen, nó thường không quan tâm đến bất kỳ nội dung nào của cấu trúc được trả về - tất cả những gì nó sẽ quan tâm là các chức năng khác như freadsẽ làm bất cứ điều gì chúng cần làm với nó.

Nếu một thư viện chuẩn lưu trong FILE*thông tin về ví dụ như vị trí đọc hiện tại trong tệp đó, một cuộc gọi đến freadsẽ cần có thể cập nhật thông tin đó. Có freadđược một con trỏ để FILElàm cho dễ dàng. Nếu freadthay vào đó nhận được một FILE, nó sẽ không có cách nào cập nhật FILEđối tượng được giữ bởi người gọi.

Ẩn thông tin

Lợi thế của việc trả về một con trỏ cho một cấu trúc trái ngược với trả về toàn bộ cấu trúc trong câu lệnh return của hàm là gì?

Một trong những phổ biến nhất là ẩn thông tin . C không có khả năng tạo các trường structriêng tư, chứ chưa nói đến việc cung cấp các phương thức để truy cập chúng.

Vì vậy, nếu bạn muốn ngăn chặn mạnh mẽ các nhà phát triển có thể nhìn thấy và can thiệp vào nội dung của một điểm, như vậy FILE, cách duy nhất và duy nhất là ngăn họ tiếp xúc với định nghĩa của nó bằng cách coi con trỏ là mờ đục có kích thước điểm và định nghĩa là không biết với thế giới bên ngoài. Định nghĩa về FILEý chí sau đó chỉ hiển thị cho những người thực hiện các hoạt động yêu cầu định nghĩa của nó, như fopen, trong khi chỉ có khai báo cấu trúc sẽ hiển thị cho tiêu đề công khai.

Tương thích nhị phân

Ẩn định nghĩa cấu trúc cũng có thể giúp cung cấp phòng thở để duy trì khả năng tương thích nhị phân trong API dylib. Nó cho phép người triển khai thư viện thay đổi các trường trong cấu trúc mờ mà không phá vỡ tính tương thích nhị phân với những người sử dụng thư viện, vì bản chất của mã của họ chỉ cần biết họ có thể làm gì với cấu trúc, chứ không phải nó lớn như thế nào hoặc trường nào nó có.

Ví dụ, tôi thực sự có thể chạy một số chương trình cổ xưa được xây dựng trong thời đại Windows 95 ngày nay (không phải lúc nào cũng hoàn hảo, nhưng đáng ngạc nhiên là nhiều chương trình vẫn hoạt động). Rất có thể là một số mã cho các nhị phân cổ đó đã sử dụng các con trỏ mờ cho các cấu trúc có kích thước và nội dung đã thay đổi từ thời Windows 95. Tuy nhiên, các chương trình tiếp tục hoạt động trong các phiên bản mới của windows vì chúng không tiếp xúc với nội dung của các cấu trúc đó. Khi làm việc trên thư viện nơi khả năng tương thích nhị phân là quan trọng, những gì khách hàng không tiếp xúc thường được phép thay đổi mà không phá vỡ tính tương thích ngược.

Hiệu quả

Trả lại một cấu trúc đầy đủ là NULL sẽ khó hơn tôi cho rằng hoặc kém hiệu quả hơn. Đây có phải là một lý do hợp lệ?

Nó thường kém hiệu quả hơn khi giả sử loại có thể phù hợp trên thực tế và được phân bổ trên ngăn xếp trừ khi thường có bộ cấp phát bộ nhớ ít khái quát hơn được sử dụng phía sau hậu trường malloc, giống như bộ nhớ gộp của bộ cấp phát có kích thước thay đổi được phân bổ. Đây là một sự đánh đổi an toàn trong trường hợp này, rất có thể, cho phép các nhà phát triển thư viện duy trì các bất biến (đảm bảo khái niệm) liên quan đến FILE.

Đó không phải là một lý do hợp lệ ít nhất là từ quan điểm hiệu suất để fopentrả về một con trỏ vì lý do duy nhất nó trả về NULLlà do không mở được tệp. Điều đó sẽ tối ưu hóa một kịch bản đặc biệt để đổi lấy việc làm chậm tất cả các đường dẫn thực hiện trường hợp thông thường. Có thể có một lý do năng suất hợp lệ trong một số trường hợp để làm cho các thiết kế đơn giản hơn để làm cho chúng trả về các con trỏ để cho phép NULLđược trả về trong một số điều kiện hậu.

Đối với các hoạt động tập tin, chi phí hoạt động tương đối tầm thường so với chính các hoạt động tập tin và fclosekhông thể tránh khỏi hướng dẫn sử dụng . Vì vậy, không giống như chúng ta có thể tiết kiệm cho khách hàng những rắc rối trong việc giải phóng (đóng) tài nguyên bằng cách đưa ra định nghĩa FILEvà trả lại theo giá trị fopenhoặc hy vọng phần lớn hiệu suất được cung cấp do chi phí tương đối của các hoạt động tệp để tránh phân bổ heap .

Điểm nóng và sửa lỗi

Tuy nhiên, đối với các trường hợp khác, tôi đã lập hồ sơ rất nhiều mã C lãng phí trong các cơ sở mã di sản với các điểm nóng trong mallocbộ nhớ cache bắt buộc và không cần thiết do sử dụng thực hành này quá thường xuyên với các con trỏ mờ và phân bổ quá nhiều thứ không cần thiết trong đống, đôi khi trong các vòng lớn.

Một cách thực hành khác mà tôi sử dụng thay vào đó là để lộ các định nghĩa cấu trúc, ngay cả khi máy khách không có ý định giả mạo chúng, bằng cách sử dụng một tiêu chuẩn quy ước đặt tên để truyền đạt rằng không ai khác nên chạm vào các trường:

struct Foo
{
   /* priv_* indicates that you shouldn't tamper with these fields! */
   int priv_internal_field;
   int priv_other_one;
};

struct Foo foo_create(void);
void foo_destroy(struct Foo* foo);
void foo_something(struct Foo* foo);

Nếu có những lo ngại về khả năng tương thích nhị phân trong tương lai, thì tôi đã thấy nó đủ tốt để chỉ dự trữ một số không gian thừa cho các mục đích trong tương lai, như vậy:

struct Foo
{
   /* priv_* indicates that you shouldn't tamper with these fields! */
   int priv_internal_field;
   int priv_other_one;

   /* reserved for possible future uses (emergency backup plan).
     currently just set to null. */
   void* priv_reserved;
};

Không gian dành riêng đó hơi lãng phí nhưng có thể là một trình tiết kiệm cuộc sống nếu chúng ta thấy trong tương lai chúng ta cần thêm một số dữ liệu vào Foomà không phá vỡ các nhị phân sử dụng thư viện của chúng tôi.

Theo tôi, ẩn thông tin và khả năng tương thích nhị phân thường là lý do hợp lý duy nhất để chỉ cho phép phân bổ các cấu trúc heap bên cạnh các cấu trúc có độ dài thay đổi (sẽ luôn yêu cầu nó, hoặc ít nhất là hơi khó sử dụng nếu khách hàng phải phân bổ bộ nhớ trên ngăn xếp theo kiểu VLA để phân bổ VLS). Ngay cả các cấu trúc lớn thường rẻ hơn để trả về theo giá trị nếu điều đó có nghĩa là phần mềm hoạt động nhiều hơn với bộ nhớ nóng trên ngăn xếp. Và ngay cả khi chúng không rẻ hơn để trả về theo giá trị khi tạo, người ta có thể chỉ cần làm điều này:

int foo_create(struct Foo* foo);
...
/* In the client code: */
struct Foo foo;
if (foo_create(&foo))
{
    foo_something(&foo);
    foo_destroy(&foo);
}

... để khởi tạo Footừ ngăn xếp mà không có khả năng sao chép thừa. Hoặc khách hàng thậm chí có quyền tự do phân bổ Footrên heap nếu họ muốn vì một lý do nào đó.