Re: [Mixxx-devel] c++11 support is here
Hi, I think we use always the copy-initialization for pod types inside Mixxx (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. 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. 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? Now back to my original Question: How about CSAMPLE I think I still prefer: CSAMPLE a = 0.0; If auto is desired and a refactoring towards a complex type likely auto a = CSAMLE(0.0); seams to be reasonable. 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 +, 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 +, 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
Re: [Mixxx-devel] c++11 support is here
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 +, 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
Re: [Mixxx-devel] c++11 support is here
I have three. This doesn't actually tell you anything about type, and requires less code change later when that simple type becomes a complex type. Why rely on the compiler to perform an optimization that it has no obligation to perform? Honestly whatever the project feels is best, but document it and enforce it. On Sat, Jun 6, 2015, 3:57 AM Musikpirat mi...@christian-hufgard.de wrote: Hi, Am 05.06.2015 um 22:44 schrieb Owen Williams: 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. What is the advantage of not knowing what kind of object you are working with? I'm a java developer (and not a mixxx developer ;) and one of the greatest things in java was the introduction of typed lists and generics. Of course the IDE does help you when hovering an object or with code completion. But I believe coding goes much faster if you know the type - and what you can do with it. Christian -- ___ 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
Re: [Mixxx-devel] c++11 support is here
Am 06.06.2015 um 10:53 schrieb Gavin Swanson: I have three. This doesn't actually tell you anything about type, and requires less code change later when that simple type becomes a complex type. If a simple type becomes a complex type you usually do something else with it than before. So there is more to do than just change some types. Which is supported by IDEs. :) Why rely on the compiler to perform an optimization that it has no obligation to perform? Because it is the compilers job to do so. ;) Honestly whatever the project feels is best, but document it and enforce it. +1 Christian -- ___ 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
Re: [Mixxx-devel] c++11 support is here
On another note. I have not seen a c++ ide, that's not super expensive, that can provide the type of refactoring support java does. On Sat, Jun 6, 2015, 5:01 AM Musikpirat mi...@christian-hufgard.de wrote: Am 06.06.2015 um 10:53 schrieb Gavin Swanson: I have three. This doesn't actually tell you anything about type, and requires less code change later when that simple type becomes a complex type. If a simple type becomes a complex type you usually do something else with it than before. So there is more to do than just change some types. Which is supported by IDEs. :) Why rely on the compiler to perform an optimization that it has no obligation to perform? Because it is the compilers job to do so. ;) Honestly whatever the project feels is best, but document it and enforce it. +1 Christian -- ___ 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
Re: [Mixxx-devel] c++11 support is here
Hi, Am 05.06.2015 um 22:44 schrieb Owen Williams: 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. What is the advantage of not knowing what kind of object you are working with? I'm a java developer (and not a mixxx developer ;) and one of the greatest things in java was the introduction of typed lists and generics. Of course the IDE does help you when hovering an object or with code completion. But I believe coding goes much faster if you know the type - and what you can do with it. Christian -- ___ 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
Re: [Mixxx-devel] c++11 support is here
On 06/05/2015 09:55 AM, Daniel Schürmann wrote:
Hi all.
Good news! Thank you RJ.
I just one objection to the C++11 white list.
The new keyword auto.
No auto is awesome. I've started a new simulation Montecarlo simulation
program for my PhD and use exclusively auto to declare my variables. So
far I was never surprised by type and I get the benefit that I force the
compiler to check that each of my variables is initialized, incredibly
useful!
At first it seems a bit odd but once you are used to only using auto it
gets convenient with no noticeable downside.
A good post on that topic is.
http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
I can also recommend the chapter about 'auto' in Effective Modern C++
2015-06-05 6:43 GMT+02:00 RJ Ryan rr...@mixxx.org:
Mixxx is switching to C++11! The master branch now has -std=c++11 turned
on. 1.12 will be the last release without C++11 support.
This means we have new minimum requirements for compilers:
* Visual Studio 2013 (12.0)
* GCC 4.8 (supported on Ubuntu 14.04 and up)
* Clang 3.3 (supported on Ubuntu 14.04 and up. Supported on XCode 4.4 and
higher)
Nice
** Backport some C++14 stuff **
We should introduce a compat header to backport some useful C++14 stuff.
This can be done rather easily because it is just a minor addition to
C++11. A obvious one is the make_unique and make_shared template.
namespace std {
// we use C++11 as a minimum requirment. make_unique was added in C++14
to the
// standard. So always use this.
template typename T, typename... Ts
std::unique_ptrT make_unique(Ts... params) {
return std::unique_ptrT(new T(std::forwardTs(params)...));
}
template typename T, typename... Ts
std::shared_ptrT make_shared(Ts... params) {
return std::shared_ptrT(new T(std::forwardTs(params)...));
}
} // namespace std
This sure that we allocate the smartpointer and real pointer adjacent to
each other in ram, It can be later used like
auto tmp = make_uniqueQWidget(var1, var2, var3);
--
___
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
Re: [Mixxx-devel] c++11 support is here
Hi all. Good news! Thank you RJ. I just one objection to the C++11 white list. The new keyword auto. IMHO auto helps to speed up the code writing. But it makes the code harder to understand. Some IDEs are starting to display the real type, but that does not help in GitHub reviews or other editors. We should generally prefer explicit types There are some exceptions where auto comes handy: * function pointers * complex template types. For all the rest we should not use auto. The is an other reason for auto: during refactoring Lets asume a function float getValue() ant the usage float a = getValue(); if we change getValue() to return double. We have to check all usages of getValue() to double a = getValue(); this is not required for auto a = getValue(); IMHO this kind of laziness is convenient but dangerous. The developer should be forced to check what happen by the refactoring not rely on an auto keyword. The problem is only shifted to the usage of auto a. Kind regards, Daniel 2015-06-05 6:43 GMT+02:00 RJ Ryan rr...@mixxx.org: Mixxx is switching to C++11! The master branch now has -std=c++11 turned on. 1.12 will be the last release without C++11 support. This means we have new minimum requirements for compilers: * Visual Studio 2013 (12.0) * GCC 4.8 (supported on Ubuntu 14.04 and up) * Clang 3.3 (supported on Ubuntu 14.04 and up. Supported on XCode 4.4 and higher) To gradually ramp up our use of C++11 we're starting with a feature whitelist/blacklist. Here's the initial list of features that are supported across all 3 of these compilers: http://mixxx.org/wiki/doku.php/coding_guidelines#c_11 Let me know if your favorite feature isn't on there. My main goal is to be conservative and not go wild with complexity if it isn't needed. Please resist the urge to be fancy for its own sake. Ideally this will allow us to simplify our codebase, not make it more complex. Thanks, RJ -- ___ 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
Re: [Mixxx-devel] c++11 support is here
Hi Max,
Thank you for the nice blog.
I did not know all these reason pro auto.
I am currently working in a huge c# project, which uses a Mixed style var
/ explicit types.
Since It is not all my code, It is sometimes a pain to understand the code
with all the vars and the
mixed style:
QListQString list = getList();
is much easier to understand than
auto list = getList();
It might help if we have
auto list = getListOfQString();
or something.
If you start a project from the scratch, It seams there are much more
reasons for using auto.
But in a big existing project, we have to consider careful if enough pro
arguments exists.
And If, how we will manage a transition to a desired AAA Style.
It will be finally OK for me if we decide to replace all local declarations
with auto.
What will be a good strategy, that does not and up only in reducing
readability?
Can we set up some more rules?
Kind regards,
Daniel
2015-06-05 10:38 GMT+02:00 Max Linke max_li...@gmx.de:
On 06/05/2015 09:55 AM, Daniel Schürmann wrote:
Hi all.
Good news! Thank you RJ.
I just one objection to the C++11 white list.
The new keyword auto.
No auto is awesome. I've started a new simulation Montecarlo simulation
program for my PhD and use exclusively auto to declare my variables. So
far I was never surprised by type and I get the benefit that I force the
compiler to check that each of my variables is initialized, incredibly
useful!
At first it seems a bit odd but once you are used to only using auto it
gets convenient with no noticeable downside.
A good post on that topic is.
http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
I can also recommend the chapter about 'auto' in Effective Modern C++
2015-06-05 6:43 GMT+02:00 RJ Ryan rr...@mixxx.org:
Mixxx is switching to C++11! The master branch now has -std=c++11 turned
on. 1.12 will be the last release without C++11 support.
This means we have new minimum requirements for compilers:
* Visual Studio 2013 (12.0)
* GCC 4.8 (supported on Ubuntu 14.04 and up)
* Clang 3.3 (supported on Ubuntu 14.04 and up. Supported on XCode 4.4
and
higher)
Nice
** Backport some C++14 stuff **
We should introduce a compat header to backport some useful C++14 stuff.
This can be done rather easily because it is just a minor addition to
C++11. A obvious one is the make_unique and make_shared template.
namespace std {
// we use C++11 as a minimum requirment. make_unique was added in C++14
to the
// standard. So always use this.
template typename T, typename... Ts
std::unique_ptrT make_unique(Ts... params) {
return std::unique_ptrT(new T(std::forwardTs(params)...));
}
template typename T, typename... Ts
std::shared_ptrT make_shared(Ts... params) {
return std::shared_ptrT(new T(std::forwardTs(params)...));
}
} // namespace std
This sure that we allocate the smartpointer and real pointer adjacent to
each other in ram, It can be later used like
auto tmp = make_uniqueQWidget(var1, var2, var3);
--
___
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
Re: [Mixxx-devel] c++11 support is here
On Fri, Jun 5, 2015 at 4:38 AM, Max Linke max_li...@gmx.de wrote:
On 06/05/2015 09:55 AM, Daniel Schürmann wrote:
Hi all.
Good news! Thank you RJ.
I just one objection to the C++11 white list.
The new keyword auto.
No auto is awesome. I've started a new simulation Montecarlo simulation
program for my PhD and use exclusively auto to declare my variables. So
far I was never surprised by type and I get the benefit that I force the
compiler to check that each of my variables is initialized, incredibly
useful!
At first it seems a bit odd but once you are used to only using auto it
gets convenient with no noticeable downside.
The downside comes when you need to read someone else's code :P.
We should follow the google C++ style guide here -- which is somewhere
between Daniel and Max on this point:
https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#auto
Which can pretty much be summarized as use auto to prevent repeating
yourself.
A good post on that topic is.
http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/
I can also recommend the chapter about 'auto' in Effective Modern C++
2015-06-05 6:43 GMT+02:00 RJ Ryan rr...@mixxx.org:
Mixxx is switching to C++11! The master branch now has -std=c++11 turned
on. 1.12 will be the last release without C++11 support.
This means we have new minimum requirements for compilers:
* Visual Studio 2013 (12.0)
* GCC 4.8 (supported on Ubuntu 14.04 and up)
* Clang 3.3 (supported on Ubuntu 14.04 and up. Supported on XCode 4.4
and
higher)
Nice
** Backport some C++14 stuff **
We should introduce a compat header to backport some useful C++14 stuff.
This can be done rather easily because it is just a minor addition to
C++11. A obvious one is the make_unique and make_shared template.
+1 -- make_unique is great. make_shared is c++11 I believe.
namespace std {
// we use C++11 as a minimum requirment. make_unique was added in C++14
to the
// standard. So always use this.
template typename T, typename... Ts
std::unique_ptrT make_unique(Ts... params) {
return std::unique_ptrT(new T(std::forwardTs(params)...));
}
template typename T, typename... Ts
std::shared_ptrT make_shared(Ts... params) {
return std::shared_ptrT(new T(std::forwardTs(params)...));
}
} // namespace std
This sure that we allocate the smartpointer and real pointer adjacent to
each other in ram, It can be later used like
auto tmp = make_uniqueQWidget(var1, var2, var3);
--
___
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
Re: [Mixxx-devel] c++11 support is here
On Fri, Jun 5, 2015 at 1:35 AM, Sean M. Pappalardo - D.J. Pegasus spappala...@mixxx.org wrote: On 06/04/2015 09:43 PM, RJ Ryan wrote: * Visual Studio 2013 (12.0) Does VS2015 offer more C++11 features? Since it's free, we can just declare that to be the minimum version from here on. Partially because all of our documentation and the build VM was just updated to use 2013 as the minimum :). Sincerely, Sean M. Pappalardo D.J. Pegasus Mixxx Developer - Controller Specialist -- ___ 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
Re: [Mixxx-devel] c++11 support is here
On Fri, 2015-06-05 at 08:14 -0400, RJ Ryan wrote: Which can pretty much be summarized as use auto to prevent repeating yourself. My rule of thumb is, use auto when the type is long AND easily understandable from the context. So don't use auto instead of QString just because, but do use auto instead of blahfoo::const_iterator. And for range-based for loops, please *always* use auto when iterating through a map, because it's easy to get the types wrong. -- ___ 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
Re: [Mixxx-devel] c++11 support is here
Hi I have updated http://mixxx.org/wiki/doku.php/coding_guidelines?#auto according to our discussion. It is still a draft. Lets tweak it until we have a commitment. I am unsure what is the recommended version for our own typedefs: CSAMPLE sample = 0.0; auto sample = (CSAMPLE)0.0; auto sample = CSAMPLE(0.0); auto sample = static_castCSAMPLE(0.0); And object inits auto string = QString(Hello world!); QString string(Hello world!); Any preferences? Kind regards, Daniel Am 05.06.2015 um 15:27 schrieb Owen Williams: On Fri, 2015-06-05 at 08:14 -0400, RJ Ryan wrote: Which can pretty much be summarized as use auto to prevent repeating yourself. My rule of thumb is, use auto when the type is long AND easily understandable from the context. So don't use auto instead of QString just because, but do use auto instead of blahfoo::const_iterator. And for range-based for loops, please *always* use auto when iterating through a map, because it's easy to get the types wrong. -- ___ 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
Re: [Mixxx-devel] c++11 support is here
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 https://lists.sourceforge.net/lists/listinfo/mixxx-devel
Re: [Mixxx-devel] c++11 support is here
CSAMPLE sample(0.0); On Fri, Jun 5, 2015, 4:45 PM Owen Williams 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 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
Re: [Mixxx-devel] c++11 support is here
In a project the size of mixxx (at least as they come up) every situation should be enumerated and documented (to the extent possible in an os project). This provides new developers the information to maintain consistency. The code, especially in a large project that hasn't had the formatting enforced, can't always be the example. Whatever the project decides, consistency, and documentation are the most important. On Fri, Jun 5, 2015, 8:27 PM Owen Williams owilli...@mixxx.org wrote: Well my thinking is more aimed at humans reading code than the compiler reading it. The function-style initialization looks like a class initialization, which makes CSAMPLE look heavier than it is. What I've been taught is that what's most important is the syntactic clues that a reader picks up at the call site, without needing to dive into a call hierarchy. A simple assignment of x = 0 is clearly low-weight. x(0) could be anything from low-weight to extremely heavy. If there is a low-weight way to write the assignment, that's preferred because it gives the reader a better sense of the true code complexity. For classes, it's a little more up in the air: auto blah = MyClassType(0) isn't wonderful, because the auto is sort of a waste of breath. Just do MyClassType blah(0); auto is ok for new pointers like auto* blah = new MyType(0); because nothing is being repeated and it's super clear what type the auto has. It's all a matter of taste and I don't think it's necessary to enumerate every possible situation. owen On Sat, 2015-06-06 at 00:11 +, 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 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 +, Gavin Swanson wrote: http://stackoverflow.com/a/4470763 On Fri, Jun 5, 2015, 7:21 PM Owen Williams 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 +, Gavin Swanson wrote: CSAMPLE sample(0.0); On Fri, Jun 5, 2015, 4:45 PM Owen Williams 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 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
Re: [Mixxx-devel] c++11 support is here
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 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 +, Gavin Swanson wrote: http://stackoverflow.com/a/4470763 On Fri, Jun 5, 2015, 7:21 PM Owen Williams 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 +, Gavin Swanson wrote: CSAMPLE sample(0.0); On Fri, Jun 5, 2015, 4:45 PM Owen Williams 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 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
Re: [Mixxx-devel] c++11 support is here
http://stackoverflow.com/a/4470763 On Fri, Jun 5, 2015, 7:21 PM Owen Williams 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 +, Gavin Swanson wrote: CSAMPLE sample(0.0); On Fri, Jun 5, 2015, 4:45 PM Owen Williams 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 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
Re: [Mixxx-devel] c++11 support is here
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 +, Gavin Swanson wrote: http://stackoverflow.com/a/4470763 On Fri, Jun 5, 2015, 7:21 PM Owen Williams 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 +, Gavin Swanson wrote: CSAMPLE sample(0.0); On Fri, Jun 5, 2015, 4:45 PM Owen Williams 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 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
Re: [Mixxx-devel] c++11 support is here
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 +, Gavin Swanson wrote: CSAMPLE sample(0.0); On Fri, Jun 5, 2015, 4:45 PM Owen Williams 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 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
Re: [Mixxx-devel] c++11 support is here
And ho. ly. crap. Microsoft, yes, Microsoft, now has a version of their VS code editor that runs natively on Linux and Mac: https://www.visualstudio.com/products/code-vs Not that I'd use it because it will likely push developers to use Microsoft-specific functionality as VS always has, but I'm just floored that MS would ever develop an application for Linux. Sean smime.p7s Description: S/MIME Cryptographic Signature -- ___ 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
