Open
Bug 304648
Opened 20 years ago
Updated 3 years ago
Can use nsAString as concrete type
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
NEW
People
(Reporter: Biesinger, Unassigned)
Details
The following code compiles:
nsCAutoString asdf("asdf");
nsACString foo = NS_LITERAL_CSTRING("foo") + asdf;
Should it?
Comment 1•20 years ago
|
||
No. I'm presuming from the nsCAutoString that this is the internal string API?
Reporter | ||
Comment 2•20 years ago
|
||
right. Note that just:
nsACString foo;
does indeed fail to compile.
![]() |
||
Comment 3•20 years ago
|
||
I'd think that the code at http://lxr.mozilla.org/seamonkey/source/xpcom/string/public/nsTAString.h#587 would deal with this (unless you're using one of those compilers, which I doubt)...
Comment 4•20 years ago
|
||
nope. it is this constructor:
http://lxr.mozilla.org/seamonkey/source/xpcom/string/public/nsTAString.h#488
Comment 5•20 years ago
|
||
That constructor is used to support automatic promotion of a nsSubstringTuple, which does not inherit from nsAString, to a nsAString in XPCOM method calls.
There is no real harm in the code in comment #0, right?
Reporter | ||
Comment 6•20 years ago
|
||
probably not... but couldn't that conversion also be implemented using an:
operator nsTAString_CharT();
on the substring tuple?
Comment 7•20 years ago
|
||
> probably not... but couldn't that conversion also be implemented using an:
>
> operator nsTAString_CharT();
>
> on the substring tuple?
I tried that first, but it didn't seem to work out very well. It might be worth playing around with it again, but I seem to recall that either the casting operator wasn't being invoked, or it was resulting in extra data copying. It's been a while. Feel free to experiment!
Updated•12 years ago
|
Priority: -- → P3
Assignee | ||
Updated•5 years ago
|
Component: String → XPCOM
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•