C ++ neden bir LR (1) ayrıştırıcısıyla ayrıştırılamıyor?

Ayrıştırıcılar ve ayrıştırıcı jeneratörleri hakkında okuyordum ve bu ifadeyi wikipedia'nın LR ayrıştırma sayfasında buldum:

Birçok programlama dili, bir LR ayrıştırıcısının bazı varyasyonları kullanılarak ayrıştırılabilir. Dikkate değer bir istisna C ++.

Neden böyle? C ++ 'ın hangi özel özelliği LR ayrıştırıcılarıyla ayrıştırmanın imkansız olmasına neden olur?

Google'ı kullanarak, yalnızca C'nin LR (1) ile mükemmel bir şekilde ayrıştırılabileceğini buldum, ancak C ++ LR (∞) gerektiriyor.

Lambda Ultimate'da C ++ için LALR dilbilgisini tartışan ilginç bir konu var .

C ++ ayrıştırma tartışmasını içeren bir doktora tezine bir bağlantı içerir, bu şunları belirtir:

"C ++ dilbilgisi belirsiz, bağlama bağlı ve potansiyel olarak bazı belirsizlikleri çözmek için sonsuz bir ileriye ihtiyaç duyuyor".

Birkaç örnek vermeye devam etmektedir (pdf'in 147. sayfasına bakınız).

Örnek:

int(x), y, *const z;

anlamı

int x;
int y;
int *const z;

Karşılaştırmak:

int(x), y, new int;

anlamı

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

(virgülle ayrılmış bir ifade).

İki belirteç dizisi aynı ilk alt diziye, ancak son öğeye bağlı olan farklı ayrıştırma ağaçlarına sahiptir. Belirsiz olandan önce keyfi olarak birçok jeton olabilir.

LR ayrıştırıcıları tasarım gereği belirsiz dilbilgisi kurallarını kullanamazlar. (Fikirlerin çalışıldığı 1970'lerde teoriyi daha kolay hale getirdi).

C ve C ++ aşağıdaki ifadelere izin verir:

x * y ;

İki farklı ayrımı vardır:

1. X türüne işaretçi olarak y'nin bildirimi olabilir.
2. Cevabı atmak, x ve y çarpımı olabilir.

Şimdi, ikincisinin aptal olduğunu ve göz ardı edilmesi gerektiğini düşünebilirsiniz. Çoğu sizinle aynı fikirde; ancak, bunun bir yan etkisi olabileceği durumlar vardır (örneğin, çarpma aşırı yüklenmişse). ama mesele bu değil. Nokta var olan iki farklı ayrıştırır ve bu nedenle bir program bu şekline bağlı olarak farklı anlamlara gelebilir gerektiğini çözümlenir edilmiştir.

Derleyici uygun koşullar altında uygun olanı kabul etmelidir ve başka herhangi bir bilginin yokluğunda (örneğin, x türü bilgisi) daha sonra ne yapılacağına karar vermek için her ikisini de toplamalıdır. Dolayısıyla bir dilbilgisi buna izin vermelidir. Bu da dilbilgisini belirsiz kılar.

Bu nedenle saf LR ayrıştırma bunu başaramaz. Antlr, JavaCC, YACC veya geleneksel Bison gibi yaygın olarak bulunan diğer ayrıştırıcı jeneratörler ve hatta "saf" bir şekilde kullanılan PEG tarzı ayrıştırıcılar da olamaz.

Çok daha karmaşık durumlar vardır (şablonun sözdizimi ayrıştırılması keyfi bir önden okuma gerektirirken, LALR (k) çoğu k jetonunu ileriye bakabilir), ancak saf LR (veya diğerleri) ayrıştırmasını vurmak için yalnızca bir karşı örnek alır .

Çoğu gerçek C / C ++ ayrıştırıcısı bu örneği, fazladan bir saldırı ile bir tür deterministik ayrıştırıcı kullanarak işler: sembol tablosu koleksiyonu ile ayrıştırmayı iç içe geçirirler ... böylece "x" ile karşılaşıldığında, ayrıştırıcı x'in bir tür ya da değil ve böylece iki potansiyel çözüm arasında seçim yapabilir. Ancak bunu yapan bir ayrıştırıcı bağlamdan bağımsız değildir ve LR ayrıştırıcıları (saf olanlar, vs.) bağlamdan bağımsızdır.

Bu dezavantajı yapmak için LR ayrıştırıcılarına hile ve kural başına azaltma süresi semantik kontrolleri eklenebilir. (Bu kod genellikle basit değildir). Diğer ayrıştırıcı türlerinin çoğunda, ayrıştırma işleminin çeşitli noktalarına anlamsal denetimler eklemek için bazı araçlar vardır, bunlar bunu yapmak için kullanılabilir.

Yeterince hile yaparsanız, LR ayrıştırıcılarının C ve C ++ için çalışmasını sağlayabilirsiniz. GCC adamları bir süre yaptılar, ancak elle kodlanmış ayrıştırma için vazgeçtiler, bence daha iyi hata teşhisi istediler.

Yine de, güzel ve temiz olan ve C ve C ++ 'ı herhangi bir sembol tablosu korsanlığı olmadan gayet iyi ayrıştıran başka bir yaklaşım var: GLR ayrıştırıcılar . Bunlar tam bağlamsız ayrıştırıcılardır (etkili bir şekilde sonsuz görünüme sahip). GLR ayrıştırıcıları, her iki ayrışmayı da kabul ederek belirsiz ayrışmayı temsil eden bir "ağaç" (aslında çoğunlukla ağaç gibi yönlendirilmiş asiklik bir grafik) üretir. Ayrıştırma sonrası geçiş belirsizlikleri çözebilir.

Bu tekniği DMS Software Reengineering Tookit için C ve C ++ ön uçlarında kullanıyoruz (Haziran 2017 itibariyle bunlar MS ve GNU lehçelerinde tam C ++ 17'yi ele alıyor). Milyonlarca satır büyük C ve C ++ sistemlerini işlemek için kullanılmıştır, tam, kesin ayrıştırmalar, kaynak kodunun tüm ayrıntılarını içeren AST'ler üretmektedir. ( C ++ 'ın en sinir bozucu ayrışması için AST'ye bakınız. )

Sorun asla böyle tanımlanmadı, oysa ilginç olmalı:

Bu yeni dilbilgisinin "bağlamsız" bir yacc ayrıştırıcısı tarafından mükemmel şekilde ayrıştırılabilmesi için gerekli olabilecek en küçük C ++ dilbilgisi değişiklikleri grubu nedir? (sadece bir 'hack' kullanmaktan geçer: typename / tanımlayıcı anlam ayrımı, ayrıştırıcı, her typedef / class / struct için lexer'ı bilgilendirir)

Birkaç tane görüyorum:

1. Type Type;yasak. Tür adı olarak bildirilen bir tanımlayıcı, tür adı olmayan bir tanımlayıcı struct Type Typeolamaz (belirsiz olmayan ve yine de izin verilebilir not ).

   3 tür vardır names tokens:

   • types : yerleşik türü veya typedef / class / struct nedeniyle
   • Şablon fonksiyonlar
   • tanımlayıcılar: fonksiyonlar / yöntemler ve değişkenler / nesneler

   Şablon işlevlerini farklı jetonlar olarak değerlendirmek func<belirsizliği çözer . Eğer funcbir şablon işlevi adıdır, o zaman <başka türlü, bir şablon parametresi listesinin başında olmalıdır funcbir işlev işaretçisi ve <karşılaştırma operatörüdür.

2. Type a(2);bir nesne örneğidir. Type a();ve Type a(int)fonksiyon prototipleridir.

3. int (k); tamamen yasak, yazılmalı int k;

4. typedef int func_type(); ve typedef int (func_type)();yasaktır.

   Typedef işlevinin, typedef işlev işaretçisi olması gerekir: typedef int (*func_ptr_type)();

5. şablon özyineleme 1024 ile sınırlıdır, aksi takdirde derleyiciye seçenek olarak artırılmış bir maksimum değer aktarılabilir.

6. int a,b,c[9],*d,(*f)(), (*g)()[9], h(char); ile yasaklanmış olabilir, int a,b,c[9],*d; int (*f)();

   int (*g)()[9];

   int h(char);

   işlev prototipi veya işlev işaretçisi bildirimi başına bir satır.

   Çok tercih edilen bir alternatif, korkunç işlev işaretçisi sözdizimini değiştirmek,

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

   şu şekilde yeniden senkronize ediliyor:

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

   bu, döküm operatörü ile uyumlu (int (MyClass::*)(char*))

7. typedef int type, *type_ptr; de yasaklanmış olabilir: typedef başına bir satır. Böylece

   typedef int type;

   typedef int *type_ptr;

8. sizeof int, sizeof char, sizeof long longVe co. her kaynak dosyada bildirilebilir. Bu nedenle, türü kullanan her kaynak dosya intile başlamalıdır.

   #type int : signed_integer(4)

   ve unsigned_integer(4)bu #type direktifin dışında yasaklanacaktı sizeof int, bu birçok C ++ başlığında mevcut olan aptal belirsizlik için büyük bir adım olurdu.

Yeniden eşitlenmiş C ++ 'ı uygulayan derleyici, belirsiz sözdizimini kullanan bir C ++ kaynağı ile karşılaşırsa, source.cppçok fazla ambiguous_syntaxklasör taşıyacak ve source.cppderlemeden önce otomatik olarak net bir çeviri oluşturacaktır .

Biraz biliyorsanız lütfen belirsiz C ++ sözdiziminizi ekleyin!

Benim de görebileceğiniz gibi burada cevap , C ++ deterministically nedeniyle tip çözünürlük aşamasında (tipik sonrası ayrıştırma) bir LL veya LR parser tarafından ayrıştırılamaz sözdizimi değişen içeren işlemlerin sırasını ve AST dolayısıyla temel şekli ( tipik olarak bir birinci-aşama ayrışması ile sağlanması beklenmektedir).

Bence cevaba oldukça yakınsın.

LR (1), soldan sağa ayrıştırma işleminin içeriğe bakmak için yalnızca bir jetona ihtiyaç duyduğu anlamına gelirken, LR (∞) sonsuz bir ileriye bakış anlamına gelir. Yani, ayrıştırıcı şimdi nerede olduğunu bulmak için gelen her şeyi bilmek zorunda kalacaktı.

C ++ 'daki "typedef" sorunu ayrıştırılırken bir sembol tablosu oluşturan bir LALR (1) ayrıştırıcısı ile ayrıştırılabilir (saf bir LALR ayrıştırıcısı değil). "Şablon" sorunu muhtemelen bu yöntemle çözülemez. Bu tür LALR (1) ayrıştırıcısının avantajı, dilbilgisinin (aşağıda gösterilmiştir) bir LALR (1) dilbilgisi (belirsizlik olmaması) olmasıdır.

/* 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. */

Aşağıdaki giriş sorunsuz bir şekilde çözümlenebilir:

 typedef int x;
 x * y;

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

LRSTAR ayrıştırıcı jeneratör yukarıda dilbilgisi notasyonu okur ve bir ayrıştırıcı oluşturduğu kolları ayrıştırma ağacında veya AST Belirsizlik olmadan "typedef" sorunu. (Açıklama: Ben LRSTAR'ı yaratan adam benim.)