270110 - Add versions of nsDependentString and friends to the Gecko SDK

Status: RESOLVED FIXED

(Core :: XPCOM, enhancement)

Description

[Darin Fisher]

Add versions of nsDependentString and friends to the Gecko SDK.

This is possible with the advent of NS_StringContainerInit2 from bug 264274.

Comment 1

[Darin Fisher]

Attachment: v0 preliminary patch

This is just a preliminary patch.  At the minimum, I think it is important to
use some preprocessor magic to rename classnames either internally or
externally so that there are not symbol conflicts at runtime.

Comment 2

[Darin Fisher]

Attachment: v1 patch

Comment 3

[Benjamin Smedberg]

Comment on attachment 167276 [details] [diff] [review]
v1 patch

I'm confused. How did you solve the "conflicting nsAString symbols" problem? It
seems that you're mixing the frozen and non-frozen string impls; am I wrong
about that?

Comment 4

[Darin Fisher]

> I'm confused. How did you solve the "conflicting nsAString symbols" problem?

I didn't change nsAString.  We still have the problem of the internal nsAString
being named the same as the external one.  That needs to be solved by
introducing a #define for nsAString, either internally or externally.  That
isn't a prerequisite for this patch.


> It seems that you're mixing the frozen and non-frozen string impls; am I 
> wrong about that?

I am not mixing the two.  Instead, I am making available many of the string
classes, like nsDependentString and nsDependentSubstring, but I am expressing
them in terms of the frozen string library.  This does not eliminate the
internal string classes; it only provides similar idioms for those writing code
on top of the Gecko SDK.  Take note of the #ifdef MOZILLA_STRICT_API :-)

Comment 5

[Benjamin Smedberg]

Comment on attachment 167276 [details] [diff] [review]
v1 patch

ok, I was confusing nsStringSupport.h and nsStringAPI.h

Comment 6

[Darin Fisher]

fixed-on-trunk