C ++ 0x, ganci del compilatore e le caratteristiche lingue hardcoded

Question

Sono un po 'curioso di sapere alcune delle nuove caratteristiche di C ++ 0x. In particolare gamma-based per i loop e href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2672.htm" rel="nofollow noreferrer"> < strong> liste di inizializzazione . Entrambe le caratteristiche richiedono una classe definita dall'utente per un funzionamento corretto e completo.

questo post , e mentre il top-risposta è stata utile. Non so se è del tutto corretto (io sono probabilmente solo completamente equivoco, vedi 3 ° commento sulla prima risposta) . Secondo le specifiche attuali elenchi di inizializzazione, l'intestazione definisce un tipo:

template<class E> class initializer_list {
public:
    initializer_list();

    size_t size() const; // number of elements
    const E* begin() const; // first element
    const E* end() const; // one past the last element
};

Si può vedere questo nelle specifiche, basta Ctrl + F 'classe initializer_list' .

Al fine di = {1,2,3} per essere implicitamente fuso nella classe initializer_list, il compilatore deve avere una certa conoscenza della relazione tra {} e initializer_list. Non v'è alcun costruttore che riceve nulla, quindi l'initializer_list per quanto posso dire è un wrapper che viene legato a tutto ciò che il compilatore è in realtà generando.

E 'lo stesso con il ciclo for( : ), che richiede anche un tipo definito dall'utente lavorare (anche se secondo le specifiche, aggiornati da non richiedere alcun codice per array e liste di inizializzazione. Ma elenchi di inizializzazione richiedono <initializer_list>, quindi è un utente requisito codice -defined per delega).

Perchè sono incomprensioni completamente come funziona qui? Io non sono sbagliato nel pensare che queste nuove funzionalità fanno infatti si basano molto pesantemente sul codice utente. Ci si sente come se le caratteristiche sono cotto a metà, e invece di costruire l'intera funzione nel compilatore, è in fase di metà-fatto dal compilatore e per metà fatto in include. Qual è la ragione di questo?

Modifica ho scritto 'fanno molto affidamento sul codice del compilatore', e non 'affidarsi pesantemente al codice utente'. Che credo completamente buttato fuori la mia domanda. La mia confusione non si tratta di nuove funzionalità in fase di realizzazione nel compilatore, è le cose che sono costruiti in compilatore che si basano su codice utente.

Answer 1

  

non sbaglio a pensare che queste nuove funzionalità si basano infatti estremamente pesantemente sul codice compilatore

Essi si basano molto sul compilatore. Se avete bisogno di includere un'intestazione o no, il fatto è che in entrambi i casi, la sintassi sarebbe un errore di analisi con oggi compilatori. Il for (:) non lo fa abbastanza in forma in oggi standard, dove il costrutto unica consentita è for(;;)

  

Ci si sente come se le caratteristiche sono cotto a metà, e invece di costruire l'intera funzione nel compilatore, è in fase di metà-fatto dal compilatore e per metà fatto in include. Qual è la ragione di questo?

Il supporto deve essere attuato nel compilatore, ma si sono tenuti a includere colpo di testa di un sistema per farlo funzionare. Questo può servire un paio di scopi, nel caso di liste di inizializzazione, porta il tipo (interfaccia al supporto del compilatore) in spazio per l'utente in modo che si può avere un modo di usarlo (pensare a come va_args sono in C). Nel caso della gamma-based per (che è solo zucchero sintattico) è necessario portare la gamma in ambito modo che il compilatore in grado di eseguire la sua magia. Si noti che la norma definisce for ( for-range-declaration : expression ) statement equivalenti a ([6.5.4] / 1 del progetto):

{ 
   auto && __range = ( expression ); 
   for ( auto __begin = std::Range<_RangeT>::begin(__range), 
         __end = std::Range<_RangeT>::end(__range); 
         __begin != __end; 
         ++__begin ) { 
      for-range-declaration = *__begin; 
      statement 
   } 
} 

Se si desidera utilizzarlo solo su array e contenitori STL che potrebbero essere attuate senza il concetto Range (non nel senso C ++ 0x), ma se si desidera estendere la sintassi in classi definite dall'utente (i propri contenitori ) il compilatore può facilmente dipendere il modello Range esistente (con il proprio possibile di specializzazione). Il meccanismo di base su un modello in fase di definizione è equivalente a richiedere un'interfaccia statica sul contenitore.

La maggior parte delle altre lingue sono andati nella direzione di richiedere una normale interfaccia (ad esempio Container, ...) e l'utilizzo di runtime il polimorfismo su questo. Se questo doveva essere fatto in C ++, l'intera STL avrebbe dovuto passare attraverso un importante refactoring come contenitori STL non condividono una base o un'interfaccia comune, e non sono disposti a essere utilizzato polimorphically.

Se del caso, l'attuale standard non sarà underbaked nel momento in cui si spegne.

Answer 2

E 'solo lo zucchero sintassi. Il compilatore si espanderà le date costrutti sintattici in equivalente C ++ espressioni che fanno riferimento ai tipi standard / i nomi dei simboli direttamente.

Questa non è l'unico accoppiamento forte che i moderni compilatori C ++ hanno tra di loro lingua e il "mondo esterno". Ad esempio, extern "C" è un po 'di un linguaggio hack per accogliere il modello collegati C. modi di lingua-oriented di dichiarare archiviazione thread-local implicitamente dipendono da un sacco di RTL aggiustamenti al lavoro.

O guardare C. Come si accede tramite gli argomenti passati ...? È necessario fare affidamento sulla libreria standard; ma che utilizza la magia che ha una dipendenza molto duro su come esattamente il compilatore C espone stack frame.

UPDATE:

Se non altro, l'approccio C ++ ha preso qui è più nello spirito di C ++ che l'alternativa - che sarebbe quello di aggiungere un intrinseca di raccolta o un intervallo tipo, cotto in alla lingua. Invece, è stato fatto attraverso un tipo di gamma vendor-definito. Io davvero non vedo come molto diverso ad argomenti variadic, che sono allo stesso modo inutile senza le macro accessor vendor-definito.