Perché gli sviluppatori di giochi C ++ non usano la libreria boost? [chiuso]

Quindi, se passi del tempo a visualizzare / rispondere alle domande su Stack Overflow sotto il tag C ++, noterai rapidamente che quasi tutti usano la libreria boost ; alcuni direbbero addirittura che se non lo si utilizza, non si sta scrivendo C ++ "reale" (non sono d'accordo, ma non è questo il punto).

Ma poi c'è l'industria del gioco, che è ben nota per l'utilizzo del C ++ e non per il boost. Non posso fare a meno di chiedermi perché sia ​​così. Non mi interessa usare boost perché scrivo giochi (ora) come hobby, e parte di quell'hobby sta implementando ciò di cui ho bisogno quando posso e usando librerie standard quando non posso. Ma sono solo io.

Perché gli sviluppatori di giochi, in generale, non usano la libreria boost? Sono problemi di prestazioni o di memoria? Stile? Qualcos'altro?

Stavo per fare questo in caso di overflow dello stack, ma ho pensato che la domanda fosse meglio fare qui.

MODIFICARE :

Mi rendo conto che non posso parlare per tutti i programmatori di giochi e non ho visto tutti i progetti di gioco, quindi non posso dire che gli sviluppatori di giochi non abbiano mai usato boost; questa è semplicemente la mia esperienza.

Consentimi di modificare la mia domanda per chiedere anche, se usi boost, perché hai scelto di usarlo?

Alcuni sviluppatori lo fanno, altri no (nei giochi e altrove). Dipende dalle esigenze / requisiti di tali sviluppatori e dalla tecnologia esistente che devono sfruttare.

Libreria standard C ++ s 'è spesso dato lo stesso trattamento, e la gente spesso si chiedono la stessa cosa vi state chiedendo circa esso , anche. La maggior parte dei motivi sono simili, ad esempio:

• Uno sviluppatore potrebbe già disporre di una libreria di funzionalità interna che fornisce gli stessi servizi forniti dalla libreria standard o da Boost. Tali librerie interne venivano spesso scritte molto tempo fa, quando il supporto all'implementazione per la libreria standard era debole e Boost era praticamente inesistente, quindi dovevano essere scritte più o meno . In questo scenario, di solito non vale davvero la pena abbandonare la funzionalità interna: sarebbe un grande sforzo di porting che destabilizzerebbe molto codice e non fornirebbe quasi alcun vantaggio.

• Uno sviluppatore potrebbe lavorare su piattaforme in cui il supporto del compilatore per le tecniche avanzate C ++ sfruttate da Boost non è ben supportato, in modo tale che il codice Boost non si compili affatto o funzioni in modo piuttosto scadente. Questo vale anche per la libreria standard, anche se oggi molto meno.

• Boost e la libreria standard del linguaggio sono di uso generale e sebbene ciò vada bene per la maggior parte delle applicazioni, a volte uno sviluppatore ha esigenze specifiche che possono essere meglio affrontate da contenitori più specializzati.

Penso che quanto sopra siano due ragioni ragionevoli, sebbene ce ne siano sicuramente altre. Devi stare attento però perché molte ragioni per evitare Boost, le librerie standard o qualunque cosa si riducano alla sindrome "non inventata qui", che può essere un'indicazione che la ragione non è molto ben radicata nelle realtà pratiche.

Ricorda inoltre che le esigenze di uno studio di grandi dimensioni di solito sono molto diverse da quelle di un singolo sviluppatore. Ad esempio, un singolo sviluppatore probabilmente ha meno codice legacy in circolazione da mantenere e quindi forse il porting da una versione di Boost cresciuta in casa o la funzionalità di libreria standard non sarà così grande e farà risparmiare a quello sviluppatore la necessità di mantenere quel codice come ampiamente in futuro - invalidando così il mio primo punto elenco.

Alla fine, si tratta di valutare le tue esigenze e il tempo investito rispetto al tuo obiettivo desiderato e determinare quale opzione soddisfa al meglio le tue esigenze. Gli sviluppatori che non usano Boost o la libreria standard di solito lo hanno fatto e hanno raggiunto quella conclusione - forse lo farai anche tu, e forse no.

Modifica Tornando a questa domanda dopo qualche anno
Dopo aver continuato a utilizzare sempre più librerie di boost, ho pensato di aggiornare questa domanda per fornire un valido esempio del motivo per cui dovresti usare boost quando la descrizione del prodotto corrisponde alla funzionalità desiderata. Ciò convincerà anche chi dice male. Scarica openSSL, prova a creare un'applicazione client e server con esso. Ora prova a farlo funzionare su ogni piattaforma. Quindi, scarica e usa boost :: asio :: ssl per creare la stessa applicazione. Se non sei convinto che boost sia il posto giusto per cercare codice multipiattaforma pulito, ben ottimizzato, peer-review, questo semplice esercizio ti convertirà.

Versione Tl; dr:

Secondo me, non vedi un sacco di aziende di sviluppo indie o di piccole e medie dimensioni che usano il boost perché è una bestia selvaggia enorme e potente che non è facile da domare e sei praticamente da solo quando cerchi di imparare come per usarlo. La documentazione è carente in alcuni modi (vedi versione lunga) e "la comunità" attorno al progetto sembra mancare, sparpagliata o inattiva (rispetto ad altri progetti).

Versione molto lunga:

mi rendo conto che esiste già una risposta accettata, ma come qualcuno che utilizza effettivamente il boost in quasi tutti i progetti che faccio, ho pensato di pubblicare una risposta.

Ricordo quando per la prima volta mi sono dato da fare per dare una spinta e onestamente non avevo idea di cosa stesse succedendo. Boost non è affatto ben documentato. Le persone potrebbero non essere d'accordo con me sul fatto che sono sicuro perché ci sono tonnellate di frammenti di codice di esempio e commenti e simili, ma è tutto molto freddo e vago oltre che difficile da navigare.

Inoltre sembra difficile trovare un posto in cui ti senti come se avessi trovato "la comunità" attorno al progetto. In effetti la comunità sembra inesistente o nomade. Sfortunatamente anche la loro mailing list è stata trollata da così tanti siti di sanguisughe che puoi andare in questa tana del coniglio sempre tornando indietro da dove hai iniziato.

Questi due fattori rendono l'apprendimento dell'uso delle librerie boost un compito piuttosto scoraggiante. Anche se i tecnicismi dell'utilizzo di boost non sono eccessivamente complessi, si tratta di un enorme set di librerie e di fissarlo quando tutto ciò che ti è armato è qualche frammento di codice e pezzi sparsi della mailing list dagli angoli più bui di Internet ... bene hai capito.

Ho iniziato a armeggiare con una spinta intorno alla versione 1.45 ed è solo ora nella versione 1.52 / 1.53 che mi sento abbastanza a mio agio da usarlo in produzione. Ci sono così tante cose a cui abituarsi e ricordare, anche cose semplici come come hai configurato boost e ricordare quella configurazione, perché il modo in cui le librerie sono costruite e le funzioni possono variare selvaggiamente in base alle tue preferenze al momento della compilazione a causa di come le cose personalizzabili siamo.

Tuttavia , non commettere errori , una volta che puoi esercitare un potenziamento, hai guadagnato un'arma potente per costruire rapidamente solidi programmi multipiattaforma. Prendi solo boost::asioper esempio. Puoi scrivere un web server asincrono estremamente potente, scalabile e solido come una roccia in sole duecento righe. Nel corso degli anni ho scritto più client, server, proxy ecc. Con solo poche centinaia di righe di codice ognuna che non mi hanno ancora deluso e possono portarle da una piattaforma all'altra in pochi minuti.

Come altri hanno sottolineato, le aziende più grandi di solito sono bloccate con roba legacy o piace rotolare le proprie che capisco perfettamente. C'è anche questa cosa davvero sciocca di cui ho sentito parlare e che ho incontrato in cui i lead di sviluppo e oi project manager proibiscono di usare boost perché è "troppo grande". La mia ipotesi è che credano che boost sia 1 singola libreria o che non abbiano mai sentito parlare di BCP .

Per quanto riguarda il PERCHÉ ho scelto di utilizzare boost

Direi che lo uso perché, come insinui nella tua domanda, è "la" libreria C ++. Boost è visto nel mondo C ++ come il coltellino svizzero di cose che alla fine dovrai usare. Quindi l'idea è che se ce n'è bisogno, dovrebbe esserci una versione altamente performante e portatile di essa in spinta. Le grandi aziende contribuiscono a dare impulso , le persone molto istruite con curriculum impressionanti contribuiscono e lo mantengono , e quando viene sviluppato un nuovo standard di C ++, le persone di solito cercano di migliorare per vedere quali parti dovrebbero diventare C ++ standardizzate ISO.

Quindi, se devo aggiungere alcune funzionalità per cui esiste probabilmente una libreria esistente, il primo posto che cercherò è boost solo perché sono abbastanza sicuro nelle scommesse che è abbastanza ben ottimizzato, portatile, sarà supportato e mantenuto per molto tempo e verranno individuati e risolti i bug. Nel mondo open source quelle qualità possono essere molto difficili da trovare.

Abbiamo usato un po 'di Boost nel nostro vecchio posto di lavoro. I motivi principali per averlo principalmente evitato e limitato il suo utilizzo sono stati:

• tempi di compilazione - alcuni di questi sono molto lenti da compilare e finisci per essere riluttante ad avere un #incluso in qualsiasi delle tue intestazioni
• complessità - non è ben noto alla maggior parte degli sviluppatori di giochi e quindi rende il codice illeggibile
• prestazioni: alcuni concetti funzionano lentamente per impostazione predefinita, ad es. shared_ptr

Stessa cosa viene (era?) Detta per la STL "più standard". Questo articolo parla di EASTL, una riscrittura interna di (parti di) STL di Electronic Arts per soddisfare le esigenze di sviluppo del gioco che sono piuttosto diverse da quelle dello sviluppo di applicazioni "più generiche".

Quindi, forse, qualcuno da qualche parte sta riscrivendo (parti di) boost per soddisfare le sue esigenze nello sviluppo del gioco!

Chi dice che non usano boost? Ho conosciuto uno o due motori C ++ che hanno utilizzato boost. Non ho mai lavorato direttamente con loro; ma questo è principalmente perché la mia esperienza risiede in Unreal.

Per quanto riguarda i motivi che ho riscontrato per non usare boost, e questi sono soggettivi:

• Ci piace girare le nostre strutture dati specifiche per le piattaforme su cui stiamo implementando
• Ci piace limitare la quantità di codice non sviluppato internamente che dobbiamo usare nei nostri progetti, specialmente quando quel codice esterno dipende da altre librerie sviluppate esternamente.

Fondamentalmente si riduce a: una soluzione generale non è sempre la "giusta misura".

Sono sicuro che qualcuno che ha effettivamente lavorato con la biblioteca potrebbe commentare meglio.

Esco in StackOverflow e non uso boost. Aggiungerò il mio motivo, perché non è ancora stato menzionato.

Boost ha molte idee fantastiche, davvero. Mi piace guardare quello che hanno fatto e provare nuove cose e idee. Sono fantastici, perché sono terreno fertile per molti miglioramenti del C ++.

Ma la spinta è una bestia molto ingombrante per molte ragioni. Uno dei motivi è che devono (vogliono) essere compatibili praticamente con qualsiasi compilatore con qualsiasi stranezza. Di conseguenza hanno bisogno di usare molti trucchi, come MPL per riuscirci. Ad esempio (molto tempo fa) volevo usare il loro shared_ptr, farlo funzionare significava che avevo bisogno delle fonti e delle librerie di quello che sembrava il 90% di boost. Ho finito per scrivere il mio; 50 righe di codice leggibili. (I miei requisiti erano più severi, come nessun debole_ptr o sicurezza del thread.)

Spesso hai bisogno di un piccolo sottoinsieme di boost, ma l'integrazione dell'intero boost non vale la seccatura.

Modifica :

Giusto per chiarire è, dal momento che sembra non essere venuto chiaramente (cioè downvote). Io uso non utilizzare librerie di terze parti. Ma nella maggior parte dei casi, a parità di condizioni, integrando una libreria di terze parti o aumentando, l'altra libreria di terze parti è più veloce e più pulita. Il resto viene eseguito nell'esercizio con le dita "2h". Faccio uno sguardo molto duro nel costruirlo o comprare la domanda.

Nel nostro caso (non nei giochi), abbiamo un'ottima ragione per non usare boost (né std): abbiamo un sacco di codice che risale a un decennio. Secondo gli anziani, std e boost erano o incompleti, pieni di bug o semplicemente troppo lenti per le cose ad alte prestazioni di cui abbiamo bisogno. Quindi alcune classi di base sono state implementate, usando gli stessi concetti (come gli iteratori) e spesso ottimizzate per i nostri algoritmi. Al giorno d'oggi, tutte e tre le librerie (le nostre, std e boost) sono molto simili.

Ma vogliamo trasferire su tutto il nostro codice? Non proprio. Presumo che molte altre aziende affrontino lo stesso dilemma. Riscrivi molto codice testato e funzionante o non usa std / boost.

Non utilizzo personalmente boost o altri codici generici durante la creazione di giochi, poiché i giochi non sono generalmente di uso generale. Il tipo di codice che potrebbe essere necessario per implementare un gioco è in genere specifico per lo sviluppo del gioco, non sempre ma come il 98% (cifra casuale) del tempo. Puoi aggiungere questi ultimi frammenti di codice da boost o da qualche altra lib, ma probabilmente è meglio solo scrivere quella piccola parte di cui hai bisogno qua e là.

Da un lato, penso che sia piuttosto divertente scrivere il proprio codice in c ++, motivo per cui non ho mai usato boost o qualcosa del genere.

l'eredità nelle biblioteche domestiche non è un fattore ... il motivo principale per cui qualcuno non dovrebbe usare per potenziare altre librerie di uso generale è perché non sono velocità e memoria ottimizzate, anche se devo dire che Cryengine utilizza l'STL ma compilano è una versione open source chiamata STLPort, quindi non abbiate paura di usare STL, implementate semplicemente i vostri allocatori personalizzati e starete bene. non usare boost tho.