"const int" or "int const" ?
-
Both the following are valid C++ and have the same meaning:
const int i = 0;
int const j = 0;The first style is widely used, and everyone will recognise and understand it. The second style is not so immediately understandable to most developers. However, always putting the
constqualifier immediately to the right of what it qualifies can prevent some esoteric bugs. There's a brief discussion of why, with examples, here[^], in the section titled Avoiding confusion by using a good programming style. I only found a few other examples when I searched a few weeks ago, so it's safe to assume the second method is not widely known. In your opinion, is the safer, but less well-known and understood style "better" than the widely-used one, or not? For what it's worth, I think the safer style is "better", but obviously changing such a deeply engrained style across a development team or organisation is likely to prove difficult. Gavin Greig "Haw, you're no deid," girned Charon. "Get aff ma boat or ah'll report ye." Matthew Fitt - The Hoose O Haivers: The Twelve Trauchles O Heracles. -
Both the following are valid C++ and have the same meaning:
const int i = 0;
int const j = 0;The first style is widely used, and everyone will recognise and understand it. The second style is not so immediately understandable to most developers. However, always putting the
constqualifier immediately to the right of what it qualifies can prevent some esoteric bugs. There's a brief discussion of why, with examples, here[^], in the section titled Avoiding confusion by using a good programming style. I only found a few other examples when I searched a few weeks ago, so it's safe to assume the second method is not widely known. In your opinion, is the safer, but less well-known and understood style "better" than the widely-used one, or not? For what it's worth, I think the safer style is "better", but obviously changing such a deeply engrained style across a development team or organisation is likely to prove difficult. Gavin Greig "Haw, you're no deid," girned Charon. "Get aff ma boat or ah'll report ye." Matthew Fitt - The Hoose O Haivers: The Twelve Trauchles O Heracles."const int" and "int const" are absolutely identical in meaning. I've literally never seen "int const" outside of reference books and web pages. The "avoiding confusion" section in the quoted page is actually about programming style, which is a highly personal issue. --Mike-- Latest blog entry: *drool* (Alyson) [May 10] Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber "You have Erica on the brain" - Jon Sagara to me
-
"const int" and "int const" are absolutely identical in meaning. I've literally never seen "int const" outside of reference books and web pages. The "avoiding confusion" section in the quoted page is actually about programming style, which is a highly personal issue. --Mike-- Latest blog entry: *drool* (Alyson) [May 10] Ericahist | Homepage | RightClick-Encrypt | 1ClickPicGrabber "You have Erica on the brain" - Jon Sagara to me
Maybe my examples weren't best chosen. As the article I referred to points out, the position of the
constqualifier can become significant when you introduce a pointer or reference. So although "const int" and "int const" are identical, "const int*" and "int* const" are not. The first is a pointer to a const int, while the second is a const pointer to a non-const int. Of course, you might not make this error if you separate the pointer from the type, because "const int *" and "int const *" are also identical in meaning. Thinking in terms of always putting const to the right of what you are making const would help to avoid this sort of confusion. Now, if you are using typedefs, it can be more confusing still:typedef int * PINT;
typedef const PINT CPINT; // const pointer to int
typedef const int * PCINT; // pointer to const intIt might be "reasonable" to expect, when attempting to understand line 2 that the type defined in line 3 would be identical, because all we've done is substitute "int *" for the typedef PINT - but the result is not the same. However, if you adopt the "const to the right" convention, then making that direct substitution does work:
typedef int * PINT;
typedef PINT const CPINT; // const pointer to int
typedef int * const CPINT; // const pointer to intOf course, you could say that you'll never write such a typedef, but the typedef could be created by someone else within a template - Loki makes use of typedefs in its Typelists, for example - and if you're not using the "const to the right" convention then it will be harder to understand and debug any resulting issues. So yes, it is a style issue, but there is at least one specific circumstance in which it will commonly lead to an incorrect understanding of the way C++ works, and poor understanding leads directly to bugs. What I was really hoping for were some opinions as to whether an improvement in long term understandability of code justified the short term confusion that would be inevitable by overturning a long-standing convention? Reference: "C++ Templates - The Complete Guide", David Vandevoorde and Niccolai Josuttis. There is also a short article (c.1998), available somewhere online, which seems to have been the first to raise this issue, but unfortunately I haven't managed to find it again to provide a link. Gavin Greig "Haw, you're no deid," girned Charon. "Get aff ma boat or ah'll report ye." M