On 27.10.2016 22:54, Jaak Ristioja wrote: > Hi! > > While refactoring some option filters code for Sword++ I found two > strange option filters, GreekLexAttribs and PapyriPlain which inherit > from SWOptionFilter and use SWOptionFilter::SWOptionFilter(). This > behavior was introduced in SVN 1864: > > commit bdc81675088ca687338ca29acef6c384710b6bcf > Author: scribe <scribe@bcd7d363-81e1-0310-97ec-a550e20fc99c> > Date: Sun Nov 20 06:06:40 2005 +0000 > > Cleaned up headers to remove unnecessary includes > > git-svn-id: https://crosswire.org/svn/sword/trunk@1864 > bcd7d363-81e1-0310-97ec-a550e20fc99c > > Neither of those classes override any of the SWOptionFilter methods for > options, hence the effects of SWOptionFilter::SWOptionFilter() are > permanent for instances of these classes. This means that > getOptionName() returns "" for both of these classes. This looks as if > it could cause problems for SWMgr which seems to rely on these being > unique strings for each class (e.g. in SWMgr::AddGlobalOptions). So its > rather confusing. > > Some SWMgr methods test whether getOptionName() returns NULL. I couldn't > find any conclusive hints in Sword source code to describe the rationale > of it returning NULL. None of the Sword classes themselves seem to > return NULL themselves. So the only possible way for getOptionName() to > return NULL is for some child class overriding getOptionName() or > overwriting that protected field. Before SVN 1864 these virtual methods > were also part of SWFilter and their defaults returned NULL (well, 0). > Can someone please enlighten me about this code? > > Thanks! > > Many blessings, > Jaak > > PS: Should these two classes actually be simple On/Off-style option > filters and properly call the other SWOptionFilter constructor?
Bump. _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page