Sta memorizzando il puntatore (di new'd object) nella collezione statica dal costruttore di oggetti un linguaggio comune in C ++

Question

Sta memorizzando il puntatore (di new'd object) nella collezione statica dal costruttore di oggetti un linguaggio comune in C ++

#1 da (4 voti)
#2 da (3 voti)
#3 da (0 voti)

1

Sto rivedendo un approccio che vedo comunemente usato nella memorizzazione di oggetti (ad esempio un oggetto client socket). Vale a dire, l'uso di un contenitore statico per contenere gli oggetti. Detti oggetti sono creati da alcune funzioni di aiuto come segue:

create_client(params) {
  ...
  client* cl = new client(...);
  return cl;
}

La cosa che mi ha confuso all'inizio era la funzione chiamata così:

if (!create_client (...))
   //generate error message

vale a dire. una copia del puntatore sembra essere semplicemente buttata via.

Ma su un'indagine lo vedo nel costruttore del client:

client::client(...) {
    ...
    coll[id] = this;
}

Dove coll è una mappa di id per un puntatore all'oggetto. Ma comunque, solo una collezione. coll è statico (non è sicuro se sia rilevante).

C'è un nome per questo idioma? È una buona pratica?

c++

posta user619818 18.06.2014 - 17:51

fonte

3 risposte

4

Is there a name for this idiom? Is it good practice?

No e no, a meno che tu non contali "Terribile" come nome di un idioma. Non esiste uno stato globale mutabile idiomatico. Gli idiomi esistono per evitare tali schifezze.

risposta data 18.06.2014 - 19:14

fonte

0

Questa cosa è chiamata multiton , quindi, sì, è un idioma. Non è comunque una buona pratica.

risposta data 20.06.2014 - 07:18

fonte

Leggi altre domande sui tag c++

Trattare con oggetti simili con differenti firme di metodo Terminologia: coda contro fifo

score 3 · Accepted Answer

Non ho familiarità con C ++, ma non mi piace l'assegnazione nella struttura statica dal costruttore, perché:

1) Introduce una dipendenza: ora la classe contenuta deve conoscere l'istanza contenente. Non puoi riutilizzare la classe senza riscrivere o utilizzare la stessa struttura.

2) Causa una perdita di riferimento dal costruttore, poiché il riferimento alla classe è disponibile per altri thread prima il costruttore ha terminato l'esecuzione.

Come minimo, avrei spostato l'assegnazione dell'istanza dal costruttore alla funzione create_client .