27 ms·
I always try to avoid auto in c++ or var in C#. On the paper it is a nice was to save you from typing out the type but this is only true if you have tool suppor
by Surac 10mo ago
I always try to avoid auto in c++ or var in C#. On the paper it is a nice was to save you from typing out the type but this is only true if you have tool support and can use your mouse to obtain the type. In printouts or even in a text snippet I’m am lost. I think auto inC++ was the try to shorten some overburden type constructs and make it a little more friendly to use heavy templating. Please forgive my bad English. I’m no native speaker
- majoe 10mo agoI came to like auto over the years, although I also use it sparingly. Sometimes the concrete types only add visual noise and not much helpful information, e.g. iterators: auto it = some_container.begin(); Not even once have I wished to know the actual type of the iterator.
- samdoesnothing 10mo agoOdd, it's not a problem in dynamically typed languages or languages like Kotlin, Swift, etc. I think it's more just what you're used to.
- deleted 10mo ago[deleted]
- Rucadi 10mo agoauto has a good perk, it prevents uninitialized values (Which is a source of bugs). For example: auto a; will always fail to compile not matter what flags. int a; is valid. Also it prevents implicit type conversions, what you get as type on auto is the type you put at the right. That's good.
- jb1991 10mo agoThis is indeed exactly correct. Probably on its own this is the most important reason for most people to use it, as I think most of the millions of C++ developers in the world (and yes there are apparently millions) are not messing with compiler flags to get the checks that probably should be there by default anyway. The keyword auto gives you that.
- feelamee 10mo agouninitialized values are not the source of bugs. This is a good way to find logic errors in code (e.g. using sanitizer)
- jb1991 10mo ago"bug" can refer to many categories of problems, including logic errors. I've certainly seen uninitialized variables be a source of bugs. Stackoverflow for example is full of discussions about debugging problems caused by uninitialized variables, and the word "bug" is very often used in those contexts. What do you mean it is not a source of bugs?
- 1718627440 10mo ago> What do you mean it is not a source of bugs? I think what they mean, and what I also think is that the bug does not come from the existence of uninitialized variables. It comes from the USE of uninitialized variables. Making the variables initialized does not make the bug go away, at most it silences it. Making the program invalid instead (which is what UB fundamentally is) is way more helpful for making programs have less bugs. That the compiler still emits a program is a defect, although an unfixable one. As to my knowledge C (and derivatives like C++) is the only common language where the question "Is this a program?" has false positives. It is certainly an interesting choice.
- feelamee 10mo agoI mean that bug is *not in* uninitialized variable - bug in program logic. E.g. one of code pathes don't initialize variable. So, I see uninitialized variables as a good way to find such logic errors. And, therefore, advice to always initialize variable - bad practice. Of course if you already have a good value to initialize variable - do it. But if you have no - better leave it uninitialized. Moreover - this will not cause safety issues in production builds because you can use `-ftrivial-auto-var-init` to initialize automatic variables to e.g. zeroes (`-fhardened` will do this too)
- amelius 10mo agoMaybe an in-between solution could be a tool that substitutes auto in your code.
- pjmlp 10mo agoThat is like saying that one rather make fire with sticks and stones than with a lighter, because otherwise one would be lost when going out camping. IDEs are an invention from the late 1970's, early 1980's.
- gpderetta 10mo agoVery much true. On the other hand web based review interfaces seem to be stuck in the '60, when they could be so much better if they properly integrated with the compiler.
- pjmlp 10mo agoThe ones on Github with VSCode (Web) integration look quite good already.
- 1718627440 10mo agoI think IDEs are a moving target. Do you consider syntax highlighting to make something an IDE? Macro expansion? Autocomplete? intellisense-like based on full text search? based on a parser? based on the compiler? Is Kate an editor or an IDE? It has LSP support. Having syntax highlighting makes me slightly faster, but I want to still be able to understand things, when looking at a diff or working over SSH and using cat.
- pjmlp 10mo agoNope, that is a programmer's editor.
- 1718627440 10mo agoI agree, but that means, that even complete integration of the compiler does not make an IDE. So the only distinguishing feature I can think of is startup time /s .
- addaon 10mo ago
- xnorswap 10mo agoThe guidelines I follow for C# has "use var where it's obvious, but explicitly type when not". So for example I'd write: var x = new List<Foo>(); Because writing: List<Foo> x = new List<Foo>(); Feels very redundant Whereas I'd write: List<Foo> x = FooBarService.GetMyThings(); Because it's not obvious what the type is otherwise ( Some IDEs will overlay hint the type there though ). Although with newer language features you can also write: List<Foo> x = new(); Which is even better.
- tcfhgj 10mo agoI would rename `x` to `foos` and jump to the function/use IDE hints for the exact type when needed.
- Aeglaecia 10mo agoan interesting demarcation of subjective mental encapsulation ... associating the anonymous type of a buffer with the buffer's name ... as opposed to explicitly specifying the type of an anonymously named buffer
- Leherenn 10mo agoRight, although I would argue the most interesting part of the type here is the container, not the containee. With good naming it should be pretty obvious it's a Foo, and then either you know the type by heart, or will need to look up the definition anyway. With standard containers, you can have the assumption that everyone knows the type, at least high level. So knowing whether it's a list, a vector, a stack, a map or a multimap, ... is pretty useful and avoid a lookup.
- lan321 10mo agoI usually prefer List<Foo> x = new(); since it gives me better alignment and since it's not confused with dynamic. Nowadays I only use var x = new List<Foo>(); in non-merged code as a ghetto TODO if I'm considering base types/interface.
- binary132 10mo agoIt’s extremely convenient for certain things. For example, let’s say I’m referring to an enum constant field of a deeply-nested type. This can easily be expressed as “auto k = a.b.c.d.kind” instead of “Alpha::Bet::Charlie::Delta::Kinds k = a.b.c.d.kind”. It should be used sparingly in local contexts where the meaning cannot be confusing.