Perché boost include due diverse versioni di strong_typedef.hpp?

Question

Mentre stavo creando un progetto di recente, ho notato che ho ricevuto un avviso del compilatore (convertito in errore) sulla macro BOOST_STRONG_TYPEDEF ridefinita. Dopo ulteriori indagini ho notato che ci sono due diverse versioni di strong_typedef.hpp incluse in boost: una al livello superiore e una entro serialization/.

C'è anche una differenza tra le due versioni, non solo una versione duplicata della macro. La versione di livello superiore non in modo esplicito il valore-init sua T mentre la versione serializzazione fa:

Codice tagli:

boost/strong_typedef.hpp:

T t;              \ 
    explicit D(const T t_) : t(t_) {};       \ 
    D(){};              \ 
    D(const D & t_) : t(t_.t){}         \ 

boost/serialization/strong_typedef.hpp:

T t;              \ 
    explicit D(const T t_) : t(t_) {};       \ 
    D(): t() {};            \ 
    D(const D & t_) : t(t_.t){}         \ 

Perché sono ci sono due diverse versioni della macro e quale ha più senso come implementazione? Quello che costringerà i tipi built-in a essere inizializzati o quello che non lo fa (il più fedelmente possibile mimando il tipo sottostante che è fortemente tipizzato)?

Answer 1

Sembra che la directory boost/strong_typedef.hpp sia un artefatto storico.

La mancanza di inizializzazione esplicita del membro t era un bug in boost/serialization/strong_typedef.hpp un paio di anni fa nella revisione svn 71183. Vedere the bug ticket.

Nel bagagliaio Subversion di Boost, boost/strong_typedef.hpp è un file in gran parte vuoto che dice:

#error "This header is deprecated. Please use: boost/serialization/strong_typedef.hpp" 

Questo cambiamento, r48575, è stato fatto nel 2008 - non so il motivo per cui non è mai stata fusa in un comunicato . Forse perché romperebbe gli utenti senza un sacco di rialzi o forse è una svista. Lo stesso cambiamento (r48575) è ciò che ha creato boost/serialization/strong_typedef.hpp nel bagagliaio.

Se non vogliono rompere gli utenti esistenti, allora forse il file deprecato dovrebbe solo includere il file in boost/serialization quindi c'è una singola implementazione canonica. In ogni caso, sembrerebbe che se si può evitare di usare boost/strong_typedef.hpp in favore di usare quello in serialization, questo è quello che suggerirei.

Come nota a margine, tenere a mente che un anno fa, l'autore di Boost serializzazione (e strong_typedef.hpp), Bob Ramey, posted a comment in another bug ticket su strong_typedef.hpp che potreste trovare interessante:

Io non credo che il la libreria di serializzazione lo usa di più. Certo che è ancora lì. Non ho idea se qualcuno lo usa.

Answer 2

Io sono l'autore di entrambe le versioni di boost/strong_typedef.hpp.

A causa di obiezioni stridenti a includere direttamente nell'intestazione base di boost, sono passato alla libreria di serializzazione. Per mantenere la compatibilità con le versioni precedenti, l'ho lasciato nella directory di intestazione base di boost. Ho dimenticato di unire questo file nel ramo di rilascio per far apparire l'avviso. Ho anche dimenticato di cambiare il nome in BOOST_SERIALIZATION_STRONG_TYPEDEF.E da allora ho aggiunto l'inizializzazione alla classe base. Credo che da quando ho fatto lo split, ho incluso una correzione nella versione nella libreria di serializzazione.

Ho appena guardato la libreria di serializzazione e l'utilizzo di strong_typedef è ora minimo. Immagino che riuscirò a rimuoverlo completamente. Quindi, sarebbe completamente scomparso.

In realtà dovrebbe essere un'utilità separata. Ma non posso davvero occuparmi di tutto ciò che richiede boost (test, documenti, build, revisione). E boost non ha davvero un buon posto per queste utility di sola intestazione di piccole dimensioni. Un giorno ho sperato che queste piccole utility di cui avevo bisogno per la libreria di serializzazione sarebbero migrate alla base di boost. Ma sono venuto per essere scoraggiato da quell'idea.