2009-10-02 32 views
6

Tôi không hoàn toàn hiểu được điểm có tiêu đề; có vẻ như vi phạm nguyên tắc DRY! Tất cả các thông tin trong một tiêu đề là (có thể được) chứa trong việc thực hiện.Lý do cơ bản đằng sau các tiêu đề là gì?

+1

Bạn có nghĩa là các tệp tiêu đề, như trong dự án C? – timdev

+0

Chính xác. (15 ký tự) – RCIX

+3

bạn nói đúng. Điều bạn quên là chúng được phát minh cách đây khoảng 30 năm. Bạn phải thỏa hiệp để có được một thứ đơn giản, đủ để biên dịch trong một vài KB bộ nhớ. – jalf

Trả lời

20

Nó đơn giản hóa quá trình biên dịch. Khi bạn muốn biên dịch các đơn vị một cách độc lập, bạn cần một cái gì đó để mô tả các phần sẽ được liên kết mà không phải nhập toàn bộ tất cả các tệp khác.

Nó cũng cho phép mã ẩn. Người ta có thể phân phối một tiêu đề để cho phép người khác sử dụng chức năng mà không phải phân phối việc triển khai.

Cuối cùng, nó có thể khuyến khích việc tách giao diện khỏi triển khai.

Chúng không phải là cách duy nhất để giải quyết những vấn đề này, nhưng 30 năm trước chúng là một vấn đề tốt. Có thể chúng tôi sẽ không sử dụng các tệp tiêu đề cho một ngôn ngữ ngày nay, nhưng chúng không được phát minh vào năm 2009.

+0

Nhưng nếu bạn không phân phối triển khai thì cuộc gọi của bạn hoạt động như thế nào? nó kỳ diệu xuất hiện trên internet để gọi bản sao của bạn? – RCIX

+11

Bạn gửi mã thư viện được biên soạn + tiêu đề. – timdev

+0

Sau đó, làm thế nào để những thứ như .NET hoặc cho phép khám phá API của các DLL đã biên dịch? – RCIX

0

Và điều gì sẽ xảy ra nếu bạn muốn cung cấp cho người khác các khai báo sử dụng thư viện của bạn mà không cho họ triển khai?

Như một câu trả lời khác chỉ ra - lý do ban đầu cho tiêu đề là làm cho phân tích cú pháp/biên dịch dễ dàng hơn trên nền tảng với các công cụ rất đơn giản và hạn chế. Đó là một bước tiến lớn để có một cỗ máy với 2 đĩa mềm để bạn có thể có trình biên dịch trên một và mã của bạn trên một cái khác - làm cho mọi thứ trở nên dễ dàng hơn nhiều.

+0

Tôi có thể tưởng tượng một trình biên dịch sẽ có tùy chọn lấy tệp nguồn của bạn và tạo tệp kê khai tự động ... không cần phải tự bảo trì chúng. –

+0

Vâng, bạn có thể làm điều đó, nhưng bạn cần một cách để cho nó biết những gì nên được xuất khẩu và những gì không nên. Viết tiêu đề của riêng bạn cho phép bạn rất cụ thể. – dmckee

3

Nó giúp suy nghĩ một chút về khả năng của các máy tính có sẵn khi viết c. Bộ nhớ chính được đo bằng kilowords, và không nhất thiết phải rất nhiều. Đĩa lớn hơn, nhưng không nhiều. Lưu trữ nghiêm túc có nghĩa là các cuộn băng cuộn, được gắn bằng tay, bởi các nhà khai thác gắt gỏng, những người thực sự muốn bạn đi xa để họ có thể chơi săn lùng. Máy 1 MIPS là la hét nhanh. Và với tất cả những giới hạn này, bạn phải chia sẻ. Có thể với số điểm của những người dùng khác.

Bất kỳ điều gì làm giảm không gian hoặc phức tạp về thời gian biên dịch là một chiến thắng lớn. Và tiêu đề làm cả hai.

+4

"Nhà điều hành Grumpy" đã không chơi săn lùng. Chúng tôi đã bị lạc trong một mê cung của những đoạn uốn lượn, tất cả đều giống nhau. – themis

4

