Dấu chấm phẩy trong C++?

Question

Lỗi "dấu chấm phẩy bị thiếu" có thực sự cần thiết không? Tại sao không coi nó như một lời cảnh báo?

Khi tôi biên dịch mã này

int f = 1 
int h=2; 

trình biên dịch thông minh nói với tôi rằng nơi tôi đang thiếu nó. Nhưng với tôi nó giống như - "Nếu bạn biết điều đó, chỉ cần đối xử với nó như thể nó là ở đó và đi trước (Sau đó tôi có thể sửa chữa các cảnh báo.)

int sdf = 1, df=2; 
    sdf=1 df =2 

Ngay cả đối với mã này, nó cư xử như nhau đó.. nghĩa là, ngay cả khi nhiều báo cáo (không có;). đang ở trong cùng một dòng, trình biên dịch biết

Vì vậy, tại sao không chỉ loại bỏ yêu cầu này tại sao không cư xử như Python, Visual Basic vv

Tóm tắt? thảo luận

Hai ví dụ/trường hợp bị thiếu và dấu chấm phẩy thực sự sẽ gây ra sự cố.

1.

return 
(a+b) 

này được trình bày như là một trong những khía cạnh tồi tệ nhất của JavaScript. Nhưng, trong trường hợp này, chèn dấu chấm phẩy là một vấn đề cho JavaScript, nhưng không phải là cho C++. Trong C++, bạn sẽ gặp lỗi khác nếu việc chèn ; được thực hiện sau khi trả lại. Đó là, một giá trị trả về bị thiếu.

int *y; 
int f = 1 
*y = 2; 

Đối với điều này tôi đoán, không có cách nào tốt hơn để giới thiệu như tách tuyên bố, đó là một dấu chấm phẩy .

Answer 1

Có nhiều trường hợp cần dấu chấm phẩy.

gì nếu bạn có:

int *y; 
int f = 1 
*y = 2; 

này sẽ được phân tích như

int *y; 
int f = 1 * y = 2; 

Vì vậy, nếu không có sự phẩy nó là mơ hồ.

Answer 2

Đó là rất tốt rằng trình biên dịch C++ không thực hiện việc này. Một trong các khía cạnh tồi tệ nhất của JavaScript là chèn dấu chấm phẩy. Ảnh này:

return 
    (a + b); 

Trình biên dịch C++ sẽ vui vẻ tiếp tục trên dòng kế tiếp như mong đợi, trong khi ngôn ngữ "chèn" dấu chấm phẩy, như JavaScript, sẽ coi nó là "trả về"; và bỏ lỡ "(a + b);".

Thay vì dựa vào sửa lỗi trình biên dịch, hãy tạo thói quen sử dụng dấu chấm phẩy.

Answer 3

Đầu tiên, đây chỉ là một ví dụ nhỏ; bạn có chắc trình biên dịch có thể thông minh cho bạn biết điều gì sai cho mã phức tạp hơn không? Đối với bất kỳ đoạn mã nào? Có phải tất cả các trình biên dịch thông minh nhận ra điều này theo cùng một cách, sao cho một đoạn mã C++ có thể được đảm bảo di động với dấu chấm phẩy bị thiếu?

Thứ hai, C++ được tạo hơn một thập kỷ trước khi tài nguyên máy tính không gần như bây giờ. Thậm chí ngày nay, các bản dựng có thể tốn rất nhiều thời gian. Dấu chấm phẩy giúp phân định rõ ràng các lệnh khác nhau (cho người dùng và trình biên dịch!) Và hỗ trợ cả lập trình viên và trình biên dịch trong việc hiểu những gì đang xảy ra.

Answer 4

Trong các chương trình C, dấu chấm phẩy là dấu phân tách câu lệnh, không phải dấu tách. Bạn có thể muốn đọc this fun article.

Answer 5

+1 cho cả hai.

Dấu chấm phẩy là dấu phân cách dòng lệnh, không giống VB, python, vv C và C++ bỏ qua khoảng trắng trong dòng mã bao gồm cả dấu xuống dòng! Điều này ban đầu là vì lúc khởi động của màn hình máy tính C chỉ có thể đối phó với 80 ký tự của văn bản và như C++ được dựa trên đặc điểm kỹ thuật C nó theo sau.

Tôi có thể đăng câu hỏi "Tại sao tôi phải nhận lỗi về thiếu ký tự trong VB khi tôi thử và viết mã trên nhiều dòng, chắc chắn nếu VB biết vấn đề nó có thể chèn nó?"

Chèn tự động như đã được chỉ ra có thể là một cơn ác mộng, đặc biệt là trên mã kết thúc tốt đẹp trên dòng thứ hai.

