Чи слід ініціалізувати структури C через параметр або значення повернення? [зачинено]

Компанія, в якій я працюю, ініціалізує всі їх структури даних за допомогою функції ініціалізації:

//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);

Я отримав деякий поштовх назад, намагаючись ініціалізувати свої структури так:

//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);

Чи є перевага один перед іншим?
Що робити, і як би я обґрунтував це як кращу практику?

У другому підході у вас ніколи не буде напівініціалізованого Foo. Розмістити всю конструкцію в одному місці здається більш розумним і очевидним місцем.

Але ... 1-й спосіб не такий вже й поганий, і його часто використовують у багатьох областях (є навіть обговорення найкращого способу введення залежності, або введення властивості, як ваш перший спосіб, або введення конструктора, як 2-го) . Ні це не так.

Тож якщо жодне з них не є правильним, а решта компанії використовує підхід №1, то вам слід підходити до існуючої бази коду, а не намагатися зіпсувати це, вводячи новий шаблон. Це справді найважливіший чинник гри тут, добре грайте зі своїми новими друзями і не намагайтеся бути такою спеціальною сніжинкаю, яка робить все по-іншому.

Обидва підходи поєднують код ініціалізації в єдиний виклик функції. Все йде нормально.

Однак є два питання з другим підходом:

1. Другий фактично не конструює отриманий об'єкт, він ініціалізує інший об’єкт на стеку, який потім копіюється на кінцевий об'єкт. Ось чому я бачив би другий підхід як трохи неповноцінний. Отриманий вами відштовхувач, ймовірно, пов'язаний із цією стороною копією.

   Це ще гірше, коли ви отримуєте заняття Derived від Foo(Структур в основному використовується для орієнтації об'єкта в C): При другому підході, функція ConstructDerived()буде називати ConstructFoo(), скопіювати отриманий тимчасовий Fooоб'єкт протягом суперкласу слот Derivedоб'єкта; закінчити ініціалізацію Derivedоб’єкта; тільки щоб отриманий об'єкт знову був скопійований після повернення. Додайте третій шар, і вся справа стає абсолютно смішною.

2. При другому підході ConstructClass()функції не мають доступу до адреси об'єкта, що будується. Це унеможливлює зв'язок об'єктів під час побудови, оскільки це потрібно, коли об’єкт повинен зареєструвати себе з іншим об'єктом для зворотного виклику.

Нарешті, не всі structsє повноцінними класами. Деякі structsфактично просто зв'язують купу змінних разом, без будь-яких внутрішніх обмежень значень цих змінних. typedef struct Point { int x, y; } Point;був би хорошим прикладом цього. Для цих функцій використання ініціалізатора здається непосильним. У цих випадках складний буквальний синтаксис може бути зручним (це C99):

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

або

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

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

Залежно від вмісту структури та конкретного компілятора, який використовується, будь-який підхід може бути швидшим. Типовою закономірністю є те, що структури, що відповідають певним критеріям, можуть повертатися в регістри; для функцій, що повертають інші типи структур, абонент повинен десь виділити простір для тимчасової структури (як правило, у стеку) та передати його адресу як "прихований" параметр; у випадках, коли повернення функції зберігається безпосередньо в локальній змінній, адреса якої не міститься жодним зовнішнім кодом, деякі компілятори можуть мати можливість передавати адресу цієї змінної безпосередньо.

Якщо тип структури відповідає певним вимогам реалізації, які потрібно повернути в регістри (наприклад, або не більше одного машинного слова, або заповнюючи точно два машинні слова), функція повернення структури може бути швидшою, ніж передача адреси структури, особливо оскільки виставлення адреси змінної зовнішньому коду, що може зберігати її копію, може запобігти корисним оптимізаціям. Якщо тип не задовольняє таким вимогам, згенерований код для функції, що повертає структуру, буде аналогічним для функції, яка приймає вказівник призначення; код виклику, швидше за все, буде швидшим для форми, яка бере вказівник, але ця форма лежить втратити деякі можливості оптимізації.

Це занадто погано. C не забезпечує засоби сказати, що функції заборонено зберігати копію переданого вказівника (семантика, аналогічна посиланню на C ++), оскільки передача такого обмеженого покажчика отримає прямі переваги щодо ефективності передачі вказівник на попередньо існуючий об’єкт, але в той же час уникати смислових витрат, що вимагають від компілятора вважати адресу змінної "відкритим".

Один аргумент на користь стилю "вихідний параметр" полягає в тому, що він дозволяє функції повертати код помилки.

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!
}

Враховуючи деякий набір споріднених структур, якщо ініціалізація може не вдатися до будь-якої з них, може бути доцільним, щоб усі вони використовували стиль параметри заради послідовності.

Я припускаю, що ваша увага зосереджена на ініціалізації через вихідний параметр проти ініціалізації шляхом повернення, а не на розбіжність у наданні аргументів конструкції.

Зауважте, що перший підхід може Fooбути непрозорим (хоча не з тим, як ви його зараз використовуєте), і це зазвичай бажано для довгострокової ремонтоздатності. Ви можете розглянути, наприклад, функцію, яка виділяє непрозору Fooструктуру, не ініціалізуючи її. Або, можливо, вам потрібно повторно ініціалізувати Fooструктуру, попередньо ініціалізовану з різними значеннями.