Aslında aşırı yüklenmenin bir nedeni var mı? kısa devre yok mu?

Operatörlerin kısa devre davranışı &&ve ||programcılar için harika bir araçtır.

Fakat aşırı yüklendiğinde neden bu davranışı kaybediyorlar? Operatörlerin fonksiyonlar için sadece sözdizimsel şeker olduğunu anlıyorum, ancak operatörler boolbu davranışa sahipler, neden bu tek tiple sınırlandırılmalı? Bunun arkasında herhangi bir teknik gerekçe var mı?

Tüm tasarım süreçleri, karşılıklı uyumsuz hedefler arasında uzlaşmaya yol açar. Ne yazık ki, &&C ++ ' da aşırı yüklenmiş operatörün tasarım süreci kafa karıştırıcı bir sonuç verdi: İstediğiniz özellik &&- kısa devre davranışı - atlandı.

Tasarım sürecinin bu talihsiz yerde, bilmediğim yerde nasıl sonuçlandığına dair detaylar. Bununla birlikte, daha sonraki bir tasarım sürecinin bu hoş olmayan sonucu nasıl dikkate aldığını görmek önemlidir. C # aşırı &&operatör olan kısa devre. C # tasarımcıları bunu nasıl başardılar?

Diğer cevaplardan biri "lambda kaldırma" yı gösteriyor. Yani:

A && B

ahlaken eşdeğer bir şey olarak gerçekleştirilebilir:

operator_&& ( A, ()=> B )

burada ikinci argüman tembel değerlendirme için bir mekanizma kullanır, böylece değerlendirildiğinde ifadenin yan etkileri ve değeri üretilir. Aşırı yüklenmiş operatörün uygulanması, tembel değerlendirmeyi yalnızca gerektiğinde yapacaktır.

C # tasarım ekibinin yaptığı bu değil. (Kenara: lambda kaldırma olsa olduğunu bunu yapmak için zamanı geldiğinde ne yaptığını ifade ağacı temsil ait ??.. Belirli dönüşüm işlemlerini gerektirir operatörü, tembel yapılacak ayrıntılı olarak ancak büyük bir Arasöz olacağını anlatan yeterli demek: lambda kaldırma çalışıyor ancak bundan kaçınmak istediğimiz kadar ağır.)

Aksine, C # çözümü sorunu iki ayrı soruna ayırır:

• sağ taraftaki işleneni değerlendirmeli miyiz?
• yukarıdakilerin cevabı "evet" ise, iki işleneni nasıl birleştirebiliriz?

Bu nedenle, &&doğrudan aşırı yüklenmeyi yasa dışı hale getirerek sorun çözülür . Aksine, C # 'da , her biri bu iki sorudan birini yanıtlayan iki işleç aşırı yüklenmelidir .

class C
{
    // Is this thing "false-ish"? If yes, we can skip computing the right
    // hand size of an &&
    public static bool operator false (C c) { whatever }

