Hi, Tim<br><br>Thanks for fixing the leak. I spent sometime to look at the kinds of mem leaks Flopc++ has, and it seems that not all leaks are caused by MP_domain.hpp. Many can be traced to pointers returned by a method call, and the caller never deletes these pointers afterward. For instance, in &quot;mp_model.cpp&quot;, call getDefaultModel() returns a pointer to MP_model(0), but it is never deleted.  
<br>-------------------------<br>MP_model&amp; MP_model::default_model = *new MP_model(0);<br>MP_model* MP_model::current_model = &amp;MP_model::default_model;<br>MP_model &amp;MP_model::getDefaultModel() { return default_model;}
<br>MP_model *MP_model::getCurrentModel() { return current_model;}<br>-----------------------<br><br>Similar patterns can be found in other places. In &quot;mp_constant.cpp&quot;,<br>---------------------------<br>&nbsp;Constant::Constant(double d) :
<br>&nbsp;&nbsp;&nbsp; Handle&lt;Constant_base*&gt;(new Constant_double(d)) {}<br>--------------------------<br>Constant(d) returns a pointer to Constant_double(d), and it is never deleted by its caller. <br><br>I guess it may require a major overhaul to fix all these leaks as there are many methods return pointers to some newed classes.
<br><br>Cheers<br>Paul<br><br><br><br><br><br><br><div><span class="gmail_quote">On 5/20/07, <b class="gmail_sendername">Tim Hultberg</b> &lt;<a href="mailto:Tim.Hultberg@eumetsat.int">Tim.Hultberg@eumetsat.int</a>&gt; wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi, Paul<br><br>yes this one is just as easy as you say. I have fixed it now in<br>stable/1.0.
<br><br>[if you find more easy ones, let me know :-)]<br><br>The remaining leaks (I am aware of) comes from some limitations in the<br>current implementation of MP_domain. I have a leak free implementation<br>of it in branches/experiment/experiment/New_domain.hpp but I have never
<br>had the time to integrate it properly.<br><br>Cheers, Tim<br><br>Tim Hultberg<br><br>&gt;&gt;&gt; &quot;Paul Huang&quot; &lt;<a href="mailto:huangpaul99@gmail.com">huangpaul99@gmail.com</a>&gt; 05/18/07 9:33 PM &gt;&gt;&gt;
<br>Hi, Tim<br><br>I understand you know FlopC++ has quite a few memory leaks.&nbsp;&nbsp;Some are<br>minor<br>but some are significant. After checking the source code, I assume,<br>based on<br>my limited understanding, some leaks are easy to fix. For example, in
<br>mp_model.cpp, a pointer c is newed and passed to &quot;Solver-&gt;loadProblem&quot;<br>but<br>never released. Here is the code<br><br>---------------------------------------------------<br>c =&nbsp;&nbsp;new double[n];<br>&nbsp;&nbsp;for (int j=0; j&lt;n; j++) {
<br>&nbsp;&nbsp;&nbsp;&nbsp;c[j] = 0.0;<br>&nbsp;&nbsp;}<br>&nbsp;&nbsp;for (size_t i=0; i&lt;coefs.size(); i++) {<br>&nbsp;&nbsp;&nbsp;&nbsp;int col = coefs[i].col;<br>&nbsp;&nbsp;&nbsp;&nbsp;double elm = coefs[i].val;<br>&nbsp;&nbsp;&nbsp;&nbsp;c[col] = elm;<br>&nbsp;&nbsp;}<br><br>&nbsp;&nbsp;// Column bounds<br>&nbsp;&nbsp;for (int j=0; j&lt;n; j++) {
<br>&nbsp;&nbsp;&nbsp;&nbsp;l[j] = 0.0;<br>&nbsp;&nbsp;&nbsp;&nbsp;u[j] = inf;<br>&nbsp;&nbsp;}<br><br>&nbsp;&nbsp;for (varIt i=Variables.begin(); i!=Variables.end(); i++) {<br>&nbsp;&nbsp;&nbsp;&nbsp;for (int k=0; k&lt;(*i)-&gt;size(); k++) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;l[(*i)-&gt;offset+k] = (*i)-&gt;lowerLimit.v[k];
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;u[(*i)-&gt;offset+k] = (*i)-&gt;upperLimit.v[k];<br>&nbsp;&nbsp;&nbsp;&nbsp;}<br>&nbsp;&nbsp;}<br><br>&nbsp;&nbsp;Solver-&gt;loadProblem(n, m, Cst, Rnr, Elm, l, u, c, bl, bu);<br>-----------------------------------------------<br><br>My question is,&nbsp;&nbsp;is it just as easy as add &quot;delete [] c&quot; after calling
<br>&quot;Solver-&gt;loadProblem&quot; and then the problem will be fixed, or it is not<br>as<br>easy as it looks and more complication is involved? If the former is<br>true,<br>then my second question is, when are you going to fix those easy-to-fix
<br>leaks? :-)<br><br><br>Cheers<br>Paul<br><br></blockquote></div><br>