<div dir="ltr"><div dir="ltr">From <a href="https://timsong-cpp.github.io/cppwp/lex.string#15">https://timsong-cpp.github.io/cppwp/lex.string#15</a>:<br></div><div dir="ltr">    <i>whether successive evaluations of a string-literal yield the same or a different object is unspecified  </i><br></div><div dir="ltr"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 7, 2019 at 9:52 PM Elvis Stansvik <<a href="mailto:elvis.stansvik@orexplore.com">elvis.stansvik@orexplore.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Den mån 7 jan. 2019 kl 20:41 skrev David Cole via vtk-developers<br>
<<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>>:<br>
><br>
> Is it built with the /GF compiler flag?<br>
><br>
> <a href="https://docs.microsoft.com/en-us/cpp/build/reference/gf-eliminate-duplicate-strings?view=vs-2017" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/cpp/build/reference/gf-eliminate-duplicate-strings?view=vs-2017</a><br>
<br>
(Also note that flag is in effect when /O1 or /O2 is used)<br>
<br>
><br>
><br>
> On Mon, Jan 7, 2019 at 11:59 AM Ben Boeckel via vtk-developers<br>
> <<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>> wrote:<br>
> ><br>
> > On Mon, Jan 07, 2019 at 11:39:17 -0500, Ken Martin via vtk-developers wrote:<br>
> > > On VS2017 Debug with DEBUG_LEAKS I'm seeing an odd issue. DebugLeaks is<br>
> > > complaining about vtkCommands being leaked because the two string literals<br>
> > > in the below code have different addresses (the string address is used in a<br>
> > > map type structure). Looking at DebugLeaks the only way this code would<br>
> > > work is if they have the same address. But I checked in the debugger and<br>
> > > they have different addresses.<br>
> > ><br>
> > > <snip><br>
> > ><br>
> > > I can fix it by doing the following but wanted a c++ expert to weigh in,<br>
> > > was the original code OK? Is this a compiler compliance issue? Is the<br>
> > > proposed fix the right approach?<br>
> ><br>
> > I don't think the standard says anything about a string literal with the<br>
> > same content as another literal having to share an address. I'd expect<br>
> > that this is mainly optimization at the compiler or linker level. For<br>
> > example, this:<br>
> ><br>
> >     const char* foo = "foobar";<br>
> >     const char* bar = "bar";<br>
> ><br>
> > can be satisfied with this in the resulting binary:<br>
> ><br>
> >     "foobar\0"<br>
> >      ^  ^<br>
> >      |  bar<br>
> >      foo<br>
> ><br>
> > but I'd expect the standard to say that doing `foo < bar` is always<br>
> > undefined behavior since they're not pointers to the same object.<br>
> ><br>
> > > const char *cname = "vtkCommand or subclass";<br>
> > ><br>
> > > //----------------------------------------------------------------<br>
> > > vtkCommand::vtkCommand():AbortFlag(0),PassiveObserver(0)<br>
> > > {<br>
> > > #ifdef VTK_DEBUG_LEAKS<br>
> > > vtkDebugLeaks::ConstructClass(cname);<br>
> > > #endif<br>
> > > }<br>
> > ><br>
> > > //----------------------------------------------------------------<br>
> > > void vtkCommand::UnRegister()<br>
> > > {<br>
> > > int refcount = this->GetReferenceCount()-1;<br>
> > > this->SetReferenceCount(refcount);<br>
> > > if (refcount <= 0)<br>
> > > {<br>
> > > #ifdef VTK_DEBUG_LEAKS<br>
> > > vtkDebugLeaks::DestructClass(cname);<br>
> > > #endif<br>
> > > delete this;<br>
> > > }<br>
> > > }<br>
> ><br>
> > This looks reasonable to me. Maybe add `static`?<br>
> ><br>
> > --Ben<br>
> > _______________________________________________<br>
> > Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
> ><br>
> > Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
> ><br>
> > Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
> ><br>
> > Follow this link to subscribe/unsubscribe:<br>
> > <a href="https://vtk.org/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">https://vtk.org/mailman/listinfo/vtk-developers</a><br>
> ><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="https://vtk.org/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">https://vtk.org/mailman/listinfo/vtk-developers</a><br>
><br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://vtk.org/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">https://vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</blockquote></div>