C ++ 11 neden C99 olarak belirlenmiş başlatıcı listelerini desteklemiyor? [kapalı]

Düşünmek:

struct Person
{
    int height;
    int weight;
    int age;
};

int main()
{
    Person p { .age = 18 };
}

Yukarıdaki kod C99'da yasaldır, ancak C ++ 11'de yasal değildir.

Neydi c ++ 11 standart komitenin bu kadar kullanışlı bir özelliği desteklememesinin mantığı?

C ++ 'ın yapıcıları vardır. Sadece bir üyeyi başlatmak mantıklıysa, bu, uygun bir kurucu uygulayarak programda ifade edilebilir. Bu, C ++ 'nın teşvik ettiği türden bir soyutlamadır.

Öte yandan, atanmış başlatıcılar özelliği daha çok açığa çıkarma ve üyelerin doğrudan istemci kodundan erişmesini kolaylaştırma ile ilgilidir. Bu, 18 yaşında (yaşında?) Ama boyu ve ağırlığı sıfır olan bir kişiye sahip olmak gibi şeylere yol açar.

Başka bir deyişle, atanmış başlatıcılar, dahili öğelerin açığa çıktığı bir programlama stilini destekler ve müşteriye, türü nasıl kullanmak istediğine karar verme esnekliği verilir.

C ++, esnekliği bir tipin tasarımcısının tarafına koymakla daha çok ilgilenir , böylece tasarımcılar bir türü doğru kullanmayı kolaylaştırabilir ve yanlış bir şekilde kullanmayı zorlaştırabilir. Tasarımcıyı bir türün nasıl başlatılabileceği konusunda kontrol altına almak bunun bir parçasıdır: tasarımcı kurucuları, sınıf içi başlatıcıları vb. Belirler.

15 Temmuz ' 17'de P0329R4 ,c ++ 20standart: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf
Bu, aşağıdakiler için sınırlı destek sağlar:c99Atanmış Başlatıcılar. Bu sınırlama C.1.7 [diff.decl] .4 ile aşağıdaki şekilde açıklanmıştır:

struct A { int x, y; };
struct B { struct A a; };

C'de geçerli olan aşağıdaki Belirlenmiş Başlatma C ++ 'da kısıtlanmıştır:

• struct A a = { .y = 1, .x = 2 } C ++ 'da geçersizdir çünkü göstericiler veri üyelerinin bildirim sırasında görünmelidir
• int arr[3] = { [1] = 5 } C ++ 'da geçersiz çünkü dizi atanmış başlatma desteklenmiyor
• struct B b = {.a.x = 0} C ++ 'da geçersizdir çünkü göstericiler yuvalanamaz
• struct A c = {.x = 1, 2} C ++ 'da geçersizdir çünkü veri üyelerinin tümü veya hiçbiri belirteçler tarafından başlatılmalıdır

İçin c ++ 17ve daha önceki Boost , Atanmış Başlatıcılar için desteğe sahipti ve destek eklemek için çok sayıda teklif vardı.c ++standart, örneğin: n4172 ve Daryle Walker'ın Başlatıcılara Atama Ekleme Önerisi . Öneriler,c99Visual C ++, gcc ve Clang'daki Belirlenmiş Başlatıcılar şunları iddia ediyor:

Değişikliklerin uygulanmasının nispeten kolay olacağına inanıyoruz

Ancak standart komite , bu tür önerileri defalarca reddederek şunları ifade eder:

EWG, önerilen yaklaşımla ilgili çeşitli sorunlar buldu ve birçok kez denendiği ve her başarısız olduğu için sorunu çözmeye çalışmanın mümkün olduğunu düşünmedi.

Ben Voigt'in yorumları , bu yaklaşımla ilgili aşılmaz sorunları görmeme yardımcı oldu; verilen:

struct X {
    int c;
    char a;
    float b;
};

Bu işlevler hangi sırayla çağrılırdı? c99: struct X foo = {.a = (char)f(), .b = g(), .c = h()}? Şaşırtıcı bir şekildec99:

Herhangi bir başlatıcıdaki alt ifadelerin değerlendirme sırası belirsiz bir şekilde sıralanır ^{[ 1 ]}

(Visual C ++, gcc ve Clang, çağrıları bu sırayla yapacakları için üzerinde anlaşmaya varılmış bir davranışa sahip görünüyor :)

Ancak standardın belirsiz doğası, bu işlevlerin herhangi bir etkileşimi olsaydı, sonuçta ortaya çıkan program durumunun da belirsiz olacağı ve derleyicinin sizi uyarmayacağı anlamına gelir : Hatalı Çalışma Belirlenmiş Başlatıcılar Hakkında Uyarılmanın Bir Yolu Var mı?

c ++ gelmez sıkı başlatıcı listesi gereksinimleri 11.6.4 [dcl.init.list] 4:

