C++ modelli specifici dovuti alla progettazione del linguaggio

Question

mi c'è voluto molto tempo per rendersi conto di quanto sia importante e sottili con le variabili che:

1) esiste nello stack

2) hanno i loro distruttori chiamato quando cadono fuori di scopo

sono.

Queste due cose permettono cose come:

A) RAII

B) refcounted GC

Abbastanza interessante, (1) & (2) non sono disponibili in lingue "minori" come C/Assemblea; né in linguaggi "superiori" come Ruby/Python/Java (dal momento che GC previene la distruzione prevedibile degli oggetti).

Sono curioso - quali altre tecniche sapete che sono molto specifiche del linguaggio C++, a causa delle scelte di progettazione linguistica.

Grazie!

Modifica: Se la risposta è "questo funziona in C++ & questo altro langauge", va bene lo stesso. Le cose che voglio imparare sono simili a:

Scegliendo di non avere alcune caratteristiche (come GC), otteniamo altre funzionalità (come RAII + distruzione prevedibile di oggetti). In quali aree del C++, scegliendo NON hanno caratteristiche che altri linguaggi "di livello superiore" hanno, C++ riesce a ottenere schemi che quelle lingue superiori non possono esprimere.

Answer 1

Mi piacciono molto i corsi di tratto. Non esattamente specifico del C++ (altri linguaggi come Scala li hanno), ma consente di adattare gli oggetti, in sostanza per specificare un insieme di operazioni che un tipo dovrebbe supportare. Immagina di volere un "hasher", nel senso di tr1::hash. l'hash è definito per alcuni tipi, ma non per altri. Come puoi creare una classe che ha un hash definito per tutti i tipi che vuoi? È possibile dichiarare una classe come ad esempio:

template < typename T> 
struct hashing_tratis 
{ 
    typedef std::tr1::hash<T> hashing_type; 
}; 

che è, ci si aspetta una classe che ha il hasing_type corretta definito per essere utilizzato. Tuttavia, hash non è definito, per esempio, per myType, in modo da poter scrivere:

template <> 
struct hashing_traits<myType> 
{ 
    typedef class_that_knows_how_to_hash_myType hashing_type; 
}; 

In questo modo, si supponga che avete bisogno di un modo per hash qualsiasi tipo che si usa nel programma (compreso myType).Puoi scrivere un hasher "universale" creando un tratto hasing:

template <typename T> 
struct something { 
    typename hashing_traits<T>::hashing_type hasher; 
    .... // here hasher is defined for all your relevant types, and knows how to hash them 

Answer 2

Beh, questo può essere fatto nel linguaggio di programmazione D, così come i due si parla, ma i modelli potenti abbastanza per funzionare essenzialmente come compilazione tempo anatra digitando sono abbastanza utili. Ho spesso l'impressione che una buona parte del dibattito tra i linguaggi statici e quelli dinamici possa essere risolta con un sistema di template sufficientemente buono, così che anche se i tipi devono essere risolti staticamente in fase di compilazione, non è necessario che siano noti al momento dello sviluppo. C++ ha aperto la strada a quest'idea (almeno tra le lingue tradizionali). D lo fa ancora di più.

Con modelli e compilare in tempo duck typing si ottiene il meglio dei due mondi: La flessibilità di non dover specificare i tipi al momento lo sviluppo di una funzione o classe e la sicurezza e le prestazioni di conoscerle al momento della compilazione.

Answer 3

curiously recurring template pattern

expression templates

Probabilmente l'intero concetto meta-programmazione così

Answer 4

Beh, quasi tutti i modelli di progettazione '' hanno un forte legame con C++. Dovresti piuttosto pensare che non abbiano NIENTE a che fare con "design appropriato" e "best practice" e TUTTO quello che fa con bizzarri difetti del C++ e considerare attentamente il reale bisogno di ognuno di essi invece di complicare il tuo codice. Soprattutto perché molti dei modelli di design sono cerotti per risolvere problemi creati da altri modelli di design. Questo si applica dieci volte di più quando si usa una lingua diversa dal C++, perché il C++ ha un enorme numero di problemi che nessun altro linguaggio fa.

Ad esempio, singleton è l'esempio più ovvio di questo.La vera ragione di ciò è il modo in cui C++ ha inizializzato in modo molto scarso l'inizializzazione statica. Senza questo, in realtà devi sapere cosa stai facendo per far funzionare correttamente l'inizializzazione, e la maggior parte delle persone non lo fa. Per la maggior parte degli usi, il sovraccarico extra di singleton va bene, ma si dovrebbe tenere presente che ha un sovraccarico e non ha alcun uso nella maggior parte delle lingue. Crea anche ulteriori problemi in ogni singola implementazione che ho visto.

Lo stesso vale per il modello di bridge, posso vedere utilizzando singleton, ma semplicemente non c'è motivo di utilizzare mai il bridge pattern. Si riduce a 'sai cosa stai facendo?'. Se è così, non è necessario il pattern del bridge. In caso contrario, dovresti probabilmente saperne di più prima di provare a risolvere il problema chiedendoti di utilizzare il pattern del bridge. Soprattutto, non è davvero utile in tutte le lingue oltre al C++. Il punto è separare l'implementazione e l'interfaccia, che in più moderni linguaggi OO è già fatto perché hanno moduli appropriati di qualche tipo. In C++, è meglio utilizzare pure interfacce virtuali per casi come questo (e non pensate che questo abbia prestazioni peggiori, ha prestazioni molto migliori rispetto al bridge pattern combinato con i template).

Ma questo è il problema con i modelli di progettazione; non è affatto una metodologia, solo un po 'di cose a caso. Le cose a caso la maggior parte delle persone che le difendono non capiscono veramente, la maggior parte delle quali non ha alcun luogo in cui si chiami qualcosa con la parola design in esse. Non sono strumenti di progettazione, ma soluzioni specifiche a vari problemi. Molti dei quali sono evitabili.

Ironia della sorte, l'API java è piena di bridge e un'ampia varietà di altri modelli di progettazione che sono totalmente inutili in Java. L'API Java è facile da usare la maggior parte del tempo, ma la gerarchia eccessivamente complicata può essere molto complicata con cui lavorare.

Answer 5

• sempre fare il chiamante responsabile della memoria di allocazione/deallocazione, il che significa che il codice che sarebbe simile a questa in Java/C#:

  MyClass doSomething(MyClass someInstance); 
  

  assomiglia a questo in C/C++:

• Utilizzando distruttori di chiudere i socket, file-maniglie, ecc

Answer 6

Supporto per alcune lingue multiple dispatch (con più comunemente lo double dispatch) come fa il C++, è possibile farlo in modo statico o dinamico.
Con esso è possibile consentire alle istanze di interagire l'una con l'altra senza ancora conoscere o testare per il loro tipo concreto.

Answer 7

C'è l'idioma pImpl. Funziona in modo simile al pattern Bridge.

E il Expression Template, che ritarda le valutazioni di espressione del C++.

Queste due opere anche esplorare questa domanda: More C++ Idioms e Effective C++ (Scott Meyers, 2005)