• 0

[C++] Coding style of const local variables


Question

I've been wondering about this recently (and haven't been able to find any good resources online).

Would you make local variables that should not (or do not) change const?

From following several other projects they always seem to leave them non-const.

But I thought it is a fairly good documentation tool to make them const, although it does clutter up the code somewhat, especially if you have something like "int const * p;".

This is more of a style question, so I don't care if there are or are not any performance improvements.

22 answers to this question

Recommended Posts

  • 0

As far as an online resource: stackoverflow.com. All the gurus and professional developers answer questions there. I wouldn't be where I was if it wasn't for them. I've done very little C++ but that's because I'm caught up with PHP at this point in time...

I would like to try to answer your question but I recommend you visit the link instead if you'd like to get a thorough answer.

  • 0
  On 09/04/2011 at 13:56, Lant said:

Would you make local variables that should not (or do not) change const?

If a value does not change, then I usually declare it as a static const or a preprocessor symbol. If the variable should not change because of program logic, for instance, passing a variable to a function that doesn't have permission to change it, then a simple constant qualifier is sufficient.

  On 09/04/2011 at 13:56, Lant said:

From following several other projects they always seem to leave them non-const.

But I thought it is a fairly good documentation tool to make them const, although it does clutter up the code somewhat, especially if you have something like "int const * p;".

It certainly makes code more readable, manageable, and helps to isolate logic and behavioural errors.

  On 09/04/2011 at 13:56, Lant said:

This is more of a style question, so I don't care if there are or are not any performance improvements.

It's not merely a question of style. because a constant qualifier determines how a variable can be used. It's also self documenting, prevents unexpected behaviour, and allows the compiler to perform additional optimisations.

  • 0
  On 09/04/2011 at 13:59, surrealvortex said:

No point really. I would rather include a clear comment indicating that the value should not change.

Yes, but why include a comment when it can be ignored later on when you can add a const that will be enforced by the compiler?

  • 0
  On 09/04/2011 at 14:12, Flawed said:

If a value does not change, then I usually declare it as a static const or a preprocessor symbol. If the variable should not change because of program logic, for instance, passing a variable to a function that doesn't have permission to change it, then a simple constant qualifier is sufficient.

I'm talking about local variables inside functions here, not class level or global constants.

Plenty of my code is like the following:


bool x(C c)
{
std::vector<int> v = c.fn();
int i = c.fn2();


if ( std::find(v.begin(), v.end(), i) != v.end() )
...

return ;
}
[/CODE]

If v and i was never going to be modified by the rest of the function should I make them const?

Edited by Lant
  • 0
  On 09/04/2011 at 13:59, surrealvortex said:

No point really. I would rather include a clear comment indicating that the value should not change.

And permit behaviour that defies the design of the program? You're inviting problems if you follow that path. Let the code document itself, and at the same time prevent unexpected behaviour; it's far easier to debug and certify your application this way.

  • 0
  On 09/04/2011 at 14:19, Lant said:

I'm talking about local variables inside functions here, not class level or global constants.

Plenty of my code is like the following:


bool x(C c)
{
std::vector<int> v = c.fn();
int i = c.fn2();


if ( std::find(v.begin(), v.end(), i) != v.end() )
...

return ;
}
[/CODE]

If v and i was never going to be modified by the rest of the function should I make them const?

For instance in boost\date_time\src\gregorian\greg_month.cpp

[CODE]
special_values special_value_from_string(const std::string& s) {
short i = date_time::find_match(special_value_names,
special_value_names,
date_time::NumSpecialValues,
s);
if(i >= date_time::NumSpecialValues) { // match not found
return not_special;
}
else {
return static_cast<special_values>(i);
}
}
[/CODE]

The i is never changed, but it is not declared const.

This is from boost sources, and they use fairly up-to-date coding methods and styles.

So why don't they do it?

[b]I don't think in that example i is a constant. Simple as that.[/b]

Imagine if they call date_time::find_match() again within the program. If the i variable was a constant and date_time::find_match() returned a different value, the i variable would change and the program would throw a runtime error

Also, from: Stackoverflow.com

  Quote

In general, I think it's always a good idea to make your intentions clear this way, for a number of reasons:

It's easier to understand what you meant when you wrote it.

