Add versions of nsDependentString and friends to the Gecko SDK. This is possible with the advent of NS_StringContainerInit2 from bug 264274.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.8beta
Created attachment 166130 [details] [diff] [review] 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 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?
> 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 on attachment 167276 [details] [diff] [review] v1 patch ok, I was confusing nsStringSupport.h and nsStringAPI.h
Attachment #167276 - Flags: review?(bsmedberg) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.