New string types: nsAutoStringN<> and nsAutoCStringN<>

[Nicholas Nethercote]

Hi,

For a long time we have had types nsAutoString and nsAutoCString which are
strings with 64 chars of inline storage. They are good for holding short
strings, most often on the stack, because they avoid the need to heap
allocate
a char buffer.

I recently landed patches (bug 1386103) that introduce nsAutoStringN and
nsAutoCStringN. These are like the existing types but their length is a
template parameter. So if you want an nsString with 128 chars of inline
storage, you'd use nsAutoStringN<128>. If you want an nsCString with enough
inline storage to store an nsID you'd use nsAutoCStringN<NSID_LENGTH>.

nsAutoString and nsAutoCString have been redefined as typedefs for
nsAutoStringN<64> and nsAutoCStringN<64>, respectively.

I have updated the MDN docs appropriately:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/
Guide/Internal_strings

Nick

p.s. The "Auto" in these names is confusing. "Auto" in Mozilla code usually
refers to an RAII wrapper type such as AutoPtr or AutoLock. nsInlineString
and
nsInlineCString would be better names for these types... but that's a
change
for another day.

[Ben Kelly]

On Sun, Aug 20, 2017 at 6:35 PM, Nicholas Nethercote <n.neth...@gmail.com
> wrote:

> Hi,
>
> For a long time we have had types nsAutoString and nsAutoCString which are
> strings with 64 chars of inline storage. They are good for holding short
> strings, most often on the stack, because they avoid the need to heap
> allocate
> a char buffer.
>
> I recently landed patches (bug 1386103) that introduce nsAutoStringN and
> nsAutoCStringN. These are like the existing types but their length is a
> template parameter. So if you want an nsString with 128 chars of inline
> storage, you'd use nsAutoStringN<128>. If you want an nsCString with enough
> inline storage to store an nsID you'd use nsAutoCStringN<NSID_LENGTH>.
>
> nsAutoString and nsAutoCString have been redefined as typedefs for
> nsAutoStringN<64> and nsAutoCStringN<64>, respectively.
>

First, let me say this is a great addition. Thanks!

I do have a question, though. My impression was that something like
nsAutoCString stored its data in a null terminated string. So you can do
things like:

nsAutoCString someValue;
printf_stderr("value = %s\n", someValue.get());

Does nAutoCStringN also store its value null-terminated? Is that null
somehow accounted for in the storage? I don't see where that is done:

http://searchfox.org/mozilla-central/source/xpcom/string/nsTString.h#664

Should that be `mStorage[N + 1]`?

Thanks.

Ben

[Ben Kelly]

On Mon, Aug 21, 2017 at 10:00 AM, Ben Kelly <bke...@mozilla.com> wrote:

> Should that be `mStorage[N + 1]`?
>

Maybe not since things like NSID_LENGTH include the null pointer on their
end. Sorry for my confusion.

[Jonathan Kew]

On 20/08/2017 23:35, Nicholas Nethercote wrote:
> Hi,
>
> For a long time we have had types nsAutoString and nsAutoCString which are
> strings with 64 chars of inline storage. They are good for holding short
> strings, most often on the stack, because they avoid the need to heap
> allocate
> a char buffer.
>
> I recently landed patches (bug 1386103) that introduce nsAutoStringN and
> nsAutoCStringN. These are like the existing types but their length is a
> template parameter. So if you want an nsString with 128 chars of inline
> storage, you'd use nsAutoStringN<128>. If you want an nsCString with enough
> inline storage to store an nsID you'd use nsAutoCStringN<NSID_LENGTH>.

Nice!

Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix,
and perhaps put Auto[C]String into the mozilla namespace?

> nsAutoString and nsAutoCString have been redefined as typedefs for
> nsAutoStringN<64> and nsAutoCStringN<64>, respectively.
>

> I have updated the MDN docs appropriately:
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/
> Guide/Internal_strings
>
> Nick
>
> p.s. The "Auto" in these names is confusing. "Auto" in Mozilla code usually
> refers to an RAII wrapper type such as AutoPtr or AutoLock. nsInlineString
> and
> nsInlineCString would be better names for these types... but that's a
> change
> for another day.

