0

The topic basically says it all. I'm following a tutorial where it says type const &value, but visual studio keeps automatically correcting it to type const& value.

Is there a difference?

Is there a convention?

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
M. Doe
  • 301
  • 1
  • 4
  • 6
  • There are also `const type& value` and `const type &value`. – Pete Becker Mar 11 '20 at 18:43
  • 7
    No difference whatsoever. – HolyBlackCat Mar 11 '20 at 18:43
  • 1
    https://stackoverflow.com/questions/22766907/whats-the-semantically-accurate-position-for-the-ampersand-in-c-references – Mat Mar 11 '20 at 18:44
  • You can also write `type const & value`, or put each token on a separate line if you like. – Mat Mar 11 '20 at 18:46
  • @M. Doe By default Visual Studio uses a bad code formatting suggested by Stroustrup. – Vlad from Moscow Mar 11 '20 at 18:48
  • Normally VS's code formatting is very configurable, but I can't find an option for this. But then I noticed my version never tries to format the spacing in types. What version are you using? – François Andrieux Mar 11 '20 at 18:50
  • The nice thing about standards is that there are so many to choose from. – Deduplicator Mar 11 '20 at 18:50
  • @Deduplicator I think you mean convention. It's actually important that we all agree on the same standard. – François Andrieux Mar 11 '20 at 18:51
  • Does this answer your question? [What is the difference between const int\*, const int \* const, and int const \*?](https://stackoverflow.com/questions/1143262/what-is-the-difference-between-const-int-const-int-const-and-int-const) – pablo285 Mar 11 '20 at 18:52
  • @FrançoisAndrieux Convention, standard, both work there. – Deduplicator Mar 11 '20 at 18:52
  • Its simply a style thing. You can't say one is more correct than the other. So would argue that placing the '&` with the type (like Cis studio is doing) is more C++ like and that putting it with the variable is more C like. – Martin York Mar 11 '20 at 18:54
  • @M. Doe You have a choice between two styles: a bad style introduced by Stroustrup that contradicts the C and C++ grammar and a better style that gives a knowledge what is declarator in C and C++. For example you may write type const ( &value ); but you may not write ( type const & ) value; – Vlad from Moscow Mar 11 '20 at 18:56
  • @Deduplicator A standard is a universally agreed norm. No style guide is universally adopted. Standard and convention are not at all equivalent. – François Andrieux Mar 11 '20 at 18:57
  • There is no difference. There is a convention, in this case I'd call it the Visual Studio convention, which prefers the `&` be positioned with no space before and has a space after. Should you follow the convention? If so, you're golden. If not, then you might have to delve into Visual Studio's configuration options. – Eljay Mar 11 '20 at 19:41

1 Answers1

2

The way that C++ Parses tokens stipulates that these two statements will be treated equivalently, and there is no difference in the code that will be generated.

As to why MSVC keeps autocorrecting to the other, I really don't think it should, but my guess for why it does is that MSVC is helping you keep your code consistent (which is important!), and it is assuming that the way you want the code to look is in this format: type const& name.

This format is more recognizably C++, whereas the other method, type const &name is more C-like (despite the fact that C doesn't have references; but it does have pointers, and a similar declaration type const *name would be more obviously C as well), and MSVC wants to enforce the C++ style.

But again; there's no functional difference between them. Both are valid, both will compile, and both will have the same behavior.

Xirema
  • 19,889
  • 4
  • 32
  • 68
  • 1
    It's worth noting that all of the automatic formatting rules, including when to and when not to format, are configured in Tools->Options...->Text Editor->C/C++->Formatting. – François Andrieux Mar 11 '20 at 19:45
  • 1
    The "recognizably C++" is more accurately "recognizably C++ according to some". Yes, some big names (like Stroustrup) advocate it, but there are differing views. This style breaks if the same formatting is used to declare more than one variable, e.g. `type* a, b;` where `a` is a pointer and `b` is not, but the formatting suggests both are pointers. Additional rules are then needed that would otherwise be unnecessary like "don't write declarations of multiple variables", which makes things even uglier (absurd to need a stylistic rule mostly to deal with a deficiency in another stylistic rule). – Peter Mar 11 '20 at 21:03