On 14 April 2018 at 15:38, Murray Cumming wrote:
What are you using from C++17?
Nothing major. Just some constexpr if, std::apply() and std::invoke():
https://github.com/libsigcplusplus/libsigcplusplus/commits/master
GCC's C++17 implementation is not stable yet, so
On 14 April 2018 at 15:38, Murray Cumming wrote:
> On Thu, 2018-04-12 at 21:10 +0100, Jonathan Wakely wrote:
>> On 12 April 2018 at 21:02, Murray Cumming wrote:
>> > I've just released a version of libsigc++-3.0 (currently unstable)
>> > that
>> > requi
On Thu, 2018-04-12 at 21:10 +0100, Jonathan Wakely wrote:
> On 12 April 2018 at 21:02, Murray Cumming wrote:
> > I've just released a version of libsigc++-3.0 (currently unstable)
> > that
> > requires C++17. This means that gtkmm-4.0 (currently unstable)
> > requires
&
On 12 April 2018 at 21:02, Murray Cumming wrote:
> I've just released a version of libsigc++-3.0 (currently unstable) that
> requires C++17. This means that gtkmm-4.0 (currently unstable) requires
> C++17 too. I should have mentioned it first, but I think this is fine.
What are you usi
I've just released a version of libsigc++-3.0 (currently unstable) that
requires C++17. This means that gtkmm-4.0 (currently unstable) requires
C++17 too. I should have mentioned it first, but I think this is fine.
--
Murray Cumming
murr...@murrayc.com
www.murrayc.com
On 13 June 2017 at 08:31, Murray Cumming wrote:
>
> So, I think:
> 1. We would use std::string_view everywhere if all the C functions took
> a length instead of assuming null-termination. That's not going to
> happen.
>
> 2. Overriding all methods to take either a const char* or a std::string
>
On Sun, 2017-05-21 at 15:03 +0100, Daniel Boles wrote:
[snip]
> > I guess we might start taking std::string_view with C++17 instead
> > of
> > std::string and this might largely take care of this.
>
>
> I don't see how string_view would make any difference to whether
gt; of function type, but not not part of the function signature) (since
> C++17)."
>
> So I suspect that the noexcept specification may still not affect name
> mangling.
Right. See the foo and bar examples.
You can't overload like this:
void f() noexcept;
void f();
But you
On Tue, 4 Apr 2017 23:28:09 +0100
Jonathan Wakely <gt...@kayari.org> wrote:
> On 4 April 2017 at 23:08, Chris Vine wrote:
[snip]
> > It also seems
> > weird that merely applying -std=c++17 to your code should break its
> > ABI. The more I think about it, the
On 4 April 2017 at 23:28, Chris Vine <ch...@cvine.freeserve.co.uk> wrote:
> On Tue, 4 Apr 2017 23:09:33 +0100
> Jonathan Wakely <gt...@kayari.org> wrote:
>> On 4 April 2017 at 22:56, Chris Vine wrote:
>> > I would check that. It didn't affect ABI in C++11/14, but
On 4 April 2017 at 23:08, Chris Vine wrote:
> On second thoughts, noexcept(true) might possibly change ABI in C++17,
> but it seems inconceivable that noexcept(false) would.
Right.
You can verify this fairly easily:
https://godbolt.org/g/akduU4
Notice that the type of foo (as used in th
On Tue, 4 Apr 2017 23:09:33 +0100
Jonathan Wakely <gt...@kayari.org> wrote:
> On 4 April 2017 at 22:56, Chris Vine wrote:
> > I would check that. It didn't affect ABI in C++11/14, but I am not
> > so sure about C++17. According to
> > http://en.cppreference.com/w
On 4 April 2017 at 22:56, Chris Vine wrote:
> I would check that. It didn't affect ABI in C++11/14, but I am not so
> sure about C++17. According to
> http://en.cppreference.com/w/cpp/language/noexcept_spec,
> in C++17 "The noexcept-specification is a part of the function type
ay Cumming wrote:
> > > > Any ideas about how we should support C++17 in gtkmm-3.0 without
> > > > losing
> > > > C++11/14 compatibility and without breaking ABI?
> > >
> > > Replace all dynamic exception specifications with noe
On Tue, 04 Apr 2017 18:13:46 +0200
Murray Cumming <murr...@murrayc.com> wrote:
> On Tue, 2017-04-04 at 15:09 +0100, Jonathan Wakely wrote:
> > On 4 April 2017 at 14:52, Murray Cumming wrote:
> > > Any ideas about how we should support C++17 in gtkmm-3.0 without
>
On Tue, 2017-04-04 at 15:09 +0100, Jonathan Wakely wrote:
> On 4 April 2017 at 14:52, Murray Cumming wrote:
> > Any ideas about how we should support C++17 in gtkmm-3.0 without
> > losing
> > C++11/14 compatibility and without breaking ABI?
>
> Replace all dynam
On 4 April 2017 at 15:09, Jonathan Wakely wrote:
> On 4 April 2017 at 14:52, Murray Cumming wrote:
>> Noticed here:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1438766
From that bug report:
(In reply to Murray Cumming from comment #6)
> This makes sense: C++17 will remo
On 4 April 2017 at 14:52, Murray Cumming wrote:
> Any ideas about how we should support C++17 in gtkmm-3.0 without losing
> C++11/14 compatibility and without breaking ABI?
Replace all dynamic exception specifications with noexcept(false) (or
just no exception specification). That's not
Any ideas about how we should support C++17 in gtkmm-3.0 without losing
C++11/14 compatibility and without breaking ABI?
Or should we require C++17 for later gtkmm-3.0 versions?
Noticed here:
https://bugzilla.redhat.com/show_bug.cgi?id=1438766
--
Murray Cumming
murr...@murrayc.com
19 matches
Mail list logo
