[PUSHED] Re: [PATCH] more work in SW module to convert SV_DECL_PTRARR

[Michael Stahl]

On 14/05/12 15:15, Noel Grandin wrote:
> Hi
> 
> These patches are more work in the SW module to convert SV_DECL_PTRARR 
> to std::vector or boost::ptr_vector

thanks again, pushed to master.

> These patches were compiled with debug=true, so I'm pretty sure I 
> converted all of the debug stuff as well.

much better, though there was still a DBGUTIL-only place left...

> And it passes "make check" at the global level.

i wondered about the copy constructor that you removed in patch #1,
which was pretty horrible (i mean the copy ctor, not your removal), and
worried that it may be automatically generated, but apparently it is
not, i get a compiler error when trying to invoke it.

also i tried to derive the class from boost::noncopyable, but ran into
surprising problems, namely that its base class SwClient is already
derived from boost::noncopyable, so GCC said:

direct base ‘boost::noncopyable_::noncopyable’ inaccessible in
‘SwAuthorityFieldType’ due to ambiguity

it is very surprising that it was possible to write a copy constructor
for this class before, investigation revealed that it did not invoke the
SwClient copy constructor, but another SwClient constructor (indirectly)...

more seriously is this in patch #5. tautofmt.cxx:

>                     SwTableAutoFmt* p = &(*pTableTbl)[ nIndex ];
>                     pTableTbl->erase( pTableTbl->begin() + nIndex );
> 
>                     p->SetName( aFormatName );

the boost::ptr_vector::erase deletes the element, so p is invalid.  have
tried to fix this with the boost::ptr_vector::transfer method.

also, patch #6 introduced a memory leak, because the SwTableLines member
needs to be explicitly cleaned up in the destructor now it is a std::vector.