Esiste effettivamente un motivo per il sovraccarico di && e || non corto circuito?

Il comportamento in corto circuito degli operatori &&ed ||è uno strumento straordinario per i programmatori.

Ma perché perdono questo comportamento quando sono sovraccarichi? Capisco che gli operatori sono semplicemente zucchero sintattico per le funzioni, ma gli operatori per boolquesto comportamento, perché dovrebbe essere limitato a questo singolo tipo? C'è qualche ragionamento tecnico dietro questo?

Tutti i processi di progettazione comportano compromessi tra obiettivi reciprocamente incompatibili. Sfortunatamente, il processo di progettazione per l' &&operatore sovraccarico in C ++ ha prodotto un risultato finale confuso: che la stessa caratteristica che si desidera &&- il suo comportamento di corto circuito - è omessa.

I dettagli di come è finito quel processo di progettazione in questo luogo sfortunato, quelli che non conosco. È tuttavia rilevante vedere come un successivo processo di progettazione abbia tenuto conto di questo risultato spiacevole. In C #, l' &&operatore sovraccarico è in corto circuito. Come sono riusciti i progettisti di C #?

Una delle altre risposte suggerisce "sollevamento lambda". Questo è:

A && B

potrebbe essere realizzato come qualcosa moralmente equivalente a:

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

dove il secondo argomento utilizza alcuni meccanismi per la valutazione pigra in modo che, quando valutati, vengano prodotti gli effetti collaterali e il valore dell'espressione. L'implementazione dell'operatore sovraccarico farebbe la valutazione pigra solo quando necessario.

Questo non è ciò che ha fatto il team di progettazione di C #. (A parte: se sollevamento lambda è quello che ho fatto quando è arrivato il momento di fare rappresentazione albero espressione del ??operatore, che richiede alcune operazioni di conversione essere effettuato pigramente Descrivendo che in dettaglio sarebbe tuttavia un importante digressione Basti dire:.. Sollevamento lambda funziona ma è sufficientemente pesante da volerlo evitare.)

Piuttosto, la soluzione C # suddivide il problema in due problemi separati:

• dovremmo valutare l'operando di destra?
• se la risposta a quanto sopra è stata "sì", come combiniamo i due operandi?

Pertanto, il problema viene risolto rendendo illegale il sovraccarico &&diretto. Piuttosto, in C # devi sovraccaricare due operatori, ognuno dei quali risponde a una di quelle due domande.

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

