Re: Replace Gtk::manage() with std::unique_ptr<>?

On 08/02/16 10:18 +1300, Ian Martin wrote: As you've said, using unique_pointer mandates a design with only one access point to the controlled object, That's not true. std::unique_ptr mandates one *owner* of the object, but that doesn't prevent you accessing it through any number of

Re: Replace Gtk::manage() with std::unique_ptr<>?

On 08/02/16 13:19 +0100, Murray Cumming wrote: On Mon, 2016-02-08 at 11:56 +, Jonathan Wakely wrote: [snip] A cleaner API would operate in terms of rvalues returned from functions, and passed straight into other functions, avoiding std::move entirely. [snip] Do you mean like

Re: Replace Gtk::manage() with std::unique_ptr<>?

On 08/02/16 00:08 +0100, Murray Cumming wrote: On Sun, 2016-02-07 at 22:51 +0100, Dr. Diether Knof wrote: Hello, I think, to use std::unique_ptr and std::move instead of Gtk::manage is a good idea, but it is more difficult to use: > auto widget = std::make_unique("some button"); OK >

Re: Replace Gtk::manage() with std::unique_ptr<>?

On 08/02/16 15:40 +0100, Murray Cumming wrote: On Mon, 2016-02-08 at 12:40 +, Jonathan Wakely wrote: [snip] You said (1) "doesn't seem much better" than use-after-move, which I disagree with. It's infinitely better because it is not undefined and doesn't crash :-) Of course. I

Re: Replace Gtk::manage() with std::unique_ptr<>?

On 08/02/16 15:56 +0100, Murray Cumming wrote: On Mon, 2016-02-08 at 15:44 +0100, Krzesimir Nowak wrote: Just a minor hint here - Button* b {}; should do the trick and it is not that lot more of typing. Thanks. Whether we should now use curly brackets for "uniform initialization" wherever

Re: Problem using std::prev on ustring iterator

On 18 March 2016 at 17:57, jeremy.harmon wrote: > Hello, > > When I try to use std::prev on a ustring const_iterator nothing > happens, operator-- works fine. > > Glib::ustring str = "test"; > Glib::ustring::iterator iter = str.begin(); > > std::advance(iter); > printf("%c\n", *iter); > >

Re: Problem using std::prev on ustring iterator

On 18 March 2016 at 18:11, Jonathan Wakely <gt...@kayari.org> wrote: > On 18 March 2016 at 17:57, jeremy.harmon wrote: >> Hello, >> >> When I try to use std::prev on a ustring const_iterator nothing >> happens, operator-- works fine. >> >> Glib::ust

Re: Shouldn't Glib::ustring::raw() return const char* ?

On 2 August 2016 at 07:03, John Emmas wrote: > I just updated my compiler to VS2015 after using VS2005 for many years. I > built a small test app and linked it to my DLLs (which are still built with > the older compiler). Ultimately, they'll be getting built with the new > compiler and I was

Re: Bug in documentation: Gio::File Class Reference

On 3 August 2016 at 23:38, Alwin Leerling wrote: > I believe I may have found some errors in the reference documentation > of the Gio::File Class: > > Function signatures > > std::string Gio::File::get_basename() const > std::string Gio::File::get_path() const > std::string

Re: gtkmm 4: Glib::ustring: implicit conversions with streams

On 20 December 2016 at 09:26, Kjell Ahlstedt wrote: > > The conversions done by Glib::ustring are reasonable, at least if the read > or written stream uses the global locale. A std::locale contains a codecvt > facet, used for converting between one character encoding in the stream > (file) and a

Re: Supporting C++17

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 and > may appear

Re: Supporting C++17

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

Re: Supporting C++17

On 4 April 2017 at 23:37, Chris Vine wrote: > Aha, this may be it. > http://en.cppreference.com/w/cpp/language/noexcept_spec also says: > "Functions differing only in their exception specification cannot be > overloaded (just like the return type, exception specification is part > of function

Re: Supporting C++17

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

Re: Supporting C++17

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

Re: Supporting C++17

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

Re: enums that are really just sets of constants

