Tại sao C ++ không thể được phân tích cú pháp bằng trình phân tích cú pháp LR (1)?

Tôi đã đọc về trình phân tích cú pháp và trình tạo trình phân tích cú pháp và tìm thấy tuyên bố này trong trang phân tích cú pháp LR của wikipedia:

Nhiều ngôn ngữ lập trình có thể được phân tích cú pháp bằng cách sử dụng một số biến thể của trình phân tích cú pháp LR. Một ngoại lệ đáng chú ý là C ++.

Tại sao nó như vậy? Tính chất đặc biệt nào của C ++ khiến nó không thể phân tích cú pháp với trình phân tích cú pháp LR?

Sử dụng google, tôi chỉ thấy rằng C có thể được phân tích cú pháp hoàn hảo với LR (1) nhưng C ++ yêu cầu LR ().

Có một chủ đề thú vị trên Lambda the Ultimate thảo luận về ngữ pháp LALR cho C ++ .

Nó bao gồm một liên kết đến một luận án tiến sĩ bao gồm một cuộc thảo luận về phân tích cú pháp C ++, trong đó nêu rõ:

"Ngữ pháp C ++ không rõ ràng, phụ thuộc vào ngữ cảnh và có khả năng đòi hỏi phải có cái nhìn vô hạn để giải quyết một số sự mơ hồ".

Nó tiếp tục đưa ra một số ví dụ (xem trang 147 của pdf).

Ví dụ là:

int(x), y, *const z;

Ý nghĩa

int x;
int y;
int *const z;

So với:

int(x), y, new int;

Ý nghĩa

(int(x)), (y), (new int));

(một biểu thức được phân tách bằng dấu phẩy).

Hai chuỗi mã thông báo có cùng một chuỗi con ban đầu nhưng các cây phân tích khác nhau, phụ thuộc vào phần tử cuối cùng. Có thể có nhiều mã thông báo tùy ý trước khi định dạng.

Trình phân tích cú pháp LR không thể xử lý các quy tắc ngữ pháp mơ hồ, theo thiết kế. (Làm cho lý thuyết trở nên dễ dàng hơn vào những năm 1970 khi các ý tưởng đang được thực hiện).

Cả C và C ++ đều cho phép tuyên bố sau:

x * y ;

Nó có hai phân tích khác nhau:

1. Nó có thể là khai báo của y, như con trỏ để gõ x
2. Nó có thể là bội số của x và y, ném đi câu trả lời.

Bây giờ, bạn có thể nghĩ rằng cái sau là ngu ngốc và nên được bỏ qua. Hầu hết sẽ đồng ý với bạn; tuy nhiên, có những trường hợp nó có thể có tác dụng phụ (ví dụ: nếu bội số bị quá tải). Nhưng đó không phải là vấn đề. Vấn đề là ở đó là hai phân tích khác nhau, và do đó một chương trình có thể có nghĩa là những thứ khác nhau tùy thuộc vào cách này nên đã được phân tích cú pháp.

Trình biên dịch phải chấp nhận thông tin phù hợp trong các trường hợp thích hợp và trong trường hợp không có bất kỳ thông tin nào khác (ví dụ: kiến ​​thức về loại x) phải thu thập cả hai để quyết định sau này phải làm gì. Do đó, một ngữ pháp phải cho phép điều này. Và điều đó làm cho ngữ pháp mơ hồ.

Do đó, phân tích cú pháp thuần túy không thể xử lý việc này. Cũng không thể có nhiều trình tạo trình phân tích cú pháp có sẵn rộng rãi khác, như Antlr, JavaCC, YACC hoặc Bison truyền thống, hoặc thậm chí các trình phân tích cú pháp kiểu PEG, được sử dụng theo cách "thuần túy".

Có rất nhiều trường hợp phức tạp hơn (cú pháp phân tích cú pháp yêu cầu tìm kiếm tùy ý, trong khi LALR (k) có thể nhìn về phía trước hầu hết các mã thông báo k), nhưng chỉ mất một ví dụ để bắn hạ phân tích thuần túy (hoặc các mẫu khác).

Hầu hết các trình phân tích cú pháp C / C ++ thực sự xử lý ví dụ này bằng cách sử dụng một số loại trình phân tích cú pháp xác định có thêm một hack: chúng đan xen phân tích cú pháp với bộ sưu tập bảng ký hiệu ... để đến lúc gặp "x", trình phân tích cú pháp biết nếu x là một loại hoặc không, và do đó có thể chọn giữa hai phân tích tiềm năng. Nhưng một trình phân tích cú pháp không thực hiện ngữ cảnh này và các trình phân tích cú pháp LR (các trình phân tích thuần túy, v.v.) không có ngữ cảnh (tốt nhất).

