2013-01-06 14 views
12

Il seguente codice di esempio si compila bene in Visual C++:C++ modificatore privato ignorato su nidificato struct anonima

class Test { 
private: 
    struct { 
     struct { 
      int privateData; 
     }; 
    }; 
}; 

int main(int, char **) 
{ 
    Test test; 
    test.privateData = 0; 
    return 0; 
} 

Ma perché? Mi aspetterei un errore del compilatore perché il membro privateData dovrebbe essere inaccessibile alla funzione principale, dal momento che dovrebbe essere private come il contenitore del contenitore. So che le strutture senza nome non fanno parte del C++ ufficiale, ma questo design è asinino.

Tra l'altro ho anche provato a cambiare private in protected e struct in union: sembra che il compilatore si rifiuta di onorare modificatori di accesso sulle strutture anonime e sindacati che sono nidificati all'interno di un altro anonimo unione struct o.

Qualcuno può spiegare questa funzione?

+3

Sembra il bug corretto in _VS2005sp1_, quale versione stai utilizzando? Tieni presente che _anonymous structs_ non è una funzione _C++ _ standard ... –

+0

no, sto usando VS 2012 –

+2

@ K-ballo gcc compila anche questo ... –

risposta

6

Sì, è un bug. Microsoft ha riconosciuto che è, il rapporto di feedback is here.

In questo momento il bug è in stato "non risolverà" e non è chiaro quando (se mai) verrà risolto. C'è una soluzione alquanto strana, il parser IntelliSense integrato in Visual Studio, scritto da Edison Design Group, si lamenta di ciò. Si ottengono gli scarabocchi rossi e il messaggio:

Error: member "Test.privateData" (declared at line 10) is inaccessible

+2

Stai suggerendo che ci sono orde di sviluppatori spostati nel tempo che _rely_ sugli specificatori di accesso non si sovrappongono correttamente attraverso due livelli di strutture anonime? –

+0

@LightnessRacesinOrbit La mia comprensione è che non ci sono orde, ma un pacchetto a cui piace usare "soluzioni alternative" di Microsoft, e per queste persone non risolvono questo e problemi simili. Invece, lo contrassegnano con il loro parser di codice –

+0

@ BЈовић: Mi sembra un caso strettissimo che non varrebbe la pena di tali considerazioni, anche quando c'è anche un piccolo vantaggio nel fissarlo ... –