Noi (dovremmo) sapere che i contenitori di libreria standard C++, incluso std :: string, non sono destinati ad essere ereditati da. Ma ancora, C++ 98/03 ci ha permesso di farlo anche se stava portando a bug.I container standard C++ 11 sono "final"?
Ora che la parola chiave final è disponibile, sono quei contenitori di libreria standard contrassegnati con final per impedire un cattivo utilizzo dell'ereditarietà con essi?
In caso contrario, perché?
Il LWG ha discusso questo problema durante la recente riunione a Kona dal 6 al 10 febbraio 2012. Questo è il LWG issue 2113.
Il LWG ha deciso di contrassegnare LWG 2113 come NAD (non un difetto), con la logica che lo standard è già chiaro che le classi esistenti come i container e std::string non possono essere contrassegnate come definitive dall'implementazione.
La discussione ha incluso il fatto che, sebbene possa essere disapprovato derivare da tali classi, è chiaramente legale farlo in C++ 98/03. E renderlo illegale in C++ 11 romperebbe troppo codice.
Aggiornamento
In questo momento, non i tipi di libreria nella current working draft sono contrassegnati final.
std::string non sembra contrassegnato come finale, né gli altri contenitori.
La mia ipotesi sul perché sarebbe che anche se derivante da loro non è generalmente raccomandato, nessuno era abbastanza sicuro di quanto codice di lavoro sarebbe rotto se fosse proibito.
Si noti inoltre che, per quello che vale, final non è tecnicamente una parola chiave: è un identificativo a cui è associato un significato speciale, ma solo in circostanze specifiche. Il codice che conteneva qualcosa come int final; final = 1; funzionerà ancora. Questo è principalmente per compatibilità con le versioni precedenti - almeno nel nuovo codice, è quasi certamente meglio usare final solo per il significato speciale, non come un normale identificatore.
Non sono d'accordo con l'ultima frase. L'intero punto di non renderlo una parola chiave è essere in grado di avere parole chiave basate sul contesto. Non è confuso dire "int finale". Nel contesto, sappiamo esattamente cosa significa, quindi non c'è alcun problema. La confusione si verifica solo con "parole chiave" che possono apparire nello stesso posto delle espressioni. E questo non è il caso qui. –
@NicolBolas Se il tuo obiettivo è supportare solo evidenziatori di sintassi contenenti un compilatore C++ quasi completo, allora sei sicuro. Ma se si evita l'uso di parole chiave sensibili al contesto in altri contesti nel codice futuro, l'evidenziazione della sintassi può essere accurata senza richiedere la stessa complessità. – Yakk
Grazie per aver sistemato il tipo-o Jerry. L'ho avuto in due posti e ho appena aggiustato anche il secondo. Non l'avrei notato senza il tuo aiuto. –
Sicuramente. Mi dispiace, ho perso il secondo. –