On 19 April 2017 at 11:51, Kjell Ahlstedt wrote: > Den 2017-04-19 kl. 12:24, skrev Murray Cumming: > > On Wed, 2017-04-19 at 10:30 +0100, Jonathan Wakely wrote: > > You can also use a namespace to give them their own scope, which has > less overhead than a class type (no RTTI for

Re: enums that are really just sets of constants

On 22 April 2017 at 05:57, Dr. Diether Knof wrote: > Hello, > > for the integer wraps used for flags I have a third proposition, a working > example is attached: > * "enum class DisplayOption" for the individual flags > * "class DisplayOptions" with an implicit converter DisplayOption -> >

Re: enums that are really just sets of constants

On 19 April 2017 at 09:37, Murray Cumming wrote: > In the ABI-breaking versions of glibmm and gtkmm, we have recently > changed the enums to be C++11 "enum class"s. This is generally a > welcome improvement. > - Their values are, for instance, Things::ONE, rather than THINGS_ONE. > - Their values

Re: Why do Glib::ustring::operator[] and at() return values, not references?

On 28 June 2017 at 09:39, Daniel Boles wrote: > But the main drawback I could think of is this: It would change semantics > for anyone currently using auto some_character = non_const_ustring[N], as > the auto would now capture the proxy type, not a gunichar. To get the > latter, the type would

Re: enums that are really just sets of constants

On 23 May 2017 at 15:29, Daniel Boles wrote: > > On 23 May 2017 at 15:12, Kjell Ahlstedt wrote: > >> >> I don't understand how you can have, for instance >> void f(ResponseType r); >> if ResponseType is an uninstantiable class. If ResponseType is

Re: Making use of move semantics?

On 21 May 2017 at 10:36, Daniel Boles wrote: > I still occasionally find myself reflexively std::move()ing strings into > glibmm/gtkmm functions that I unconsciously see as taking ownership of > their arguments - only to realise it makes no difference because all of > them take strings as const&.

Re: enums that are really just sets of constants

On 23 May 2017 at 08:51, Kjell Ahlstedt wrote: > Den 2017-05-13 kl. 10:04, skrev Kjell Ahlstedt: > > Yet another suggestion in https://bugzilla.gnome.org/ > show_bug.cgi?id=86864#c43 > > Can we decide what to do with the few enums that we want to be implicitly >

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

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 >

Re: enums that are really just sets of constants

On 7 May 2017 at 15:10, Kjell Ahlstedt <kjellahlst...@gmail.com> wrote: > Den 2017-05-06 kl. 23:09, skrev Jonathan Wakely: > > On 6 May 2017 at 21:00, Murray Cumming <murr...@murrayc.com> wrote: > > The old style-enum won't let us change this, in gtkmm 3, > > Gtk::

Re: enums that are really just sets of constants

On 6 May 2017 at 21:00, Murray Cumming wrote: > On Sat, 2017-05-06 at 18:08 +0100, Daniel Boles wrote: >> So it seems that the only option is to continue using C-style enums >> within classes, e.g. class Dialog { enum ResponseType{} } as >> present.. As someone already

Re: LInking problems after switch to gcc-6.4.0

On 8 January 2018 at 10:19, Daniel Boles wrote: > I guess it's probably this: > https://stackoverflow.com/a/33395489/2757035 Yup, GCC 5+ has two versions of std::string, to link functions using std::string both the caller and callee need to agree on which version of std::string is used.

Re: get/set wrap methods.

On 23 February 2018 at 14:22, Pavlo Solntsev wrote: > Yes, I did. because my goal is to get > const T& get_name()const > method. I need to return a reference. > > Then you need to change your type to have a using member. You can't have it both ways (return a reference, but not have something to

Re: get/set wrap methods.

On 23 February 2018 at 14:37, Jonathan Wakely wrote: > On 23 February 2018 at 14:22, Pavlo Solntsev wrote: > >> Yes, I did. because my goal is to get >> const T& get_name()const >> method. I need to return a reference. >> >> > Then you need to change

Re: get/set wrap methods.

On 23 February 2018 at 14:55, Pavlo Solntsev wrote: > Daniel, > > now it is clear. I didn't and still don't understand exactly how internal > data members are represented in the generated class (I have no access to my > code now) but the situation I have by returning a reference is clear. BTW >

Re: C++17

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

Re: C++17

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

Re: Additional Glib::RefPtr Safety Mechanism

On Thu, 29 Aug 2019 at 21:27, Karsten Pedersen wrote: > Hi all, > > One area of C++ that always frustrates me is safety. Smart pointers > such as the Glib::RefPtr go a good way to avoid dangling pointers, use > after free, etc. However one area where this (and std::shared_ptr) is > lacking is

Re: Additional Glib::RefPtr Safety Mechanism

On Sat, 31 Aug 2019, 11:55 Karsten Pedersen, wrote: > I have yet to see it in any gtkmm code (you will be pleased to hear) > but my personal opinion is that it is surely a nice idea to attempt > to make C++ 100% safe rather than having to rely purely on the skills of > a developer. This is

Re: Support service

On Mon, 14 Feb 2022, 19:50 David Gasa i Castell via gtkmm-list, < gtkmm-list@gnome.org> wrote: > Dear project team, > > I write you to say that it doesn't work. > This is a useless statement. Nobody can help something so vague, what does "doesn't work" mean? > I've been using Gtkmm libraries

Re: Support service

On Mon, 14 Feb 2022 at 20:17, Martin Owens wrote: > On Mon, 2022-02-14 at 20:08 +0000, Jonathan Wakely via gtkmm-list > wrote: > > People work on them for free, > > No,  people work on them for lots of money; they distribute them for > free. > Well I think it's a bit