I've just begun having issues with some use of boost::optional producing the error shown in the subject. This is a gcc bug, filed at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679 The corresponding downstream bug for RedHat/Fedora is at https://bugzilla.redhat.com/show_bug.cgi?id=676361 and has a code listing to reproduce. Sending this partially as an FYI, and also to ask if anyone has any workaround? Altering client code to construct with boost::none or a false condition, then assigning a value if required, still yields the error on the assign operation. My current workaround is to initialize the optional<T> in question with a dummy T instance, then call reset() with no params if I want an 'uninitialized' optional. It looks rather bizarre, but if it must be then it must be. -- Rob Desbois Eml: rob.desbois@gmail.com Blog: http://theotherbranch.wordpress.com/