I just came to realize:
ReentrantMonitorAutoEnter lock1(...);
ReentrantMonitorAutoEnter lock2(...);
{
ReentrantMonitorAutoExit unlock1(...);
// This will not release the monitor.
{
ReentrantMonitorAutoExit unlock2(...);
// This will release the monitor.
}
}
Sometimes it is not cle
Is it always safe and portable to do:
char* p1 = ...;
uint8_t* p2 = reinterpret_cast(p1);
uint8_t u8 = p2[0];
without breaking strict aliasing?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
We have NS_NAMED_LITERAL_CSTRING which seems to be a better and safer
alternative for literal strings. And we should avoid using nsLiteralCString
directly to avoid the pitfall described by James.
___
dev-platform mailing list
dev-platform@lists.mozilla.
For
static constexpr auto& kSomeStrLiteral = "hello world";
NS_LITERAL_CSTRING(kSomeStrLiteral) is not allowed.
However, we can have
auto s1 = nsLiteralCString("hello world");
auto s2 = nsLiteralCString(kSomeStrLiteral);
I wonder why didn't we define NS_LITERAL_CSTRING(s) as
static_cast(nsLiteral
Kan-Ru Chen (陳侃如)於 2016年5月24日星期二 UTC+8下午4時00分12秒寫道：
> I think the current practice is to use already_AddRefed as return
> type and return foo.forget()
>
> Kanru
I think that is the legacy when we don't have move semantics. Returning
RefPtr won't incur ref-counting overhead and is more expressive
For
RefPtr GetFoo() {
RefPtr foo;
// ...
}
should we:
1. return foo and expect RVO to kick in to eliminate additional AddRef/Release
2. return foo.forget()
3. return Move(foo)
Which one is preferred?
ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is also
true for othe
Jim Blandy於 2016年4月28日星期四 UTC+8下午1時51分15秒寫道：
> I don't really think it's a good example. TakeMediaIfKnown is accepting a
> UniquePtr as an inout parameter: it uses, and may modify, its
> value. It should take UniquePtr &.
IIUC, UniquePtr can't be an inout parameter for its unique semantics which
o
https://hg.mozilla.org/mozilla-central/file/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/mfbt/UniquePtr.h#l182
"To unconditionally transfer ownership of a UniquePtr into a method, use a
|UniquePtr| argument. To conditionally transfer ownership of a resource into a
method, should the method want it,
I am tempted to assume |t| will be an empty shell after foo(Move(t)) if I don't
see the prototype foo(T&&).
For |bar(already_AddRefed&&)|, it is also possible for the callsite to say
|bar(r.forget())| without forcing the caller to handle conditional ownership
transfer which won't be caught unti
9 matches
Mail list logo
