Neden benzersiz anonim türlere sahip bir dil tasarlayasınız?

Bu, beni her zaman C ++ lambda ifadelerinin bir özelliği olarak rahatsız eden bir şeydir: Bir C ++ lambda ifadesinin türü benzersiz ve anonimdir, basitçe yazamam. Sözdizimsel olarak tamamen aynı olan iki lambda oluştursam bile, ortaya çıkan türler farklı olarak tanımlanır. Sonuç şudur: a) lambdalar yalnızca derleme zamanına, konuşulamayan türün nesneyle birlikte aktarılmasına izin veren şablon işlevlerine geçirilebilir ve b) lambdalar yalnızca türler aracılığıyla silindikten sonra yararlıdır std::function<>.

Tamam, ama C ++ 'nın yaptığı gibi, onu sadece o dilin rahatsız edici bir özelliği olarak yazmaya hazırdım. Ancak, Rust'un görünüşte aynı şeyi yaptığını öğrendim: Her Rust işlevi veya lambda benzersiz, anonim bir türe sahiptir. Ve şimdi merak ediyorum: Neden?

Öyleyse sorum şu:
Bir dil tasarımcısı bakış açısından, benzersiz, anonim bir tür kavramını bir dile sokmanın avantajı nedir?

Birçok standart (özellikle C ++), derleyicilerden ne kadar talep ettiklerini en aza indirme yaklaşımını benimser. Açıkçası zaten yeterince talep ediyorlar! Çalışması için bir şey belirtmeleri gerekmiyorsa, onu uygulama tanımlı bırakma eğilimindedirler.

Lambdalar anonim kalmasaydı, onları tanımlamamız gerekirdi. Bu, değişkenlerin nasıl yakalandığı hakkında çok şey söylemelidir. Bir lambda durumunu düşünün [=](){...}. Tür, lambda tarafından gerçekte hangi türlerin yakalandığını belirtmek zorunda kalacaktı, bu da belirlemek için önemsiz olmayabilir. Ayrıca, derleyici bir değişkeni başarıyla optimize ederse ne olur? Düşünmek:

static const int i = 5;
auto f = [i]() { return i; }

Optimize edici bir derleyici, iyakalanabilecek tek olası değerin 5 olduğunu kolayca anlayabilir ve bunun yerine auto f = []() { return 5; }. Ancak, tür anonim değilse, bu, türü değiştirebilir veya derleyiciyi daha az optimize etmeye zorlayabilir, iaslında ihtiyacı olmasa bile depolayabilir . Bu, lambdaların yapması amaçlanan şey için gerekli olmayan bir karmaşıklık ve nüans çantasıdır.

Ve aslında anonim olmayan bir türe ihtiyaç duyduğunuz kapalı durumda, her zaman kapatma sınıfını kendiniz oluşturabilir ve bir lambda işlevi yerine bir functor ile çalışabilirsiniz. Böylece, lambdaların% 99 durumunu ele almasını sağlayabilir ve sizi% 1'de kendi çözümünüzü kodlamaya bırakabilirler.

Deduplicator, yorumlarda anonimlik kadar benzersizliğe değinmediğime dikkat çekti. Benzersizliğin faydalarından daha az eminim, ancak türler benzersizse aşağıdaki davranışların açık olduğunu belirtmek gerekir (eylem iki kez örneklenecektir).

int counter()
{
    static int count = 0;
    return count++;
}

template <typename FuncT>
void action(const FuncT& func)
{
    static int ct = counter();
    func(ct);
}

...
for (int i = 0; i < 5; i++)
    action([](int j) { std::cout << j << std::endl; });

for (int i = 0; i < 5; i++)
    action([](int j) { std::cout << j << std::endl; });

Türler benzersiz olmasaydı, bu durumda hangi davranışın olması gerektiğini belirtmemiz gerekirdi. Bu aldatıcı olabilir. İsimsizlik konusunda gündeme gelen bazı konular, bu durumda benzersizlik için çirkin yüzlerini ortaya çıkarıyor.

Lambdalar sadece işlevler değil, bir işlev ve bir durumdur . Bu nedenle, hem C ++ hem de Rust, bunları bir çağrı operatörüyle bir nesne olarak uygular ( operator()C ++ 'da, Fn*Rust'taki 3 özellik).