Answer 6

; là để thuận tiện cho lập trình viên. Nếu dòng mã rất dài thì chúng ta có thể nhấn enter và đi đến dòng thứ hai bởi vì chúng ta có ; cho dấu tách dòng. Đó là quy ước lập trình. Phải có một dấu tách dòng.

Answer 7

Tôi sẽ không mở rộng nhiều nhu cầu cho các ký tự tiếp tục dấu chấm phẩy và dòng, cả hai đều có ưu điểm và nhược điểm và cuối cùng đó là lựa chọn thiết kế ngôn ngữ đơn giản (mặc dù nó ảnh hưởng đến tất cả người dùng).

Tôi lo lắng hơn về đề xuất cho trình biên dịch là sửa mã.

Nếu bạn đã từng thấy một công cụ tuyệt vời (như ... hum, hãy chọn công cụ merge) và cách nó hoạt động tự động, bạn sẽ rất vui khi trình biên dịch không sửa đổi mã. Cuối cùng, nếu trình biên dịch biết cách sửa mã, thì điều đó có nghĩa là nó biết ý định của bạn, và sự truyền tải suy nghĩ vẫn chưa được thực hiện.

Đối với cảnh báo ? Bất kỳ lập trình viên nào đáng giá muối của nó đều biết rằng các cảnh báo sẽ được coi là lỗi (và biên dịch dừng lại) vì vậy điều gì sẽ là lợi thế?

Answer 8

Có dấu chấm phẩy (hoặc ngắt dòng, chọn một) làm cho trình biên dịch trở nên đơn giản hơn và thông báo lỗi dễ đọc hơn.

Nhưng trái với những gì người khác đã nói, không phải là hình thức phân cách (như là tuyệt đối) là điều cần thiết.

Hãy xem xét, ví dụ: Haskell không có. Ngay cả phiên bản hiện tại của VB cho phép ngắt dòng ở nhiều nơi bên trong một câu lệnh, cũng như Python. Không yêu cầu tiếp tục dòng ở nhiều nơi.

Ví dụ, VB bây giờ cho phép đoạn mã sau:

Dim result = From element in collection 
      Where element < threshold 
      Select element 

Không delimiters tuyên bố, không có sự tiếp tục dòng, nhưng không có sự mơ hồ nào.

Về mặt lý thuyết, điều này có thể được thúc đẩy nhiều hơn nữa. Tất cả không rõ ràng có thể được loại bỏ (một lần nữa, nhìn vào Haskell) bằng cách giới thiệu một số quy tắc. Nhưng một lần nữa, điều này làm cho trình phân tích phức tạp hơn nhiều (nó phải nhạy cảm với ngữ cảnh ở nhiều nơi, ví dụ: ví dụ return của bạn, không thể giải quyết mà không biết loại trả về của hàm). Và một lần nữa, điều này khiến cho việc chẩn đoán có ý nghĩa trở nên khó khăn hơn vì một ngắt dòng có thể có nghĩa là bất kỳ thứ gì để trình biên dịch không thể biết lỗi nào mà người dùng đã thực hiện và thậm chí không trong đó đã xảy ra lỗi.

Answer 9

int sdf = 1,df=2; 
sdf=1 df =2 

Tôi nghĩ vấn đề chung là nếu không có sự chấm phẩy không có nói gì các lập trình viên có thể thực sự có nghĩa (ví dụ có thể-có dòng thứ hai được dự định như sdf = 1 + df - 2; với lỗi chính tả nghiêm trọng). Một cái gì đó như thế này cũng có thể là kết quả của lỗi chính tả hoàn toàn và có ý nghĩa nào đó, vì vậy nó có thể không phải là một ý tưởng hay sau khi tất cả để có trình biên dịch "sửa lỗi" âm thầm.

Bạn cũng có thể nhận thấy rằng bạn thường nhận được "dấu chấm phẩy dự kiến" trong đó vấn đề thực sự không phải là thiếu dấu chấm phẩy mà thay vào đó là một thứ hoàn toàn khác. Hãy tưởng tượng một biểu thức không đúng định dạng mà trình biên dịch có thể có ý nghĩa bằng cách lặng lẽ đi và chèn dấu chấm phẩy.

Dấu chấm phẩy có vẻ có vẻ thừa nhưng đây là cách đơn giản để người lập trình xác nhận "có, đó là ý định của tôi".

Ngoài ra, cảnh báo thay vì lỗi trình biên dịch quá yếu. Mọi người biên dịch mã với cảnh báo, bỏ qua cảnh báo họ nhận được, và AFAIK tiêu chuẩn không bao giờ quy định những gì trình biên dịch phải cảnh báo.