Best practice per lavorare con framework che inventano i propri tipi [più di una domanda C / C ++]

Question

Best practice per lavorare con framework che inventano i propri tipi [più di una domanda C / C ++]

#1 da (4 voti)
#2 da (3 voti)

4

Esiste un modo corretto per gestire le API che inventano i propri tipi?

Ad esempio, WinAPI, QT, Boost.

Molti framework hanno il loro intero e il loro tipo booleano, insieme a tipi di dati più complicati.

Quindi, è meglio usare il tipo C / C ++ nativo come bool o alternative come QBool/BOOL/etc ., e tipi di contenitori nativi come std::map/std::set/std::vector rispetto a quelli reinventati come QList/boost::something/ATL::map/etc .

E in che modo queste scelte rispondono alla portabilità multipiattaforma.

TL; DR

Quale QBool IsInteresting(const QString &str) rispetto a bool IsInteresting(const std::string &str) ?

frameworks

posta Coder 11.08.2011 - 07:25

fonte

2 risposte

3

Usa sempre contenitori e tipi standard ove possibile. I contenitori e i tipi reinventati esistono solo perché le librerie in questione precedono la standardizzazione.

risposta data 11.08.2011 - 08:54

fonte

Leggi altre domande sui tag frameworks

Come decidere i costi / i termini di manutenzione per il lavoro freelance? [chiuso] Visual Studio 2010 - Cronologia file locale

score 4 · Accepted Answer

I framework che hanno le proprie sostituzioni per i tipi di libreria standard di solito lo fanno perché sono anche compatibili con piattaforme che non hanno una buona implementazione della libreria standard (come telefoni e altri sistemi embedded).

Boost è un caso speciale - spesso è praticamente considerato parte della libreria standard e molte delle librerie di boost altamente utilizzate sono state considerate per C ++ 0x (alcune l'hanno resa, ad esempio shared_ptr). Dove possibile e utile boost è compatibile con i tipi standard (libreria) C ++.

Se si utilizzerà lo stesso framework per tutte le versioni del prodotto e copre la maggior parte delle funzionalità necessarie, è probabilmente una buona idea salvare il mal di testa e utilizzare i tipi di framework. In questo modo non devi convertire avanti e indietro tutto il tempo.

Se hai intenzione di utilizzare più framework GUI (eg se stai bersagliando più piattaforme non tutte supportate) o se stai usando più librerie di terze parti con tipi incompatibili le cose si complicano, e dovrai metterne un po ' pensato in qualsiasi soluzione abbia l'impatto totale più basso per il tuo particolare progetto.