Use of auto_ptr causes dirty compile under C++11

[noloader]

Opened to tend to all issues related to dirty compiles due to use of auto_ptr and C++011. It includes Issue 17.

Bug 17 cleared the issue under Cygwin by using a lot of define magic to determine when C++ 11 was _really_ available, and then switched to a unique_ptr if C++11 was really available. Its correct, but it might not be the easiest way to get there.

Denis provided an insightful observation in Issue 17, but it was kind of lost upon us as we rushed to use C++ language features to solve the problem. The problem was more cleanly solved...

We found we could simply use member_ptr from smartptr.h. member_ptr (1) provides the basic functionality we need, and (2) provides reset and release. member_ptr allows us to (3) forgo all the additional logic need to determine when unique_ptr was _really_ available, and (4) forgo the using auto_ptr = unique_ptr<T> template declaration.

[mouse07410]

On Oct 26, 2015, at 22:00 , Jeffrey Walton <notifications@github.commailto:notifications@github.com> wrote:
Opened to tend to all issues related to dirty compiles due to use of auto_ptr. It includes Issue 17#17

Bug 17 cleared the issue by using a lot of define magic to determine when C++ 11 was really available, and then switched to a unique_ptr if C++11 was really available. Its correct, but it might not be the easiest way to get there.

How about us switching 100% to C++11 for Crypto++ 5.7? Or maybe even 5.6.3? C++11 is spread wide enough by now, and all of the compilers I’m aware of that are currently used, support it.

[noloader]

How about us switching 100% to C++11 for Crypto++ 5.7?

I think if we do things correctly (for some definition of correct :), then it will be transparent in most places. We already have logic for the throwing destructors. member_ptr handles the issues between C++03/auto_ptr and C++11/unique_ptr.

There's one remaining use of auto_ptr. The hit onsmartptr.h is just a comment:

$ egrep auto_ptr *.h *.cpp | cut -d ":" -f 1 | sort | uniq
smartptr.h
validat1.cpp

And from validat1.cpp, around line 375:

// VC50 workaround
typedef auto_ptr<BlockTransformation> apbt;

We'll get to that one in the future, when we can break the ABI/API/versioning. (This is more a matter of versioning because we are changing symbols).

Do you recall any other C++03/C++11 issues? If you know of any, then I'd like to try and tend to them now for folks who adopt 5.6.3.

[mouse07410]

No I don't recall other C++11 issues off-hand...

Sent from my iPad

On Oct 26, 2015, at 22:25, Jeffrey Walton <notifications@github.commailto:notifications@github.com> wrote:

How about us switching 100% to C++11 for Crypto++ 5.7?

I think if we do things correctly, then it will be transparent in most places. We already have logic for the throwing destructors. member_ptr handles the issues between C++03/auto_ptr and C++11/unique_ptr.

There's one remaining use of auto_ptr. The hit onsmartptr.h is just a comment:

$ egrep auto_ptr *.h *.cpp | cut -d ":" -f 1 | sort | uniq
smartptr.h
validat1.cpp

And it is from validat1.cpp

// VC50 workaround
typedef auto_ptr apbt;

We'll get to that one in the future.

Do you recall any other C++03/C++11 issues?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/48#issuecomment-151346799.