(A parte: in realtà, tre. C # richiede che se falseviene fornito l'operatore, trueanche l' operatore deve essere fornito, il che risponde alla domanda: questa cosa è "vero-vero?". In genere non ci sarebbe motivo di fornire solo uno di questi operatori, quindi C # richiede entrambi.)

Considera una dichiarazione del modulo:

C cresult = cleft && cright;

Il compilatore genera codice per questo come si pensava che tu avessi scritto questo pseudo-C #:

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

Come puoi vedere, il lato sinistro viene sempre valutato. Se si determina che è "falso-ish", allora è il risultato. Altrimenti, viene valutato il lato destro e viene richiamato l' operatore desideroso definito dall'utente &.

L' ||operatore è definito in modo analogo, come un'invocazione dell'operatore vero e |dell'operatore desideroso :

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

Con la definizione di tutti e quattro gli operatori - true, false, &e |- C # consente non solo di dire cleft && cright, ma anche non-corto circuito cleft & cright, e anche if (cleft) if (cright) ..., e c ? consequence : alternativee while(c), e così via.

Ora, ho detto che tutti i processi di progettazione sono il risultato di un compromesso. Qui i progettisti del linguaggio C # sono riusciti a ottenere cortocircuiti &&e ||giusti, ma per farlo è necessario sovraccaricare quattro operatori anziché due , cosa che alcune persone trovano confusa. La funzione true / false dell'operatore è una delle funzionalità meno conosciute in C #. L'obiettivo di avere un linguaggio sensibile e diretto, familiare agli utenti di C ++, era contrastato dai desideri di corto circuito e dal desiderio di non implementare il lambda lifting o altre forme di valutazione pigra. Penso che fosse una posizione di compromesso ragionevole, ma è importante rendersi conto che si tratta di una posizione di compromesso. Solo un diverso posizione di compromesso rispetto a quella dei progettisti di C ++.

Se l'argomento del design del linguaggio per tali operatori ti interessa, considera di leggere le mie serie sul perché C # non definisce questi operatori su valori booleani nulla:

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

Il punto è che (entro i limiti di C ++ 98) l'operando di destra verrebbe passato alla funzione di operatore sovraccarico come argomento. In tal modo, sarebbe già stato valutato . Non c'è nulla che il codice operator||()o operator&&()potrebbe o non possa fare che eviti questo.

L'operatore originale è diverso, perché non è una funzione, ma implementato a un livello inferiore della lingua.

Funzionalità linguistiche aggiuntive avrebbero potuto rendere sintatticamente possibile la non valutazione dell'operando della mano destra . Tuttavia, non si sono preoccupati perché ci sono solo alcuni casi selezionati in cui ciò sarebbe semanticamente utile. (Proprio come ? :, che non è disponibile per il sovraccarico.

(Ci sono voluti 16 anni per ottenere lambda nello standard ...)

Per quanto riguarda l'uso semantico, considerare:

objectA && objectB

Questo si riduce a:

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

Pensa a cosa ti piacerebbe fare esattamente con l'oggetto B (di tipo sconosciuto) qui, oltre a chiamare un operatore di conversione boole a come lo diresti in parole per la definizione della lingua.

E se si sta chiamando la conversione a bool, ben ...

objectA && obectB

fa la stessa cosa, ora lo fa? Quindi perché sovraccaricare in primo luogo?

Una funzionalità deve essere pensata, progettata, implementata, documentata e spedita.

Ora ci abbiamo pensato, vediamo perché potrebbe essere facile ora (e difficile da fare allora). Inoltre, tieni presente che c'è solo una quantità limitata di risorse, quindi aggiungerlo potrebbe aver tritato qualcos'altro (cosa ti piacerebbe rinunciare per questo?).

In teoria, tutti gli operatori potevano consentire un comportamento in corto circuito con una sola caratteristica linguistica aggiuntiva "minore" , a partire dal C ++ 11 (quando furono introdotti i lambda, 32 anni dopo l'inizio della "C con classi" nel 1979, ancora rispettabile 16 dopo c ++ 98):

Il C ++ avrebbe solo bisogno di un modo per annotare un argomento come pigro-valutato - un nascosto-lambda - per evitare la valutazione fino a quando necessario e consentito (pre-condizioni soddisfatte).

Come sarebbe quella caratteristica teorica (ricorda che qualsiasi nuova funzionalità dovrebbe essere ampiamente utilizzabile)?

Un'annotazione lazy, che si applicava a un argomento di funzione, rende la funzione un modello in attesa di un functor e rende il compilatore impacchettare l'espressione in un funzione:

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

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

Sembrerebbe sotto la copertina come:

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

Prendi nota che il lambda rimane nascosto e verrà chiamato al massimo una volta.
Non ci dovrebbe essere alcun peggioramento delle prestazioni a causa di ciò, a parte le ridotte possibilità di eliminazione della sottoespressione comune.

Oltre alla complessità dell'implementazione e alla complessità concettuale (ogni caratteristica aumenta entrambe, a meno che non le elimini sufficientemente per alcune altre caratteristiche), diamo un'occhiata a un'altra considerazione importante: compatibilità con le versioni precedenti.

Sebbene questa funzionalità linguistica non rompa alcun codice, cambierebbe sottilmente qualsiasi API che ne sfrutti, il che significa che qualsiasi uso nelle librerie esistenti sarebbe un cambiamento silenzioso.

A proposito: questa funzionalità, sebbene più facile da usare, è strettamente più forte della soluzione C # di suddivisione &&e ||in due funzioni ciascuna per una definizione separata.

Con razionalizzazione retrospettiva, principalmente perché

• per garantire un corto circuito (senza introdurre una nuova sintassi) gli operatori dovrebbero essere limitati a risultatiprimo argomento effettivo convertibile in bool, e

• il corto circuito può essere facilmente espresso in altri modi, quando necessario.

Ad esempio, se una classe Tha associati &&e ||operatori, quindi l'espressione

auto x = a && b || c;

dove a, be csono espressioni di tipo T, possono essere espresse con corto circuito come

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

o forse più chiaramente come

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; }
}();

L'apparente ridondanza preserva gli effetti collaterali delle invocazioni dell'operatore.

Mentre la riscrittura lambda è più dettagliata, la sua migliore incapsulamento consente di definire tali operatori.

Non sono del tutto sicuro della conformità standard di tutto quanto segue (ancora un po 'di influenza), ma si compila in modo pulito con Visual C ++ 12.0 (2013) e MinGW g ++ 4.8.2:

#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;
            }
        }
    }
}

Produzione:

000 -> !! !! || falso
001 -> !! !! || vero
010 -> !! !! || falso
011 -> !! !! || vero
100 -> !! && !! || falso
101 -> !! && !! || vero
110 -> !! && !! vero
111 -> !! && !! vero

Qui ogni !!bang-bang mostra una conversione bool, ovvero un controllo del valore dell'argomento.

Poiché un compilatore può facilmente fare lo stesso e ottimizzarlo ulteriormente, si tratta di un'implementazione dimostrata possibile e ogni richiesta di impossibilità deve essere inserita nella stessa categoria delle richieste di impossibilità in generale, vale a dire, generalmente bollocks.

tl; dr : non vale la pena, a causa della domanda molto bassa (chi userebbe la funzione?) rispetto ai costi piuttosto elevati (è necessaria una sintassi speciale).

