5 ms·

The CppCon videos [1] are a great resource, but you'll have to thread your way through the wide variety of topics. The videos from Herb Sutter [2] will usually

by zengid 9y ago

The CppCon videos [1] are a great resource, but you'll have to thread your way through the wide variety of topics. The videos from Herb Sutter [2] will usually emphasize best practices and give great examples, although he expects the audience to have a good bit of familiarity in regards to 'modern' c++ elements (C++11 and beyond). [1] https://www.youtube.com/channel/UCMlGfpWw-RUdWX_JbLCukXg https://www.youtube.com/channel/UCMlGfpWw-RUdWX_JbLCukXg [2] https://herbsutter.com/ https://herbsutter.com/

72deluxe 9y ago
Herb Sutter is very good. His "almost always auto" idea is crazy though - who on earth thinks this is a good idea instead of being explicit?? auto main(int argc, char* argv[]) -> int Madness!
- daemin 9y ago
  I look it as a good experiment to find the right amount of auto to use. Go to one extreme and then see what bites you in practise, then make changes to where you use auto so that you get good and clean code.
  - AnimalMuppet 9y ago
    Note that "the right amount" depends not just on your personal taste, but also on the experience level of others who use your code.
  - 72deluxe 9y ago
    Yes, I think auto for iterators is good but for return types it doesn't help any poor developer left to maintain your code in 20 years time (even 2 years). Dealing with an extensive large and complex 5 million line C++ codebase at the moment where many of the original developers have left leaving zero documentation, design documents or specs, or even sensible comments, I truly increasingly cherish readability and understandability of any small portion of code without having to get a holistic overview; I should be able to understand what it's doing in isolation - auto as a return type or as a deduced return type doesn't help me see what something is doing from the calling site without having to wade through reams of other function calls or step into them; I think time will not be kind to it if overused.
    - daemin 9y ago
      A good rule to follow would be that whenever auto is used the type that it would otherwise be has to be present in the statement, or that it's an iterator. That results in still seeing what type you have but not having to repeat yourself.
