BACKGROUND: opzionali
Dal 2002 sto costruendo lentamente la mia libreria Windows Native C ++ . E diciamo che ho saltato 150KLOC (codice riutilizzabile) avendo tutto ciò di cui ho bisogno e il sink della cucina (dalla maggior parte delle API di Windows è stato oggettivato a un un'implementazione decente del client IMAP4 e il client XMLRPC di WordPress per la pubblicazione di massa ... Faccio marketing di affiliazione e strumenti SEO) . Non è ancora .NET
ma non è poi così lontano:)
Le sole librerie di terze parti utilizzate in questo sono ZLib
, MySQL
e SQLite
. Tutto il resto è costruito da zero usando STL
e / o Windows API
. (Ho ancora un lettore / scrittore PDF per implementare, IOCP tutte le cose della rete, e c'è sempre spazio per più lavoro ...)
Negli ultimi 1,5 anni ho lavorato intensamente all'aggiornamento per C ++ 11. Spostare la semantica dove dovuto, (esplicito) operatori bool, costrutti concatenati e molto altro di quello che (modesto MSVC) C ++ 11 ci ha portato. Plus CRTP per chiamate genitore / figlio incatenate, uso minimo di virtuals, rigore costante. E riuscito.
Recentemente ho preso seriamente in considerazione l'idea di pubblicarlo. È un'enorme quantità di lavoro che ho fatto solo a mio vantaggio e presumo che ci siano ancora Windows C++
sviluppatori che potrebbero utilizzare una cosa così. E per farlo, ha continuato a leggere le pratiche del codice C ++ e le linee guida per la progettazione dell'API / libreria . E 'stato fantastico! Ho inchiodato l'80-85% delle migliori pratiche di codifica da solo. Con alcune cose che affronterò presto e una domanda importante .
DOMANDA
Attualmente l'intera libreria è piuttosto basata su modelli e solo sull'intestazione. Ciò significa che tutto il codice si trova nel corpo delle classi. Non è molto facile da gestire, ma va bene. Io comprimo il codice, uso #pragma region
s e strutturo le cose con precisione.
MA SONO MOLTO tentato, dopo aver letto diverse linee guida per la codifica della libreria C ++, per suddividerlo in .hpp
+ .inl
file. Fatto sperimentalmente per alcune classi e aumenta la leggibilità e rende più facile per gli altri trattare con (anche se è un po 'più difficile da scrivere) .
So dove si trova (linea di codice, funzionalità) in qualsiasi momento. Ma altri utenti potrebbero desiderare una rapida panoramica di una dichiarazione di classi ... e la definizione SOLO se / quando necessario (debugging) .
- Quali sono le pratiche accettate e / o preferite per quanto riguarda la divisione delle dichiarazioni dalle definizioni. Preferiresti avere solo le intestazioni con codice in-body o codice separato dalla dichiarazione della funzione?
- Quali sono le pratiche correnti di altre librerie? Ho sempre scritto tutto da solo. Non è così veloce come gli altri lo fanno. Tranne le 3 librerie menzionate sopra, devo ancora usare un altro codice di terze parti.
This is an important question for me because it's a one way road. I can't refactor it the other way later on so any feedback matters and is appreciated...
Grazie .