Esporta (0) Stampa
Espandi tutto
Il presente articolo è stato tradotto automaticamente. Passare il puntatore sulle frasi nell'articolo per visualizzare il testo originale. Ulteriori informazioni.
Traduzione
Originale
1 di 1 hanno valutato il contenuto utile: - Valuta questo argomento

Ultime modifiche in Visual C++

In questo documento sono elencate le ultime modifiche in Visual C++ in Visual Studio 2013.

  • La parola chiave finale genera ora un errore di simbolo non risolto. Il codice seguente genera un errore mentre in precedenza sarebbe stato compilato:

    struct S1 {
        virtual void f() = 0;
    };
    
    struct S2 final : public S1 {
        virtual void f();
    };
    
    int main(S2 *p)
    {
        p->f();
    }
    
    

    Nelle versioni precedenti non viene generato alcun errore perché la chiamata è una chiamata virtuale. Tuttavia, il programma viene arrestato in modo anomalo in fase di esecuzione. Ora viene generato un errore del linker perché la classe è finale. In questo esempio, per correggere l'errore, si esegue il collegamento all'oggetto che contiene la definizione di S2::f.

  • Quando si utilizzano funzioni friend negli spazi dei nomi, è necessario dichiarare di nuovo la funzione friend prima di farvi riferimento. In caso contrario, verrà generato un errore perché il compilatore ora è conforme allo standard ISO C++. Nell'esempio seguente la compilazione non viene più eseguita:

    namespace NS {
        class C {
            void func(int);
            friend void func(C* const) {}
        };
    
        void C::func(int) { 
            NS::func(this);  // error
        }
    }
    
    

    Per correggere questo codice, dichiarare la funzione friend:

    namespace NS {
        class C {
            void func(int);
            friend void func(C* const) {}
        };
    
        void func(C* const);  // conforming fix
    
        void C::func(int) { 
            NS::func(this); 
        }
    }
    
    
  • Il linguaggio C++ standard non consente la specializzazione esplicita in una classe. Visual C++ la consente in alcuni casi, ma in casi come il seguente esempio, l'errore viene generato perché il compilatore non considera la seconda funzione come una specializzazione della prima.

    template <int N>
    class S { 
    public: 
        template  void f(T& val); 
        template <> void f(char val); 
    }; 
    
    template class S<1>; 
    
    

    Per correggere questo codice, modificare la seconda funzione come indicato nell'esempio che segue:

    template <> void f(char& val);
    
  • Visual C++ non tenta più di risolvere l'ambiguità delle due funzioni riportate nell'esempio seguente e ora restituisce un errore:

    template<typename T> void Func(T* t = nullptr); 
    template<typename T> void Func(...); 
    
    int main() { 
        Func<int>(); // error
    } 
    
    

    Per correggere questo codice, definire la chiamata:

    template<typename T> void Func(T* t = nullptr); 
    template<typename T> void Func(...); 
    
    int main() { 
        Func<int>(nullptr); // ok
    } 
    
    
  • Prima che il compilatore fosse reso conforme a C++11 ISO, il codice seguente sarebbe stato compilato e avrebbe generato x per risolversi nel tipo int:

    auto x = {0}; 
    
    int y = x; 
    
    

    Ora il codice risolve x in un tipo di std::initializer_list<int> e genera un errore nella riga successiva che tenta di assegnare x al tipo int. Non viene eseguita alcuna conversione per impostazione predefinita. Per correggere questo codice, sostituire auto con il tipo int:

    int x = {0}; 
    
    int y = x; 
    
    
  • Un'inizializzazione aggregata non è più consentita quando il tipo del valore a destra non corrisponde al tipo del valore a sinistra in corso di inizializzazione e pertanto viene generato un errore. Questo perché lo standard ISO C++11 richiede l'inizializzazione uniforme per funzionare senza conversioni verso un tipo di dati più piccolo. In precedenza, se fosse stata disponibile una conversione verso un tipo di dati più piccolo, sarebbe stato generato un avviso C4242 anziché un errore.

    int i = 0;
    char c = {i}; // error
    
    

    Per correggere questo codice, aggiungere una conversione esplicita verso un tipo di dati più piccolo:

    int i = 0;
    char c = {static_cast<char>(i)};
    
    
  • La seguente inizializzazione non è più consentita::

    void *p = {{0}};
    
    

    Per correggere questo codice, utilizzare uno di questi formati:

    void *p = 0; 
    // or 
    void *p = {0};
    
  • È stata modificata la ricerca del nome. Il codice seguente viene risolto in modo diverso in Visual C++ in Visual Studio 2012 e in Visual C++ in Visual Studio 2013:

    enum class E1 {a};
    enum class E2 {b};
    
    int main()
    {
        typedef E2 E1;
        E1::b;
    }
    
    

    In Visual C++ in Visual Studio 2012, E1 nell'espressione E1::b viene risolto in ::E1 nell'ambito globale. In Visual C++ in Visual Studio 2013, E1 nell'espressione E1::b viene risolto nella definizione di typedef E2 in main() e ha il tipo ::E2.

