Funções lambda não fazem mágica

Muitos se encantaram com a inclusão de lambdas à linguagem C++ no novo padrão aprovado no ano passado. Tanto é que as versões mais novas dos principais compiladores já suportam a nova sintaxe. Mas vale lembrar que algumas regras básicas da linguagem continuam valendo, e você deve levar isso em consideração ao criar seus lambdas.

[Nota: conforme apresentado pelo Paulo Pires nos comentários, me convenci de que lambdas, afinal, fazem mágica. O post corrigindo as informações apresentadas está aqui.]

Meu experimento começou há pouco mais de uma semana. Estava estudando a linguagem Go, criada pelo Google, e um trecho de código em especial chamou minha atenção: uma função que retornava o próximo número da sequência de Fibonacci a cada chamada.

func fib() func() int {
    n1 := 0
    n2 := 1

    return func() int {
        temp := n1 + n2
        n1 = n2
        n2 = temp
        return temp
    }
}

func main() {
    f := fib()

    // Imprime os dez primeiros numeros 
    // da sequencia de Fibonacci
    for i:=0; i<10; i++ {
        fmt.Println( f() )
    }
}

Resultado:
1
2
3
5
8
13
21
34
55
89

Eu fiquei bem empolgado com a engenhosidade de Go e resolvi brincar com lambdas também em C++. A princípio, tentei uma tradução quase literal do código acima, tomando cuidado apenas para capturar n1 e n2 por referência, já que são variáveis que minha função deveria modificar.

#include <functional>

std::function<int()> fib() {
    int n1 = 0, n2 = 1;
   
    return [&] {
        int temp = n1 + n2;
        n1 = n2; n2 = temp;
        return temp;
    }
}

Resultado:
1
11
20
20
20
20
20
20
20
20

Mas, que diabos! Não era isso que o código deveria gerar! O que está acontecendo?

Este é um comportamento que está explicado no padrão C++11. Se uma expressão lambda captura variáveis por referência e estas variáveis saem de escopo (portanto, "deixam de existir") antes do código ser chamado, o resultado disso incorre em comportamento indefinido. Qualquer coisa pode sair daí, desde o resultado correto até o apocalipse zumbi.

Zumbis - o undefined behavior da natureza.

No nosso caso não ocorre nada tão drástico, mas ainda assim imprevisível. Ambas n1 e n2 são variáveis locais e, apesar de serem referenciadas pela função lambda, elas não são transferidas para o seu escopo. Assim, quando nosso código sai de fib, ambas deixam de existir e  nossa pequena lambda está utilizando áreas de memória com valores completamente aleatórios para realizar o cálculo da sequência de Fibonacci.

Tentando consertar a minha trapalhada, modifiquei a declaração das variáveis para que ambas tivessem escopo estático, sendo, portanto, mantidas após o fim da função na qual foram declaradas. Rodei o código e... Sucesso! A sequência de Fibonacci foi exibida corretamente! Então está tudo correto, certo?

Declarar n1 e n2 como variáveis estáticas resolveu um problema, mas introduziu outro. Para que você tenha uma noção melhor de por quê ainda não temos nada igual a Go, basta uma mudança simples abaixo.

func main () {
    f := fib()
    g := fib()

    for i := 0; i < 10; i++ {
        fmt.Printf("%d\t%d\n", f(), g())
    }
}

Resultado:
1    1
2    2
3    3
5    5
8    8
13    13
21    21
34    34
55    55
89    89

O código equivalente em C++ retorna algo bem diferente:

2    1
5    3
13    8
34    21
89    55
233    144
610    377
1597    987
4181    2584
10946    6765

Isso é consequência direta da nossa "solução". Como n1 e n2 são variáveis estáticas, não importa quantas "funções" nós retornemos através de fib, todas irão apontar para as mesmas variáveis n1 e n2.

Também não adianta declarar n1 e n2 como estáticas dentro da função lambda. As expressões lambda de C++ não são nada além de uma facilidade da linguagem, um syntatic sugar. O que o compilador fará, na realidade, será criar uma função comum com o código de definição da expressão lambda em uma outra região de memória, com um nome que só ele conhece. Então ele passará um ponteiro para essa função dentro de uma variável do tipo function<int()>. Não importa quantos objetos você crie com fib, todos chamarão uma mesma função estática, com as mesmas variáveis estáticas.

Solução Final

A solução para o nosso problema passa por uma técnica conhecida de C++, objetos-função, ou functors.

Estes objetos nada mais são do que classes que sobrecarregam operator () para que suas instâncias possam ser "invocadas" com a mesma sintaxe com que se invoca funções. Como classes podem ter variáveis membro, com contextos e espaço de memória separados, uma instancia do functor não tem qualquer influência sobre outras instancias.

Assim, temos o nosso gerador de sequência Fibonacci usando um functor.

#include <cstdio>

class Fib {
    int n1, n2;

public:
    Fib(): n1(0), n2(1) { }

    int operator()() {
        int temp = n1 + n2;
        n1 = n2; n2 = temp;
        return temp;
    }
};

int main() {
    Fib f, g;

    for(int i=0; i < 10; i++) {
        std::printf("%d\t%d\n", f(), g());
    }

    return 0;
}

Resultado:
1    1
2    2
3    3
5    5
8    8
13    13
21    21
34    34
55    55
89    89

Conclusão

Ao final deste experimento, você deve estar se perguntando qual a vantagem que funções lambda trouxeram a C++, já que elas não proporcionam nada que não fosse possível anteriormente sem elas. A resposta é "contexto".

Como as funções lambda são declaradas apenas no momento em que são utilizadas, elas tem o benefício implícito de dar maior legibilidade ao código. Eu não preciso procurar nos arquivos de código-fonte do meu projeto o que a função ou functor xyz faz quando invocada com std::for_each, por exemplo. O código está no mesmo local em que é chamado, dando uma visão melhor de como ele se relaciona e modifica o contexto no qual está inserido. Elas nos ajudam a programar melhor e cometer menos erros, ou ao menos identificá-los mais facilmente.

Portanto, lambdas tem sua utilidade em C++. Elas, com certeza, dão novo fôlego à linguagem, e ao nosso código. Mas ainda é C++.