Kiến trúc sư của nhiều ngôn ngữ hiện đại như Java, Eiffel và C# rõ ràng đồng ý với bạn - những ngôn ngữ đó trích xuất siêu dữ liệu về mô-đun từ việc triển khai. Tuy nhiên, khái niệm tiêu đề không loại trừ điều đó - rõ ràng sẽ là một nhiệm vụ đơn giản cho trình biên dịch trích xuất tệp .h trong khi biên dịch .c, ví dụ, giống như các trình biên dịch cho các ngôn ngữ khác làm ngầm. Thực tế là các trình biên dịch C điển hình hiện tại không làm điều đó không phải là vấn đề thiết kế ngôn ngữ - đó là vấn đề triển khai; dường như không có nhu cầu của người dùng cho một tính năng như vậy, do đó, không có nhà cung cấp trình biên dịch nào thực hiện nó.

Là lựa chọn thiết kế ngôn ngữ, có các tệp .h riêng biệt (ở định dạng văn bản có thể đọc được và có thể chỉnh sửa) mang lại cho bạn tốt nhất của cả hai thế giới: bạn có thể bắt đầu biên dịch mã khách hàng một cách riêng biệt dựa trên việc triển khai mô-đun. tồn tại, nếu bạn muốn, bằng cách viết các tập tin .h bằng tay; hoặc bạn (giả định bởi một trình biên dịch vô lý cung cấp nó ;-) có thể tự động lấy tệp .h từ việc triển khai như là một tác dụng phụ của việc biên dịch nó.

Nếu C, C++, & c, tiếp tục phát triển (dường như chúng vẫn hoạt động tốt ngày hôm nay ;-), và nhu cầu như của bạn không viết tiêu đề một cách thủ công, cuối cùng trình biên dịch sẽ phải cung cấp "tiêu đề thế hệ" tùy chọn, và "tốt nhất của cả hai thế giới" sẽ không ở lại lý thuyết!-)

+2

Làm thế nào để tốt nhất của cả hai thế giới phải duy trì cùng một thông tin trong hai tệp? Tốt nhất của cả hai thế giới sẽ có một cái gì đó giống như các tập tin tiêu đề tự động và tạo ra ngầm cho sự tiện lợi của lập trình viên. Tiêu đề là bản hack nguyên thủy đòi hỏi nhiều nỗ lực hơn, làm chậm quá trình biên dịch (mã hóa ngày nay trên CPU ngày nay) và làm phức tạp mã của bạn bằng cách buộc bạn phải suy nghĩ về việc đưa vào và thứ tự khai báo để tránh tham chiếu tuần hoàn. Và trình biên dịch không thể tự động xác định tệp .h. Nó sẽ thay đổi ngữ nghĩa của mã của bạn trong một số trường hợp. – jalf

+2

@jaif, như tôi đã nói, không có gì trong trình biên dịch _forbids_ chuẩn C có cờ để tạo tùy chọn .h từ .c khi biên dịch (bao gồm tất cả các thực thể có thể nhìn thấy bên ngoài và chỉ những người đó): nếu bạn nghĩ khác, hãy chỉ cho tôi nơi bị cấm . Nếu trình biên dịch không làm điều đó trong thực tế, nó phải là thiếu nhu cầu - tức là, người dùng C hoặc C++ rõ ràng không nghĩ rằng thiếu tính năng này là một vấn đề lớn, nếu không họ sẽ áp lực nhà cung cấp trình biên dịch cung cấp nó! –

1

Không, bạn không có tiêu đề trong Java - nhưng bạn có giao diện và mọi chuyên gia Java nghiêm túc đều khuyên bạn định nghĩa mọi thứ được sử dụng bởi các dự án/hệ thống khác làm giao diện và triển khai.

Cho phép xem định nghĩa giao diện java chứa chữ ký cuộc gọi, nhập định nghĩa và đối tượng.

Tệp tiêu đề MOST C chứa chữ ký cuộc gọi, nhập định nghĩa và hằng số.

Vì vậy, đối với tất cả các mục đích thực, các tệp tiêu đề C/C++ chỉ là định nghĩa giao diện và do đó được coi là Điều tốt. Bây giờ tôi biết khả năng của mình để xác định một thứ khác vô số trong các tập tin tiêu đề cũng như (MARCROs, hằng vv vv), nhưng đó chỉ là một phần của toàn bộ thế giới tuyệt vời của C: -