Ayraçlı bir init listesinin başlatıcı listesi içinde, paket genişletmelerinden (17.5.3) kaynaklananlar da dahil olmak üzere başlatıcı yan tümceleri göründükleri sırayla değerlendirilir. Yani, belirli bir başlatıcı cümlesiyle ilişkili her değer hesaplaması ve yan etki, her değer hesaplamasından ve başlatıcı listesinin virgülle ayrılmış listesinde onu izleyen herhangi bir başlatıcı cümlesiyle ilişkili yan etkiden önce sıralanır.

Yani c ++ destek, bunun sırayla yürütülmesini gerektirecekti:

1. f()
2. g()
3. h()

Önceki ile son derece uyumluluk c99uygulamalar.
Yukarıda tartışıldığı gibi, bu sorun, kabul edilen Atanan Başlatıcılar üzerindeki sınırlamalarla aşılmıştır.c ++ 20. Atanmış Başlatıcıların yürütme sırasını garanti eden standart bir davranış sağlarlar.

Biraz bilgisayar korsanlığı, bu yüzden sadece eğlence için paylaşın.

#define with(T, ...)\
    ([&]{ T ${}; __VA_ARGS__; return $; }())

Ve şu şekilde kullanın:

MyFunction(with(Params,
    $.Name = "Foo Bar",
    $.Age  = 18
));

şuna genişler:

MyFunction(([&] {
 Params ${};
 $.Name = "Foo Bar", $.Age = 18;
 return $;
}()));

Belirtilen başlatıcı şu anda C ++ 20 çalışma gövdesine dahil edilmiştir: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf, böylece sonunda onları görebiliriz!

C ++ 11'de Bulunmayan İki Çekirdek C99 Özelliği , “Atanmış Başlatıcılar ve C ++” dan bahseder.

Potansiyel optimizasyonla ilgili 'atanmış başlatıcı' olduğunu düşünüyorum. Burada örnek olarak "gcc / g ++" 5.1 kullanıyorum.

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>    
struct point {
    int x;
    int y;
};
const struct point a_point = {.x = 0, .y = 0};
int foo() {
    if(a_point.x == 0){
        printf("x == 0");
        return 0;
    }else{
        printf("x == 1");
        return 1;
    }
}
int main(int argc, char *argv[])
{
    return foo();
}

Derleme zamanında a_point.xsıfır olduğunu biliyorduk , bu yüzden bunun footek olarak optimize edilmesini bekleyebilirdik printf.

$ gcc -O3 a.c
$ gdb a.out
(gdb) disassemble foo
Dump of assembler code for function foo:
   0x00000000004004f0 <+0>: sub    $0x8,%rsp
   0x00000000004004f4 <+4>: mov    $0x4005bc,%edi
   0x00000000004004f9 <+9>: xor    %eax,%eax
   0x00000000004004fb <+11>:    callq  0x4003a0 <printf@plt>
   0x0000000000400500 <+16>:    xor    %eax,%eax
   0x0000000000400502 <+18>:    add    $0x8,%rsp
   0x0000000000400506 <+22>:    retq   
End of assembler dump.
(gdb) x /s 0x4005bc
0x4005bc:   "x == 0"

foox == 0yalnızca yazdırmak için optimize edilmiştir .

C ++ sürümü için,

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
struct point {
    point(int _x,int _y):x(_x),y(_y){}
    int x;
    int y;
};
const struct point a_point(0,0);
int foo() {
    if(a_point.x == 0){
        printf("x == 0");
        return 0;
    }else{
        printf("x == 1");
        return 1;
    }
}
int main(int argc, char *argv[])
{
    return foo();
}

Ve bu, optimize edilmiş montaj kodunun çıktısıdır.

g++ -O3 a.cc
$ gdb a.out
(gdb) disassemble foo
Dump of assembler code for function _Z3foov:
0x00000000004005c0 <+0>:    push   %rbx
0x00000000004005c1 <+1>:    mov    0x200489(%rip),%ebx        # 0x600a50 <_ZL7a_point>
0x00000000004005c7 <+7>:    test   %ebx,%ebx
0x00000000004005c9 <+9>:    je     0x4005e0 <_Z3foov+32>
0x00000000004005cb <+11>:   mov    $0x1,%ebx
0x00000000004005d0 <+16>:   mov    $0x4006a3,%edi
0x00000000004005d5 <+21>:   xor    %eax,%eax
0x00000000004005d7 <+23>:   callq  0x400460 <printf@plt>
0x00000000004005dc <+28>:   mov    %ebx,%eax
0x00000000004005de <+30>:   pop    %rbx
0x00000000004005df <+31>:   retq   
0x00000000004005e0 <+32>:   mov    $0x40069c,%edi
0x00000000004005e5 <+37>:   xor    %eax,%eax
0x00000000004005e7 <+39>:   callq  0x400460 <printf@plt>
0x00000000004005ec <+44>:   mov    %ebx,%eax
0x00000000004005ee <+46>:   pop    %rbx
0x00000000004005ef <+47>:   retq   

Bunun a_pointgerçekten bir derleme zamanı sabiti değeri olmadığını görebiliriz .