Bb531344.collapse_all(it-it,VS.120).gifLibreria di modelli standard

  • Se il codice riconosce i modelli simulati dell'alias della versione precedente, è necessario modificarlo. Ad esempio, anziché allocator_traits<A>::rebind_alloc<U>::other, è necessario impostare allocator_traits<A>::rebind_alloc<U>. Sebbene ratio_add<R1, R2>::type non sia più necessario e si consiglia ora di utilizzare un'istruzione di tipo ratio_add<R1, R2>, il precedente continuerà a essere compilato. Questo perché ratio<N, D> deve disporre di un typedef "type" per un rapporto ridotto (che sarà lo stesso tipo se è già ridotto).

  • È necessario utilizzare #include <algorithm> quando si chiama std::min() o std::max().

  • Se il codice esistente utilizza le enumerazioni con ambito simulate della versione precedente (enumerazioni tradizionali senza ambito contenute negli spazi dei nomi), è necessario modificarle. Ad esempio, se si fa riferimento al tipo std::future_status::future_status, è ora necessario impostare std::future_status. Tuttavia, la maggior parte del codice non è interessato, ad esempio std::future_status::ready viene compilato.

  • explicit operator bool() è più rigido di operator unspecified-bool-type(). explicit operator bool() consente conversioni esplicite a bool, ad esempio dato shared_ptr<X> sp, static_cast<bool>(sp) e bool b(sp) sono entrambi validi e "conversioni contestuali" verificabili in modo booleano a bool, ad esempio if (sp), !sp, sp && whatever. Tuttavia, explicit operator bool() impedisce le conversioni implicite a bool, pertanto non è possibile impostare bool b = sp e dato un tipo restituito bool non è possibile impostare return sp.

  • Ora che i modelli variadic reali sono implementati, _VARIADIC_MAX e le macro correlate non hanno alcun effetto. Se si definisce ancora _VARIADIC_MAX, esso viene ignorato. Se si è riconosciuto il sistema di macro con lo scopo di supportare i modelli variadic simulati in qualsiasi altro modo, è necessario modificare il codice.

  • Oltre alle parole chiave comuni, le intestazioni STL ora impediscono l'impostazione delle macro delle parole chiave sensibili al contesto "override" e "final".

  • reference_wrapper/ref()/cref() impediscono ora l'associazione a oggetti temporanei.

  • <random> ora applica rigorosamente le precondizioni in fase di compilazione.

  • Vari tratti di tipo STL hanno la precondizione "T deve essere un tipo completo". Sebbene il compilatore applichi ora tale regola in modo più rigido, questa non può essere applicata in tutte le situazioni. Poiché le violazioni di precondizione STL attivano un comportamento non definito, lo standard non garantisce l'applicazione.

  • STL non supporta /clr:oldSyntax.

  • La specifica C++11 per common_type<> presenta delle conseguenze impreviste e indesiderate; in particolare, fa in modo che common_type<int, int>::type restituisca int&&. Pertanto, Visual C++ implementa la Proposta per risolvere il problema 2141 del gruppo di lavoro di libreria, che fa sì che common_type<int, int>::type restituisca int.

    Come effetto collaterale di questa modifica, il case di identità non funziona più (common_type<T> non restituisce sempre il tipo T). Ciò è conforme alla Proposta, ma interrompe il codice basato sul comportamento precedente.

    Se è necessario un tratto di tipo di identità, non utilizzare std::identity non standard definito in <type_traits>, perché non funzionerà con <void>. Diversamente, implementare un tratto di tipo di identità per le proprie esigenze. Di seguito è riportato un esempio:

    template <typename T> struct Identity {
        typedef T type;
    };
    
    

