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
>
|