Re: [DynInst_API:] RFC: require users to have C++11

[Bill Williams <bill@xxxxxxxxxxx>]

I won't say it's entirely a fool's errand to expect to build Dyninst mutators with a less capable compiler than one uses to build Dyninst itself, but it seems not to be a terribly valuable form of backwards compatibility, especially given that our only binary distribution at present is managed by RedHat. :) If I'm wrong on that point, though, folks should speak up.

In general I think I'd prefer to deprecate boost:: in favor of std:: where boost-isms have made it into C++11. I don't have firm notions on a migration timetable, though, and user feedback is more relevant than my preferences about code hygiene here.

--bw

________________________________________
From: Dyninst-api <dyninst-api-bounces@xxxxxxxxxxx> on behalf of Josh Stone <jistone@xxxxxxxxxx>
Sent: Tuesday, August 30, 2016 4:32 PM
To: dyninst-api@xxxxxxxxxxx
Subject: Re: [DynInst_API:] RFC: require users to have C++11

Anyone? Anyone? Bueller?

If we're going to keep pre-C++11 compatibility, we must keep the public
headers clean.  For instance, in commit 895d3fad7e59 I fixed a template
'>>' which was not allowed before C++11.  Now I just noticed another
case of this problem was added in commit dff30ae88e36.

On 08/17/2016 11:47 AM, Josh Stone wrote:
> Dyninst already requires C++11 features to build itself, but maintains
> support for pre-C++11 in the public interface.  This means for instance
> that we have to use std::tr1::unordered_map and boost::shared_ptr
> instead of the C++11 std::unordered_map and std::shared_ptr.
>
> For a small example motivation, I was looking at the enormous function
> SyscallInformation::SyscallInformation(), which has to fill the mapping
> tables.  Right now it does this with individual insert() calls, which
> generates a lot of code.  I'm thinking of a few ways to make this more
> data-driven, and the easiest would be with C++11 initializer lists:
>
>   Linux_Arch_ppc64_syscallNames.insert({
>     {0, "restart_syscall"},
>     {1, "exit"},
>     {2, "fork"},
>     /* ... */
>   });
>
> Now, this map is purely internal, so we could just go ahead convert it
> from the generic dyn_hash_map to a C++11 std::unordered_map and go
> crazy.  But I'd like to have the opportunity to use C++11 throughout the
> code, without worrying about what's in public headers.
>
> Assuming we want to maintain RHEL6 support (GCC 4.4), that still limits
> us to some earlier "C++0x" features, listed at the link below.  I'm not
> sure about the state of Dyninst's minimum MSVC on the Windows side.
> https://gcc.gnu.org/gcc-4.4/cxx0x_status.html
>
> FWIW, GCC6 leaped up to -std=gnu++14 as the default mode.  This is in
> Fedora 24 now and will be in Ubuntu 16.10.
>
>
> Could we make this change in master now for Dyninst 9.3?  Wait for 10.0?
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>

_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api