C ++ e l'uso di vecchie versioni di Visual Studio

Qualsiasi aggiornamento incluso l'acquisto di una nuova versione di VS costa denaro. In molti casi non c'è alcun reale vantaggio nell'ottenere "l'ultima cosa" che giustifica il costo. L'attesa ha i suoi vantaggi:

• Tutti i bug iniziali sono corretti e puoi potenzialmente risparmiare tempo che potrebbe essere stato sprecato con un cattivo comiler
• Tempo necessario per aggiornare e familiarizzare con il nuovo ambiente.
• Il prodotto diventa più economico dopo un po 'di tempo e lo sporco diventa economico dopo la prossima versione "successiva".

Inoltre, hai davvero bisogno dell'ultima? VS 2010 è utile solo se si eseguono applicazioni Azure. Se non usi Dot net potresti essere meglio con VS6!

Le aziende cercheranno sempre di venderti un nuovo compilatore sostenendo che fa le cose più velocemente e meglio ecc. Realtà: Visual Studio 2010 impiega 10 minuti per caricare i sistemi di 4 anni medi utilizzati nella mia azienda; anche dopo aver chiuso tutte le altre applicazioni. Non pagheremo solo il nuovo Visual Studio, ma dovremo anche aggiornare i nostri PC e il nostro sistema operativo. Questi si sommano al costo. Stiamo meglio con VS2008 in esecuzione su Windows XP

La domanda è, se hai qualche centinaio di migliaia di righe di MFC (un linguaggio / framework che ha avuto il suo hay-day circa 10 anni fa) scritto in modo piuttosto scadente, basato su C ++ in VS 2005 e stai considerando un aggiornamento a VS 2010 :

1. Vuoi trascorrere una settimana o due o più per far compilare il tuo vecchio junkware nel nuovo compilatore che presenta alcune differenze sottili, ma molto fastidiose?
2. Vuoi fare un test completo di regressione di quel codice appena compilato per vedere se è successo qualcosa di strano?
3. Tutto questo fastidio vale la pena (per quanto ammettiamolo) un nuovo sfondo blu?

Conosco molti negozi C ++ che usano ancora VS6.

Il problema è spesso correlato al vecchio hardware SDK che fornisce supporto solo per il compilatore VS6.

L'altro problema spesso citato è che c'è più rischio di raccogliere costi costosi nel cambiare il compilatore (specialmente con VS) piuttosto che continuare a usare quello originariamente utilizzato per la produzione. Penso che sia una ragione valida. Non dimenticare mai che l'aggiornamento ha un costo.

In alcuni casi, quando il progetto deve evolversi per anni o quando è un (molto) nuovo progetto, allora è meglio iniziare o continuare con i migliori strumenti disponibili. In questo caso, scegliere un compilatore più recente è una buona idea. Il lavoro per correggere le interruzioni dal passaggio a un nuovo compilatore viene sempre compensato da caratteristiche migliori. Se non lo è, il nuovo compilatore non è abbastanza buono, quindi non vale la pena.

Nel caso specifico di VS2010, non dimenticare il cambio di interfaccia. Il problema è che per funzionare senza problemi, l'interfaccia richiede un computer un po 'performante che non tutti i negozi hanno (essendo colpa loro o no). Altro: qualsiasi grande "cambiamento" come questo, che è molto evidente, spezzerà qualsiasi community in "era meglio prima" e "ora è buono". Quindi, quando decidono di cambiare radicalmente una caratteristica apparente come questa, sanno che ci vorrà del tempo prima che la comunità si abitui ad essa. Immagino che non cambieranno il sistema di interfaccia prima di qualcosa come 5 anni da oggi.

C'è anche un catch-22

Se vs2008 funziona per il tuo prodotto e c'è un grosso costo nel fissarlo per funzionare con VS2010, lo fai solo quando perdi abbastanza clienti perché non hai il supporto VS2010 per farlo.

Nel frattempo i tuoi clienti non sono passati a vs2010 perché fanno affidamento sulla tua libreria (e su una serie di altri) che non funzionano con vs2010, o potrebbero non farlo. Non hanno intenzione di passare al tempo e alle spese per l'aggiornamento fino a quando tutte le biblioteche su cui si basano sono state aggiornate e testate e ci sono sufficienti vantaggi per giustificare il costo

Secondo me, lavorando solo con C ++, non ci sono molti motivi per aggiornare tra il 2005 e il 2010.

Il supporto standard per C ++ nel 2005 è in genere "abbastanza buono" e il supporto per C ++ 0x non sarà completamente implementato fino alla versione successiva al 2010, se possibile.

Ho visto poche persone utilizzare qualsiasi funzionalità di VC ++ oltre al pulsante "Costruisci", l'editor di testo e il debugger, e quelli non sono cambiati molto tra il 2005 e il 2008. Per il 2010 hanno cambiato l'interfaccia utente un po ', ma sembra soprattutto cosmetico, senza miglioramenti di funzionalità che posso dire.

Inoltre, la maggior parte degli aggiornamenti di Visual Studio sembra concentrata sul lavoro con .NET, quindi se non la usi, non ci sono molti motivi per spendere i soldi.

Tu dici Visual Studio, ma penso che tu stia davvero parlando delle versioni del compilatore, quindi sto rispondendo in termini di compilatori.

Lavoravo in un'azienda che forniva sia software installabile, sia un ampio set di API per i clienti per creare i propri plugin e software contro i nostri.

Quando sono entrato, la compagnia ha ufficialmente supportato queste linee di compilazione C ++:

