Re: Debug build compile error in 'gobject/gobject.c'

Hi; On 3 August 2016 at 19:35, John Emmas wrote: > On 03/08/2016 18:46, Emmanuele Bassi wrote: >> >> This is likely a MSVC 8 issue. The GOBJECT_IF_DEBUG macro expands the >> second argument to a code block, and it seems MSVC 8 has issues when >> that includes a conditional

Re: Debug build compile error in 'gobject/gobject.c'

On 08/ 3/16 11:35 AM, John Emmas wrote: On 03/08/2016 18:46, Emmanuele Bassi wrote: This is likely a MSVC 8 issue. The GOBJECT_IF_DEBUG macro expands the second argument to a code block, and it seems MSVC 8 has issues when that includes a conditional pre-processor directive. GOBJECT_IF_DEBUG

Re: Debug build compile error in 'gobject/gobject.c'

The confusion is arising from the fact that the working code is in 2.48 https://github.com/GNOME/glib/blob/glib-2-48/gobject/gobject.c#L398-L406 The non-working code is in master. On Wed, Aug 3, 2016 at 11:35 AM, John Emmas wrote: > On 03/08/2016 18:46, Emmanuele Bassi

Re: Debug build compile error in 'gobject/gobject.c'

On 03/08/2016 18:46, Emmanuele Bassi wrote: This is likely a MSVC 8 issue. The GOBJECT_IF_DEBUG macro expands the second argument to a code block, and it seems MSVC 8 has issues when that includes a conditional pre-processor directive. GOBJECT_IF_DEBUG hasn't changed since 2014, and the same

Re: Debug build compile error in 'gobject/gobject.c'

I don't believe you're allowed to legally use macros inside a macro expansion - https://stackoverflow.com/questions/19111383/ifdef-inside-a-macro-call-works-with-gcc-but-not-with-msvc On Wed, Aug 3, 2016 at 10:46 AM, Emmanuele Bassi wrote: > Hi; > > On 3 August 2016 at 18:36,

Re: Debug build compile error in 'gobject/gobject.c'

Hi; On 3 August 2016 at 18:36, John Emmas wrote: > Hi there - I just came across a problem after updating libglib to the latest > git master (my last update was about a fortnight ago). > > I'm building with MSVC 8 and when I try to compile 'gobject/gobject.c' the > Release

Debug build compile error in 'gobject/gobject.c'

Hi there - I just came across a problem after updating libglib to the latest git master (my last update was about a fortnight ago). I'm building with MSVC 8 and when I try to compile 'gobject/gobject.c' the Release version compiles fine but compiling in Debug mode gives me an error around

Re: Trouble With Gtk(Dialog) Memory Management

Hi Emanuelle, Thanks for the info about the slice allocator, I think that'll be good for my purposes. As for valgrind and the suppression files, I tried a few, it's too bad that it's hard to differentiate between actual memory leaks and the ones that valgrind shows as leaks... Do you have any

Re: Trouble With Gtk(Dialog) Memory Management

Hi; On 3 August 2016 at 15:37, Jonas wrote: > Hello Emmanuele, > > I reran my code, looked a bit at the archives (especially your answer > to a question about a potential memory leak of gtk_widget_destroy() >

Re: Trouble With Gtk(Dialog) Memory Management

Hello Emmanuele, I reran my code, looked a bit at the archives (especially your answer to a question about a potential memory leak of gtk_widget_destroy() https://mail.gnome.org/archives/gtk-list/2008-September/msg00108.html) and here's where I am now: - not only the test program for the dialog

Re: Trouble With Gtk(Dialog) Memory Management

Hi; you should probably search the archives of this very mailing list, as this question has been asked countless times. The tl;dr is: * GObject uses a slab allocator, not the system one * top is not a memory profiling tool * if you keep things running in a tight loop you don't give GTK any

Trouble With Gtk(Dialog) Memory Management

Hello everyone, I have a question about a memory leak I seem to have with GtkDialog. I already posted this on DreaminCode (username Progammer) and decided to ask the same question on the mailing lists here. Here it is: "[...]I looked at the Gtk and GObject Documentation and figured out the