<72251B925CE10A478606EEAC6AA683BE0DA20C22B0@xxxxxxxxxxxxxxxxxxxxxxx>
Accept-Language: nb-NO, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: nb-NO, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Loop: netcdfgroup@xxxxxxxxxxxxxxxx
=20
Hello list,
(Sorry for double-posting, this is the same as former email but in plain te=
xt).
=20
NetCDF 4.0.1 Windows; pre-built netcdf.dll dated 29.09.08, C++ interface co=
mpiled into separate application. Microsoft Visual Studio 2005 SP 1.
=20
I am wondering if there is a memory leak in the function (or macro) NcVar::=
as_double(), as defined in netcdf.cpp line 548.
=20
I am terribly unfamiliar with macros and code blocks wrapped in #defines, a=
nd have a hard time understanding what happens.
=20
Inside an NcFile object, my code does:
=20
dt.m_dt =3D get_var(pTd->name())->as_double(pTd->size()-1);
// dt is a COleDateTime, dt.m_dt is a double
// pTd is a NcDim*
=20
to get the last value of the coordinate variable associated with pTd.=20
When executing the offending line, the applications memory usage increases =
24 KB. A get_space() function called from the macro seems to allocate space=
according to the total size of the variable.The size of pTd is approx. 270=
0, and with 8 byte double, 24 kB makes sense.=20
I do see the "delete tmp;" in netcdf.cpp line 538, but my compiler refuse t=
o trace into this macro and I'm unable to determine why the memory is not f=
reed.
=20
Is this a memory leak, or am I being fooled by the Windows Task Manager's m=
emory usage state?
=20
Best regards,
=20
Sjur K :-)
=20