• GCC 3.4.6 (Red Hat Enterprise 4)
• GCC 4.1.2 (Fedora Core 7 e Red Hat Enterprise 5)
• Visual C ++ 2003 / 7.1
• Visual C ++ 2005 / 8.0

Mi sono unito ad agosto 2008, quindi Visual C ++ 2008 era uscito per circa 8-9 mesi. Non c'era davvero alcun interesse attivo nell'aggiungere / passare a nuove versioni.

Abbiamo eliminato gradualmente il supporto VC ++ 2003 perché Microsoft non l'ha supportato a lungo e i clienti erano già passati a VC ++ 2005

Per quanto riguarda il modo in cui abbiamo aggiunto il nuovo supporto per il compilatore C ++:

I driver principali non erano cose come i test di regressione, o "cosa succede se il nostro codice non viene compilato" - una parte significativa del codice è stata scritta C ++ 98 standard, e il codice moderno come ho scritto doveva compilare il compilatore con il minimo comune denominatore supportato.

Il driver principale erano i nostri clienti e le loro richieste.

All'inizio del 2009, alcuni dei nostri clienti (sto parlando di grandi appaltatori della difesa e simili) hanno espresso interesse a passare a Visual C ++ 2008 e si sono domandati quando lo avremmo supportato, perché hanno dovuto creare i loro plug-in / estensione / software contro una versione compatibile delle librerie. Penso che abbiano appena preso una decisione dall'alto e che Microsoft abbia eliminato gradualmente il supporto per Visual Studio 2005, quindi hanno dovuto spostarsi verso l'alto.

Questo ha dato il via all'inizio di noi a sviluppare il nostro software contro Visual C ++ 2008, ed è stato allora che queste preoccupazioni si sono presentate:

• test di regressione - assicurati che le persone che hanno utilizzato VC ++ 2008 abbiano codificato in modo che funzionasse con i compilatori più vecchi
• porting di ogni singola dipendenza a VC ++ 2008 - il nostro software variava dai toolkit fondamentali agli analizzatori di rete fino al software di simulazione di visualizzazione completo, quindi ci devono essere buoni motivi finanziari per spendere i soldi e il tempo per portare decine di decine di librerie dipendenti e applicazioni interne a un nuovo compilatore
• QAing (avevamo due membri del QA e la maggior parte degli sviluppatori ha fatto da sé, questo è un processo costoso)
• Costruisci il nostro software contro VC ++ 2008 - non del tutto indolore

Cose simili si sono verificate quando i clienti volevano sfruttare i sistemi di memoria alta e ci hanno chiesto quando avremmo supportato i sistemi a 64 bit: suggerire l'assalto di attività simili come sopra per la creazione di software VC ++ 2008 a 64 bit e 64 -bit Red Hat 5 software.

Sono stato coinvolto in molte di queste porte e ho modificato il codice per funzionare - Supporto a 64 bit di Visual C ++ 2005, supporto per SunStudio 11 (mi ha dato ENORME incubi), supporto per SunStudio 12 (mi ha dato anche enormi incubi).

Il che evidenzia un altro punto: spostare i compilatori non è un compito facile se i tuoi clienti richiedono alcuni compilatori ignorati - ho passato molto tempo a riscrivere parti di Boost, Qt e un sacco di altre librerie open source in particolare per far funzionare il software su alcuni compilatori. Ciò ha fatto seguito ai cambiamenti che ho dovuto apportare in un gruppo di codice sorgente della mia azienda, e stai parlando di comprendere 5 basi di codice diverse e le sottili differenze tra i compilatori. I bug del compilatore mi hanno morso un po 'di volte e sono sicuro che avrei potuto farmi un nome nella comunità di Solaris con tutte le modifiche che ho apportato per far funzionare alcuni grandi progetti open source sui compilatori Sun o IBM.

Quando sono uscito dalla società (alla fine dello scorso anno), i clienti stavano iniziando a richiedere il supporto di Visual Studio 2010 perché significava che Visual Studio 2008 sarebbe presto scomparso. Penso che la società stia iniziando a eliminare gradualmente il supporto per VS2005 e il supporto per GCC 3.4.6, poiché il supporto di Microsoft / Red Hat per quelle versioni dei loro software / sistemi operativi terminerà.

Quindi no, il codice che abbiamo scritto non sfruttava le fantastiche funzionalità di C ++, non stavamo usando std::shared_ptr o std::unordered_map o qualsiasi caratteristica di C ++ 11. Useremo il boost per darci quel supporto, ma dovevamo garantire che il nostro codice potesse compilare i nostri compilatori ufficialmente supportati. Soprattutto, abbiamo dovuto supportare ciò che una gran parte dei nostri clienti desiderava.

Il nostro aggiornamento da VS6 a VS2008 richiedeva che uno sviluppatore lavorasse per diverse settimane per aggiornare il nostro codebase prima che il resto di noi potesse persino avviare il processo di aggiornamento sia del software che delle pratiche di codifica. Poi ci sono stati test, e dopo oltre un anno, abbiamo occasionalmente colpito un bug oscuro causato da esso.

Il nostro progetto e i nostri file non possono essere aggiornati al 2010 (sono stati appena raggiunti nel 2008), quindi vengono utilizzati solo per il lavoro sui nostri nuovi prodotti. Il nostro aggiornamento sarà completo solo una volta che tutti i nostri clienti finiranno di migrare, e non abbiamo ancora quei prodotti pronti per le versioni beta ancora. A quel punto, il 2010 sarà il vecchio sistema obsoleto.