[webkit-reviews] review requested: [Bug 23175] String and UString should be able to share a UChar* buffer. : [Attachment 26618] Addressed comments -- Part 2: Refactor UString::Rep into two classes which reduces memory usage for the base Rep class.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun Jan 11 16:51:55 PST 2009


David Levin <levin at chromium.org> has asked  for review:
Bug 23175: String and UString should be able to share a UChar* buffer.
https://bugs.webkit.org/show_bug.cgi?id=23175

Attachment 26618: Addressed comments -- Part 2: Refactor UString::Rep into two
classes which reduces memory usage for the base Rep class.
https://bugs.webkit.org/attachment.cgi?id=26618&action=review

------- Additional Comments from David Levin <levin at chromium.org>

> > +static const unsigned numCharactersToStore = 0x100; // Note that
SmallStrings::m_singleCharacterStrings should be the same size.
>We have COMPILE_ASSERT so that such things can be checked rather than just
mentioned in comments.
Fixed.

> > +}	// namespace JSC
> > +
> > +#endif  // SmallStrings_h
> I suggest only one space before "//" to match the style elsewhere, rather
than two spaces.
Fixed.

> > -		 rep->capacity = newCapacity;
> > +		 rep->baseString()->capacity = newCapacity;

> I would have expected you to use "base" here rather than re-fetching
> rep->baseString(). Is this better in some way?

rep has just been recreated, so the local variable base is no longer valid at
this point.


> > +		 UChar* data() const;
> I'm surprised this can be non-inline without hurting performance slightly.

Still inlined just not defined in the class definition.


> > +		 void setBaseString(PassRefPtr<BaseString> base) { ASSERT(base
!= this); m_baseString = base.releaseRef(); }
> > +		 BaseString* baseString() { return
reinterpret_cast<BaseString*>(baseIsSelf() ? this : m_baseString); }
> > +		 const BaseString* baseString() const { return const_cast<const
BaseString*>(const_cast<Rep*>(this)->baseString());  }

> It's annoying to have these reinterpret_cast here. Instead you should just
> define these inline functions outside the class definition, in a place that
can
> see the definition of BaseString.

Fixed.

> > +		 static BaseString& empty() { return *emptyBaseString; }
> > +	     private:
> > +		 friend void initializeUString();
> I'd prefer a blank line before the private line.

Fixed.

> +    inline UChar* UString::Rep::data() const
> +    {
> +	   const UString::BaseString* base = baseString();
> Do you need the UString:: qualifier on BaseString here?

Fixed.


> > +	     UString::BaseString* base = m_rep->baseString();
>And here?
Fixed.


> > -		 bool baseIsSelf() const { return baseString == this; }
>> +		bool baseIsSelf() const { return
m_identifierTableAndFlags.isFlagSet(BaseStringFlag); }

> Why can't we keep the old definition, but move it down in the file where it
can...

and

> > +		 void* m_baseString; // If "this" is a BaseString instance, it
is 0. BaseString* otherwise.
> Seems really ugly to have this be a void*. Can't it be a BaseString* instead?

> When is the fact that it's a void* helpful?

and

> I'm going to say review- because of the reinterpret_cast question, and the
> question of whether we really do need a bit to tell whether something is a
base
> string.

In the next change, I'll make this point to something else if it is a
BaseString.  This is the reason for the flag and putting 0 in there in the case
of the BaseString and for making a it void* that no code can use directly.

Why re-use this field? In order to not make BaseString any bigger.  (I've been
under the impression that this is desired.)


More information about the webkit-reviews mailing list