It is most definitely Appel's NetCDF C++ 4 (new) library. The problem was
reproducible on both Linux (RHEL 6) and Mac OS X (latest and greatest).
For now I worked around it by initializing the member variable in the
class's initialization list, but that limits it to a one time only deal.
Which is fine for my purposes, but it's worth noting. The weirdest thing is
that I dug into the source, and I don't see anything wrong with the
assignment operator. It's a pretty simple bit of code.
On Wed, Nov 19, 2014 at 3:57 PM, Russ Rew <russ@xxxxxxxxxxxxxxxx> wrote:
> Hi Jack,
>
> There are two different, non-compatible netCDF C++ releases, and I suspect
> you may be trying to use the new netcdf-cxx4 library on code intended for
> the legacy netcdf-cxx release. You can still get, build, and install the
> legacy release, but it is no longer being maintained or supported. See this
> download site <http://www.unidata.ucar.edu/downloads/netcdf/> for either
> version.
>
> The newer netcdf-cxx4 software, contributed by Lynton Appel, is not
> designed to be backward-compatible, but provides the benefits of a modern
> C++ library with its use of name spaces, exceptions, and templates. The
> legacy API used none of those, and it is impractical to upgrade in a
> backward-compatible way to also provide support for the netCDF-4 enhanced
> data model.
>
> In case you want to upgrade to the netcdf-cxx4 library, the latest version
> <https://github.com/Unidata/netcdf-cxx4> of the source has significant
> bug fixes and other improvements over the current release available from
> the legacy Downloads site referenced above.
>
> --Russ
>
> On Wed, Nov 19, 2014 at 12:17 PM, Jack Stalnaker <jack.stalnaker@xxxxxxxxx
> > wrote:
>
>> I'm sure this has been asked before, but I cannot find it in the
>> archives. I cannot seem to use an NcFile object as a class member. If I do
>> the following (shortened for clarity), I get a NcBadId exception:
>>
>> class Trync
>> {
>> public:
>> Trync()
>> {
>> fooFile = NcFile("foo.nc",NcFile::replace);
>> int a = 1;
>> fooFile.putAtt("bar", ncInt, size_t(1), &a);
>> }
>>
>> NcFile fooFile;
>> };
>>
>> int main()
>> {
>> Trync tnc;
>> return 0;
>> }
>>
>>
>> To be clear, the exception happens even without the putAtt command. It
>> just happens during the destruction of fooFile. I've looked at the
>> definition of operator=() and it does seem to correctly copy myId from its
>> rhs. Does anybody know what's going on, and is there a workaround?
>>
>> Thanks
>>
>> _______________________________________________
>> netcdfgroup mailing list
>> netcdfgroup@xxxxxxxxxxxxxxxx
>> For list information or to unsubscribe, visit:
>> http://www.unidata.ucar.edu/mailing_lists/
>>
>
>
