Devo inizializzare le strutture C tramite parametro o in base al valore restituito? [chiuso]

La società in cui lavoro sta inizializzando tutte le loro strutture di dati attraverso una funzione di inizializzazione in questo modo:

//the structure
typedef struct{
  int a,b,c;  
} Foo;

//the initialize function
InitializeFoo(Foo* const foo){
   foo->a = x; //derived here based on other data
   foo->b = y; //derived here based on other data
   foo->c = z; //derived here based on other data
}

//initializing the structure  
Foo foo;
InitializeFoo(&foo);

Ho avuto qualche spinta indietro nel tentativo di inizializzare le mie strutture in questo modo:

//the structure
typedef struct{
  int a,b,c;  
} Foo;

//the initialize function
Foo ConstructFoo(int a, int b, int c){
   Foo foo;
   foo.a = a; //part of parameter input (inputs derived outside of function)
   foo.b = b; //part of parameter input (inputs derived outside of function)
   foo.c = c; //part of parameter input (inputs derived outside of function)
   return foo;
}

//initialize (or construct) the structure
Foo foo = ConstructFoo(x,y,z);

C'è un vantaggio l'uno rispetto all'altro?
Quale dovrei fare e come lo giustificherei come pratica migliore?

Nel 2 ° approccio non avrai mai un Foo parzialmente inizializzato. Mettere tutta la costruzione in un posto sembra un posto più sensato e ovvio.

Ma ... il 1 ° modo non è poi così male, ed è spesso usato in molte aree (c'è persino una discussione sul modo migliore per iniettare dipendenza, o iniezione di proprietà come la tua prima strada, o iniezione del costruttore come la seconda) . Né è sbagliato.

Quindi, se nessuno dei due è sbagliato e il resto dell'azienda utilizza l'approccio n. 1, allora dovresti adattarti alla base di codice esistente e non cercare di rovinarlo introducendo un nuovo modello. Questo è davvero il fattore più importante in gioco qui, gioca bene con i tuoi nuovi amici e non cercare di essere quel fiocco di neve speciale che fa le cose in modo diverso.

Entrambi gli approcci raggruppano il codice di inizializzazione in una singola chiamata di funzione. Fin qui tutto bene.

Tuttavia, ci sono due problemi con il secondo approccio:

1. Il secondo in realtà non costruisce l'oggetto risultante, inizializza un altro oggetto sullo stack, che viene quindi copiato sull'oggetto finale. Ecco perché vedrei il secondo approccio leggermente inferiore. Il push-back che hai ricevuto è probabilmente dovuto a questa copia estranea.

   Ciò è ancora peggio quando si ricava una classe Derivedda Foo(le strutture sono ampiamente utilizzate per l'orientamento degli oggetti in C): con il secondo approccio, la funzione ConstructDerived()chiamerebbe ConstructFoo(), copiando l' Foooggetto temporaneo risultante nello slot superclasse di un Derivedoggetto; completare l'inizializzazione Deriveddell'oggetto; solo per avere nuovamente l'oggetto risultante copiato nuovamente al ritorno. Aggiungi un terzo livello e l'intera cosa diventa completamente ridicola.

2. Con il secondo approccio, le ConstructClass()funzioni non hanno accesso all'indirizzo dell'oggetto in costruzione. Ciò rende impossibile collegare oggetti durante la costruzione, poiché è necessario quando un oggetto deve registrarsi con un altro oggetto per un callback.

Infine, non tutte structssono classi a tutti gli effetti. Alcuni structseffettivamente raggruppano insieme un mucchio di variabili, senza alcuna restrizione interna ai valori di queste variabili. typedef struct Point { int x, y; } Point;sarebbe un buon esempio di questo. Per questi usi di una funzione di inizializzazione sembra eccessivo. In questi casi, la sintassi letterale composta può essere conveniente (è C99):

Point = { .x = 7, .y = 9 };

o

Point foo(...) {
    //other stuff

    return (Point){ .x = n, .y = n*n };
}

A seconda del contenuto della struttura e del particolare compilatore utilizzato, entrambi gli approcci potrebbero essere più veloci. Un modello tipico è che le strutture che soddisfano determinati criteri possono essere restituite nei registri; per le funzioni che restituiscono altri tipi di struttura, al chiamante è richiesto di allocare spazio per la struttura temporanea da qualche parte (in genere nello stack) e passare il suo indirizzo come parametro "nascosto"; nei casi in cui il ritorno di una funzione è memorizzato direttamente in una variabile locale il cui indirizzo non è detenuto da alcun codice esterno, alcuni compilatori potrebbero essere in grado di passare direttamente l'indirizzo di quella variabile.

Se un tipo di struttura soddisfa i requisiti di un'implementazione particolare da restituire nei registri (ad esempio, non essendo più grande di una parola macchina o riempiendo esattamente due parole macchina) con una funzione di ritorno, la struttura può essere più veloce del passaggio dell'indirizzo di una struttura, in particolare poiché esporre l'indirizzo di una variabile a un codice esterno che potrebbe conservarne una copia potrebbe precludere alcune utili ottimizzazioni. Se un tipo non soddisfa tali requisiti, il codice generato per una funzione che restituisce una struttura sarà simile a quello per una funzione che accetta un puntatore di destinazione; il codice chiamante sarebbe probabilmente più veloce per il modulo che utilizza un puntatore, ma il modulo perde alcune opportunità di ottimizzazione.

Peccato che C non fornisca un mezzo per dire che una funzione è vietata dal conservare una copia di un puntatore passato (semantica simile a un riferimento C ++) poiché passare un puntatore così limitato sarebbe ottenere i vantaggi diretti delle prestazioni del passaggio un puntatore a un oggetto preesistente, ma allo stesso tempo evitare i costi semantici di richiedere a un compilatore di considerare "esposto" l'indirizzo di una variabile.

Un argomento a favore dello stile "parametro di output" è che consente alla funzione di restituire un codice di errore.

struct MyStruct {
    int x;
    char *y;
    // ...
};

int MyStruct_init(struct MyStruct *out) {
    // ...
    char *c = malloc(n);
    if (!c) {
        return -1;
    }
    out->y = c;
    return 0;  // Success!
}

Considerando alcune serie di strutture correlate, se l'inizializzazione può fallire per ognuna di esse, può valere la pena farle usare tutte lo stile fuori parametro per motivi di coerenza.

Presumo che il tuo focus sia sull'inizializzazione tramite parametro di output rispetto all'inizializzazione tramite return, non sulla discrepanza nel modo in cui vengono forniti gli argomenti di costruzione.

Si noti che il primo approccio potrebbe consentire Foodi essere opaco (sebbene non con il modo in cui lo si utilizza attualmente), e questo è generalmente desiderabile per la manutenibilità a lungo termine. Ad esempio, è possibile considerare una funzione che alloca una Foostruttura opaca senza inizializzarla. O forse è necessario inizializzare nuovamente una Foostruttura che era stata inizializzata in precedenza con valori diversi.