Wrapping pthread e time.h: future proofing o paranoia?

Trovo questo genere di cose inutili e indaffarate nella maggior parte delle situazioni. L'unica volta che riesco a pensare che sia necessario è se pianifichi, dal primo giorno, di scrivere per più librerie.

Altrimenti, se lo fai, per caso, è necessario sostituire i pthread in futuro, pensi davvero che tutte le ipotesi sottostanti su come funzioneranno le varie sfaccettature della biblioteca? Quelli mutex e thread avranno esattamente la stessa semantica?

Se fai , puoi semplicemente scrivere uno shim che emula i nomi dei pthreads quando sarà il momento.

Se non , devi toccare comunque tutto, quindi non hai salvato nulla pre-scrivendo lo shim.

Detto questo, hai una base di codice esistente che funziona. Mentre consiglierei di abbandonare queste sciocchezze su nuovi progetti in corso, non consiglierei MAI di cambiare il modo in cui il codice esistente funziona solo perché le librerie sono fastidiose.

Non so quanti anni abbia il tuo codebase, ma i pthread vengono implementati in modo ben conforme su tutti gli unicatori che contano è una cosa molto recente, guidata tanto dal diradamento della mandria Unix quanto da altro.

Il threading è stato per molto tempo scarsamente definito su comuni box Unix, e più di una piccola variabile tra piattaforme e persino versioni del kernel, posso certamente ricordare le librerie di threading dello spazio utente e il pasticcio di #ifdef che tendeva ad essere richiesto per ottenere un programma multithread su cui costruire Linux e Irix, per non parlare di BSD, Linux, IRIX, Solaris, osX ...., i wrapper erano comuni almeno per ottenere il pasticcio di #defines in un unico posto.

time_t ha avuto anche vari problemi relativi alle lunghezze delle parole e al problema del 2038, posso benissimo vedere anche il volerlo avvolgere, in particolare se il salvataggio di strutture non elaborate su file è una cosa nei tuoi sistemi.

Potrebbe essere che i tuoi senior dev fossero cresciuti con quella roba, e avendo scritto wrapper che funzionano sono riluttanti a cambiare le cose.

Come per la maggior parte dei modelli / architetture software, questa domanda non ha risposta / non risposta. Se queste librerie sono una parte intergrale del tuo software e sono pesantemente utilizzate in tutto il codice, allora sì, scrivere wrapper per quelle librerie non è una cattiva idea. A meno che, ovviamente, la scrittura di wrapper per tali librerie costerebbe più tempo e impegno rispetto all'adattamento del codice a un'altra libreria senza avere un wrapper.