2011-02-03 30 views
38

Tôi đã thực hiện một số lượng lập trình hợp lý trong C/C++ trước đây, nhưng ngày nay nó chỉ chiếm một tỷ lệ phần trăm nhỏ của chương trình tôi làm (ngôn ngữ kịch bản phù hợp hơn rất nhiều cho rất nhiều công việc tôi làm). Tôi đã làm việc trên một số dự án lập trình C trong vài ngày qua và đã rất ngạc nhiên khi biết bao nhiêu chi tiết cú pháp nhỏ mà tôi đã quên. Điều tồi tệ hơn là cc/gcc thường có thông báo lỗi khó hiểu hoặc không mang tính thông tin về những vấn đề này (xin lỗi tôi không thể nhớ bất kỳ ví dụ cụ thể nào).Tại sao clang không được sử dụng nhiều hơn?

Tôi đã tìm hiểu về trình biên dịch clang cách đây không lâu và đã quyết định thử điều đó. Các thông báo lỗi rõ ràng hơn nhiều và giúp tôi xác định và khắc phục các vấn đề trong cú pháp của tôi. Câu hỏi của tôi là tại sao công cụ này không được sử dụng/đề cập nhiều hơn nó? Có phải là nó quá mới so với các nghi phạm thông thường (cc/gcc), hoặc là nó không hỗ trợ các tính năng mà họ hỗ trợ, hoặc là nó khó khăn hơn để có được? Tôi có một thời gian khó tin rằng cuối cùng, kể từ khi nó được cài đặt với các công cụ dev trên iMac của tôi và yêu cầu một lệnh duy nhất (sudo apt-get install clang) để cài đặt trên hộp Ubuntu của tôi.

+1

Bạn nên đợi XCode4 và sau đó bạn sẽ thấy việc sử dụng tiếng kêu sẽ tăng vọt. – ismail

+0

Một lưu ý: CLang là sản phẩm trưởng thành cho C, tuy nhiên hỗ trợ C++ vẫn là một tiến bộ liên tục, C++ 03 là bình thường, nhưng C++ 0x bị tụt lại phía sau wrt VC++ và gcc. Nó đang được phát triển tích cực mặc dù. –

+1

Tôi đã sử dụng chương trình C trong GCC, bởi vì, tốt, * này là * trình biên dịch, tôi đoán tôi phải nhìn bên ngoài hộp một chút, tôi thực sự thích sự biểu cảm của các trình biên dịch khiếu nại, 1 để giới thiệu trình biên dịch này. –

Trả lời

34

Câu hỏi của tôi là tại sao công cụ này không được sử dụng/đề cập nhiều hơn?

Có thể là do lịch sử và vì cách chúng ta thường xử lý.

Gcc truyền thống là trình biên dịch thực sự (miễn phí) thực tế có thể được sử dụng để biên dịch các chương trình C trên ít nhất tất cả các bản sao * nix miễn phí ra khỏi đó. Đó là những gì hầu như tất cả các hệ thống cơ sở và hạt nhân của Linux, * BSD, bây giờ có lẽ OSX, và những người khác được biên dịch với.

Trong khi các lỗ hổng ở đây và ở đó, về cơ bản, điều này có nghĩa là: gcc hoạt động. Và nếu nó không bị hỏng, đừng sửa nó. Trong số này, giờ đây bạn có cơ sở người dùng lớn, thật dễ dàng để nhận trợ giúp với gcc, có rất nhiều người đã sử dụng gcc, đang làm việc trên gcc, v.v.

Nói chung, nếu bạn muốn chuyển đổi cộng đồng khổng lồ từ một thứ gì đó mà họ quen thuộc, với một thứ gì đó khác, rằng "cái gì đó khác" phải * đáng kể "tốt hơn. Chỉ cần" tốt hơn "thường không đủ lý do.Tôi nghĩ bạn có thể tìm thấy những ví dụ về điều này trong nhiều lĩnh vực của xã hội. Một số người sẽ chỉ nghi ngờ nếu nó liên quan đến nhiệm vụ, nếu nó có lỗi, nếu nó tạo ra mã chậm hơn, v.v. - có vẻ như trong bản chất con người là đáng ngờ - những điều mới đáng sợ . Nhiều người thậm chí không biết về clang, nhiều người không quan tâm bởi vì họ hài lòng với gcc.

Mặc dù, nếu bạn thay vì muốn sử dụng tiếng kêu, hãy thực hiện - thông báo lỗi thực sự "tốt hơn" và dễ hiểu hơn so với gcc.

6

Câu hỏi của tôi là tại sao công cụ này không được sử dụng/đề cập nhiều hơn? Có phải nó quá mới so với các nghi phạm thông thường…

