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

Julien Finet julien.finet at kitware.com
Tue Jan 8 03:24:43 EST 2019


>From https://timsong-cpp.github.io/cppwp/lex.string#15:
    *whether successive evaluations of a string-literal yield the same or a
different object is unspecified  *


On Mon, Jan 7, 2019 at 9:52 PM Elvis Stansvik <elvis.stansvik at orexplore.com>
wrote:

> 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
> >
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://vtk.org/pipermail/vtk-developers/attachments/20190108/8ba73b36/attachment.html>


More information about the vtk-developers mailing list