On 10 Feb 2011, at 22:13, David Nečas wrote:
>
> And others, Gtk+ devs probably including, consider this a useful
> optimisation – and in many cases a necessity. You still do not seem to
> accept even the existence of this point of view.
>
I would say quite the reverse. Every single person h
On 11/02/11 09:13, David Nečas wrote:
While I agree having a clean-up function could be useful in some cases
(dynamical modules with GUI) this ‘widespread expectation in C++’ stuff
is just rubbish.
Yeti
___
gtk-app-devel-list mailing list
gtk-app-dev
On Thu, 2011-02-10 at 10:50 +0200, Costin Chirvasuta wrote:
> > Because malloc() implementations generally kept a linear linked list of
> > free space, and traversed the list on a free() in case they found
> > adjacent memory areas to the one you were freeing, which they could join
> > together and
On Thu, Feb 10, 2011 at 07:28:40PM +, John Emmas wrote:
> To me, the debate has become something very simple when a program
> needs to allocate a block of memory only once, does the programmer
> necessarily have to release it programmatically or can he defer it to
> the OS? Remember we ar
GTK+ 3.0.0 is now available for download at:
http://download.gnome.org/sources/gtk+/3.0/
ftp://ftp.gtk.org/pub/gtk/3.0/
sha256 sums:
ec0729bf28f09a16e0b0a6a588556c7cee091f40426505b3694a9488bf6cbf67 gtk
+-3.0.0.tar.bz2
d294155389c9ba4765c0b26805967f2dae1d84565f5d4095d489f94619406df9 gtk
+-3.0.
On 10 Feb 2011, at 17:48, Michael Torrie wrote:
>
> I guess we're at an impasse then. The discussion has now moved from the
> definition of "leak" to some personal idea of what "beauty" is.
In which case, maybe we should agree to use the word "leak" for the simple
purpose of identifying the
On 02/10/2011 12:19 AM, Costin Chirvasuta wrote:
> I find not cleaning up explicitly quite ugly. I shudder at the thought
> and maybe I'm not the only one. Not only that, but cleaning up
> explicitly is obviously useful for some people.
I guess we're at an impasse then. The discussion has now mov
Hi all,
I'm always working on a treeview that display a "sorted filtered" :
the model displayed is a GtkTreeModelSort whose child is a
GtkTreeModelFilter whose child is a GtkListStore.
Sometime when the model is actually sort and filtered I have on
selection 2 Gtk-Critical on gtk_tree_model_sort_r
> To describe the standard mechanism of garbage collection as a boneheaded
> idea shows a total lack of awareness of first year Computer Science course
> principles. That garbage collection has been refined and highly optimised
> over the years is true; however it is a very necessary thing with m
On 10 Feb 2011, at 11:36, Freddie Unpenstein wrote:
> I really don't want to have to sit around for an extra 10-20 seconds while a
> closing application crawls along pulling data from swap space for no
> particularly good reason, when the OS could have simply marked those pages as
> available
On 10/02/11 19:50, Costin Chirvasuta wrote:
I'm sorry, I now understand what you mean. If what you say is true
(which I don't doubt) it's a really boneheaded mechanism in my
opinion. Defragmenting memory in realtime is a performance nightmare.
But that's irrelevant. Your point is well taken.
T
The basic idea that one must understand about programming is that of
paradigms and concepts. They are really stressed for C++ and higher
level stuff (scripting languages notwithstanding ofcourse). But if
you're gonna use C you're gonna write paradigms and concepts that
you'll really have to be ensu
From: "Carlos Pereira" [jose.carlos.pere...@ist.utl.pt], Date: 10/02/2011 09:10:
>> something), but aside from that it's a pure waste of CPU cycles.
> I am sorry, I totally disagree.
> I can only see two cases. Either fixing these hundreds and hundreds of
> mem leaks is easy or difficult.
> In the
Hi All
On 10/02/11 18:26, John Emmas wrote:
On 9 Feb 2011, at 17:01, James Morris wrote:
Not only do we have to write our own code, we have to put work into
making other peoples code ignore the errors in other peoples code so
we can see the errors in our own code. It's a bloody outrage!
I'v
> Because malloc() implementations generally kept a linear linked list of
> free space, and traversed the list on a free() in case they found
> adjacent memory areas to the one you were freeing, which they could join
> together and make into a single larger area.
I'm sorry, I now understand what y
15 matches
Mail list logo