Đây chính xác là lý do. Nó vẫn là chức năng mới và cốt lõi vẫn đang được phát triển tích cực. Hãy nhớ rằng các dự án hiện tại có thể đang sử dụng các tính năng của trình biên dịch cụ thể - hoặc sử dụng các thư viện làm - và các nhà phát triển, trong mọi trường hợp, không thích thay đổi công cụ làm việc cho các thử nghiệm có thể có lỗi không mong muốn hoặc hiệu năng/kích thước không xác định. sự cân bằng, ngay cả khi các công cụ mới ngày càng trở nên tốt hơn mỗi ngày.

+0

Xin lưu ý rằng hỗ trợ C++ chỉ mới được hoàn thành RẤT gần đây và có thể vẫn còn các lỗi ẩn chứa xung quanh. Và các biểu tượng gỡ lỗi vẫn cần phải làm việc quá (tôi đã nghe tin đồn về đầu ra biểu tượng gỡ lỗi là 5x lớn hơn GCC ...) – bdonlan

+1

@bdonlan, gỡ lỗi kích thước biểu tượng vấn đề chỉ trên Linux btw. – ismail

+0

@bdonlan: Tôi đã cố gắng nói điều đó với 'thử nghiệm', nhưng cần được nhấn mạnh. Cảm ơn. –

7

LLVM đã được khoảng một thời gian, nhưng - ít nhất là ở cổ rừng của tôi - nó chỉ nổi lên gần đây, có thể là do Apple đã đẩy mạnh việc thay thế gcc bằng Clang trong chuỗi công cụ của riêng họ.

Ngoài ra, tôi tin rằng hỗ trợ C++ chỉ vừa mới trở thành sản phẩm cấp. EDIT: Dường như thậm chí chưa đến mức đó. (Xem ý kiến ​​dưới đây.)

Một yếu tố khác có thể là LLVM phần lớn được hỗ trợ bởi một nhà cung cấp duy nhất, theo đó các nhà phát triển không phải của Apple có một sự ngờ vực bẩm sinh.

+3

Nó không phải là sản phẩm cấp, chỉ cần tính năng hoàn chỉnh (C++ 03). Ví dụ. nó không thể biên dịch Qt chính xác AFAIK (nó biên dịch nhưng các bài kiểm tra đơn vị hiển thị các hồi quy). –

+0

@ Tamás: Cảm ơn bạn đã bình luận. Tôi đã sửa đổi câu trả lời của mình. –

+5

+1 và tôi sẽ thêm câu hỏi thứ hai chỉ để nhận xét cuối cùng! * Được hỗ trợ bởi một nhà cung cấp duy nhất, mà các nhà phát triển không phải của Apple có một sự ngờ vực bẩm sinh. * –

9

Đầu phía trước cào là tương đối mới. Ví dụ: 2.8 release vào tháng 10 năm 2010 đánh dấu việc hoàn thành hỗ trợ C++ 98/03.

Dường như với sự trưởng thành ngày càng tăng, sẽ có sự chấp nhận ngày càng tăng. Ví dụ, có công việc đang diễn ra trên làm cho hệ điều hành FreeBSD (và BSD của hệ điều hành khác) xây dựng với clang, loại bỏ sự phụ thuộc vào GCC/G ++.

Apple đang đẩy kết hợp LLVM/clang. Dường như họ sẽ ngừng hỗ trợ nhánh công cụ GCC cũ của họ (dựa trên 4.2) và chỉ phụ thuộc vào các công cụ clang để phát triển OSX/iOS.

Clang cũng đang chứng kiến ​​ngày càng tăng thông qua trong các trình biên dịch tùy chỉnh cho các ngôn ngữ C-tương tự (ví dụ các trình biên dịch ngôn ngữ đổ bóng cho OpenCL)

3

Là một lập trình viên sinh viên, tôi tìm thấy nó một tổng trời chủ yếu là do nó thông báo lỗi hữu ích và dễ hiểu. Tôi sử dụng nó chủ yếu cho lập trình trong C, mặc dù tôi bắt đầu chi nhánh ra vào C + + cũng sử dụng Clang.

Vì sao nó không được đề cập nhiều hơn, tôi nghi ngờ đó là vì GCC đã được thiết lập quá lâu, đối với hầu hết người dùng, nó là trình biên dịch. GCC cho tôi hoạt động tốt, ngoại trừ các thông báo lỗi cực kỳ khó hiểu khi một sinh viên ném tôi đi một chút.

Nhìn chung, tôi rất khuyên bạn nên sử dụng Clang cho cả sinh viên và nhà phát triển. Kể từ khi nó bây giờ là trình biên dịch chính thức cho Apple và Xcode, tôi nghi ngờ nó sử dụng và nhận dạng tên sẽ nhanh chóng đón nhận. FreeBSD dường như cũng đã thông qua nó như là trình biên dịch chính của họ mặc dù tôi nghi ngờ rằng sẽ có ít tác động đến sự phổ biến của nó hơn là nó được thông qua bởi Apple.