It's easier for others to reason about your code when they read it.

It's easier for the compiler to make inferences about what you want to do.

It's easier for the compiler to prevent logical errors.

Making variables constant is a perfectly legitimate way to accomplish all of the above, in the specific case of intending "I don't want this variable to change its value".

(This is why I love stack overflow, they just find the right words to explain which I'm bad at) :)

In short, it is strongly suggested you make the int a constant if the integer will not change throughout the program.

  • 0
  On 09/04/2011 at 14:19, Lant said:

I'm talking about local variables inside functions here, not class level or global constants.

Plenty of my code is like the following:


bool x(C c)
{
std::vector<int> v = c.fn();
int i = c.fn2();


if ( std::find(v.begin(), v.end(), i) != v.end() )
...

return ;
}
[/CODE]

If v and i was never going to be modified by the rest of the function should I make them const?

Why not write it as:

[CODE]
bool x(C c)
{
std::vector<int> v = c.fn();
if ( std::find(v.begin(), v.end(), c.fn2()) != v.end() )
...

return ;
}
[/CODE]

But if you insist on doing it that way, no I don't see a need to define it as a constant in the function. The const qualifier is most beneficial when two modules are interacting, or to prevent some unexpected behaviour. Use of it in a local function as in your example is unnecessary. There are cases though where you might want to define a static local constant for a function; for instance, in order to encapsulate/hide the details of it if it's specific to that function, or perhaps if a function returns a constant pointer, but for simple temporary values on the stack, there isn't much point.

  • 0
  On 09/04/2011 at 14:34, Flawed said:

Why not write it as:


bool x(C c)
{
std::vector<int> v = c.fn();
if ( std::find(v.begin(), v.end(), c.fn2()) != v.end() )
...

return ;
}
[/CODE]

But if you insist on doing it that way, no I don't see a need to define it as a constant in the function. The const qualifier is most beneficial when two modules are interacting, or to prevent some unexpected behaviour. Use of it in a local function as in your example is unnecessary. There are cases though where you might want to define a static local constant for a function; for instance, in order to encapsulate/hide the details of it if it's specific to that function, or perhaps if a function returns a constant pointer, but for simple temporary values on the stack, there isn't much point.

I disagree with this. For the same reasons I had posted in my reply above Flawed's post.

  • 0
  On 09/04/2011 at 14:25, Tekkerson said:

I don't think in that example i is a constant. Simple as that.

Imagine if they call date_time::find_match() again within the program. If the i variable was a constant and date_time::find_match() returned a different value, the i variable would change and the program would throw a runtime error

It could be declared "const short i" and it would all be perfectly fine until the static_cast which would probably cause a compile error as the cast is trying to remove constness. (I realised it was a bad example so I removed it)

But it wouldn't throw a runtime error.

  • 0
  On 09/04/2011 at 14:25, Tekkerson said:

In short, it is strongly suggested you make the int a constant if the integer will not change throughout the program.

I agree with "throughout the program", or even:

void my_func() {
static const int my_func_number = 12345;
/* do some work */
}

But for temporary local function variables, I don't really see a justification in general, and certainly not in the example code provided by the OP.

  • 0
  On 09/04/2011 at 14:44, Lant said:

It could be declared "const short i" and it would all be perfectly fine until the static_cast which would probably cause a compile error as the cast is trying to remove constness. (I realised it was a bad example so I removed it)

But it wouldn't throw a runtime error.

You know, that's funny at first I typed compile then I edited it to runtime... (thought processes got mixed up or something)

  • 0
  On 09/04/2011 at 14:45, Flawed said:

I agree with "throughout the program", or even:

void my_func() {
static const int my_func_number = 12345;
/* do some work */
}

But for temporary local function variables, I don't really see a justification in general, and certainly not in the example code provided by the OP.

If it's a constant, it should always be declared constant no matter where it is. What if for some reason you changed something in the code that made the variable change when it wasn't supposed to? It's just a good coding practice. But that's for the OP to decide.

  • 0
  On 09/04/2011 at 14:41, Tekkerson said:

I disagree with this. For the same reasons I had posted in my reply above Flawed's post.

That was talking in general, and I do agree with those principles as can be seen by my original post, but in general, temporary local function variables aren't likely to be const targets.

Edit: Removed my unnecessary sarcasm.

  • 0

My code is already littered with BOOST_STATIC_CONSTANTs,

what I was really after is if the documentation value of declaring local variables (mostly stl containers) const is worth it over the readability loss of adding const.

I suppose its just one of those things in C++ that there is no real answer either way

  • 0
  On 09/04/2011 at 14:53, Tekkerson said:

If it's a constant, it should always be declared constant no matter where it is. What if for some reason you changed something in the code that made the variable change when it wasn't supposed to? It's just a good coding practice. But that's for the OP to decide.

I agree in general with your logic, but you have to ask the question, why is that variable a constant? We are speculating without knowing the actual case. At first glance, I wouldn't declare it as a constant, but that's just me. Perhaps you are right.

  • 0
  On 09/04/2011 at 14:57, Flawed said:

That was talking in general, and I do agree with those principles as can be seen by my original post, but in general, temporary local function variables aren't likely to be const targets.

I do have another thing to add though. Even with Flawed's point, even in the smallest cases I just think it's a good habit to do it where it applies, Lant.

Though, in the end I think this is more of a personal question. It boils down to:

Would you prefer cleanliness/convenience (less declarations) over "correctness" (which also has it's benefits)? Which is what I think sums up both me and Flawed's point.

Edit: To fit with Flawed's edits. :p

  • 0
  On 09/04/2011 at 14:58, Lant said:

My code is already littered with BOOST_STATIC_CONSTANTs,

what I was really after is if the documentation value of declaring local variables (mostly stl containers) const is worth it over the readability loss of adding const.

I suppose its just one of those things in C++ that there is no real answer either way

It's the same in C as well. While I agree with most of what Tekkerson's said, in practise, I rarely use const qualifiers in my own code in temporary local function variables. The occasions when I do are, if I want to declare a static const value to be used only for that function only, or if another function returns a pointer value that is immutable.

Though now I think about it, Tekkerson's arguments are compelling. So if you find it makes your code more readable, manageable, and prevents program logic / behavioural errors, then go for it.

  • 0

I only use const where the language forces me to, for example:

void myFunction(const std::string&amp; arg); // const must be used to allow the following usage:
myFunction("String literal");

Having successfully developed applications in Python, where there is no equivalent of the C++ const keyword, I don't believe const adds enough value to be worth having to constantly (no pun intended) worry about it. I just put constants in ALL_CAPS and I never declare const methods.

  • 0
  On 09/04/2011 at 14:22, Flawed said:

And permit behaviour that defies the design of the program? You're inviting problems if you follow that path. Let the code document itself, and at the same time prevent unexpected behaviour; it's far easier to debug and certify your application this way.

Const variables can be modified indirectly. It is not foolproof.

I can see where you are coming from. The code definitely will document itself that way, but when I suggested adding a comment, I meant a detailed comment explaining the intention. Not something like: /*This is a const*/

  • 0
  On 09/04/2011 at 18:17, surrealvortex said:

Const variables can be modified indirectly. It is not foolproof.

I can see where you are coming from. The code definitely will document itself that way, but when I suggested adding a comment, I meant a detailed comment explaining the intention. Not something like: /*This is a const*/

I would discard what I said there. I misunderstood the original question, and that comment was aimed at function parameters and class/global scope variables. Nevertheless, I agree with what you are saying. A terse comment can help explain the variable's purpose and/or why it's immutable if it's not already self explanatory. Personally, I haven't really felt the need to use constant qualifiers at the function scope level except in the special circumstances I outlined previously, but I suppose as long as the code is readily readable, then either way would work.

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Posts

    • Movavi Video Editor 25.9.0 by Razvan Serea With Movavi Video Editor, you can either enhance your video files with two or three simple steps, or turn them into something completely new. Create your own movies using multiple filters, transitions, and special effects: show multiple videos on one screen with the Picture in picture effect or change the background with the Chroma Key effect, imitate the camera zoom or make your video look like an old-style movie. Adjust video parameters such as brightness, contrast and colors. Stabilize shaky footage, improve video quality and remove defects. Create video presentations, tutorials or educational videos: add titles and record your own narration to create a video with voiceover. Import video from any source: TV-tuner, webcam, camcorder, or VHS. Drop multiple media files onto a timeline and let your imagination do the rest! Features at a glance: Video and audio editing on a timeline Edit, enhance videos Add background music Apply titles and effects Image quality improvement Hollywood-worthy effects High-grade titles and fades Digitize VHS tapes, record video from TV tuners Stabilize any shaky sections Support for a wide range of formats Prepare your videos for uploading to YouTube, Facebook, Vimeo, or any other website New in Movavi Video Editor 2025: Revamped timeline for easier editing The new timeline is now clearer and more streamlined. Get your projects done faster and have more fun with anything – from short vids for socials to longer family movies. Frame-precise cuts in a click Give your videos a sharper look with the new Blade tool. Easily make precise cuts and create eye-catching montages like your favorite bloggers. Pro-quality color correction Get next-level color correction with the same simplicity. Boost colors in a snap and make more viewers fall in love with your videos. AI motion tracking Enhance reality in your videos with additional moving graphics. Just click, and AI will quickly attach any photos, videos, emojis, or memes to objects in your footage. Perfect-match overlay effects Now each overlay effect has 13 blending modes to choose from. Try each of them with the press of a button and pick the one that fits your video perfectly. Best video effects – at your fingertips Create awesome videos in any style with our huge collection of professionally designed effects. Now you can try them all right away, right in the app. Movavi Video Editor 25.9.0 changelog: New Copy effects from one clip to another in a snap. Just right-click the clip → Clip effects → Copy effects. Then right-click again to paste. Try it once, and it might just become your new favorite feature. Improvements Enjoy speedier, smoother previews – now up to 20% faster! Hover over any clip to see the difference. Especially handy when you’ve got a load of clips on the timeline. Speed up editing with new keyboard shortcuts. Ctrl + Z to undo, Ctrl + scroll to zoom the timeline. You’ll find the full list in the Help menu. Fixed issues Some under-the-hood improvements that’ll be useful for faster content creation. Download: Movavi Video Editor Plus 25.9.0 | 5.1 MB (Shareware) View: Movavi Video Editor Plus Website | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
    • I don't disagree, but I am also not absolving Microsoft. Data protection is the user's responsibility AND OneDrive shouldn't arbitrarily lockout paying users with no way to get support. Again, both statements can be true at the same time. I doubt you mean to imply it is okay for companies to violate their SLAs and screw over their customers. Assuming you don't think that, then we have no disagreement my friend.
    • Also, Microsoft locks Windows 11 user out, shows how easy losing data from forced encryption is The reddit post has nothing to do with Windows 11 or 'Forced' Encryption, at all, reading the thread a guy has uploaded a load of files, deleted the source, tripped the ToS for some reason and been locked out The guy could have been using Windows 7 box with no drive encryption. A more accurate headline would be User with no backup looses data
    • I've been using Microsoft cloud storage since before it was named OneDrive. Though typically only upload the following items. Game Screenshots of like crashes if its a driving game, or occasionally a Video recorded with GameDVR All Purchased Music from former Microsoft App store when they offered music during Windows 8.1, Xbox/Groove Music days, in additon to the 30 Free Albums Christmas 2024 for using a Windows Phone at the time. Of course everything is also backed up on 3 external hard drives as well. and albums that would be hard to replace, also uploaded to GoogleDrive, ((though can't upload all of it to Google drive, as not enough space there to lol)) Been using Microsoft Hotmail & Outlook email ever since first released Hotmail originally signed up April 1998 during high school class Outlook.com email converted to when first launched many years ago
  • Recent Achievements

    • Week One Done
      Rhydderch earned a badge
      Week One Done
    • Experienced
      dismuter went up a rank
      Experienced
    • One Month Later
      mevinyavin earned a badge
      One Month Later
    • Week One Done
      rozermack875 earned a badge
      Week One Done
    • Week One Done
      oneworldtechnologies earned a badge
      Week One Done
  • Popular Contributors

    1. 1
      +primortal
      699
    2. 2
      ATLien_0
      272
    3. 3
      Michael Scrip
      214
    4. 4
      +FloatingFatMan
      186
    5. 5
      Steven P.
      144
  • Tell a friend

    Love Neowin? Tell a friend!