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

[Josh Stone <jistone@xxxxxxxxxx>]

On 08/31/2016 09:08 AM, Bill Williams wrote:
> 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.

I don't know about "less capable" compilers.  What I heard about ABIs at
the workshop sounds like most folks are still hesitant to mix compilers
at all.  With my Red Hat on, we'd generally prefer you just use our
system gcc, or our newer DTS gcc that promises to be compatible.

But the question is just the mode of that compiler.  We require some
level of C++11 (or preliminary C++0x) for dyninst itself already.  But
before GCC6 the default was still -std=gnu++98, so mutators won't be
using a new mode unless explicitly chosen.

*Just* requiring C++11 should be an easy thing to ask of mutators.
Switching to new std types might cause a little porting headache,
depending on how well folks use typedefs.  Hey, just use "auto" now! :)

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

Certainly we need user feedback.  Is there any other forum to ask?

I'd like to move forward, but I don't feel strongly that we must.  I
just want a decision so we can fix the header compatibility if needed.
Well, I'll go ahead and fix the '>>' nit mentioned below, and we can
keep thinking about it.

> ________________________________________
> 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
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
>