Assignment to optional is not possible if operator& is overriden

[Andrey Semashev]

The assignment operator for optional< T > uses T::operator& to dispatch the call between assign_expr functions. This dispatch breaks if the T::operator& returns something else than T*. This is the case with ATL types, such as CComBSTR.

The suggested fix is to replace call to operator& with addressof. Please, find the attached patch against the 1.40 release.

[Andrey Semashev]

BTW, I just now noticed that the assignment operator accepts its argument by value. It may be worth to accept it by const reference, as the operator is not only called for in-place factories but also for other types. For example:

struct MyString
{
    MyString(std::string const&);
};

std::string str = "Hello";
boost::optional< MyString > opt;

opt = str; // here a needless copy of str will be constructed

I'm attaching an updated patch that fixes this, too.

[Andrey Semashev]

An updated fix that also optimises away copying the assignment argument

[Andrey Semashev]

(In [67020]) Refs #3395. Optional construction and assignment now works correctly for types with overridden operator&. Also silenced some GCC warnings about broken strict aliasing rules.

[Ralf W. Grosse-Kunstleve]

proposed patch for review

[Ralf W. Grosse-Kunstleve]

The current optional.hpp leads to gcc 3.2 warnings (Redhat 8.0). It is easily fixed with the proposed patch I attached a minute ago. Is this OK to commit? -- It is tested already locally on a large number of platforms.

[Steven Watanabe]

Replying to rwgk:

The current optional.hpp leads to gcc 3.2 warnings (Redhat 8.0). It is easily fixed with the proposed patch I attached a minute ago. Is this OK to commit? -- It is tested already locally on a large number of platforms.

This looks good to me.

[anonymous]

Looks good to me as well. Please go ahead and commit.

[Andrey Semashev]

Perhaps, the patch should also take into account GCC versions prior to 3.2? I really don't know since which version may_alias has become available.

[Ralf W. Grosse-Kunstleve]

I checked in my patch as svn trunk rev. [67109] before seeing comment 6.

Is anyone still using a gcc before 3.2? Even 3.2 is ancient now (released 2002). It is the oldest gcc I have, i.e. I couldn't test with any older versions.

[Andrey Semashev]

That's ok, I've updated your change with a check for earlier GCC versions. Try with the updated version.

[anonymous]

It ran without a problem in our nightly builds (24 platforms). Thanks!

[Andrey Semashev]

(In [67183]) Merged changes from trunk. Fixes #3395. Also updates swap behavior: if default constructor has no-throw guarantee, swap will use it to provide no-throw guarantee itself. operator>> behavior changed slightly so that the stream is not accessed when unrecognized character sequence is detected. The stream is marked with failbit in such a case.