    // If we didn't skip the RHS, how do we combine them?
    public static C operator & (C left, C right) { whatever }
    ...

(Bir kenara: aslında, üç. C #, operatörün falsesağlanması durumunda, operatörün de sağlanması truegerektiğini gerektirir , bu da soruyu cevaplar: bu şey "true-ish?" Dir.Genellikle böyle bir operatörü sağlamak için hiçbir neden olmaz. her ikisini de gerektirir.)

Formun bir ifadesini düşünün:

C cresult = cleft && cright;

Derleyici, bu sözde-C # yazdığınızı düşündüğü gibi bunun için kod üretir:

C cresult;
C tempLeft = cleft;
cresult = C.false(tempLeft) ? tempLeft : C.&(tempLeft, cright);

Gördüğünüz gibi, sol taraf daima değerlendirilir. Eğer "false-ish" olduğu belirlenirse, sonuç budur. Aksi takdirde, sağ taraf değerlendirilir ve istekli kullanıcı tanımlı operatör &çağrılır.

||Operatör bir operatörün çağırma doğru ve istekli olarak, benzer bir şekilde tanımlanır |operatör:

cresult = C.true(tempLeft) ? tempLeft : C.|(tempLeft , cright);

Dört operatörleri tanımlayarak - true, false, &ve |- C # söylemek sadece verir cleft && crightolmayan kısa devre değil, aynı zamanda cleft & crightve aynı zamanda if (cleft) if (cright) ...ve c ? consequence : alternativeve while(c)ve böyle devam eder.

Şimdi, tüm tasarım süreçlerinin uzlaşmanın sonucu olduğunu söyledim. Burada C # dil tasarımcıları kısa devre &&ve ||doğru olmayı başardı , ancak bunu yapmak için iki yerine dört operatörün aşırı yüklenmesi gerekiyor , bu da bazı insanların kafa karıştırıcı buluyor. Operatör true / false özelliği, C # 'da en az anlaşılan özelliklerden biridir. C ++ kullanıcılarına aşina olan mantıklı ve anlaşılır bir dile sahip olma amacına kısa devre yapma arzusu ve lambda kaldırma veya diğer tembel değerlendirme biçimlerini uygulama isteği karşı çıkmıştır. Bunun makul bir uzlaşmaya pozisyon olduğunu düşünüyorum, ama buna fark etmek önemlidir olduğu bir uzlaşma pozisyonu. Sadece farklı C ++ tasarımcılarına göre daha uzlaşma.

Bu tür operatörler için dil tasarımı konusu sizi ilgilendiriyorsa, C # 'ın nulllable Booleans üzerinde bu operatörleri neden tanımlamadığına dair dizimi okumayı düşünün:

http://ericlippert.com/2012/03/26/null-is-not-false-part-one/

Mesele şu ki (C ++ 98 sınırları içinde) sağ taraftaki işlenen, argüman olarak aşırı yüklenmiş operatör fonksiyonuna aktarılacaktır. Bunu yaparken zaten değerlendirilmiş olur . Hiçbir şey operator||()ya operator&&()ya bu önleyeceğini yapamazdım olabilir kodu.

Orijinal işleç farklıdır, çünkü bu bir işlev değildir, ancak dilin daha düşük bir düzeyinde uygulanır.

Ek dil özellikleri olabilir sağ elin dışı değerlendirmesini işlenen sözdizimsel yapmış mümkün . Ancak, bunlar anlamsal olarak yararlı olacak sadece birkaç vaka olduğu için rahatsız etmediler . (Tıpkı ? :aşırı yükleme için mevcut olmayan gibi .

(Lambdaları standart haline getirmek 16 yıl sürdü ...)

Anlamsal kullanıma gelince, şunları göz önünde bulundurun:

objectA && objectB

Bu kaynar:

template< typename T >
ClassA.operator&&( T const & objectB )

Bir dönüşüm operatörünü çağırmak dışında, burada objectB (bilinmeyen tipte) ile tam olarak ne yapmak istediğinizi ve bunu booldil tanımı için kelimelere nasıl koyacağınızı düşünün.

Ve eğer sen edilir de, bool dönüşümü çağıran ...

objectA && obectB

aynı şeyi yapıyor, şimdi yapıyor mu? Peki neden ilk etapta aşırı yük?

Bir özellik düşünülmeli, tasarlanmalı, uygulanmalı, belgelenmeli ve gönderilmelidir.

Şimdi düşündük, şimdi neden kolay olabileceğini görelim (ve o zaman yapmak zor). Ayrıca, sınırlı miktarda kaynak olduğunu unutmayın, bu yüzden eklemek başka bir şey doğranmış olabilir (Bunun için ne yapmak istersiniz?).

Teorik olarak, tüm operatörler , C ++ 11'den itibaren (lambdalar tanıtıldığında, 1979'da "sınıflarla C" başladıktan 32 yıl sonra, hala saygın bir 16 " kısa" ek dil özelliği ile kısa devre davranışına izin verebilir. c ++ 98'den sonra):

C ++, gerekli ve izin verilene kadar (ön koşullar karşılandı) değerlendirmeyi önlemek için tembel olarak değerlendirilen - gizli-lambda - bir argümana açıklama eklemek için bir yola ihtiyaç duyacaktır.

Bu teorik özellik neye benzeyecektir (Yeni özelliklerin yaygın olarak kullanılabilir olması gerektiğini unutmayın)?

Ek açıklama lazy işlev bağımsız değişkenine uygulanan işlevi bir işlev bekleyen bir şablon yapar ve derleyiciyi ifadeyi bir işlevciye dönüştürür:

A operator&&(B b, __lazy C c) {return c;}

// And be called like
exp_b && exp_c;
// or
operator&&(exp_b, exp_c);

Örtünün altına benziyordu:

template<class Func> A operator&&(B b, Func& f) {auto&& c = f(); return c;}
// With `f` restricted to no-argument functors returning a `C`.

// And the call:
operator&&(exp_b, [&]{return exp_c;});

Lambda'nın gizli kaldığına ve en fazla bir kez çağrılacağına dikkat edin. Ortak-alt-ekspresyon-eliminasyon şansının azalmasının yanı sıra, bundan dolayı hiçbir performans düşüşü
olmamalıdır .

Uygulama karmaşıklığı ve kavramsal karmaşıklığın yanı sıra (diğer bazı özellikler için bu karmaşıklıkları yeterince kolaylaştırmadıkça her özellik her ikisini de artırır), bir başka önemli düşünceye bakalım: Geriye dönük uyumluluk.

Bu süre dil özelliği herhangi bir kodu kırmasa da, bundan yararlanan herhangi bir API'yi ustaca değiştirir, yani mevcut kütüphanelerde herhangi bir kullanım sessiz bir kırılma değişikliği anlamına gelir.

BTW: Bu özellik, kullanımı kolay olsa da, C # bölme çözümünden kesinlikle daha güçlüdür &&ve ||her biri ayrı tanım için iki işleve sahiptir.

Retrospektif rasyonalizasyon ile, çünkü

• garantili kısa devre yapabilmek için (yeni sözdizimi getirmeden) operatörlerin Sonuçlardönüştürülebilir gerçek ilk argüman boolve

• kısa devre gerektiğinde başka şekillerde kolayca ifade edilebilir.

Örneğin, bir sınıf Tilişkilendirilmiş &&ve ||işleçler içeriyorsa,

auto x = a && b || c;

burada a, bve cÇeşidi deyimleri T, kısa devre ile ifade edilebilir

auto&& and_arg = a;
auto&& and_result = (and_arg? and_arg && b : and_arg);
auto x = (and_result? and_result : and_result || c);

veya belki daha açık bir şekilde

auto x = [&]() -> T_op_result
{
    auto&& and_arg = a;
    auto&& and_result = (and_arg? and_arg && b : and_arg);
    if( and_result ) { return and_result; } else { return and_result || b; }
}();

Görünen artıklık, operatör çağrılarının yan etkilerini korur.

Lambda yeniden yazımı daha ayrıntılı olsa da, daha iyi kapsüllenmesi kişinin bu tür operatörleri tanımlamasına izin verir .

Aşağıdakilerin (hala biraz influensa) standart uyumluluğundan tamamen emin değilim, ancak temiz Visual C ++ 12.0 (2013) ve MinGW g ++ 4.8.2 ile derler:

#include <iostream>
using namespace std;

void say( char const* s ) { cout << s; }

struct S
{
    using Op_result = S;

    bool value;
    auto is_true() const -> bool { say( "!! " ); return value; }

    friend
    auto operator&&( S const a, S const b )
        -> S
    { say( "&& " ); return a.value? b : a; }

    friend
    auto operator||( S const a, S const b )
        -> S
    { say( "|| " ); return a.value? a : b; }

    friend
    auto operator<<( ostream& stream, S const o )
        -> ostream&
    { return stream << o.value; }

};

template< class T >
auto is_true( T const& x ) -> bool { return !!x; }

template<>
auto is_true( S const& x ) -> bool { return x.is_true(); }

#define SHORTED_AND( a, b ) \
[&]() \
{ \
    auto&& and_arg = (a); \
    return (is_true( and_arg )? and_arg && (b) : and_arg); \
}()

#define SHORTED_OR( a, b ) \
[&]() \
{ \
    auto&& or_arg = (a); \
    return (is_true( or_arg )? or_arg : or_arg || (b)); \
}()

auto main()
    -> int
{
    cout << boolalpha;
    for( int a = 0; a <= 1; ++a )
    {
        for( int b = 0; b <= 1; ++b )
        {
            for( int c = 0; c <= 1; ++c )
            {
                S oa{!!a}, ob{!!b}, oc{!!c};
                cout << a << b << c << " -> ";
                auto x = SHORTED_OR( SHORTED_AND( oa, ob ), oc );
                cout << x << endl;
            }
        }
    }
}

Çıktı:

000 -> !! !! || yanlış
001 -> !! !! || doğru
010 -> !! !! || yanlış
011 -> !! !! || doğru
100 -> !! && !! || yanlış
101 -> !! && !! || doğru
110 -> !! && !! doğru
111 -> !! && !! doğru

Burada her !!bang-bang bir dönüşümü gösterir bool, yani bir argüman değeri kontrolü.

Bir derleyici aynı şeyi kolayca yapabildiğinden ve ek olarak optimize edebildiğinden, bu kanıtlanmış olası bir uygulamadır ve her türlü imkansızlık iddiası genel olarak imkansızlık iddialarıyla aynı kategoriye konulmalıdır, yani genel olarak kilitlemeler.

tl; dr : oldukça düşük maliyetlere (özel sözdizimi gerekli) kıyasla çok düşük talep (özelliği kim kullanacak?) nedeniyle çabaya değmez.

Akla gelen ilk şey, operatörün aşırı yüklenmesi fonksiyonların yazılmasının sadece fantezi bir yoludur, oysa operatörlerin boolean versiyonu ||ve &&buitlin şeyleridir. Bu, derleyicinin kısa devre yapma özgürlüğüne sahip olduğu anlamına gelirken, x = y && zboolean olmayanlarla ifade yve zbenzer bir fonksiyon çağrısına yol açması gerekir X operator&& (Y, Z). Bu y && z, sadece her iki parametrenin de işlevi çağırmadan önce değerlendirilmesi gereken operator&&(y,z)garip bir şekilde adlandırılmış bir işlevin çağrısı olan (kısa devre için uygun kabul edilen herhangi bir şey dahil) yazmak için süslü bir yol anlamına gelir .

Bununla birlikte, işlevin çağrılmasına ve ardından bir yapıcı çağrısına çevrilen işleç &&için olduğu gibi , işleçlerin çevirisinin biraz daha karmaşık hale getirilmesinin mümkün olabileceği iddia edilebilir .newoperator new

Teknik olarak bu sorun olmaz, kısa devreye olanak sağlayan ön koşula özgü bir dil sözdizimi tanımlanması gerekir. Ancak, kısa devrelerin kullanım durumları ile sınırlı olacaktır Yiçin convetible olan X(sadece ilk parametresinden yani hesaplama sonucu), ya da başka aslında kısa devreyi nasıl yapılacağı ek bilgi olmalıydı. Sonuç şu şekilde görünmelidir:

X operator&&(Y const& y, Z const& z)
{
  if (shortcircuitCondition(y))
    return shortcircuitEvaluation(y);

  <"Syntax for an evaluation-Point for z here">

  return actualImplementation(y,z);
}

Biri nadiren aşırı yüklenmek ister operator||ve operator&&çünkü nadiren yazmanın a && bgerçekte sezgisel olmayan bir bağlamda sezgisel olduğu bir durum vardır . Bildiğim tek istisna, örneğin gömülü DSL'ler için ifade şablonlarıdır. Ve bu birkaç durumdan sadece birkaçı kısa devre değerlendirmesinden yararlanabilir. İfade şablonları genellikle yoktur, çünkü bunlar daha sonra değerlendirilecek ifade ağaçları oluşturmak için kullanılır, bu nedenle her zaman ifadenin her iki tarafına da ihtiyacınız vardır.

Kısacası: ne derleyici yazarlar ne de standart yazarlar, çemberlerden atlamak ve ek hantal sözdizimi tanımlamak ve uygulamak gereğini hissetmediler, çünkü bir milyonda bir kullanıcı tanımlı kısa devre yapmanın iyi olacağını düşünebilir operator&&ve operator||- sadece el başına mantığı yazmaktan daha az çaba olmadığı sonucuna varmak için.

Lambdas tembellik getirmenin tek yolu değildir. Tembel değerlendirme, C ++ 'da İfade Şablonları kullanılarak nispeten basittir . Anahtar kelimeye gerek yoktur lazyve C ++ 98'de uygulanabilir. İfade ağaçları zaten yukarıda bahsedilmektedir. İfade şablonları zayıf (ama zeki) insanın ifade ağaçlarıdır. İşin püf noktası, ifadeyi Exprşablonun özyinelemeli iç içe yerleştirilmiş örneklerinin bir ağacına dönüştürmektir . Ağaç, inşaattan sonra ayrı ayrı değerlendirilir.

Aşağıdaki kod, kısa devre &&ve ||operatörleri Ssağladığı sürece logical_andve logical_orserbest fonksiyonlar ve dönüştürülebilir olduğu sürece sınıf için uygular bool. Kod C ++ 14'te ancak fikir C ++ 98'de de geçerlidir. Canlı örneğe bakın .

#include <iostream>

struct S
{
  bool val;

  explicit S(int i) : val(i) {}  
  explicit S(bool b) : val(b) {}

  template <class Expr>
  S (const Expr & expr)
   : val(evaluate(expr).val)
  { }

  template <class Expr>
  S & operator = (const Expr & expr)
  {
    val = evaluate(expr).val;
    return *this;
  }

  explicit operator bool () const 
  {
    return val;
  }
};

S logical_and (const S & lhs, const S & rhs)
{
    std::cout << "&& ";
    return S{lhs.val && rhs.val};
}

S logical_or (const S & lhs, const S & rhs)
{
    std::cout << "|| ";
    return S{lhs.val || rhs.val};
}


const S & evaluate(const S &s) 
{
  return s;
}

template <class Expr>
S evaluate(const Expr & expr) 
{
  return expr.eval();
}

struct And 
{
  template <class LExpr, class RExpr>
  S operator ()(const LExpr & l, const RExpr & r) const
  {
    const S & temp = evaluate(l);
    return temp? logical_and(temp, evaluate(r)) : temp;
  }
};

struct Or 
{
  template <class LExpr, class RExpr>
  S operator ()(const LExpr & l, const RExpr & r) const
  {
    const S & temp = evaluate(l);
    return temp? temp : logical_or(temp, evaluate(r));
  }
};


template <class Op, class LExpr, class RExpr>
struct Expr
{
  Op op;
  const LExpr &lhs;
  const RExpr &rhs;

  Expr(const LExpr& l, const RExpr & r)
   : lhs(l),
     rhs(r)
  {}

  S eval() const 
  {
    return op(lhs, rhs);
  }
};

template <class LExpr>
auto operator && (const LExpr & lhs, const S & rhs)
{
  return Expr<And, LExpr, S> (lhs, rhs);
}

template <class LExpr, class Op, class L, class R>
auto operator && (const LExpr & lhs, const Expr<Op,L,R> & rhs)
{
  return Expr<And, LExpr, Expr<Op,L,R>> (lhs, rhs);
}

template <class LExpr>
auto operator || (const LExpr & lhs, const S & rhs)
{
  return Expr<Or, LExpr, S> (lhs, rhs);
}

template <class LExpr, class Op, class L, class R>
auto operator || (const LExpr & lhs, const Expr<Op,L,R> & rhs)
{
  return Expr<Or, LExpr, Expr<Op,L,R>> (lhs, rhs);
}

std::ostream & operator << (std::ostream & o, const S & s)
{
  o << s.val;
  return o;
}

S and_result(S s1, S s2, S s3)
{
  return s1 && s2 && s3;
}

S or_result(S s1, S s2, S s3)
{
  return s1 || s2 || s3;
}

int main(void) 
{
  for(int i=0; i<= 1; ++i)
    for(int j=0; j<= 1; ++j)
      for(int k=0; k<= 1; ++k)
        std::cout << and_result(S{i}, S{j}, S{k}) << std::endl;

  for(int i=0; i<= 1; ++i)
    for(int j=0; j<= 1; ++j)
      for(int k=0; k<= 1; ++k)
        std::cout << or_result(S{i}, S{j}, S{k}) << std::endl;

  return 0;
}

Mantıksal operatörlerin kısa devre yapmasına izin verilir, çünkü ilişkili doğruluk tablolarının değerlendirilmesinde bir "optimizasyon" dur. Bu, mantığın kendisinin bir fonksiyonudur ve bu mantık tanımlanmıştır.

Aslında aşırı yüklenmenin &&ve ||kısa devre yapmamanın bir nedeni var mı ?

Özel aşırı yüklenmiş mantıksal işleçler, bu doğruluk tablolarının mantığını takip etmek zorunda değildir .

Fakat aşırı yüklendiğinde neden bu davranışı kaybediyorlar?

Bu nedenle, tüm fonksiyonun normal şekilde değerlendirilmesi gerekir. Derleyici, normal aşırı yüklenmiş bir operatör (veya işlev) olarak işlem görmelidir ve yine de diğer işlevlerde olduğu gibi optimizasyon uygulayabilir.

İnsanlar mantıksal operatörleri çeşitli nedenlerle aşırı yüklerler. Örneğin; belirli bir alanda, insanların alışkın olduğu "normal" mantıksal alanlar olmayan belirli bir anlamı olabilir.

Kısa devre, "ve" ve "veya" doğruluk tablosundan kaynaklanmaktadır. Kullanıcının hangi işlemi tanımlayacağını ve ikinci operatörü değerlendirmek zorunda kalmayacağınızı nasıl bilebilirsiniz?

ancak bool operatörleri bu davranışa sahiptir, neden bu tek tiple sınırlandırılmalıdır?

Sadece bu kısma cevap vermek istiyorum. Bunun nedeni, yerleşik &&ve ||ifadelerin aşırı yüklenmiş operatörler gibi işlevlerle uygulanmamasıdır.

Kısa devre mantığının derleyicinin belirli ifadeleri anlaması için yerleşik olması kolaydır. Tıpkı diğer yerleşik kontrol akışları gibi.

Ancak operatör aşırı yüklemesi, belirli kurallara sahip işlevlerle yerine getirilir, bunlardan biri, işlev olarak çağrılmadan önce bağımsız değişken olarak kullanılan tüm ifadelerin değerlendirilmesidir. Açıkçası farklı kurallar tanımlanabilir, ancak bu daha büyük bir iştir.