Bb531344.collapse_all(it-it,VS.120).gifMFC e ATL

  • Libreria MFC per MBCS non è più inclusa in Visual Studio perché il formato Unicode è estremamente diffuso e l'utilizzo di MBCS si è ridotto significativamente. Questa modifica mantiene inoltre MFC più allineato a Windows SDK stesso, poiché molti dei nuovi controlli e messaggi sono solo Unicode. Tuttavia, se è necessario continuare a utilizzare la libreria MFC per MBCS, è possibile scaricarla dall'Area download di MSDN. Il pacchetto ridistribuibile di Visual C++ include ancora questa libreria.

  • L'accessibilità per la barra multifunzione MFC è stata modificata.  Anziché un'architettura a un livello è ora un'architettura gerarchica. È ancora possibile utilizzare il comportamento precedente chiamando CRibbonBar::EnableSingleLevelAccessibilityMode().

  • Il metodo CDatabase::GetConnect è stato rimosso. Per migliorare la sicurezza, la stringa di connessione viene ora archiviata crittografata e viene decrittografata solo se necessario; non può essere restituita come testo normale. La stringa può essere ottenuta utilizzando il metodo CDatabase::Dump.

  • La firma di CWnd::OnPowerBroadcast è stata modificata. La firma di questo gestore messaggi è stata modificata per accettare un LPARAM come secondo parametro.

  • Le firme sono state modificate per includere i gestori di messaggi. Gli elenchi di parametri delle seguenti funzioni sono stati modificati per utilizzare i gestori di messaggi ON_WM_* aggiunti recentemente:

    • CWnd::OnDisplayChange è stato modificato in (UINT, int, int) anziché (WPARAM, LPARAM) in modo da poter utilizzare la nuova macro ON_WM_DISPLAYCHANGE nella mappa messaggi.

    • CFrameWnd::OnDDEInitiate è stato modificato in (CWnd*, UINT, UNIT) anziché (WPARAM, LPARAM) in modo da poter utilizzare la nuova macro ON_WM_DDE_INITIATE nella mappa messaggi.

    • CFrameWnd::OnDDEExecute è stato modificato in (CWnd*, HANDLE) anziché (WPARAM, LPARAM) in modo da poter utilizzare la nuova macro ON_WM_DDE_EXECUTE nella mappa messaggi.

    • CFrameWnd::OnDDETerminate è stato modificato in (CWnd*) come parametro anziché (WPARAM, LPARAM) in modo da poter utilizzare la nuova macro ON_WM_DDE_TERMINATE nella mappa messaggi.

    • CMFCMaskedEdit::OnCut è stato modificato per non richiedere alcun parametro anziché (WPARAM, LPARAM) in modo da poter utilizzare la nuova macro ON_WM_CUT nella mappa messaggi.

    • CMFCMaskedEdit::OnClear è stato modificato per non richiedere alcun parametro anziché (WPARAM, LPARAM) in modo da poter utilizzare la nuova macro ON_WM_CLEAR nella mappa messaggi.

    • CMFCMaskedEdit::OnPaste è stato modificato per non richiedere alcun parametro anziché (WPARAM, LPARAM) in modo da poter utilizzare la nuova macro ON_WM_PASTE nella mappa messaggi.

  • Gli oggetti #ifdef nei file di intestazione MFC sono stati rimossi. Numerosi oggetti #ifdef nei file di intestazione MFC relativi alle versioni di Windows non supportate (WINVER < 0x0501) sono stati rimossi.

  • La DLL ATL (atl120.dll) è stata rimossa. La DLL ATL viene ora fornita come intestazioni e come libreria statica (atls.lib).

  • Atlsd.lib, atlsn.lib e atlsnd.lib sono stati rimossi. Atls.lib non include più dipendenze o codice con set di caratteri specifici per il debug/rilascio. Poiché funziona esattamente come per Unicode/ANSI e per il debug/rilascio, è richiesta una sola versione della libreria.

  • Lo Strumento di traccia ATL/MFC è stato rimosso durante la rimozione della DLL ATL e il meccanismo di tracciatura è stato semplificato. Il costruttore CTraceCategory ora accetta un parametro (il nome della categoria) e le macro TRACE chiamano funzioni CRT di report di debug.

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.

Aggiunte alla community

AGGIUNGI
Mostra:
© 2014 Microsoft. Tutti i diritti riservati.