Temel olarak, [a] { return a + 1; }C ++ 'da şuna benzer

struct __SomeName {
    int a;

    int operator()() {
        return a + 1;
    }
};

daha sonra __SomeNamelambda'nın kullanıldığı bir örnek kullanarak .

|| a + 1Rust'tayken , in Rust gibi bir şeye

{
    struct __SomeName {
        a: i32,
    }

    impl FnOnce<()> for __SomeName {
        type Output = i32;
        
        extern "rust-call" fn call_once(self, args: ()) -> Self::Output {
            self.a + 1
        }
    }

    // And FnMut and Fn when necessary

    __SomeName { a }
}

Bu, çoğu lambdanın farklı türlere sahip olması gerektiği anlamına gelir .

Şimdi, bunu yapmanın birkaç yolu var:

• Anonim türlerle, her iki dilin de uyguladığı şey budur. Bunun bir başka sonucu da tüm lambdaların farklı bir türe sahip olması gerektiğidir . Ancak dil tasarımcıları için bunun açık bir avantajı vardır: Lambdas, dilin halihazırda var olan diğer daha basit bölümleri kullanılarak basitçe tanımlanabilir. Bunlar, dilin zaten var olan parçalarının etrafındaki sözdizimi şekeridir.
• Lambda türlerini adlandırmak için bazı özel sözdizimi ile: Bu, ancak gerekli değildir çünkü lambdalar C ++ 'daki şablonlarla veya genel ve Rust'taki Fn*özelliklerle kullanılabilir. Her iki dil de sizi lambdaları kullanmak için yazıp silmeye zorlamaz ( std::functionC ++ veya Box<Fn*>Rust'ta).

Ayrıca her iki dilde yapamaz yakalama bağlamını yapmak önemsiz lambda'lar kabul dikkat edebilirsiniz işlev işaretçileri dönüştürülebilir.

Daha basit bir özellik kullanarak bir dilin karmaşık özelliklerini tanımlamak oldukça yaygındır. Örneğin, hem C ++ hem de Rust, aralık için döngülere sahiptir ve her ikisi de bunları diğer özellikler için sözdizimi şekeri olarak tanımlar.

C ++ tanımlar

for (auto&& [first,second] : mymap) {
    // use first and second
}

eşdeğer olarak

{

    init-statement
    auto && __range = range_expression ;
    auto __begin = begin_expr ;
    auto __end = end_expr ;
    for ( ; __begin != __end; ++__begin) {

        range_declaration = *__begin;
        loop_statement

    }

} 

ve Rust tanımlar

for <pat> in <head> { <body> }

eşdeğer olarak

let result = match ::std::iter::IntoIterator::into_iter(<head>) {
    mut iter => {
        loop {
            let <pat> = match ::std::iter::Iterator::next(&mut iter) {
                ::std::option::Option::Some(val) => val,
                ::std::option::Option::None => break
            };
            SemiExpr(<body>);
        }
    }
};

bir insan için daha karmaşık görünseler de, hem bir dil tasarımcısı hem de bir derleyici için daha basittir.

(Caleth'in cevabına ekleniyor, ancak yoruma sığmayacak kadar uzun.)

Lambda ifadesi, anonim bir yapı için sözdizimsel bir şekerdir (bir Voldemort türü, çünkü adını söyleyemezsiniz).

Bu kod pasajında ​​anonim bir yapı ile bir lambda anonimliği arasındaki benzerliği görebilirsiniz:

#include <iostream>
#include <typeinfo>

using std::cout;

int main() {
    struct { int x; } foo{5};
    struct { int x; } bar{6};
    cout << foo.x << " " << bar.x << "\n";
    cout << typeid(foo).name() << "\n";
    cout << typeid(bar).name() << "\n";
    auto baz = [x = 7]() mutable -> int& { return x; };
    auto quux = [x = 8]() mutable -> int& { return x; };
    cout << baz() << " " << quux() << "\n";
    cout << typeid(baz).name() << "\n";
    cout << typeid(quux).name() << "\n";
}

Bu bir lambda için hala tatmin edici değilse, anonim bir yapı için de aynı şekilde tatmin edici olmamalıdır.

Bazı diller, biraz daha esnek olan bir tür ördek yazımına izin verir ve C ++, bir lambda kullanmak yerine doğrudan bir lambda değiştirebilen bir şablondan bir nesne oluşturmaya gerçekten yardımcı olmayan şablonlara sahip olsa da std::functionsarmalayıcı.

Neden benzersiz anonim türlere sahip bir dil tasarlayasınız ?

Çünkü isimlerin alakasız olduğu ve yararlı olmadığı ve hatta ters etki yarattığı durumlar vardır. Bu durumda, varlıklarını soyutlama yeteneği yararlıdır çünkü isim kirliliğini azaltır ve bilgisayar bilimindeki iki zor problemden birini (şeylerin nasıl adlandırılacağı) çözer. Aynı nedenle, geçici nesneler kullanışlıdır.

lambda

Benzersizlik, özel bir lambda şeyi, hatta anonim tipler için özel bir şey değildir. Dildeki adlandırılmış türler için de geçerlidir. Aşağıdakileri düşünün:

struct A {
    void operator()(){};
};

struct B {
    void operator()(){};
};

void foo(A);

Ben geçemediği Not Biçine foosınıfları aynı olsa bile,. Aynı özellik adsız türler için de geçerlidir.

lambdalar yalnızca derleme zamanının, konuşulamayan türlerin std :: function <> ile silinen nesneyle birlikte geçirilmesine izin veren şablon işlevlerine geçirilebilir.

Lambdaların bir alt kümesi için üçüncü bir seçenek vardır: Yakalamayan lambdalar işlev işaretçilerine dönüştürülebilir.

Anonim bir türün sınırlamaları bir kullanım durumu için sorun oluşturuyorsa, çözüm basittir: Bunun yerine adlandırılmış bir tür kullanılabilir. Lambdas, adlandırılmış bir sınıfla yapılamayacak hiçbir şey yapmaz.

Cort Ammon'un kabul ettiği cevap iyi, ancak uygulanabilirlikle ilgili yapılması gereken bir önemli nokta daha var.

İki farklı çeviri birimim olduğunu varsayalım, "one.cpp" ve "two.cpp".

// one.cpp
struct A { int operator()(int x) const { return x+1; } };
auto b = [](int x) { return x+1; };
using A1 = A;
using B1 = decltype(b);

extern void foo(A1);
extern void foo(B1);

İki aşırı yükleme fooaynı tanımlayıcıyı ( foo) kullanır ancak farklı karışık adlara sahiptir. (POSIX-ish sistemlerde kullanılan Itanium ABI'de, karıştırılmış isimler _Z3foo1Ave bu özel durumda _Z3fooN1bMUliE_E,.)

// two.cpp
struct A { int operator()(int x) const { return x + 1; } };
auto b = [](int x) { return x + 1; };
using A2 = A;
using B2 = decltype(b);

void foo(A2) {}
void foo(B2) {}

C ++ derleyicisi gerekir ait parçalanmış adı sağlamak void foo(A1)"two.cpp" içinde mangled adıyla aynıdır extern void foo(A2)Birlikte iki nesne dosyalarını bağlayabilirsiniz böylece, "one.cpp" in. Bu, "aynı tür" olan iki türün fiziksel anlamıdır : temelde ayrı olarak derlenen nesne dosyaları arasındaki ABI uyumluluğu ile ilgilidir.

C ++ derleyicisi olduğu değil emin olmak için gerekli B1ve B2vardır "Aynı tip." (Aslında, farklı tipte olmalarını sağlamak gerekiyor; ancak bu şu anda o kadar önemli değil.)

Derleyici bunu sağlamak için hangi fiziksel mekanizmayı kullanıyor A1ve A2"aynı tip" mi?

Basitçe yazım biçimlerini inceler ve ardından türün tam olarak nitelenmiş adına bakar. Adlı bir sınıf türüdür A. ( ::AKüresel isim alanında olduğu için.) Yani her iki durumda da aynı tip. Anlaması kolay. Daha da önemlisi, uygulanması kolaydır . İki sınıf türünün aynı tür olup olmadığını görmek için adlarını alır ve bir strcmp. Bir sınıf türünü bir işlevin karıştırılmış ismine karıştırmak için, onun adına karakter sayısını ve ardından bu karakterleri yazarsınız.

Yani, adlandırılmış türlerin karıştırılması kolaydır.

Ne fiziksel mekanizma olabileceğini derleyici kullanımı sağlamak için B1ve B2C ++ aynı tip olmalarını gerektiğinde "aynı tip," varsayımsal dünyada nelerdir?

Tipi değil çünkü Eh, türünün adını kullanamadı sahip bir isim.

Belki bir şekilde lambda gövdesinin metnini kodlayabilirdi . Ama bu biraz garip olurdu, çünkü aslında b"one.cpp" içindeki "two.cpp" deki biraz farklı b: "one.cpp" x+1ve "two.cpp" var x + 1. Bu boşluk fark ya şeklindeki bir kural ile gelip olurdu Yani yok olsun ya da o yapar (sonuçta onları farklı yapmak) veya bu belki öyle (belki programın geçerlilik uygulaması-tanımlanır veya belki de "teşhis gerektirmeyen kötü biçimlidir"). Her neyse,A

Zorluktan çıkmanın en kolay yolu, her lambda ifadesinin benzersiz tipte değerler ürettiğini söylemektir. O zaman farklı çeviri birimlerinde tanımlanan iki lambda türü kesinlikle aynı tür değildir . Tek bir çeviri biriminde, lambda türlerini yalnızca kaynak kodun başından itibaren sayarak "adlandırabiliriz":

auto a = [](){};  // a has type $_0
auto b = [](){};  // b has type $_1
auto f(int x) {
    return [x](int y) { return x+y; };  // f(1) and f(2) both have type $_2
} 
auto g(float x) {
    return [x](int y) { return x+y; };  // g(1) and g(2) both have type $_3
} 

Elbette bu isimlerin sadece bu çeviri birimi içinde anlamı vardır. Bu OG'ler $_0her zaman diğer bazı TU'larla aynı tipte $_0olsa da, bu OG'ler struct Aher zaman diğer bazı OG'lerden farklı bir tiptir struct A.

Bu arada, "lambda metnini kodla" fikrimizin başka bir ince problemi olduğuna dikkat edin: lambdas $_2ve $_3tamamen aynı metinden oluşuyor , ancak açıkça aynı tür olarak kabul edilmemeleri gerekiyor !

Bu arada, C ++, derleyicinin rasgele bir C ++ ifadesinin metnini nasıl karıştıracağını bilmesini gerektirir .

template<class T> void foo(decltype(T())) {}
template void foo<int>(int);  // _Z3fooIiEvDTcvT__EE, not _Z3fooIiEvT_

Ancak C ++, derleyicinin rastgele bir C ++ ifadesini nasıl karıştıracağını bilmesini gerektirmez (henüz) . decltype([](){ ...arbitrary statements... })C ++ 20'de bile hala biçimsiz.

Ayrıca / kullanarak adsız bir türe yerel bir takma ad vermenin kolay olduğuna dikkat edin . Sorunuzun bu şekilde çözülebilecek bir şey yapmaya çalışmaktan kaynaklanmış olabileceğine dair bir his var.typedefusing

auto f(int x) {
    return [x](int y) { return x+y; };
}

// Give the type an alias, so I can refer to it within this translation unit
using AdderLambda = decltype(f(0));

int of_one(AdderLambda g) { return g(1); }

int main() {
    auto f1 = f(1);
    assert(of_one(f1) == 2);
    auto f42 = f(42);
    assert(of_one(f42) == 43);
}

EKLENMEK İÇİN DÜZENLENMİŞTİR: Diğer cevaplarla ilgili yorumlarınızın bazılarını okurken, nedenini merak ediyormuşsunuz gibi geliyor

int add1(int x) { return x + 1; }
int add2(int x) { return x + 2; }
static_assert(std::is_same_v<decltype(add1), decltype(add2)>);
auto add3 = [](int x) { return x + 3; };
auto add4 = [](int x) { return x + 4; };
static_assert(not std::is_same_v<decltype(add3), decltype(add4)>);

Bunun nedeni, yakalamasız lambdaların varsayılan olarak oluşturulabilir olmasıdır. (C ++ 'da yalnızca C ++ 20'den itibaren, ancak kavramsal olarak her zaman doğru olmuştur.)

template<class T>
int default_construct_and_call(int x) {
    T t;
    return t(x);
}

assert(default_construct_and_call<decltype(add3)>(42) == 45);
assert(default_construct_and_call<decltype(add4)>(42) == 46);

Eğer denediyseniz default_construct_and_call<decltype(&add1)>, tvarsayılan olarak başlatılmış bir işlev işaretçisi olur ve muhtemelen segfault olursunuz. Faydalı değil gibi.

C ++ statik olarak bağlandığından, C ++ lambdalar farklı işlemler için farklı türlere ihtiyaç duyar . Bunlar yalnızca kopyala / taşı-yapılandırılabilir, bu nedenle çoğunlukla türlerini adlandırmanıza gerek yoktur. Ama hepsi bir şekilde bir uygulama detayı.

C # lambdaların "anonim işlev ifadeleri" olduklarından ve hemen uyumlu bir temsilci türüne veya ifade ağacı türüne dönüştürüldükleri için bir türe sahip olup olmadığından emin değilim. Eğer öyleyse, muhtemelen telaffuz edilemeyen bir türdür.

C ++ ayrıca her tanımın benzersiz bir türe yol açtığı anonim yapılara sahiptir. Burada isim telaffuz edilemez değil, standart söz konusu olduğu sürece mevcut değil.

C # anonim veri türlerine sahiptir ve bu türler , tanımlandıkları kapsamdan çıkmalarını dikkatle yasaklar. Uygulama, bunlara da benzersiz, telaffuz edilemez bir isim verir.

Anonim bir türe sahip olmak, programcıya uygulamalarının içine girmemesi gerektiğini gösterir.

Kenara:

Sen edebilir bir lambda en türüne bir ad verin.

auto foo = []{}; 
using Foo_t = decltype(foo);

Herhangi bir yakalamaya sahip değilseniz, bir işlev işaretçisi türü kullanabilirsiniz.

void (*pfoo)() = foo;

Neden anonim türleri kullanmalı?

Derleyici tarafından otomatik olarak oluşturulan türler için seçim, (1) bir kullanıcının türün adı için isteğini yerine getirmek veya (2) derleyicinin kendi başına birini seçmesine izin vermektir.

1. İlk durumda, kullanıcının böyle bir yapı her göründüğünde açıkça bir ad vermesi beklenir (C ++ / Rust: bir lambda tanımlandığında; Rust: bir işlev tanımlandığında). Bu, kullanıcının her seferinde vermesi gereken yorucu bir ayrıntıdır ve çoğu durumda addan bir daha asla bahsedilmez. Bu nedenle, derleyicinin onun için otomatik olarak bir isim bulmasına izin vermek ve decltypeihtiyaç duyulan birkaç yerde türe başvurmak için veya tür çıkarımı gibi mevcut özellikleri kullanmasına izin vermek mantıklıdır .

2. İkinci durumda, derleyicinin tür için benzersiz bir ad seçmesi gerekir; bu muhtemelen belirsiz, okunamayan bir ad olacaktır __namespace1_module1_func1_AnonymousFunction042. Dil tasarımcısı, bu ismin nasıl muhteşem ve hassas ayrıntılarla nasıl inşa edildiğini tam olarak belirleyebilir, ancak bu, kullanıcıya hiçbir mantıklı kullanıcının güvenemeyeceği bir uygulama ayrıntısını gereksiz yere ifşa eder, çünkü ad, küçük refaktörler karşısında bile hiç şüphesiz kırılgandır. Bu aynı zamanda dilin gelişimini gereksiz yere kısıtlar: gelecekteki özellik eklemeleri, mevcut ad oluşturma algoritmasının değişmesine ve geriye dönük uyumluluk sorunlarına yol açabilir. Bu nedenle, bu ayrıntının çıkarılması ve otomatik oluşturulan türün kullanıcı tarafından anlatılamayacağını iddia etmek mantıklıdır.

Neden benzersiz (farklı) türleri kullanmalı?

Bir değerin benzersiz bir türü varsa, optimize eden bir derleyici, garantili doğrulukla tüm kullanım sitelerinde benzersiz bir türü izleyebilir. Sonuç olarak, kullanıcı bu belirli değerin kaynağının derleyici tarafından tam olarak bilindiği yerlerden emin olabilir.

Örnek olarak, derleyicinin gördüğü an:

let f: __UniqueFunc042 = || { ... };  // definition of __UniqueFunc042 (assume it has a nontrivial closure)

/* ... intervening code */

let g: __UniqueFunc042 = /* some expression */;
g();

derleyici, kaynağını bile bilmeden gmutlaka kaynaklanması gereken tam bir güvene sahiptir . Bu, çağrının sanallaştırılmasına izin verir . Kullanıcı, buna yol açan benzersiz veri akışını korumaya büyük özen gösterdiğinden, bunu da bilirdi .fggfg

Bu, zorunlu olarak kullanıcının neler yapabileceğini kısıtlar f. Kullanıcı şunları yazma özgürlüğüne sahip değildir:

let q = if some_condition { f } else { || {} };  // ERROR: type mismatch

çünkü bu iki farklı türün (yasadışı) birleşmesine yol açacaktır.

Bu sorunu çözmek için, kullanıcı __UniqueFunc042benzersiz olmayan türe yükseltebilir &dyn Fn(),

let f2 = &f as &dyn Fn();  // upcast
let q2 = if some_condition { f2 } else { &|| {} };  // OK

Bu tür silme işlemiyle yapılan takas &dyn Fn(), derleyicinin muhakemesini karmaşıklaştıran kullanımlardır . Verilen:

let g2: &dyn Fn() = /*expression */;

derleyici, işlevden /*expression */mi yoksa başka işlevlerden mi g2kaynaklandığını fve bu kaynağın hangi koşullar altında geçerli olduğunu belirlemek için titizlikle incelemelidir . Birçok durumda, derleyici vazgeçmek olabilir: söyleyebilirdi belki insan g2gerçekten geliyor ftüm durumlarda ancak uzanan yol fiçin g2çok sanal çağrı sonuçlanan deşifre etmek derleyici kıvrık g2kötümser performansı ile.

Bu tür nesneler genel (şablon) işlevlere teslim edildiğinde daha belirgin hale gelir:

fn h<F: Fn()>(f: F);

Biri ararsa h(f)nerede f: __UniqueFunc042, o heşsiz örneğine uzmanlaşmıştır:

h::<__UniqueFunc042>(f);

Bu, derleyicinin hözel argüman için özel kod üretmesini sağlar fve gönderim f, satır içi değilse, büyük olasılıkla statik olacaktır.

Karşı senaryoda, bir kişi h(f)ile arandığında f2: &Fn(), hşu şekilde somutlaştırılır:

h::<&Fn()>(f);

türdeki tüm işlevler arasında paylaşılır &Fn(). hDerleyici, içeriden , opak bir tür işlevi hakkında çok az şey bilir &Fn()ve bu nedenle, yalnızca fsanal bir gönderimle konservatif olarak çağırabilir . Statik olarak göndermek için, derleyicinin çağrıyı h::<&Fn()>(f)kendi çağrı sitesinde satır içi yapması gerekir ki hbu çok karmaşıksa garanti edilmez .

İlk olarak, yakalamasız lambda bir işlev işaretçisine dönüştürülebilir. Bu yüzden bir tür jeneriklik sağlarlar.

Şimdi neden yakalamalı lambdalar işaretçiye dönüştürülemiyor? İşlevin lambda durumuna erişmesi gerektiğinden, bu durumun bir işlev bağımsız değişkeni olarak görünmesi gerekir.

Kullanıcı koduyla isim çakışmalarını önlemek için.

Aynı uygulamaya sahip iki lambdanın bile farklı türleri olacaktır. Sorun değil, çünkü bellek düzeni eşit olsa bile nesneler için farklı türlere sahip olabilirim.