If you're using GSlice on a dynamically-sized array, you are using GSlice
wrong. This is not what GSlice was designed for and you will cause
fragmentation.
The case for munmap is better, but again, I'd just store the overall size
of the region, rather than calculating it again.
On Tue, Dec 18, 2
On Tue, Dec 18, 2012 at 05:37:08PM -0500, Jasper St. Pierre wrote:
> The call for freeing a block of memory is free(void *data);
And the call for freeing a GSlice-allocated block of memory is
void g_slice_free1(gsize block_size, gpointer mem_block);
And the call for freeing a memory-mapped r
I don't understand why freeing an array requires knowing the size of it.
The call for freeing a block of memory is free(void *data);, without any
size in there. The libc keeps track of the size of each block in its
allocator.
On Tue, Dec 18, 2012 at 1:58 PM, Günther Wutz wrote:
> I can live wit
I can live with that. I thought it should be possible, because its a
normal thing in an object oriented fashion. I looked at the generated
output from Vala, but they does not use multidimensional arrays, they
make the calculation themself and use a one-dimensional array. Then
freeing is simple :)
Hello,
I have been trying to change the fonts used by eclipse which I believe are
borrowed from my ubuntu system. Using `gtk-chtheme` I was able to change
the default font and some of the fields in eclipse have changed as well
while others remained the same. In gtk3, there are different font setti
On 2012-12-18 19:30, Henrique Camargo wrote:
I've submitted the bug report. Sorry for the delay. The URL for the
bug is https://bugzilla.gnome.org/show_bug.cgi?id=690452
I wanted to provide a patch, but looking at the stylesheets that are
included in the documentation page, I came to the conclu
On Wed, Nov 28, 2012 at 12:52 PM, David King wrote:
> It is possible to view the GTK+ documentation with the same CSS (which is
> the default gtk-doc style, I think) by installing the relevant documentation
> package locally and then either using Devhelp (a really useful tool, by the
> way) or ope
On Tue, Dec 18, 2012 at 08:45:42PM +0100, Nicola Fontana wrote:
> I always wondered if this double step finalization is hystorical
> craft. Why not drop finalize() altogether and avoid double dispose
> calls directly from libgobject?
The purpose of dispose() is to break reference cycles, i.e. to e
Il Tue, 18 Dec 2012 19:46:40 +0100 David Nečas scrisse:
> On Tue, Dec 18, 2012 at 07:19:33PM +0100, Nicola Fontana wrote:
> > I always free dynamic stuff (included allocated memory) in
> > dispose(), not in finalize(), protecting it from double calls.
> > There you should have a still valid insta
On Tue, Dec 18, 2012 at 07:19:33PM +0100, Nicola Fontana wrote:
> I always free dynamic stuff (included allocated memory) in
> dispose(), not in finalize(), protecting it from double calls.
> There you should have a still valid instance to query.
GObject gives the following, somewhat contradictory
Il Tue, 18 Dec 2012 04:57:52 +0100 Günther Wutz scrisse:
> I have an Class A, which stores two Integer as properties (say x and y)
> and an Class B which inherits from A and makes a multidimensional array
> on the heap with size x*y. In my finalize method i want to free the
> dynamically allocate
The issue is that the class has already been finalized. At that point, you
are no longer allowed to access any properties.
I suppose you could also try and access raw storage from class A, but
storing any data you'll need to free something in class B when you allocate
it seems like the cleanest so
Use g_object_get(CAST_TO_PARENT_TYPE(obj), "x", &x, NULL);
On Tue, Dec 18, 2012 at 4:57 AM, Günther Wutz wrote:
> Hi,
>
> i have read the development stuff about GObject initialization and
> destruction of an Object. But i have currently a problem, which drives
> me crazy.
>
> I have an Class A,
13 matches
Mail list logo
