2010-02-27 8 views
43

La libreria Loki implementa alcuni concetti molto diffusi (puntatore intelligente, visitatore, fabbrica, ecc.). Il libro associato "Modern C++ Design" è spesso menzionato, ma la libreria stessa non è ampiamente utilizzata. Perché?Perché la libreria Loki non è più utilizzata?

La maggior parte degli sviluppatori sembra preferire Boost. In particolare, perché le persone spesso decidono di usare i puntatori intelligenti di Boost piuttosto che quelli di Loki?

+23

Nessuno ha bisogno di un puntatore intelligente con 6 parametri di modello. –

+4

Loki non può essere compilato per errore da nessun compilatore mainstream quando è stato pubblicato. Alexandrescu è un tipo intelligente. Troppo intelligente per me. –

+4

@johannes: la maggior parte dei parametri del modello hanno valori predefiniti, quindi non è necessario impostarli. E potresti semplicemente usare typedef per associare alcuni parametri del template. – Frank

risposta

11

Si desidera utilizzare una libreria che il prossimo programmatore conoscerà e che sarà ben supportata in futuro, in modo da scegliere una libreria principale. Poiché è una grande quantità di persone, molte persone lo usano, quindi diventa la scelta predefinita.

4

Parlando come qualcuno che ha usato un po 'della libreria Boost, e ha anche guardato a Loki più di una volta, il problema più grande è stata la scarsità di documentazione. Inoltre, Loki utilizza alcuni dei bit più pelosi dei modelli C++. Roba eccitante, ma anche piuttosto scoraggiante.

+4

* "Loki utilizza alcuni dei bit più pelosi dei modelli C++" * - così Boost, o sto fraintendendo qualcosa? –

+6

Vedere il file 'shared_ptr' faq: * La parametrizzazione scoraggia gli utenti. Il modello shared_ptr viene elaborato con cura per soddisfare le esigenze comuni senza un'estesa parametrizzazione. Un giorno potrebbe essere inventato un puntatore intelligente altamente configurabile che è anche molto facile da usare e molto difficile da usare impropriamente. Fino ad allora, shared_ptr è il puntatore intelligente di scelta per una vasta gamma di applicazioni. (Chi è interessato a puntatori intelligenti basati su policy dovrebbe leggere Modern C++ Design di Andrei Alexandrescu.) * –

+4

@litb: Come ho detto sull'IRC, non sono d'accordo. Mi è sembrato più naturale usare il puntatore intelligente del loki e poi quello di boost. Se volessi che il mutex si bloccasse sul puntatore intelligente di loki, dovevo solo inserire una classe mutex per questo. Il puntatore intelligente di Loki è la soluzione più generica che ho trovato sul problema. A volte rende l'uso più facile. –

19

Loki è una sorta di ricerca/prova di concetto. Alexandrescu spinge nuove idee, altre persone adottano quelle per il mondo reale. Anche boost::shared_ptr è quasi letteralmente in TR1.

2

Ho usato Loki una volta per un piccolo strumento (fondamentalmente un interprete) e in realtà mi è piaciuto. I miei colleghi erano meno entusiasti della biblioteca, quindi il suo uso è rimasto limitato a questo piccolo sottoprogetto.

6

Io in realtà preferisco il modo di fare di Loki e ho contribuito a Loki stesso a decorare un pattern che ora si trova nel tracker perché il progetto per quanto ne so non viene più mantenuto.
Io uso boost_patch_pointer solo perché sarà lo standard molto presto, potrei non gradire il fatto che non posso personalizzarlo per agire esattamente come voglio che agisca ma devo conviverci.
L'utilizzo della libreria standard è importante in quanto mantiene il codice gestibile da altri programmatori. Se è open source e vuoi sperimentare, vai avanti e usa Loki. Nessuno ti sta fermando.
In realtà, Windows Vista utilizza alcune delle funzionalità di Loki.
Immagino che non stiano usando le implementazioni ridondanti di puntatori e visitatori intelligenti.

16

Loki soffre di una buona libreria che tocca diverse aree funzionali (supporto per metaprogamodello con alcune applicazioni specifiche: puntatori intelligenti, singoletti, oggetti funzione, guardie di campo ecc.), Mentre boost è una raccolta di molte librerie in genere esauriente coprendo ogni area funzionale e molto più altamente sintonizzati per la portabilità (prima).

Quando 9 uccelli su 10 possono essere uccisi con la stessa pietra, molte persone iniziano con boost e riempiono gli spazi con le librerie di terze parti. È molto difficile competere con la spinta se si sovrappongono. Dato che non si sovrappone con molto di spinta, le persone scaricheranno/installeranno comunque boost per ottenere l'altra funzionalità, quindi a meno che non inchiodi un'area in cui la spinta è debole e la differenza è significativa per il progetto, si "sistemeranno" "per aumentare anche lì.

Inoltre, Alexandrescu ha ripetuto i tentativi di far entrare Loki in boost, e alcuni degli autori chiave del boost non erano cooperativi. La mia opinione personale è che vogliono il più completo ma molto meno user-friendly MPL per avere più "market share": come autori della libreria e dei libri cartacei che sono l'unica documentazione decente (in netto contrasto con la maggior parte degli altri boost biblioteche che hanno un'eccellente documentazione online), ne fanno abbastanza bene.

Se qualcuno è offeso e non è d'accordo con questa analisi, sono tutto orecchie.

Un altro problema pratico con il codice estremamente parametrizzata è che in progetti di grandi dimensioni in cui diversi sviluppatori/squadre lavorano in modo indipendente, faranno spesso finiscono con sottilmente diverse istanze dello stesso modello piuttosto arbitrariamente. Questo rende più difficile per passare valori tra tali sottosistemi: il ricevitore può essere necessario:

  • essere parametrizzata (cioè su modelli, e quindi in serie, che introduce le dipendenze di compilazione e lento costruisce in sistemi scala aziendale)
  • forniscono una copertura minima per tutte le possibili istanziazioni (ad esempio controllo dei codici di errore e attesa/gestione delle eccezioni)
  • che passa attraverso un tempo di compilazione a tempo di esecuzione basato su una base di accesso astratta con implementazioni per ogni istanza) che compromette alcune delle i vantaggi prestazionali della parametrizzazione

Questo è tutto possibile, ma ci vuole un grande programmatore per navigare nel terreno.

+1

Questo è esattamente il problema con boost, boost IS la libreria standard C++ o dovrebbe essere, dato che l'attuale libreria standard non è adatta a nessuno ... Ecco perché il C++ viene scaricato da linguaggi come Java e C#, a causa dello standard molto ricco biblioteca.Per non parlare del fatto che sia Java che C# consentono di collegare altre librerie se lo desiderano, dal momento che hanno delle belle interfacce pensate per essere estensibili. – Coyote21

Problemi correlati