On 12-07-25 1:45 PM, Dave Mandelin wrote:
On Wednesday, July 25, 2012 7:45:43 AM UTC-7, Bobby Holley wrote:
On Wed, Jul 25, 2012 at 4:21 PM, Aryeh Gregor wrote:
> On Wednesday, July 25, 2012 3:04:31 PM UTC+3, Justin Lebar wrote:
> > > The next step is to s/nsnull/nullptr/ in the codebase, and
get rid
> of nsnull.
> >
> > Forgive my ignorance, but how does this affect NULL? Would that be
> > deprecated in favor of nullptr as well? Should we use nsnull instead
> > of NULL in new code, in anticipation of the nsnull --> nullptr
switch?
>
> That would be a logical next step, for sure. I'd definitely say
nullptr
> should be used instead of NULL where possible, because the extra type
> safety is valuable. I guess it would make sense to try mass-changing NULL
> to nullptr,
What about the JS engine (which uses NULL), and code that uses js-engine
style, such as (parts of) XPConnect? I imagine that the embedding situation
makes things more complicated there than a simple find/replace.
SpiderMonkey officially has a C++ API now, so nullptr should be OK. There is at
least one wrinkle, which is that we need to support jsd for a while yet, which
is C. There are a few |NULL|s in jsapi.h that look like they are exposed to C,
so just a mass-replace wouldn't work, but there are a couple of ways to get jsd
to work and I don't think there's anything too complicated.
Then maybe we can do something like:
#ifndef __cplusplus
#define nullptr NULL
#endif
And use nullptr everywhere else in jsd.h?
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
