[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: initialization style
From: |
Rik |
Subject: |
Re: initialization style |
Date: |
Fri, 21 Jul 2017 10:24:36 -0700 |
On 07/21/2017 09:54 AM, John W. Eaton wrote:
> On 07/21/2017 12:31 AM, Rik wrote:
>
>> There were only a few instances of static buffers which I changed to use
>> local variables in this cset
>> (http://hg.savannah.gnu.org/hgweb/octave/rev/cda0614beaec).
>
> Thanks.
>
> I admit to having to read about the meaning of this type of statement
> that appears in your patch:
>
> int arg_used[7] {};
>
> and I'm still a bit confused. Is there any difference between this
> syntax and
>
> int arg_used[7] = {};
>
> ? They both initialize the elements of the array to 0, correct?
>
> Should we have a preferred style for this?
Probably we should have a style. I did some research and came back
confused enough that I simply went with the dominant convention that I saw
in other code. However, I can say a few things. The '=' can be important
because it will generally invoke copy-initialization while the use of
parentheses will generally invoke direct-initialization. The use of curly
braces can mean both things. For a non-aggregate entity it seems to do
direct-initialization, but if I read the specification correctly all
aggregate objects are always copy-initialized from the elements within the
curly braces. For arrays, as in the example, I think the assignment
operator '=' simply re-affirms what is already happening. And yes, there
are some differences between direct-initialization and copy-initialization
when it comes down to the universe of constructors that are considered for
matching. For a POD type like an int, I don't think it matters, but if you
want to have a general convention then we should consider the effects of
choosing one syntax versus the other.
References:
http://en.cppreference.com/w/cpp/language/direct_initialization
http://en.cppreference.com/w/cpp/language/aggregate_initialization
--Rik
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, (continued)
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, John W. Eaton, 2017/07/18
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, Rik, 2017/07/19
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, John W. Eaton, 2017/07/19
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, Rik, 2017/07/20
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, John W. Eaton, 2017/07/20
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, Rik, 2017/07/21
- Message not available
- Message not available
- Message not available
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, Daniel J Sebald, 2017/07/21
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, Daniel J Sebald, 2017/07/23
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, John W. Eaton, 2017/07/21
- Re: Replace OCTAVE_LOCAL_BUFFER implementation with std::unique_ptr?, Mike Miller, 2017/07/21
- Re: initialization style,
Rik <=