std :: packaged_task non rompe le promesse sulla distruzione?

Question

Sto incontrando qualcosa di molto strano quando si usano compiti preconfezionati. Durante la lettura di ~packaged_task ho l'impressione che se un std::packaged_task viene distrutto prima dell'esecuzione, la promessa verrà interrotta e il tentativo di ottenere il risultato dal futuro dovrebbe generare std::future_error.

Tuttavia, in Visual Studio 2013 questo non sembra essere il caso. Prendete questa seguente codice:

#include <iostream> 
#include <future> 
#include <functional> 

int main() { 
    std::future<int> f; 
    { 
     std::packaged_task<int()> task([](){return 3; }); 
     f = task.get_future(); 
    } 
    std::cout<<f.get()<<std::endl; 
    return 0; 
} 

mi aspetto di ottenere un std::future_error su f.get() ma invece si blocca, in attesa che il compito confezionato da eseguire.

Cercando un altro compilatore: http://ideone.com/Wt0WOc effettivamente gettare una std::future_error("Broken promise") ...

sto vedendo un bug in Visual Studio 2013 o mi sono perso qualcosa?

Answer 1

Sei corretta. ~packaged_task() abbandona lo stato condiviso (§30.6.9.1 [futures.task.members]/p9), che significa, se lo stato condiviso non è pronto, memorizzando un oggetto di eccezione di tipo future_error con condizione di errore broken_promise, quindi eseguendo lo stato condiviso pronto; e quindi rilasciando lo stato condiviso (§30.6.4 [futures.state]/p7).

Questa è una known bug che will be fixed nella prossima versione di Visual Studio, che rischia di uscire un po 'di tempo nel 2015. E' anche stato risolto nel CTP, ma è una brutta idea usare quello per il codice di produzione ..

Answer 2

Penso che sia un bug, lo standard dice ~packaged_task abbandona lo stato condiviso, il che significa che se non è ancora pronto dovrebbe archiviare un'eccezione broken_promise e rendere pronto lo stato, proprio come ci si aspetta.

Full disclosure: il test ideone.com utilizza GCC e ho realizzato di GCC <future> quindi potrei essere prevenuto quando dico il suo comportamento è corretto ... ma penso che sia ancora corretta ;-)