Re: C++17

[Kjell Ahlstedt via gtkmm-list]

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 there are still ABI
   changes possible between GCC 8 and GCC 9.

   IIRC we've already introduced some (minor) incompatibilities between
   the std::variant in GCC 7 and GCC 8.

   gtkmm-4.0 is itself unstable, so that's not a problem. And I see no
   sign that GTK+ 4.0 will become stable any time soon.

Would it be acceptable to use std::optional in gtkmm-4.0?
I'm planning to wrap the new GtkGestureStylus class.
  gboolean gtk_gesture_stylus_get_axis(GtkGestureStylus *gesture, GdkAxisUse 
axis, gdouble *value);
could then become
  std::optional get_axis(Gdk::AxisUse axis) const;



**
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: C++17

[Jonathan Wakely]

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
>> > 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 using from C++17?
>
> Nothing major. Just some constexpr if, std::apply() and std::invoke():
> https://github.com/libsigcplusplus/libsigcplusplus/commits/master

That's fine then - no ABI worries with those bits.

>> GCC's C++17 implementation is not stable yet, so there are still ABI
>> changes possible between GCC 8 and GCC 9.
>>
>> IIRC we've already introduced some (minor) incompatibilities between
>> the std::variant in GCC 7 and GCC 8.
>
> gtkmm-4.0 is itself unstable, so that's not a problem. And I see no
> sign that GTK+ 4.0 will become stable any time soon.

OK, cool. I wanted to be sure you wouldn't end up with a dependency on
something unstable, but it sounds like that won't be a problem.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: C++17

[Murray Cumming]

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
> > C++17 too. I should have mentioned it first, but I think this is
> > fine.
> 
> 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 there are still ABI
> changes possible between GCC 8 and GCC 9.
> 
> IIRC we've already introduced some (minor) incompatibilities between
> the std::variant in GCC 7 and GCC 8.

gtkmm-4.0 is itself unstable, so that's not a problem. And I see no 
sign that GTK+ 4.0 will become stable any time soon.

-- 
Murray Cumming
murr...@murrayc.com
www.murrayc.com

___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: C++17

[Jonathan Wakely]

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 using from C++17?

GCC's C++17 implementation is not stable yet, so there are still ABI
changes possible between GCC 8 and GCC 9.

IIRC we've already introduced some (minor) incompatibilities between
the std::variant in GCC 7 and GCC 8.
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list

Re: C++17's string_view (was Re: Making use of move semantics?)

[Jonathan Wakely]

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
> (ignoring ustring for now), would avoid the extra array copy, but I
> don't think it's worth it other than for methods that typically take
> very large strings.
>
> 3. GTK+ functions that take very large strings tend to take a length,
> to avoid the need for copying. For instance,
> gtk_text_buffer_set_text(). We could take std::string_view there, but
> then our use of std::string_view::to_string() would be wasteful when
> someone passes a std::string to our method.
>
> This is discouraging, so I hope I'm wrong about something.
>
>

Nope, you're correct. string_view is great if you stay in C++ world, but
suboptimal when you need to pass the string to libc functions or C APIs
taking null-terminated strings.

One possible approach (which I have no experience of in practice, only in
theory) is to use string_view objects which explicitly include the
null-terminator in their length:

template
inline std::basic_string_view
make_null_terminated_view(const C* s) noexcept
{ return { s, T::length() + 1 }; }

template
inline bool
is_null_terminated_view(std::basic_string_view sv) noexcept
{ return sv.length() && !sv.back(); }


And/or create your own cstring_view / zstring_view type which is guaranteed
to be null-terminated:

struct cstring_view : std::string_view {
  cstring_view(const char* s)
  : std::string_view(s, traits_type::length(s)+1)
  { }
};

Unlike std::string which has a null-terminator after its content that isn't
counted in the length, these string views would count the null character as
part of their content. You'd need a little more care to use this (i.e. when
using the length remember to subtract one where appropriate) but it does
mean you can pass around views to null-terminated strings efficiently
(along with their length, which is the advantage over a raw pointer).
___
gtkmm-list mailing list
gtkmm-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtkmm-list