- shortoncash 9y ago
  I initially disliked this also, but then I realized this is a natural extension of just programming generically almost all the time. You use the language to manage flow between types and to define types, but the types themselves aren't "binding" in a sense. If you use auto all the time but don't use templates, type deduction, and automatic type conversion, you're missing out on much of the language. Auto forces you to think about the general relationships between types. In a sense, it really brings all of the elements of the language together.
  - 72deluxe 9y ago
    In my example although auto was used, it was explicitly specified in the trailing return type that the function returned an int. This makes auto both needless and confusing in this instance, and should hardly be a recommendation! You are right about the joys of auto with regard to template types and deduction but the implicit type conversion in C++ is a big danger; far better to be explicit about what a function is returning for the most part due to your inability to constrain the implicit conversions; it also helps with maintainability as you can read through small portions of a giant codebase without having to have a holistic overview of the entire system - you can treat each section in isolation because it is explicit in what it is returning, so you can make decisions as a maintainer based on the explicit information in front of you instead of the "it might be this or it might be that" scenario that auto (as a return type) offers. (I'm not saying auto is bad, but should be used with caution for the return type of a function as it makes the code impossible to understand without an IDE - from looking at a diff between two files, how do I know what it is doing or make a fix under pressure?) Auto when used as a shortening of lengthy template iterator variables, then yes I heartily welcome them.
    - shortoncash 9y ago
      There is no maintainability problem if the general behavior is correct for all types that a statement can be composed of. You don't need an IDE, you just need a decent operating model of the nature of interactions between types.
- AboutTheWhisles 9y ago
  It depends on the situation. Using the 'auto' keyword makes things more generic. It can also save long type names from making expressions difficult to read. An IDE that can follow the auto to its actual type is also helpful. If a type name is small then being explicit about the type name can be much more clear since it can save someone having to hunt down what type each function might return.
  - 72deluxe 9y ago
    Yes, auto is definitely welcomed in the case of my::long::scoped::namespace::templatedItem<more::details::here>::const_iterator but using it for member functions is insane given that you have to read the entire thing left to right only to see what it returns at the end; it is far less to read just putting "int" at the far left. Of course, in the case of types that are the results of other templated types e.g. T,U -> V then it makes sense and it is obviously welcomed in the syntax of lambdas (far more sensible to me than the C# syntax or C#'s Func) but the use of it everywhere seems foolish. If it were a good idea, then we would be pushing to remove the return type being at the beginning of a function at all; please say this isn't the case! eg. main(int arg, char* argv[]) -> int or complete stupidity that makes it impossible to read without an IDE (e.g. in a diffing tool): auto main(auto arg, auto* argv[]) When it turns into that, I'm quitting the industry.
    - AboutTheWhisles 9y ago
      > using it for member functions is insane given that you have to read the entire thing left to right only to see what it returns at the end; it is far less to read just putting "int" at the far left This is not what auto as a function return type is for. Auto wasn't invented so people could put int on the right side of a function. There are two reasons to use it. The first is similar to using auto for a long type name. You can use decltype to declare the return type to be the same as the resulting type of an expression. The second is what you mentioned, keeping in mind that you can use template types in the decltype expression.
- vram22 9y ago
  Is auto in C++ the same as auto in D?

by zengid 9y ago

72deluxe 9y ago

Herb Sutter is very good. His "almost always auto" idea is crazy though - who on earth thinks this is a good idea instead of being explicit?? auto main(int argc, char* argv[]) -> int Madness!

daemin 9y ago
I look it as a good experiment to find the right amount of auto to use. Go to one extreme and then see what bites you in practise, then make changes to where you use auto so that you get good and clean code.
- AnimalMuppet 9y ago
  Note that "the right amount" depends not just on your personal taste, but also on the experience level of others who use your code.
- 72deluxe 9y ago
  Yes, I think auto for iterators is good but for return types it doesn't help any poor developer left to maintain your code in 20 years time (even 2 years). Dealing with an extensive large and complex 5 million line C++ codebase at the moment where many of the original developers have left leaving zero documentation, design documents or specs, or even sensible comments, I truly increasingly cherish readability and understandability of any small portion of code without having to get a holistic overview; I should be able to understand what it's doing in isolation - auto as a return type or as a deduced return type doesn't help me see what something is doing from the calling site without having to wade through reams of other function calls or step into them; I think time will not be kind to it if overused.
  - daemin 9y ago
    A good rule to follow would be that whenever auto is used the type that it would otherwise be has to be present in the statement, or that it's an iterator. That results in still seeing what type you have but not having to repeat yourself.
shortoncash 9y ago
I initially disliked this also, but then I realized this is a natural extension of just programming generically almost all the time. You use the language to manage flow between types and to define types, but the types themselves aren't "binding" in a sense. If you use auto all the time but don't use templates, type deduction, and automatic type conversion, you're missing out on much of the language. Auto forces you to think about the general relationships between types. In a sense, it really brings all of the elements of the language together.
- 72deluxe 9y ago
  In my example although auto was used, it was explicitly specified in the trailing return type that the function returned an int. This makes auto both needless and confusing in this instance, and should hardly be a recommendation! You are right about the joys of auto with regard to template types and deduction but the implicit type conversion in C++ is a big danger; far better to be explicit about what a function is returning for the most part due to your inability to constrain the implicit conversions; it also helps with maintainability as you can read through small portions of a giant codebase without having to have a holistic overview of the entire system - you can treat each section in isolation because it is explicit in what it is returning, so you can make decisions as a maintainer based on the explicit information in front of you instead of the "it might be this or it might be that" scenario that auto (as a return type) offers. (I'm not saying auto is bad, but should be used with caution for the return type of a function as it makes the code impossible to understand without an IDE - from looking at a diff between two files, how do I know what it is doing or make a fix under pressure?) Auto when used as a shortening of lengthy template iterator variables, then yes I heartily welcome them.
  - shortoncash 9y ago
    There is no maintainability problem if the general behavior is correct for all types that a statement can be composed of. You don't need an IDE, you just need a decent operating model of the nature of interactions between types.
AboutTheWhisles 9y ago
It depends on the situation. Using the 'auto' keyword makes things more generic. It can also save long type names from making expressions difficult to read. An IDE that can follow the auto to its actual type is also helpful. If a type name is small then being explicit about the type name can be much more clear since it can save someone having to hunt down what type each function might return.
- 72deluxe 9y ago
  Yes, auto is definitely welcomed in the case of my::long::scoped::namespace::templatedItem<more::details::here>::const_iterator but using it for member functions is insane given that you have to read the entire thing left to right only to see what it returns at the end; it is far less to read just putting "int" at the far left. Of course, in the case of types that are the results of other templated types e.g. T,U -> V then it makes sense and it is obviously welcomed in the syntax of lambdas (far more sensible to me than the C# syntax or C#'s Func) but the use of it everywhere seems foolish. If it were a good idea, then we would be pushing to remove the return type being at the beginning of a function at all; please say this isn't the case! eg. main(int arg, char* argv[]) -> int or complete stupidity that makes it impossible to read without an IDE (e.g. in a diffing tool): auto main(auto arg, auto* argv[]) When it turns into that, I'm quitting the industry.
  - AboutTheWhisles 9y ago
    > using it for member functions is insane given that you have to read the entire thing left to right only to see what it returns at the end; it is far less to read just putting "int" at the far left This is not what auto as a function return type is for. Auto wasn't invented so people could put int on the right side of a function. There are two reasons to use it. The first is similar to using auto for a long type name. You can use decltype to declare the return type to be the same as the resulting type of an expression. The second is what you mentioned, keeping in mind that you can use template types in the decltype expression.
vram22 9y ago
Is auto in C++ the same as auto in D?