Tipi concreti - come descritto da Stroustrup - C ++ Programming Language 4th ed

Question

Tipi concreti - come descritto da Stroustrup - C ++ Programming Language 4th ed

#1 da (5 voti)
#2 da (3 voti)

6

Sto attraversando un periodo difficile con questo concetto. Cosa sta facendo Stroustrup qui? Cosa c'è di speciale in una classe la cui "rappresentazione fa parte della sua definizione"? In cosa è contrapposto un "tipo concreto"? (Suppongo sia in contrasto con il "tipo astratto", ma dal momento che, AFAIK, non puoi nemmeno portare un'istanza di un tipo astratto nell'esistenza, sembra ovvio che non potresti piazzare quello sullo stack , inizializzalo, ecc.)

Esiste una classe che potrei istanziare che NON si adatta a questa descrizione di una "classe concreta"? Normalmente trovo BS molto facile da seguire, ma qui mi manca il punto.

The basic idea of concrete classes is that they behave “just like built-in types.” For example, a complex number type and an infinite-precision integer are much like built-in int, except of course that they have their own semantics and sets of operations. Similarly, a vector and a string are much like built-in arrays, except that they are better behaved (§ 4.2, § 4.3.2, § 4.4.1).

The defining characteristic of a concrete type is that its representation is part of its definition. In many important cases, such as a vector, that representation is only one or more pointers to more data stored elsewhere, but it is present in each object of a concrete class.... In particular, it allows us to

• place objects of concrete types on the stack, in statically allocated memory, and in other objects (§ 6.4.2);

• refer to objects directly (and not just through pointers or references);

• initialize objects immediately and completely (e.g., using constructors; § 2.3.2); and

• copy objects (§ 3.3).

Stroustrup, Bjarne (2013-07-10). The C++ Programming Language (4th Edition) (Section 16.3 Concrete Classes; Kindle Locations 2373-2386). Pearson Education. Kindle Edition.

c++ class

posta Chap 15.12.2013 - 21:06

fonte

2 risposte

Leggi altre domande sui tag c++ class

Codice buggy esistente o uno nuovo di zecca? (Dalla prospettiva temporale) Dovresti ricompensare in base alla completezza o alla velocità complessiva del progetto?

score 5 · Answer 1

Hai praticamente capito bene, un tipo concreto è qualcosa che puoi creare un'istanza di, mentre un tipo astratto non lo è. Ad esempio, considera una tipica gerarchia pedagogica come:

class animal {
    virtual void noise() = 0;
}
class dog: public animal {
    void noise() { cout << "bark\n"; }
public:
    human *master;
}
class cat: public animal {
    void noise() { cout << "meow\n"; }
public:
    std::vector<human *> slaves;
}

Puoi creare istanze di dog o cat perché sono concrete e non astratte. D'altra parte, non è possibile creare un'istanza di animal , ma solo tenere un puntatore (o refernce) a uno. Ad esempio:

void hungry(animal *a) {
    a->noise();
}

Nei termini in cui Stroustrup sta usando, la rappresentazione di animal non è inclusa nella definizione di class animal . La rappresentazione per un particolare tipo di animale è descritta in una sottoclasse, qui o dog o cat .

score 3 · Answer 2

Sembra un termine usato da BS con un significato che solo lui sta usando AFAIK. Non sono sicuro di capire appieno cosa intende.

Prima una citazione dalla stessa sezione:

Such types are called concrete types or concrete classes to distinguish them from abstract classes and classes in class hierarchies.

Quindi per lui un discendente non astratto di una classe astratta non è una classe concreta (che non è una sfumatura a cui sono abituato, l'uso familiare per me è che tutte le classi non astratte sono concrete), almeno se che l'ereditarietà non è un dettaglio di implementazione. Le sue lezioni concrete sembrano essere utility indipendenti.
Un'altra dicotomia concreta / astratta con cui ho familiarità è per la struttura dei dati. Una struttura dati astratta è definita dal suo funzionamento (ad esempio un dizionario fornisce look up, inserimento, ...) Una struttura dati concreta indica come vengono forniti (ad esempio una tabella hash). La sua insistenza sul fatto che la rappresentazione sia esposta è forse correlata a quello (probabilmente a causa dell'influenza della rappresentazione sulla complessità).
Stepanov e McJones in Elementi di programmazione stanno usando un concetto di tipi regolari. Stroustrup usa anche questa nozione (nella sezione 24.3.1) e non sono sicuro di quale sia la differenza con i tipi concreti. Due ipotesi:
- il tipo concreto è più una nozione di intenzione di utilizzo rispetto a proprietà rigorose mentre il concetto di Regular è destinato a descrivere proprietà che un tipo deve essere utilizzabile in contesti generici.
- la nozione di tipo regolare è un raffinamento dell'uno tipo concreto e non ha visto quando ha introdotto che dovrebbero forse essere unificati (la descrizione dei tipi concreti è già presente nella seconda descrizione ma sembra essere stata riscritto).