It knows its size() and capacity(), right?


----- Original Message -----
From: John Peterson <jwpeterson@gmail.com>
To: Kirk, Benjamin (JSC-EG)
Cc: libmesh-devel@lists.sourceforge.net <libmesh-devel@lists.sourceforge.net>
Sent: Mon Aug 11 16:52:31 2008
Subject: Re: [Libmesh-devel] Memory Leak in DofObject?

On Mon, Aug 11, 2008 at 4:09 PM, Benjamin Kirk <benjamin.kirk@nasa.gov> wrote:
>
>> I think I may have found the leak...
>>
>> Check out clear_dofs() in dof_object.h
>>
>> [snipped...]
>
> Just independently came to the same conclusion...  Nice work.
> I am checking (_dof_ids[s] != NULL) for the general case. BTW, that fixes
> it.

OK, great.  No memory leaks detected in ex10 anymore either.  Valgrind
is a pretty nice tool.  Are we finally ready to tag 0.6.3 now?!

>> In a more general sense, are we still worried enough about the
>> overhead of std::vector to warrant all this dynamic memory allocation
>> business?  I'd like to see some profiling that shows the additional
>> overhead of std::vector, but on the other hand, I'd rather not rewrite
>> DofObject first :)
>
> Given that it would be two vectors of vectors, I think the overhead is still
> too high.  That and I don't want to rewrite it either!

Fair enough, since every subvector also knows its length, I guess that
could be a bit much.  Is that the only overhead we are talking about,
though?  I wonder if compilers/memory allocators these days are smart
enough to hide such things in the struct padding...

--
John