Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-22 Thread Nicholas Nethercote
On Wed, Aug 23, 2017 at 2:50 AM, Nicholas Alexander 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 shor

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-22 Thread Nicholas Alexander
Hi Nicholas, On Mon, Aug 21, 2017 at 11:38 PM, Nicholas Nethercote < n.netherc...@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 > > Nick > > On Tue,

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-21 Thread 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 ___ dev-platform mailing list dev-platform@lists.m

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-21 Thread 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 wrote: > On Mon, Aug 21, 2017 at 8:32 AM, Jonathan Kew wrote: > > > > > Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix, > > and perhaps put Auto[C]S

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-21 Thread 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 t

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-21 Thread 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:

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-21 Thread Eric Rahm
On Mon, Aug 21, 2017 at 8:32 AM, Jonathan Kew 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 c

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-21 Thread 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

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-21 Thread Ben Kelly
On Mon, Aug 21, 2017 at 10:00 AM, Ben Kelly 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. ___ dev-platform mailing list dev-platform@lists.mozilla.or

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-21 Thread Ben Kelly
On Sun, Aug 20, 2017 at 6:35 PM, 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 > all

New string types: nsAutoStringN<> and nsAutoCStringN<>

2017-08-20 Thread 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 introd