Người ta có thể gian lận và thêm các kiểm tra ngữ nghĩa theo thời gian giảm theo quy tắc trong các trình phân tích cú pháp LR để thực hiện định hướng này. (Mã này thường không đơn giản). Hầu hết các loại trình phân tích cú pháp khác có một số phương tiện để thêm kiểm tra ngữ nghĩa tại các điểm khác nhau trong phân tích cú pháp, có thể được sử dụng để làm điều này.

Và nếu bạn gian lận đủ, bạn có thể làm cho trình phân tích cú pháp LR hoạt động cho C và C ++. Các anh chàng GCC đã làm một lúc, nhưng đã từ bỏ việc phân tích cú pháp bằng tay, tôi nghĩ bởi vì họ muốn chẩn đoán lỗi tốt hơn.

Mặc dù vậy, có một cách tiếp cận khác, rất hay và sạch và phân tích cú pháp C và C ++ tốt mà không cần bất kỳ trình hack bảng biểu tượng nào: trình phân tích cú pháp GLR . Đây là các trình phân tích cú pháp miễn phí ngữ cảnh đầy đủ (có cái nhìn vô hạn hiệu quả). Các trình phân tích cú pháp GLR đơn giản chấp nhận cả hai phân tích cú pháp, tạo ra một "cây" (thực ra là một biểu đồ chu kỳ có hướng chủ yếu giống như cây) đại diện cho phân tích mơ hồ. Một vượt qua phân tích cú pháp có thể giải quyết sự mơ hồ.

Chúng tôi sử dụng kỹ thuật này trong giao diện C và C ++ cho Tookit Tái cấu trúc phần mềm DMS của chúng tôi (tính đến tháng 6 năm 2017, chúng xử lý đầy đủ C ++ 17 theo phương ngữ MS và GNU). Chúng đã được sử dụng để xử lý hàng triệu dòng hệ thống C và C ++ lớn, với các phân tích cú pháp chính xác, đầy đủ tạo ra AST với các chi tiết đầy đủ về mã nguồn. (Xem phân tích vexing nhất của AST cho C ++. )

Vấn đề không bao giờ được định nghĩa như thế này, trong khi nó sẽ rất thú vị:

bộ sửa đổi nhỏ nhất đối với ngữ pháp C ++ cần thiết là gì để ngữ pháp mới này có thể được phân tích cú pháp hoàn hảo bởi trình phân tích cú pháp yacc "không ngữ cảnh"? (chỉ sử dụng một 'hack': định dạng tên / định danh, trình phân tích cú pháp thông báo từ vựng của mỗi typedef / class / struct)

Tôi thấy một vài cái:

1. Type Type;bị cấm. Một mã định danh được khai báo là một tên kiểu chữ không thể trở thành một mã định danh không phải là tên chữ (lưu ý struct Type Typekhông mơ hồ và vẫn có thể được cho phép).

   Có 3 loại names tokens:

   • types : kiểu dựng sẵn hoặc do typedef / class / struct
   • chức năng mẫu
   • định danh: hàm / phương thức và biến / đối tượng

   Việc xem xét các hàm mẫu như các mã thông báo khác nhau sẽ giải quyết sự func<mơ hồ. Nếu funclà tên hàm mẫu, thì <phải là đầu của danh sách tham số mẫu, nếu không funclà con trỏ hàm và <là toán tử so sánh.

2. Type a(2);là một đối tượng khởi tạo. Type a();và Type a(int)là các nguyên mẫu chức năng.

3. int (k); là hoàn toàn bị cấm, nên được viết int k;

4. typedef int func_type(); và typedef int (func_type)();bị cấm.

   Một hàm typedef phải là một con trỏ hàm typedef: typedef int (*func_ptr_type)();

5. đệ quy mẫu được giới hạn ở 1024, nếu không, mức tối đa tăng có thể được chuyển qua dưới dạng tùy chọn cho trình biên dịch.

6. int a,b,c[9],*d,(*f)(), (*g)()[9], h(char); cũng có thể bị cấm, thay thế bằng int a,b,c[9],*d; int (*f)();

   int (*g)()[9];

   int h(char);

   một dòng trên mỗi nguyên mẫu hàm hoặc khai báo con trỏ hàm.

   Một thay thế rất được ưa thích sẽ là thay đổi cú pháp con trỏ hàm khủng khiếp,

   int (MyClass::*MethodPtr)(char*);

   được nối lại như:

   int (MyClass::*)(char*) MethodPtr;

   điều này được kết hợp với các nhà điều hành diễn viên (int (MyClass::*)(char*))

