On Tuesday, April 26, 2016 at 3:39:53 AM UTC+10, Botond Ballo wrote:
> That's why we have explicit operator bool() in C++11. That only allows
Indeed. explicit operator was implied.
Here is an example of definition:
https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaData.h#201
I used to be the module owner of our coding conventions, but I believe that
duty has now fallen on Nathan Froyd with the establishment of the new
module covering c++ idioms and usage, noted in this governance thread:
https://groups.google.com/forum/#!searchin/mozilla.governance/froyd/mozilla.govern
On Mon, Apr 25, 2016 at 1:06 PM, Jim Blandy wrote:
> On Mon, Apr 25, 2016 at 4:03 AM, Jean-Yves Avenard
> wrote:
>
>> I don't know how popular this method would be, nor if people would be
>> shocked by providing a operator bool() but here it is :)
>>
>>
> Usually, the people most shocked by provi
On Mon, Apr 25, 2016 at 4:03 AM, Jean-Yves Avenard
wrote:
> I don't know how popular this method would be, nor if people would be
> shocked by providing a operator bool() but here it is :)
>
>
Usually, the people most shocked by providing an operator bool() are those
who find the type silently pa
On Thursday, April 21, 2016 at 11:15:10 AM UTC+10, Nicholas Nethercote wrote:
> The only disadvantage I can see is that it looks a bit strange at first. But
> if
> we started using it that objection would quickly go away.
>
> I have some example patches that show what this code pattern looks like
I agree with this.
FWIW, the Google style guide requires that reference params be const.
https://google.github.io/styleguide/cppguide.html#Reference_Arguments
-Ekr
On Thu, Apr 21, 2016 at 9:51 PM, Jeff Gilbert wrote:
> Pointers are prefereable for outparams because it makes it clearer
> what'
On Fri, Apr 22, 2016 at 1:05 AM, Nicholas Nethercote
wrote:
> The third example I looked at was CycleCollectedJSRuntime. Again
> problems, specifically this line in Init():
>
> mOwningThread->SetScriptObserver(this);
Others have already said what I would have here generally, but this
example is
Pointers are prefereable for outparams because it makes it clearer
what's going on at the callsite. (at least indicating that something
non-trivial is happening)
On Wed, Apr 20, 2016 at 8:07 PM, Kan-Ru Chen (陳侃如) wrote:
> Nicholas Nethercote writes:
>
>> Hi,
>>
>> C++ constructors can't be made
FWIW, I use static Create functions for fallible heap-only objects,
and StackFallible::ctor(bool* const out_success/error) for the rarer
fallible stack-createable objects.
It sounds like this lines up with existing proposals here.
Example fallible heap-only:
https://dxr.mozilla.org/mozilla-centra
More evidence that our coding conventions need an owner...
-j
On Wed, Apr 20, 2016 at 10:07 PM, Kan-Ru Chen (陳侃如)
wrote:
> Nicholas Nethercote writes:
>
> > Hi,
> >
> > C++ constructors can't be made fallible without using exceptions. As a
> result,
> > for many classes we have a constructor
On Thu, Apr 21, 2016 at 3:24 AM, Nicholas Nethercote wrote:
> On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva
> wrote:
> > Fallible construction (even with a way to report failure) is annoying if
> > only because the object's destructor has to account for the possible
> > invalid states. I much p
Your example is suffering from the fact that PR_CreateThread is taking
as parameter an object that is half-initialized, and then continues
constructing it. I believe this to be a poor design and that
unfortunately leaks into the creating of nsThread.
In such a situation I would personally still us
On Thu, Apr 21, 2016 at 8:41 PM, Martin Thomson wrote:
>
>> - I suspect that in some heap-allocated objects it will be hard to do
>> the fallible parts without having an object of the relevant type. I
>> don't have specific examples, just a hunch.
>
> I'm not aware of any way that necessary state
I prefer the fallible, if failed return null else return new pattern
myself also. With a little RAII, it keeps manual cleanup to a
minimum.
On Thu, Apr 21, 2016 at 8:24 PM, Nicholas Nethercote
wrote:
> - It doesn't appear to work with stack-allocated objects?
The advantage with a heap-allocated
FWIW, bug 1265035 was an example that got me thinking about this whole
thing, and it was a crash involving a stack-allocated object
(WorkerJSRuntime) in which initialization failed.
On Thu, Apr 21, 2016 at 8:35 PM, Nicolas Silva wrote:
> My experience is that stack allocated objects tend to be si
My experience is that stack allocated objects tend to be simpler,
shorter-lived and less prone to accumulating invalid state somewhere and
crash somewhere else. All in all they haven't been a source of pain the
way heap-allocated objects often are when it comes to invalid state
creeping up. There t
On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva wrote:
> Fallible construction (even with a way to report failure) is annoying if
> only because the object's destructor has to account for the possible
> invalid states. I much prefer having a static creation method that will
> only instantiate the o
Fallible construction (even with a way to report failure) is annoying if
only because the object's destructor has to account for the possible
invalid states. I much prefer having a static creation method that will
only instantiate the object in case of success, and mark the constructor
protected. S
On Thu, Apr 21, 2016 at 7:57 AM, Nicholas Nethercote wrote:
> On Thu, Apr 21, 2016 at 3:05 PM, Eric Rescorla wrote:
> > The general problem that
> > it doesn't alleviate is that failure to check the return value leaves you
> > with a reference/pointer to an object in an ill-defined half-construc
On 4/20/16 11:43 PM, Gerald Squelart wrote:
How about another generic helper, e.g.:
template
Maybe MakeCheckedMaybe(Args&&... aArgs)
{
nsresult rv;
Maybe m = Some(T(std::forward(aArgs)..., &rv));
if (NS_SUCCEEDED(rv)) {
return m;
}
return Nothing();
}
Existing
On Thursday, April 21, 2016 at 4:33:40 PM UTC+10, Nicholas Nethercote wrote:
> On Thu, Apr 21, 2016 at 4:19 PM, Xidorn Quan wrote:
> >>
> >> Maybe you're referring to factory methods, like this:
> >>
> >> static T* T::New();
> >>
> >> which would return null on failure. Such methods can be usefu
On Thu, Apr 21, 2016 at 4:19 PM, Xidorn Quan wrote:
>>
>> Maybe you're referring to factory methods, like this:
>>
>> static T* T::New();
>>
>> which would return null on failure. Such methods can be useful, but
>> there's two problems. First, they're not applicable to stack-allocated
>> objects
On Thu, Apr 21, 2016 at 3:57 PM, Nicholas Nethercote wrote:
> On Thu, Apr 21, 2016 at 3:05 PM, Eric Rescorla wrote:
> > So, if we are going to do something along these lines, I would want it
> to be
> > a convention that if you use MakeUnique and the like (as you should) then
> > they automatica
On Thu, Apr 21, 2016 at 3:05 PM, Eric Rescorla wrote:
> The general problem that
> it doesn't alleviate is that failure to check the return value leaves you
> with a reference/pointer to an object in an ill-defined half-constructed
> state. At least for heap allocations, I'd much rather have the p
On Wed, Apr 20, 2016 at 10:02:47PM -0700, Kyle Huey wrote:
On Wed, Apr 20, 2016 at 9:52 PM, Kris Maglione
There isn't a strict guarantee of non-nullness for reference parameters.
This is an extreme example, but technically valid:
T th(*(nsresult*)0);
IIRC this is undefined behavior, so when
I'm sympathetic to the desire to have a single fallible construction
function (this is generally how I structure things in C code), but I'm not
sure that this is really the right design for it. The general problem that
it doesn't alleviate is that failure to check the return value leaves you
with a
On Thursday, April 21, 2016 at 11:15:10 AM UTC+10, Nicholas Nethercote wrote:
> Hi,
>
> C++ constructors can't be made fallible without using exceptions. As a result,
> for many classes we have a constructor and a fallible Init() method which must
> be called immediately after construction.
>
> E
On Wed, Apr 20, 2016 at 9:52 PM, Kris Maglione
wrote:
> On Thu, Apr 21, 2016 at 02:10:59PM +1000, Nicholas Nethercote wrote:
>
>> On Thu, Apr 21, 2016 at 1:23 PM, Kris Maglione
>> wrote:
>>
>>>
>>> If we do this, can we please use |nsresult*| rather than |nsresult&|?
>>>
>>
>> I prefer a referen
On Thu, Apr 21, 2016 at 02:10:59PM +1000, Nicholas Nethercote wrote:
On Thu, Apr 21, 2016 at 1:23 PM, Kris Maglione wrote:
If we do this, can we please use |nsresult*| rather than |nsresult&|?
I prefer a reference because of the guarantee of non-nullness. But I
could live with a pointer if p
On Thu, Apr 21, 2016 at 1:23 PM, Kris Maglione wrote:
>
> If we do this, can we please use |nsresult*| rather than |nsresult&|?
I prefer a reference because of the guarantee of non-nullness. But I
could live with a pointer if people think it's better.
Nick
___
On Thu, Apr 21, 2016 at 11:07:21AM +1000, Nicholas Nethercote wrote:
Instead, we would do this:
nsresult rv;
T ts(rv);
if (NS_FAILED(rv)) {
return rv;
}
T* th = new T(rv);
if (NS_FAILED(rv)) {
delete th;
return rv;
}
If we do this, can we please use |nsresult*| rather than
|ns
Nicholas Nethercote writes:
> Hi,
>
> C++ constructors can't be made fallible without using exceptions. As a result,
> for many classes we have a constructor and a fallible Init() method which must
> be called immediately after construction.
>
> Except... there is one way to make constructors fal
On Thu, Apr 21, 2016 at 11:50 AM, Jim Blandy wrote:
> The pattern seems reasonable enough.
>
> DXR says we have 2579 "init" or "Init" functions, and 9801 callers of such
> functions. I used:
>
> function:init ext:cpp ext:h
> callers:init ext:cpp ext:h
There are also some called "Initialize" :)
I
The pattern seems reasonable enough.
DXR says we have 2579 "init" or "Init" functions, and 9801 callers of such
functions. I used:
function:init ext:cpp ext:h
callers:init ext:cpp ext:h
Do you propose we make an effort to fix up existing code, or just introduce
this as the preferred pattern in n
Hi,
C++ constructors can't be made fallible without using exceptions. As a result,
for many classes we have a constructor and a fallible Init() method which must
be called immediately after construction.
Except... there is one way to make constructors fallible: use an |nsresult&
aRv| outparam to
35 matches
Mail list logo
