C yapılarını parametre ile mi yoksa geri dönüş değeriyle mi başlatmalıyım? [kapalı]

Çalıştığım şirket, tüm veri yapılarını şöyle bir ilkleme işlevi ile başlatıyor:

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

Yapılarımı bu şekilde başlatmaya çalışırken bir miktar geri kazandım:

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

Birinin diğerine göre üstünlüğü var mı?
Hangisini yapmalıyım ve daha iyi bir uygulama olarak nasıl haklı gösterebilirim?

2. yaklaşımda asla yarı-başlatılmış bir Foo'nuz olmayacak. Tüm inşaatı tek bir yere koymak daha mantıklı ve açık bir yer gibi görünüyor.

Ama ... 1. yol o kadar da kötü değil ve çoğu zaman da kullanılıyor (bağımlılık enjekte etmenin en iyi yolunun, ya birinci yolunuz gibi mülk enjeksiyonunun ya da 2. yol gibi yapıcı enjeksiyonunun tartışılması bile var) . İkisi de yanlış değil.

Öyleyse, ikisi de yanlış değilse ve şirketin geri kalanı # 1 yaklaşımını kullanıyorsa, o zaman mevcut kod tabanına uymalı ve yeni bir kalıp tanıtarak karıştırmaya çalışmamalısınız. Buradaki oyundaki en önemli faktör bu, yeni arkadaşlarınızla iyi oynadığınız ve farklı şeyler yapan o özel kar tanesi olmaya çalışmayın.

Her iki yaklaşım da başlatma kodunu tek bir işlev çağrısında toparlar. Çok uzak çok iyi.

Ancak, ikinci yaklaşımla iki konu var:

1. İkincisi sonuçta ortaya çıkan nesneyi yapmaz, yığında başka bir nesneyi başlatır ve daha sonra nihai nesneye kopyalanır. Bu yüzden ikinci yaklaşımı biraz aşağı görecektim. Aldığınız geri bildirim büyük olasılıkla bu yabancı kopyadan kaynaklanıyor.

   Bir sınıfı türetmek, bu da kötü Derivedgelen Foo(struct'lar büyük ölçüde C nesne yönelimi için kullanılır): İkinci yaklaşımda, fonksiyon ConstructDerived()çağırır ConstructFoo(), ortaya çıkan geçici kopya Foobir üst sınıf yuvasına üzerinde nesneyi Derivednesne; Derivednesnenin başlatılmasını bitir ; yalnızca elde edilen nesnenin iade edildiğinde tekrar kopyalanmasını sağlamak. Üçüncü bir katman ekleyin ve her şey tamamen saçma olur.

2. İkinci yaklaşımla, ConstructClass()işlevler yapım aşamasında olan nesnenin adresine erişemez. Bu, yapım sırasında nesneleri birbirine bağlamayı imkansız kılar, çünkü bir nesnenin bir geri çağırma için kendisini başka bir nesneye kaydetmesi gerektiğinde gereklidir.

Son olarak, hepsi structstam teşekküllü sınıf değildir. Bazıları structs, bu değişkenlerin değerlerine herhangi bir iç kısıtlama getirmeden, bir sürü değişkeni bir araya getirir. typedef struct Point { int x, y; } Point;buna iyi bir örnek olur. Bir başlatıcı işlevinin bu kullanımı için fazlaca görünüyor. Bu durumlarda, bileşik değişmez sözdizimi uygun olabilir (C99’dur):

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

veya

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

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

Yapının içeriğine ve kullanılan belirli bir derleyiciye bağlı olarak, her iki yaklaşım da daha hızlı olabilir. Tipik bir örnek, belirli kriterleri karşılayan yapıların kayıtlara geri alınabilmesidir; diğer yapı türlerini döndüren işlevler için arayan kişinin geçici yapı için bir yere yer ayırması (tipik olarak yığında) ve adresini "gizli" bir parametre olarak iletmesi gerekir; bir işlevin dönüşünün doğrudan, adresi herhangi bir dış kod tarafından tutulmayan bir yerel değişkene depolandığı durumlarda, bazı derleyiciler bu değişkenin adresini doğrudan iletebilir.

Bir yapı tipi, bir fonksiyon dönüşüne sahip olan kayıtlara (örneğin bir makine kelimesinden daha büyük olmayan veya tam olarak iki makine kelimesini doldurarak) geri verilmesi için belirli bir uygulamanın gereksinimlerini karşılarsa yapı, özellikle bir yapının adresini iletmekten daha hızlı olabilir. çünkü bir değişkenin adresini bir kopyasını tutabilecek dış koda maruz bırakmak bazı yararlı optimizasyonları engelleyebilir. Bir tür bu gereksinimleri karşılamıyorsa, yapıyı döndüren bir işlev için oluşturulan kod, bir hedef işaretçiyi kabul eden bir işlev için aynı olacaktır; çağıran kod, imleci alan form için daha hızlı olur, ancak bu form bazı optimizasyon fırsatlarını kaybeder.

C'nin çok kötü olması, bir işlevin, bir işaretleyicinin bir kopyasının (C ++ referansına benzer bir anlamsal) bir kopyasının saklanmasının yasak olduğunu söylemenin bir yolunu sağlamaz; önceden var olan bir nesneye bir işaretçi, ancak aynı zamanda bir derleyicinin bir değişkenin adresini "maruz bıraktığını" dikkate almasını gerektiren anlamsal maliyetlerden kaçının.

"Output-parametresi" stilinin lehine olan bir argüman, fonksiyonun bir hata kodu döndürmesini sağlamasıdır.

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

Bazı ilgili yapılar kümesi göz önüne alındığında, herhangi biri için başlatma işlemi başarısız olursa, hepsinin tutarlılık uğruna parametre dışı stili kullanmaları faydalı olabilir.

Odaklanmanızın, yapı argümanlarının nasıl sağlandığındaki tutarsızlığa değil, çıktı parametresine karşı başlatmaya ve geri dönüşe göre başlatmaya başladığını düşünüyorum.

İlk yaklaşımın Fooopak olmasına izin verebileceğini unutmayın (şu anda kullanma şekliniz olmasa da) ve bu genellikle uzun süreli bakım için istenir. Örneğin, Foobaşlatılmadan opak bir yapı atanan bir işlevi düşünebilirsiniz . Belki de Foodaha önce farklı değerlerle başlatılmış bir yapıyı yeniden başlatmanız gerekir .