On 06/07/2015 10:28 PM, Daniel Schürmann wrote:
> Hi,
>
> I think we use always the copy-initialization for pod types inside Mixxx

Sure? I don't currently recall what the compiler has to do if we 
explicitly define a copy constructor, is the copy or implicitly 
generated move constructor used? For other cases we might already be 
using compiler generated move constructors.

> (Except initializations lists)
> int value = 4;
> For me this is the best readable version and is exactly what the underlying
> machine code does.
> The value 4 is copied from the text segment to a cpu register.

auto value = 4; will do the exact same thing. Check yourself with 
objdump. The reason is the way auto works. Auto is using the template 
type deduction rules to deduce the type during compile time so if you write

auto value = 4;

the compiler will translate this to

int value = 4;

and only THEN translate it into assembly. So as far as the machine code 
is concerned there is no difference at all for primitive types. Also 
things like

auto str = ComplexType(...);

will be translated to

ComplexType str = ComplexType(...)

>
> Now we have the new keyword auto.
> auto value = 4;
> Is readable in the same way, if we assume the every reader
> knows what auto is and that literal conts defaults to int.
> It forces that the variable is initialized and allows no implicit
> conversions.
> It may improve readability by hiding unimportant info.

yes the int is unimportant. the 4 shows clearly that we want to have an 
int. I also think it is ok to assume that people will now what auto does 
if they use c++11.

>
> So IMHO we should prefer these both notations over direct-initialization.
>
> If the variable of type class,
> QString string("Hallo");
> seams to be closest to the underlying assembler.
> It has the drawback that it cannot easy be distinguish from a call to a
> function
> string(). I think thats the reason why we find
> QString string = "Hallo";
> also in the Mixxx code base.
> But this implies s lot of c++ magic and complier optimization.
> We should avoid it.
>
> A correct legacy form would be (please correct me)
> QString  tring = QString("Hallo");
>
> A notation like this:
> auto string = QString("Hallo");
> may combines the best of the to worlds without any duplication.
> Is it OK if we prefer this from now?

Yes this is the correct way for C++11. And for the compiler it is the 
same as above.

>
> Now back to my original Question:  "How about CSAMPLE"
> I think I still prefer:
> CSAMPLE a = 0.0;

yeah I can't think of a nicer to read way. Valid would be

auto a = 0.0f;

but this requires me to know that CSample is a float. AFAIK there is no 
nice way to use auto with renamned primitive types.

>
> If auto is desired and a refactoring towards a complex type likely
> auto a = CSAMLE(0.0);
> seams to be reasonable.

yes otherwise I would stick with the old way.

>
> We should not use
> CSAMLPE a(0.0);
> Since it is still a POD type
>
> Can this be a common agreement?
>
> Thank you,
>
> Daniel
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Am 06.06.2015 um 11:24 schrieb Uwe Klotz:
>> +1 Gavin, I also prefer direct-initialization over copy-initialization.
>>
>> For classes without a copy constructor you need to use
>> direct-initialization anyway. And if you bravely declare your single
>> parameter constructors as 'explicit' (what you should almost always
>> do, even if Qt does not) you also need to use direct-initialization.
>>
>> http://en.cppreference.com/w/cpp/language/direct_initialization
>> "Direct-initialization is more permissive than copy-initialization:
>> copy-initialization only considers non-explicit constructors and
>> user-defined conversion functions, while direct-initialization
>> considers all constructors and implicit conversion sequences. "
>>
>> But I must confess that I use the assignment style if the type is
>> obviously a native type.
>>
>> Uwe
>>
>> On 06/06/2015 02:11 AM, Gavin Swanson wrote:
>>>
>>> are we in violent agreement then? Why not do the optimal thing in the
>>> first place for consistency sake?  Rather than rely on the compiler
>>> to do it for you. Especially in a case like this where the
>>> optimization is no more work nor is it less readable.
>>>
>>>
>>> On Fri, Jun 5, 2015, 7:38 PM Owen Williams <owilli...@mixxx.org
>>> <mailto:owilli...@mixxx.org>> wrote:
>>>
>>>     That's what I said?
>>>
>>>     "The compiler is free to elide (remove) the temporary+copying
>>>     whenever
>>>     it can, but copy constructor must still be accessible"
>>>
>>>
>>>
>>>     On Fri, 2015-06-05 at 23:34 +0000, Gavin Swanson wrote:
>>>     > http://stackoverflow.com/a/4470763
>>>     >
>>>     >
>>>     > On Fri, Jun 5, 2015, 7:21 PM Owen Williams <owilli...@mixxx.org
>>>     <mailto:owilli...@mixxx.org>>
>>>     > wrote:
>>>     >         Since CSAMPLE is a simple type, assignment is best --
>>>     and when
>>>     >         it works,
>>>     >         assignment is the way to go (hurray for smart compilers
>>>     >         eliding copies).
>>>     >         With the form sample(0.0), it gives the impression that
>>>     >         CSAMPLE is a
>>>     >         complex type with a constructor.
>>>     >
>>>     >         On Fri, 2015-06-05 at 22:16 +0000, Gavin Swanson wrote:
>>>     >         > CSAMPLE sample(0.0);
>>>     >         >
>>>     >         >
>>>     >         > On Fri, Jun 5, 2015, 4:45 PM Owen Williams
>>>     >         <owilli...@mixxx.org <mailto:owilli...@mixxx.org>>
>>>     >         > wrote:
>>>     >         >         On Fri, 2015-06-05 at 22:30 +0200, Daniel
>>>     Schürmann
>>>     >         wrote:
>>>     >         >
>>>     >         >         > CSAMPLE sample = 0.0;
>>>     >         >
>>>     >         >         This one.  auto should really only be used when
>>>     >         assigning from
>>>     >         >         a
>>>     >         >         function whose return value is obvious.
>>>     >         >
>>>     >         >
>>>     >         >
>>>     >         >
>>>     >         >
>>>     >
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>     >         >  _______________________________________________
>>>     >         >         Get Mixxx, the #1 Free MP3 DJ Mixing software
>>>     Today
>>>     >         > http://mixxx.org
>>>     >         >
>>>     >         >
>>>     >         >         Mixxx-devel mailing list
>>>     >         > Mixxx-devel@lists.sourceforge.net
>>>     <mailto:Mixxx-devel@lists.sourceforge.net>
>>>     >         >
>>>     > https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>>>     >
>>>     >
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
>>>
>>> _______________________________________________
>>> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
>>> http://mixxx.org
>>>
>>>
>>> Mixxx-devel mailing list
>>> Mixxx-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
>> http://mixxx.org
>>
>>
>> Mixxx-devel mailing list
>> Mixxx-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Get Mixxx, the #1 Free MP3 DJ Mixing software Today
> http://mixxx.org
>
>
> Mixxx-devel mailing list
> Mixxx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mixxx-devel
>

------------------------------------------------------------------------------
_______________________________________________
Get Mixxx, the #1 Free MP3 DJ Mixing software Today
http://mixxx.org


Mixxx-devel mailing list
Mixxx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mixxx-devel

Reply via email to