There's also AutoTArray, though, which uses "Auto" in the same sense as
nsAutoString...

JK

[Eric Rahm]

On Mon, Aug 21, 2017 at 8:32 AM, Jonathan Kew <jfkt...@gmail.com> wrote:

>
> Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix,
> and perhaps put Auto[C]String into the mozilla namespace?
>
>

As Nick said, renaming all the things is a job for another day :)

Coincidentally I have some pending changes that affect the internal naming
of all of our strings. Externally (outside of xpcom/string) there will be
no discernible change but I *could* move everything to the mozilla
namespace and drop the 'ns' prefix. We could then gradually migrate to the
new naming scheme externally. I think we'd eventually want to move the
include path to 'mozilla/String.h' as well if we went this route, in the
interim we could just have stubs that redirect to the mozilla path.

I'm not sure how much backing that has -- we'd be going from nsString =>
String which is pretty close to std::string -- it would be interesting to
get some feedback.

-e

[Chris Peterson]

On 2017-08-21 5:31 PM, Eric Rahm wrote:
> I'm not sure how much backing that has -- we'd be going from nsString =>
> String which is pretty close to std::string -- it would be interesting to
> get some feedback.

Or follow Rust's precedent and use type name `Str`. That would avoid
confusion with std::string or #include "string.h" on case-insensitive
file systems.

[Kris Maglione]

On Mon, Aug 21, 2017 at 05:31:14PM -0700, Eric Rahm wrote:
>I'm not sure how much backing that has -- we'd be going from nsString =>
>String which is pretty close to std::string -- it would be interesting to
>get some feedback.

It's already a pretty common practice to have MFBT identifiers with
the same names, aside from capitalization, as std classes with
the same purpose(Vector, Move, Forward, DeclVal, ...), so that
doesn't seem to be a major concern.

[Nicholas Nethercote]

I really wish our top-level namespace was "moz", rather than "mozilla".

Nick

On Tue, Aug 22, 2017 at 10:31 AM, Eric Rahm <er...@mozilla.com> wrote:

> On Mon, Aug 21, 2017 at 8:32 AM, Jonathan Kew <jfkt...@gmail.com> wrote:
>
> >
> > Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix,
> > and perhaps put Auto[C]String into the mozilla namespace?
> >
> >
> As Nick said, renaming all the things is a job for another day :)
>
> Coincidentally I have some pending changes that affect the internal naming
> of all of our strings. Externally (outside of xpcom/string) there will be
> no discernible change but I *could* move everything to the mozilla
> namespace and drop the 'ns' prefix. We could then gradually migrate to the
> new naming scheme externally. I think we'd eventually want to move the
> include path to 'mozilla/String.h' as well if we went this route, in the
> interim we could just have stubs that redirect to the mozilla path.
>

> I'm not sure how much backing that has -- we'd be going from nsString =>
> String which is pretty close to std::string -- it would be interesting to
> get some feedback.
>

> -e
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Mike Hommey]

On Tue, Aug 22, 2017 at 04:38:04PM +1000, Nicholas Nethercote wrote:
> I really wish our top-level namespace was "moz", rather than "mozilla".

It's never too late to change it. I, for one, vote +1.

Mike

[Nicholas Alexander]

Hi Nicholas,

On Mon, Aug 21, 2017 at 11:38 PM, Nicholas Nethercote <
n.neth...@gmail.com> wrote:

> I really wish our top-level namespace was "moz", rather than "mozilla".
>

Can you say why? Is it "just" shorter? Is it more pleasant to s/std/moz/
and vice versa?

Nick

[Nicholas Nethercote]

On Wed, Aug 23, 2017 at 2:50 AM, Nicholas Alexander <nalex...@mozilla.com>

wrote:
>
>> I really wish our top-level namespace was "moz", rather than "mozilla".
>
> Can you say why? Is it "just" shorter? Is it more pleasant to
s/std/moz/ and vice versa?

Mostly because it's shorter. It's good for common names to be short. And
the use of "moz" has plenty of precedent, e.g. the MOZ_ prefix is common in
macros.

Nick