Phụ Lục: Do sự cạnh tranh từ Clang, rõ ràng các thông báo lỗi trong GCC 4.8 và 4.9 đã cho thấy một sự cải thiện đáng kể; mặc dù tôi vẫn tìm thấy Clang một chút sáng suốt hơn, nhưng khoảng cách tuy nhiên đã thu hẹp đáng kể.

2

Hôm nay, tiếng kêu đang thay thế gcc ở hầu hết các places. tức là, hầu hết * hệ điều hành giống như NIX và bản phân phối Linux. Một số ví dụ oare FreeBSD, Minix và mac (một chút rõ ràng) clang đã chuyển clang thành trình biên dịch mặc định. Một số bạn bè của tôi cũng vậy, khi tôi cho họ xem.

IMHO này, có vẻ như một số người gặp sự cố với nó, có thể là trong các phiên bản cũ hơn. Nhưng với clang phiên bản 3.0, tôi không có bất kỳ vấn đề này. Như tôi đã biết trước đây, tôi đang sử dụng nó thực sự trong tất cả các dự án mới của mình. Hầu như trình biên dịch mặc định của tôi, đôi khi tôi làm make C=gcc chỉ để thấy sự khác biệt về lỗi/cảnh báo clang. Và kêu vang bao giờ hết. Với giải thích tốt hơn và thực hiện một nỗ lực tuyệt vời để tối ưu hóa. Nó bao gồm các đề xuất cho các phần mở rộng sử dụng (một số là gcc inerhid) của trình biên dịch đến một hiệu quả tốt nhất trong việc tạo mã.

Tôi đã viết một chức năng tầm thường để in thông báo lỗi. Nhưng tôi sẽ thoát khỏi chương trình sau khi in thông báo lỗi trên đầu ra tiêu chuẩn.Vì vậy, tôi thực hiện một sửa đổi đơn giản, đặt exit(1) làm tuyên bố cuối cùng trong hàm. Như sau:

void error(const char *fmt, ...) 
{ 
    va_list ap; 
    va_start(ap, fmt); 
    fprintf(stderr, "error: "); 
    vfprintf(stderr, fmt, ap); 
    va_end(ap); 
    exit(1); 
} 

Và như vậy chương trình kêu vang

cảnh báo: chức năng 'lỗi' có thể được khai báo với thuộc tính 'noreturn' [-Wmissing-noreturn] `

(gcc không sản xuất ngay cả khi không có -Wall -Wextra -Wunreachable-code -O3 cờ)

Tôi nói "điều đó có vẻ đẹp. Nhưng thuộc tính 'nonreturn' là gì? Tôi ' d không bao giờ nghe hoặc đọc về điều này. Tôi chuyển sang google và tìm kiếm clang could be declared with attribute 'noreturn' (oh, vâng, tôi chỉ có thể viết clang nonreturn attribute, nhưng hãy quên nó) và tôi tìm thấy liên kết this với giải thích tốt về thuộc tính này và khả năng đạt được của hiệu suất mà tôi có thể nhận được.

Vì vậy, tôi chạy để thêm thuộc tính này vào nguyên mẫu hàm của tôi (tất nhiên, nếu nó là trình biên dịch gcc hoặc clang; macro sẽ thực hiện việc dò tìm lừa). Oh yeah, với tôi, bất kỳ lợi ích nhỏ nào của sự hoàn hảo (tất nhiên, mà không làm cho mã không thể đọc được) nó là một chiến thắng.

Và không kết thúc ở đây, cách đây một năm, tôi thực hiện return trong một chức năng ở đó một cách cẩn thận là một công tắc được xử lý mặc định (như trong hàm error() ở đây). Nhưng ngay cả như vậy, gcc clains về chức năng mà không trả lại giá trị (Tôi xin lỗi, tôi không nhớ chính xác thông báo lỗi/cảnh báo) làm thế nào nó có thể? không có câu lệnh nào sau khi chuyển đổi, nếu không có trường hợp nào phù hợp, giá trị mặc định được thực hiện và không thực sự quan trọng các câu lệnh dưới đây, nếu có. Nhưng clang nghĩ khác, giống như tôi, và đưa ra một cảnh báo về tuyên bố này, giúp tôi tạo ra mã tốt hơn.

Và đối với loại điều rất nhỏ này, tôi yêu tiếng kêu vang. (Lưu ý: Tôi xin lỗi vì tiếng anh không tốt của tôi. Tiếng Anh không phải là tiếng mẹ đẻ của tôi, nhưng mặc dù tôi đang cố gắng thể hiện tôi ở đây)

+2

Trong số tất cả các lĩnh vực của một chương trình cần "tối ưu hóa", tôi sẽ tưởng tượng rằng hiệu suất thoát khỏi ứng dụng là mối quan tâm ít nhất. –

+0

Việc tối ưu hóa ở đây là 1) bởi trình biên dịch khi nó nhìn thấy thuộc tính "nonreturn"; 2) bởi tôi khi xóa mã chết '-Wunreachable-code' – Jack

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