7. typedef int type, *type_ptr; cũng có thể bị cấm: một dòng trên mỗi typedef. Do đó, nó sẽ trở thành

   typedef int type;

   typedef int *type_ptr;

8. sizeof int, sizeof char, sizeof long longVà đồng. có thể được khai báo trong mỗi tệp nguồn. Vì vậy, mỗi tệp nguồn sử dụng loại intnên bắt đầu bằng

   #type int : signed_integer(4)

   và unsigned_integer(4)sẽ bị cấm bên ngoài #type chỉ thị đó, đây sẽ là một bước tiến lớn đến sizeof intsự mơ hồ ngu ngốc hiện diện trong rất nhiều tiêu đề C ++

Trình biên dịch triển khai C ++ được resyntaxed, nếu gặp một nguồn C ++ sử dụng cú pháp mơ hồ, di chuyển source.cppquá một ambiguous_syntaxthư mục và sẽ tự động tạo một bản dịch rõ ràng source.cpptrước khi biên dịch nó.

Vui lòng thêm cú pháp C ++ mơ hồ của bạn nếu bạn biết một số!

Như bạn có thể thấy trong câu trả lời của tôi ở đây , C ++ chứa cú pháp không thể được phân tích cú pháp bởi trình phân tích LL hoặc LR do giai đoạn phân giải kiểu (thường là phân tích cú pháp) thay đổi thứ tự các hoạt động và do đó hình dạng cơ bản của AST ( thường được dự kiến ​​sẽ được cung cấp bởi một phân tích giai đoạn đầu tiên).

Tôi nghĩ rằng bạn khá gần với câu trả lời.

LR (1) có nghĩa là phân tích cú pháp từ trái sang phải chỉ cần một mã thông báo để nhìn về phía trước cho bối cảnh, trong khi đó LR () có nghĩa là nhìn về phía trước vô hạn. Đó là, trình phân tích cú pháp sẽ phải biết tất cả mọi thứ đang đến để tìm ra vị trí hiện tại của nó.

Vấn đề "typedef" trong C ++ có thể được phân tích cú pháp bằng trình phân tích cú pháp LALR (1) để xây dựng bảng ký hiệu trong khi phân tích cú pháp (không phải là trình phân tích cú pháp LALR thuần túy). Vấn đề "mẫu" có lẽ không thể giải quyết được bằng phương pháp này. Ưu điểm của loại trình phân tích cú pháp LALR (1) này là ngữ pháp (hiển thị bên dưới) là một ngữ pháp LALR (1) (không mơ hồ).

/* C Typedef Solution. */

/* Terminal Declarations. */

   <identifier> => lookup();  /* Symbol table lookup. */

/* Rules. */

   Goal        -> [Declaration]... <eof>               +> goal_

   Declaration -> Type... VarList ';'                  +> decl_
               -> typedef Type... TypeVarList ';'      +> typedecl_

   VarList     -> Var /','...     
   TypeVarList -> TypeVar /','...

   Var         -> [Ptr]... Identifier 
   TypeVar     -> [Ptr]... TypeIdentifier                               

   Identifier     -> <identifier>       +> identifier_(1)      
   TypeIdentifier -> <identifier>      =+> typedefidentifier_(1,{typedef})

// The above line will assign {typedef} to the <identifier>,  
// because {typedef} is the second argument of the action typeidentifier_(). 
// This handles the context-sensitive feature of the C++ language.

   Ptr          -> '*'                  +> ptr_

   Type         -> char                 +> type_(1)
                -> int                  +> type_(1)
                -> short                +> type_(1)
                -> unsigned             +> type_(1)
                -> {typedef}            +> type_(1)

/* End Of Grammar. */

Các đầu vào sau đây có thể được phân tích cú pháp mà không có vấn đề:

 typedef int x;
 x * y;

 typedef unsigned int uint, *uintptr;
 uint    a, b, c;
 uintptr p, q, r;

Trình tạo trình phân tích cú pháp LRSTAR đọc ký hiệu ngữ pháp ở trên và tạo một trình phân tích cú pháp xử lý vấn đề "typedef" mà không có sự mơ hồ trong cây phân tích hoặc AST. (Tiết lộ: Tôi là người đã tạo ra LRSTAR.)