Copia di strutture con membri non inizializzati

È valido copiare una struttura di cui alcuni membri non sono inizializzati?

Ho il sospetto che si tratti di un comportamento indefinito, ma in tal caso, rende piuttosto pericoloso lasciare membri non inizializzati in una struttura (anche se quei membri non vengono mai usati direttamente). Quindi mi chiedo se c'è qualcosa nello standard che lo consente.

Ad esempio, è valido?

struct Data {
  int a, b;
};

int main() {
  Data data;
  data.a = 5;
  Data data2 = data;
}

Sì, se il membro non inizializzato non è un tipo di carattere stretto senza segno o std::byte, quindi copiare una struttura contenente questo valore indeterminato con il costruttore di copia implicitamente definito è un comportamento tecnicamente indefinito, come lo è per copiare una variabile con valore indeterminato dello stesso tipo, perché di [dcl.init] / 12 .

Questo si applica qui, perché il costruttore di copie generato implicitamente è, tranne per unions, definito per copiare ogni membro individualmente come se inizializzasse direttamente, vedere [class.copy.ctor] / 4 .

Questo è anche argomento del numero CWG attivo 2264 .

Suppongo che in pratica non avrai alcun problema a riguardo.

Se vuoi essere sicuro al 100%, l'utilizzo std::memcpyha sempre un comportamento ben definito se il tipo è banalmente copiabile , anche se i membri hanno un valore indeterminato.

A parte questi problemi, dovresti sempre inizializzare correttamente i membri della tua classe con un valore specificato in fase di costruzione, supponendo che non sia necessario che la classe abbia un costruttore predefinito banale . Puoi farlo facilmente usando la sintassi di inizializzazione del membro predefinita per esempio inizializzare il valore dei membri:

struct Data {
  int a{}, b{};
};

int main() {
  Data data;
  data.a = 5;
  Data data2 = data;
}

In generale, la copia di dati non inizializzati è un comportamento indefinito perché tali dati potrebbero trovarsi in uno stato di trapping. Citando questa pagina:

Se una rappresentazione di oggetto non rappresenta alcun valore del tipo di oggetto, è nota come rappresentazione trap. L'accesso a una rappresentazione trap in qualsiasi modo diverso dalla lettura attraverso un'espressione lvalue di tipo carattere è un comportamento indefinito.

I NaN di segnalazione sono possibili per i tipi a virgola mobile e su alcune piattaforme gli interi possono avere rappresentazioni di trap.

Tuttavia, per tipi banalmente copiabili è possibile utilizzare memcpyper copiare la rappresentazione grezza dell'oggetto. Ciò è sicuro poiché il valore dell'oggetto non viene interpretato e viene copiata la sequenza di byte non elaborati della rappresentazione dell'oggetto.

In alcuni casi, come quello descritto, lo standard C ++ consente ai compilatori di elaborare i costrutti in qualunque modo i loro clienti troverebbero più utili, senza richiedere che il comportamento sia prevedibile. In altre parole, tali costrutti invocano "Undefined Behaviour". Ciò non implica, tuttavia, che tali costrutti debbano essere "vietati" poiché lo standard C ++ rinuncia esplicitamente alla giurisdizione su ciò che i "programmi ben formati" sono "autorizzati" a fare. Sebbene non sia a conoscenza di alcun documento di Rationale pubblicato per lo standard C ++, il fatto che descriva un comportamento indefinito come C89 suggerirebbe che il significato previsto è simile: "Il comportamento indefinito dà alla licenza dell'attore di non rilevare alcuni errori del programma che sono difficili diagnosticare.

Ci sono molte situazioni in cui il modo più efficiente di elaborare qualcosa implicherebbe la scrittura delle parti di una struttura di cui il codice a valle si preoccuperà, omettendo quelle a cui il codice a valle non importa. Richiedere che i programmi inizializzino tutti i membri di una struttura, compresi quelli di cui nulla si preoccuperà mai, impedirebbe inutilmente l'efficienza.

Inoltre, ci sono alcune situazioni in cui può essere più efficiente avere dati non inizializzati comportarsi in modo non deterministico. Ad esempio, dato:

struct q { unsigned char dat[256]; } x,y;

void test(unsigned char *arr, int n)
{
  q temp;
  for (int i=0; i<n; i++)
    temp.dat[arr[i]] = i;
  x=temp;
  y=temp;
}

se al codice downstream non interessano i valori di alcun elemento x.dato di y.datcui non sono stati elencati gli indici arr, il codice potrebbe essere ottimizzato per:

void test(unsigned char *arr, int n)
{
  q temp;
  for (int i=0; i<n; i++)
  {
    int it = arr[i];
    x.dat[index] = i;
    y.dat[index] = i;
  }
}

Questo miglioramento dell'efficienza non sarebbe possibile se ai programmatori fosse richiesto di scrivere esplicitamente ogni elemento temp.dat, compresi quelli a valle, se ne fregerebbe, prima di copiarlo.

D'altra parte, ci sono alcune applicazioni in cui è importante evitare la possibilità di perdita di dati. In tali applicazioni, può essere utile disporre di una versione del codice che sia strumentata per intercettare qualsiasi tentativo di copiare l'archiviazione non inizializzata senza tener conto del fatto che il codice downstream lo guarderebbe, oppure potrebbe essere utile disporre di una garanzia di implementazione che qualsiasi archiviazione i cui contenuti potrebbero essere trapelati verrebbero azzerati o altrimenti sovrascritti con dati non riservati.

Da quello che posso dire, lo standard C ++ non fa alcun tentativo di dire che uno di questi comportamenti è sufficientemente più utile dell'altro da giustificarlo. Ironia della sorte, questa mancanza di specifiche può essere intesa a facilitare l'ottimizzazione, ma se i programmatori non possono sfruttare alcun tipo di garanzie comportamentali deboli, eventuali ottimizzazioni verranno annullate.

Dal momento che tutti i membri di Datasono di tipi primitivi, data2otterrà l'esatta "copia bit per bit" di tutti i membri di data. Quindi il valore di data2.bsarà esattamente uguale al valore di data.b. Tuttavia, data.bnon è possibile prevedere il valore esatto di , poiché non è stato inizializzato esplicitamente. Dipenderà dai valori dei byte nell'area di memoria allocata per data.