int function target() { 
    // Default for shoot 
    return FOOT; 
} 
+0

Bạn có thể không nhận thấy nó, nhưng Java không yêu cầu bạn # bao gồm định nghĩa giao diện trước khi bạn có thể sử dụng nó. Tiêu đề làm. Điều đó khiến họ trở thành một điều tốt? – jalf

+0

Có, nhưng giao diện có mục đích cụ thể: để đảm bảo rằng bạn có thể truy cập * một số thuộc tính * và gọi * một số phương thức trên một lớp đối tượng mà không thực sự biết đối tượng đó cụ thể là gì. Tiêu đề tồn tại chỉ như một sự lặp lại của các nội dung của một đơn (Objective-) C (++) tập tin, chỉ ở dạng ngưng tụ (ít nhất là bất cứ điều gì ive nhìn thấy). – RCIX

1

Đối với chi tiết đã đọc this

Tệp tiêu đề thường chứa các khai báo chuyển tiếp của các lớp, trình con, biến và các số nhận dạng khác. Các lập trình viên muốn khai báo các mã định danh tiêu chuẩn trong nhiều hơn một tệp nguồn có thể đặt các mã định danh như vậy trong một tệp tiêu đề duy nhất, sau đó mã khác có thể bao gồm bất cứ khi nào nội dung tiêu đề được yêu cầu.

Thư viện chuẩn C và thư viện chuẩn C++ truyền thống khai báo hàm chuẩn của chúng trong tệp tiêu đề.

+0

Điểm tốt tôi cho là. – RCIX

2

Toàn bộ ý tưởng kiểm tra tệp đầu ra nhị phân của bộ xử lý ngôn ngữ sẽ khó hiểu khi C phát minh tệp .h. Có một hệ thống gọi là JOVIAL đã làm một cái gì đó như nó, nhưng nó là kỳ lạ và hạn chế nhiều hay ít dành riêng cho các dự án quân sự. (Tôi chưa từng thấy chương trình JOVIAL, tôi chỉ nghe về nó.)

Vì vậy, khi C xuất hiện mẫu thiết kế thông thường cho mô đun là "không kiểm tra gì". Có thể có một hạn chế mà các ký hiệu .text chỉ có thể liên kết tới .text và .data thành .data, nhưng đó là nó. Đó là, các trình biên dịch trong ngày thường xử lý một tệp nguồn tại một thời điểm và sau đó các trình liên kết đặt chúng lại với nhau mà không có mức kiểm tra lỗi nhỏ nhất, nếu bạn may mắn, "Tôi là biểu tượng hàm" và "Tôi một biểu tượng dữ liệu ".

Vì vậy, ý tưởng thực sự có trình biên dịch hiểu điều bạn đang gọi là hơi mới.

Thậm chí hôm nay, nếu bạn tạo tiêu đề hoàn toàn không có thật, không ai bắt được bạn trong hầu hết AOT compilers. Những thứ thông minh như ngôn ngữ CLR và Java thực sự mã hóa mọi thứ trong các tệp lớp.

Vì vậy, có, về lâu dài, có thể chúng tôi sẽ không có tệp tiêu đề.

2

Đừng quên tài liệu mà tiêu đề cung cấp. Thường có bất cứ điều gì trong đó bạn cần biết để sử dụng mô-đun. Tôi cho một phần của tôi không muốn quét qua một sourcecode looong để tìm hiểu những gì có mà tôi cần phải sử dụng và làm thế nào để gọi nó ... Bạn sẽ trích xuất thông tin này anyway, mà có hiệu quả kết quả trong một tập tin tiêu đề. Không còn là một vấn đề với IDE hiện đại, tất nhiên, nhưng làm việc với một số mã C cũ tôi thực sự thích có các tệp tiêu đề thủ công bao gồm các nhận xét về cách sử dụng và về trước và sau điều kiện.

nguồn Giữ, tiêu đề và tài liệu bổ sung đồng bộ vẫn là một thể của sâu ...

0

Khi bạn chia mã trong tiêu đề và nguồn dữ liệu mà bạn chia khai và định nghĩa.Khi bạn nhìn vào các tập tin tiêu đề, bạn có thể thấy những gì bạn có và nếu bạn cây đũa phép để xem chi tiết thực hiện bạn vào tập tin nguồn.

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