Elenco dei problemi ABI C ++

Ho visto molte discussioni su come C ++ non abbia un ABI standard nello stesso modo in cui lo fa C. Sono curioso di sapere quali sono esattamente i problemi. Finora, mi sono inventato

  1. Nome mangling
  2. La gestione delle eccezioni
  3. RTTI

Ci sono altri problemi ABI relativi al C ++?

Fuori dalla mia testa:

Specifico C ++:

  • Dove è ansible trovare il parametro “this”.
  • Come vengono chiamate le funzioni virtuali
    • cioè usa un vtable o altro
    • Qual è il layout delle strutture utilizzate per l’implementazione di questo.
  • Come vengono gestite più definizioni
    • Più istanze di modelli
    • Funzioni inline che non erano in linea.
  • Oggetti di durata dell’archiviazione statica
    • Come gestire la creazione (nell’ambito globale)
    • Come gestire la creazione di una funzione locale (come si aggiunge all’elenco di distruttori)
    • Come gestire la distruzione (distruggi in ordine inverso alla creazione)
  • Lei parla di eccezioni. Ma anche come vengono gestite le eccezioni al di fuori di main ()
    • cioè prima o dopo main ()

Generico.

  • Parametro che passa posizioni
  • Posizione del valore di ritorno
  • Allineamento dei membri
  • Imbottitura
  • Registra l’utilizzo (i registri che vengono conservati sono zero)
  • dimensione dei tipi primitivi (come int)
  • formato dei tipi primitivi (formato virgola mobile)

Il grosso problema, secondo la mia esperienza, è la libreria standard C ++. Anche se si disponesse di un ABI che impone come dovrebbe essere strutturata una class, diversi compilatori forniscono diverse implementazioni di oggetti standard come std::string e std::vector .

Non sto dicendo che non sarebbe ansible standardizzare il layout interno degli oggetti della libreria C ++, solo che non è stato fatto prima.

La cosa più simile a un ABI C ++ standard è l’ Itanium C ++ ABI :

questo documento è scritto come una specifica generica, per essere utilizzabile da C ++> implementazioni su una varietà di architetture. Tuttavia, contiene> materiale specifico del processore per l’ABI a 64 bit di Itanium, identificato come tale. ”

Il documento GCC spiega il supporto di questo ABI per C ++:

A partire da GCC 3.2, le convenzioni binarie GCC per C ++ si basano su un ABI C ++ scritto e neutrale rispetto al produttore, progettato per essere specifico per Itanium a 64 bit, ma che include anche specifiche generiche applicabili a qualsiasi piattaforma. Questo ABI C ++ è implementato anche da altri produttori di compilatori su alcune piattaforms, in particolare i sistemi GNU / Linux e BSD

Come è stato sottolineato da @Lindydancer, è necessario utilizzare anche la stessa liberia / runtime standard C ++.

Uno standard ABI per qualsiasi lingua ha davvero bisogno di venire da una determinata piattaforma che vuole supportare una cosa del genere. Gli standard linguistici, in particolare C / C ++, non possono davvero farlo per molte ragioni, ma soprattutto perché una cosa del genere renderebbe il linguaggio meno flessibile e meno portatile e quindi meno utilizzato. C in realtà non ha un ABI definito ma molte piattaforms definiscono (direttamente o indirettamente) una. La ragione per cui questo non sta accadendo con C ++ è perché la lingua è molto più grande e le modifiche sono fatte più spesso. Tuttavia, Herb Sutter ha una proposta molto interessante su come ottenere più piattaforms per creare ABI standard e su come gli sviluppatori possono scrivere codice che utilizza l’ABI in un modo standard:

https://isocpp.org/blog/2014/05/n4028

Sottolinea come C ++ ha un modo standard per collegarsi a una piattaforma C ABI ma non a un C ++ ABI tramite extern “C”. Penso che questa proposta potrebbe fare molto per consentire di definire le interfacce in termini di C ++ anziché di C.

Ho visto molte discussioni su come C ++ non abbia un ABI standard nello stesso modo in cui lo fa C.

Quale standard ABI? L’appendice J nello standard C99 è lunga 27 pagine. Oltre al comportamento indefinito (e alcune implementazioni danno a un UB un comportamento ben definito), copre un comportamento non specificato, un comportamento definito dall’implementazione, un comportamento specifico della locale e estensioni comuni.