Progettazione API libreria C ++

Sto cercando una buona risorsa per conoscere una buona progettazione delle API per le librerie C ++, guardare oggetti / dll condivisi ecc. Ci sono molte risorse per scrivere belle API, belle classi, modelli e così via a livello di sorgente, ma a malapena nulla mettere insieme le cose in libs ed eseguibili condivisi. Libri come il software di progettazione C ++ su larga scala di John Lakos sono interessanti ma ampiamente obsoleti.

Quello che sto cercando è un consiglio, cioè sulla gestione dei modelli. Con i modelli nella mia API finisco spesso con il codice della libreria nel mio eseguibile (o altra libreria), quindi se risolvo un bug lì dentro non posso semplicemente implementare la nuova libreria ma devo ricompilare e ridistribuire tutti i client di quel codice. (e sì, conosco alcune soluzioni come provare ad istanziare almeno le versioni più comuni all'interno della libreria ecc.)

Sto anche cercando altri avvertimenti e cose da tenere a mente per mantenere la compatibilità binaria mentre si lavora su librerie C ++.

Esiste un buon sito Web o un libro su tali cose?

— johannes
fonte

L'ho gestito in questo modo: sivut.koti.soon.fi/~terop/GameApi.html - cioè mentre ci sono modelli all'interno della libreria, nessuno di questi è

— nell'api

std::unique_ptrè roba abbastanza nuova. Cosa pensavi fosse più adatto alla tua API proposta? Il modo in cui hai dovuto gestire manualmente tutte le risorse, garantendo virtualmente perdite e doppie eliminazioni, ad esempio? O il modo in cui molti dei tuoi tipi avevano nomi di una o due lettere, rendendo impossibile dividere il loro scopo?

— DeadMG

@ tp1: Ma non ti sei preoccupato di vedere che li ho gestiti. Hai appena detto "gestiscili" senza farci nulla. Non li ho gestiti e adesso? Invece di utilizzare una classe RAII che non consente tali errori. Se lo avessi usato unique_ptrnon sarebbe possibile scrivere un codice del genere.

— DeadMG

@ tp1: ho notato che Env può essere distrutto. È praticamente tutto. Non sembra esserci alcuna funzionalità per gestire gli oggetti. Se volessi gestire la memoria più finemente di "Tutto ciò che ho mai creato" o "Niente", sembrerebbe che sono fregato.

— DeadMG

Porta qualsiasi conversazione estesa alla Software Engineering Chat . È possibile incorporare qualsiasi informazione utile nella domanda o in una risposta?

— ChrisF

Risposte:

C'è infatti un libro che è esattamente quello che cerchi. Si chiama, abbastanza appropriatamente, API Design per C ++. Il sito web del libro ha il codice sorgente del libro e anche Errata .

— Ingegnere mondiale
fonte

+1 preciso per il libro! Sono venuto per suggerire questo, ma risulta che mi hai battuto.

— zxcdw,

+1: sto finendo di leggere questo libro ed è una grande risorsa. Altamente raccomandato.

— Korchkidu,

Questo è praticamente impossibile. Il semplice fatto è che a volte è necessario il compilatore per fare un lavoro e non si può semplicemente scartare quella necessità. Non esiste alcuna funzione che non può creare std::vectoruna libreria solo intestazione. Il compilatore può far funzionare molte magie, ma non puoi averle senza invocarlo, e questo è un dato di fatto.

Ecco cosa puoi fare: non usare modelli dove non ne hai bisogno. Ecco cosa non puoi fare: nient'altro.

Il semplice fatto è che la ricompilazione con la nuova versione in realtà non è un grosso onere rispetto ai vantaggi di prestazioni, sicurezza e funzionalità che puoi ottenere con le librerie tipizzate staticamente.

— DeadMG
fonte

L'ho citato come esempio a cui pensare. quello che sto cercando è una guida su altri problemi simili per i quali dovrei prepararmi e le migliori pratiche per gestirli.

— johannes,

Bene, se tutte le nuove versioni che infrangono la compatibilità ABI vengono inserite in un nuovo spazio dei nomi inline, che importa se si tratta di una libreria solo di intestazione o no?

— Deduplicatore,