[vtk-developers] DebugLeaks C++ expert issue?

Elvis Stansvik elvis.stansvik at orexplore.com
Mon Jan 7 15:51:44 EST 2019


Den mån 7 jan. 2019 kl 20:41 skrev David Cole via vtk-developers
<vtk-developers at vtk.org>:
>
> Is it built with the /GF compiler flag?
>
> https://docs.microsoft.com/en-us/cpp/build/reference/gf-eliminate-duplicate-strings?view=vs-2017

(Also note that flag is in effect when /O1 or /O2 is used)

>
>
> On Mon, Jan 7, 2019 at 11:59 AM Ben Boeckel via vtk-developers
> <vtk-developers at vtk.org> wrote:
> >
> > On Mon, Jan 07, 2019 at 11:39:17 -0500, Ken Martin via vtk-developers wrote:
> > > On VS2017 Debug with DEBUG_LEAKS I'm seeing an odd issue. DebugLeaks is
> > > complaining about vtkCommands being leaked because the two string literals
> > > in the below code have different addresses (the string address is used in a
> > > map type structure). Looking at DebugLeaks the only way this code would
> > > work is if they have the same address. But I checked in the debugger and
> > > they have different addresses.
> > >
> > > <snip>
> > >
> > > I can fix it by doing the following but wanted a c++ expert to weigh in,
> > > was the original code OK? Is this a compiler compliance issue? Is the
> > > proposed fix the right approach?
> >
> > I don't think the standard says anything about a string literal with the
> > same content as another literal having to share an address. I'd expect
> > that this is mainly optimization at the compiler or linker level. For
> > example, this:
> >
> >     const char* foo = "foobar";
> >     const char* bar = "bar";
> >
> > can be satisfied with this in the resulting binary:
> >
> >     "foobar\0"
> >      ^  ^
> >      |  bar
> >      foo
> >
> > but I'd expect the standard to say that doing `foo < bar` is always
> > undefined behavior since they're not pointers to the same object.
> >
> > > const char *cname = "vtkCommand or subclass";
> > >
> > > //----------------------------------------------------------------
> > > vtkCommand::vtkCommand():AbortFlag(0),PassiveObserver(0)
> > > {
> > > #ifdef VTK_DEBUG_LEAKS
> > > vtkDebugLeaks::ConstructClass(cname);
> > > #endif
> > > }
> > >
> > > //----------------------------------------------------------------
> > > void vtkCommand::UnRegister()
> > > {
> > > int refcount = this->GetReferenceCount()-1;
> > > this->SetReferenceCount(refcount);
> > > if (refcount <= 0)
> > > {
> > > #ifdef VTK_DEBUG_LEAKS
> > > vtkDebugLeaks::DestructClass(cname);
> > > #endif
> > > delete this;
> > > }
> > > }
> >
> > This looks reasonable to me. Maybe add `static`?
> >
> > --Ben
> > _______________________________________________
> > Powered by www.kitware.com
> >
> > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
> >
> > Search the list archives at: http://markmail.org/search/?q=vtk-developers
> >
> > Follow this link to subscribe/unsubscribe:
> > https://vtk.org/mailman/listinfo/vtk-developers
> >
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Search the list archives at: http://markmail.org/search/?q=vtk-developers
>
> Follow this link to subscribe/unsubscribe:
> https://vtk.org/mailman/listinfo/vtk-developers
>


More information about the vtk-developers mailing list