La prima cosa che mi viene in mente è che il sovraccarico dell'operatore è solo un modo elegante per scrivere funzioni, mentre la versione booleana degli operatori ||e &&sono cose da buitlin. Ciò significa che il compilatore ha la libertà di cortocircuitarli, mentre l'espressione x = y && zcon non booleano ye zdeve condurre a una chiamata a una funzione simile X operator&& (Y, Z). Ciò significherebbe che y && zè solo un modo elegante di scrivere, operator&&(y,z)che è solo una chiamata di una funzione stranamente denominata in cui entrambi i parametri devono essere valutati prima di chiamare la funzione (incluso tutto ciò che riterrebbe appropriato un cortocircuito).

Tuttavia, si potrebbe sostenere che dovrebbe essere possibile rendere la traduzione degli &&operatori un po 'più sofisticata, come lo è per l' newoperatore che si traduce in chiamare la funzione operator newseguita da una chiamata del costruttore.

Tecnicamente questo non sarebbe un problema, si dovrebbe definire una sintassi del linguaggio specifica per il presupposto che consente il corto circuito. Tuttavia, l'uso di cortocircuiti sarebbe limitato ai casi in cui Yè possibile farlo X, oppure ci sarebbero state ulteriori informazioni su come eseguire effettivamente il corto circuito (ovvero calcolare il risultato solo dal primo parametro). Il risultato dovrebbe apparire un po 'così:

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

Raramente si vuole sovraccaricare operator||e operator&&, poiché raramente c'è un caso in cui la scrittura a && bè effettivamente intuitiva in un contesto non booleano. Le uniche eccezioni che conosco sono i modelli di espressione, ad esempio per i DSL incorporati. E solo una manciata di quei pochi casi trarrebbe beneficio dalla valutazione del corto circuito. I modelli di espressione di solito no, poiché vengono utilizzati per formare alberi di espressioni che vengono valutati in un secondo momento, quindi è sempre necessario avere entrambi i lati dell'espressione.

In breve: né gli autori di compilatori né gli autori di standard sentivano il bisogno di saltare attraverso i cerchi e definire e implementare una sintassi ingombrante aggiuntiva, solo perché uno su un milione potrebbe avere l'idea che sarebbe bello avere un cortocircuito su definito dall'utente operator&&e operator||- solo per arrivare alla conclusione che non è meno sforzo che scrivere la logica per mano.

Lambdas non è l'unico modo per introdurre la pigrizia. La valutazione pigra è relativamente semplice usando i modelli di espressione in C ++. Non è necessaria la parola chiave lazye può essere implementata in C ++ 98. Gli alberi delle espressioni sono già menzionati sopra. I modelli di espressione sono alberi di espressione dell'uomo povero (ma intelligente). Il trucco è convertire l'espressione in un albero di istanze ricorsivamente nidificate del Exprmodello. L'albero viene valutato separatamente dopo la costruzione.

I seguenti attrezzi codice cortocircuitati &&e ||gli operatori per la classe Sfintanto che fornisce logical_ande logical_orfunzioni libere ed è convertibile in bool. Il codice è in C ++ 14 ma l'idea è applicabile anche in C ++ 98. Vedi esempio dal vivo .

#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;
}

Il corto circuito degli operatori logici è consentito perché si tratta di una "ottimizzazione" nella valutazione delle tabelle di verità associate. È una funzione della logica stessa e questa logica è definita.

C'è davvero un motivo per cui sovraccarico &&e ||non corto circuito?

Gli operatori logici con sovraccarico personalizzato non sono obbligati a seguire la logica di queste tabelle di verità.

Ma perché perdono questo comportamento quando sono sovraccarichi?

Quindi l'intera funzione deve essere valutata come di consueto. Il compilatore deve considerarlo come un normale operatore (o funzione) sovraccarico e può comunque applicare ottimizzazioni come farebbe con qualsiasi altra funzione.

Le persone sovraccaricano gli operatori logici per una serie di motivi. Per esempio; possono avere un significato specifico in un dominio specifico che non è quello "normale" logico a cui le persone sono abituate.

Il corto circuito è dovuto alla tabella di verità di "e" e "o". Come sapresti quale operazione verrà definita dall'utente e come sapresti che non dovrai valutare il secondo operatore?

ma gli operatori di bool hanno questo comportamento, perché dovrebbe essere limitato a questo singolo tipo?

Voglio solo rispondere a questa parte. Il motivo è che il built-in &&e le ||espressioni non sono implementati con funzioni come lo sono gli operatori sovraccarichi.

Avere la logica di cortocircuito integrata nella comprensione del compilatore di espressioni specifiche è facile. È proprio come qualsiasi altro flusso di controllo integrato.

Ma il sovraccarico dell'operatore è invece implementato con funzioni che hanno regole particolari, una delle quali è che tutte le espressioni usate come argomenti vengono valutate prima che la funzione venga chiamata. Ovviamente si potrebbero definire regole diverse, ma è un lavoro più grande.