New MFBT features: enum underlying type and enum classes
Support just landed for two new C++11 features in MFBT:
https://bugzilla.mozilla.org/show_bug.cgi?id=751554
They're described in this paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf
In brief, this lets you do two new things. One is you can use MOZ_ENUM_TYPE()
to specify the underlying type of an enum, like so:
enum Foo MOZ_ENUM_TYPE(PRUint8) { A, B };
This instructs the compiler to allocate only one byte of storage for Foo, to
save space. Otherwise, the compiler is entitled to allocate anywhere from one
byte to the size of an int, and gcc in practice will allocate four bytes.
Compilers that support this include gcc 4.4 and up, Clang 2.9 and up, and VC++
2005 and up. On other compilers, it will have no effect.
The other is to define enum classes, a.k.a. strongly-typed or scoped
enumerations. This is done as follows:
MOZ_BEGIN_ENUM_CLASS(Foo, PRUint8)
A, B
MOZ_END_ENUM_CLASS(Foo)
This makes Foo one byte, as before (the size argument is mandatory). It has
two further effects. One is that Foo will not be implicitly converted from
*or* to any numeric type, including bool -- normal enums are implicitly
converted to numeric types, although not from. This ensures better
type-safety. The other is that the enumerators (A and B here) will be
scoped with the enum's name rather than being in the global scope, like class
members. Thus A and B no longer refer to anything -- you need to write
Foo::A and Foo::B. Often enums are put in classes to avoid namespace
pollution, but this is no longer necessary with enum classes.
Compilers that support scoped enumerations include gcc 4.4 and up, Clang 2.9
and up, and VC++ 2011 and later. In compilers that don't support the feature
natively, a workaround using a regular enum nested in a class is used. This
will give the same scoping behavior, but not as much type safety.
Using enum classes for all new enums is encouraged, in order to avoid
accidental conversions to other types. It does mean that implicit conversion
to boolean is not allowed, even though sometimes you do want it (if the 0 value
is none). As a partial workaround, you can define an overloaded operator!
for your enum class, so !enumVal and !!enumVal will still work. C++ permits
overloaded operators for enums and enum classes, but unfortunately not implicit
type conversions.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: New MFBT features: enum underlying type and enum classes
On Thursday, August 9, 2012 3:05:56 PM UTC+3, Ted Mielczarek wrote: Did you mean VC++ 2010 or 2012? There's no version called 2011. (VC 2010 is VC 10.0, and VC 2012 is VC 11.0, confusingly.) I meant Visual Studio 11, based on this: http://blogs.msdn.com/b/vcblog/archive/2011/09/12/10209291.aspx. Specifically, it's implemented as #if _MSC_VER = 1700. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: New MFBT features: enum underlying type and enum classes
On 8/9/12 11:29 AM, Aryeh Gregor wrote: The other is to define enum classes, a.k.a. strongly-typed or scoped enumerations. This is done as follows: [...] That sounds great! Perhaps, at some point, we will want to adapt xpidl to take advantage of this. Also, with this new feature, should we consider some static analysis to try and root out untyped enumerations? Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Switching to stdint types on mozilla-central
Hello everybody, We have had a long history of using NSPR types such as PRInt32 everywhere on mozilla-central. This is no longer necessary as we have decent support for stdint types in mozilla/StandardInteger.h. I have a series of patches up for review on bug 579517 which switch us away from NSPR types everywhere on mozilla-central except for NSPR itself and NSS. The full list of things that I am replacing is at the bottom of this email. I am planning to land this patch as soon as possible after it gets reviewed. The landing process will look like this. I will close mozilla-inbound, land on mozilla-central, merge central into inbound and deal with all of the merge conflicts, and then reopen mozilla-inbound. This should not take more that 10-15 minutes, so it probably will not affect you. This will however bitrot most of your patches, so I have put together a script here https://bugzilla.mozilla.org/attachment.cgi?id=650572 which helps you unbitrot them. This script handles mq patches, and needs to be run in the top mozilla-central directory, and it creates a backup of your mq patches in case something goes wrong. Please let me know if you have questions or concerns. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switching to stdint types on mozilla-central
...and I forgot to include the list! PRInt8 - int8_t PRUint8 - uint8_t PRInt16 - int16_t PRUint16 - uint16_t PRInt32 - int32_t PRUint32 - uint32_t PRInt64 - int64_t PRUint64 - uint64_t PRIntn - int32_t PRUintn - uint32_t PRSize - size_t PROffset32 - int32_t PROffset64 - int64_t PRPtrdiff - ptrdiff_t PRFloat64 - double -- Ehsan http://ehsanakhgari.org/ On Thu, Aug 9, 2012 at 11:57 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: Hello everybody, We have had a long history of using NSPR types such as PRInt32 everywhere on mozilla-central. This is no longer necessary as we have decent support for stdint types in mozilla/StandardInteger.h. I have a series of patches up for review on bug 579517 which switch us away from NSPR types everywhere on mozilla-central except for NSPR itself and NSS. The full list of things that I am replacing is at the bottom of this email. I am planning to land this patch as soon as possible after it gets reviewed. The landing process will look like this. I will close mozilla-inbound, land on mozilla-central, merge central into inbound and deal with all of the merge conflicts, and then reopen mozilla-inbound. This should not take more that 10-15 minutes, so it probably will not affect you. This will however bitrot most of your patches, so I have put together a script here https://bugzilla.mozilla.org/attachment.cgi?id=650572 which helps you unbitrot them. This script handles mq patches, and needs to be run in the top mozilla-central directory, and it creates a backup of your mq patches in case something goes wrong. Please let me know if you have questions or concerns. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switching to stdint types on mozilla-central
On Thu, Aug 09, 2012 at 12:26:33PM -0400, Justin Lebar wrote: This will however bitrot most of your patches, so I have put together a script here https://bugzilla.mozilla.org/attachment.cgi?id=650572 which helps you unbitrot them. This script handles mq patches, and needs to be run in the top mozilla-central directory, and it creates a backup of your mq patches in case something goes wrong. I wonder what's the right thing to do for those of us using git (an increasingly large population!). We can export all our branches as patches, run your script, and then re-import the patches, but that's a pain... I feel like maybe what we should do is have a script which git-rebase's a branch to the parent of your change, then automatically exports the branch as patches, runs your script, and re-imports the branch, as a child of your change. Anyone have a better idea? git-filter-branch from and includingthe merge-base to the head of your branch, and rebase. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Increase in mozilla-inbound bustage due to people not using Try
Justin Lebar wrote: In addition, please bear in mind that landing bustage on trunk trees actually makes the Try wait times worse (since the trunk backouts/retriggers take test job priority over Try) - leading to others not bothering to use Try either, and so the situation cascades. I thought tryserver used a different pool of machines isolated from all the other trees, because we treated the tryserver machines as pwned. Is that not or no longer the case? Yes and no, the build machines are completely different the test machines -- not so much. The testers however are shared. Testers have a completely different passwords set, as well as other mitigations. The idea here is that our test machines also have no permissions to upload anyway, nor any way to leak/get sekrets. And all machines are in a restricted network environment overall anyway. So load on inbound affects *test* load on try, yes. -- ~Justin Wood (Callek) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
