Progettazione della libreria: fornisce un file di intestazione comune o più intestazioni

Il design in generale è sempre " l'arte per bilanciare gli obiettivi contraddittori ".

Qui hai questi obiettivi:

1. Il framework dovrebbe essere semplice da usare. Se la tua API è costituita da 15 file di intestazione, gli utenti saranno sempre in difficoltà tra quelli da includere e quelli da omettere.
2. Tutte le funzionalità comuni dovrebbero essere in un singolo file di intestazione. Quindi l'I / O di file non deve essere in string.h , ma non vuoi nemmeno i 3% di file di intestazionestring.h.
3. Le dipendenze sono cattive, quindi desideri ridurle al minimo possibile
4. La lettura di enormi file di intestazione è lenta
5. Ogni funzionalità nel file di intestazione rischia di dover includere un altro file di intestazione per renderlo compilabile.

gtk.h ha senso dal momento che vuoi creare un'interfaccia utente per la tua applicazione (punto # 2). Si potrebbe obiettare che le persone dovrebbero includere ciascun widget individualmente, ma in seguito il framework diventerà leggermente più difficile da utilizzare (punto 1).

Se guardi il vecchio codice X11 / Motif, vedrai decine di dichiarazioni #include nella parte superiore del file sorgente ogni C. Compilare un po 'più velocemente, ma ci vogliono ore di lavoro manuale per mantenere questi elenchi.

OTOH, se metti troppe funzionalità nei tuoi file di intestazione, avrai troppe dipendenze e una di esse potrebbe ucciderti (ad esempio, quando questa dipendenza richiede un altro framework con una certa versione - > diavolo di dipendenza ).

Spero che tu ora capisca che non esiste una soluzione; il problema è troppo complesso e deve essere risolto nuovamente ogni volta che viene avviato un nuovo framework.

Modifica

But then there must be a pretty good reason that GTK+ actively prevents including single headers via macro checks. – matthias

Per GTK, le dichiarazioni #include fanno parte dell'API pubblica. Con queste macro, esse sono libere di riorganizzare i file di intestazione, il loro contenuto, i loro nomi e l'ordine di inclusione, in qualsiasi modo a loro piaccia in qualsiasi momento senza rompere un singolo progetto esistente.

Avere tutte le intestazioni in una sola è ottima e migliore, per gli altri è più facile includere una singola intestazione che includere diverse intestazioni.

Un problema di questo tipo di progettazione, in intestazioni grandi come windows.h , gtk.h ancora piccolo rispetto a window.h , il processo di costruzione può rallentare. In windows.h risolviamo questo problema definendo WIN32_LEAN_AND_MEAN per escludere alcune intestazioni non comuni come i socket di Windows e l'API di crittografia per accelerare il processo di costruzione, leggi qui Utilizzo delle intestazioni di Windows .

Anche quando la tua biblioteca cresce, ci sono molte intestazioni e può essere difficile lavorarci, dovrai fare un sacco di macro, lotti e finire con un'intestazione complessa per non rompere la compatibilità con le versioni precedenti.

Anche se personalmente preferisco il design a intestazione singola.