Re: Support service

2022-02-14 Thread Jonathan Wakely via gtkmm-list
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

Re: Support service

2022-02-14 Thread Jonathan Wakely via gtkmm-list
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 si

Re: Additional Glib::RefPtr Safety Mechanism

2019-09-01 Thread Jonathan Wakely via gtkmm-list
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 genera

Re: Additional Glib::RefPtr Safety Mechanism

2019-08-30 Thread Jonathan Wakely via gtkmm-list
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 tha