Take the 2-minute tour ×

I understand one of the big deals about constants is that you don't have to go through and update code where that constant is used all over the place. Thats great, but let's say you don't explicitly declare it as a constant. What benefit(s) exist(s) to take a variable that HAPPENS to actually not be changed and make it a constant, will this save on processing, and/or size of code...etc?

Basically I have a program that the compiler is saying that a particular variable is not changed and thus can be declared a constant, I just wanted to know what the benefit to adding the constant qualifier to it would be, if it makes no difference then making that change adds no value and thus no point wasting time (this same scenario occurs in more then one place) going back and "fixing" all these variables.

share|improve this question
A lot of good answers, thank you, I agree that by declaring them as constants there is the a benefit as far as development but I guess I'm thinking at runtime benefits, not necessarily compile time...if that makes sense. –  onaclov2000 Mar 26 '10 at 16:00
Runtime benefits would depend on the specific compiler and machine that the program is compiled and run on; the language describes how things should function, not how things are implemented. –  jball Mar 26 '10 at 16:10
Detection of errors at compile-time is far more important than any (minimal) benefits that might be realised at run-time. You can always make code run faster by buying faster hardware, but you cant make code correct that way. And if the code is not correct, there is no point in running it. –  anon Mar 26 '10 at 21:15

14 Answers 14

up vote 15 down vote accepted

If you declare a variable to be a constant, then the optimizer can often eliminate it via 'constant folding' and thus both speed up your program and save you space. As an example, consider this:

var int a = 5;
const int b = 7;
c = process(a*b);

The compiler will end up creating an instruction to multiply a by 7, and pass that to 'process', storing the results in c. However in this case:

const int a = 5;
const int b = 7;
c = process(a*b);

The compiler will simply pass 35 to process, and not even code the multiply. In addition, if the compiler knows that process has no side effects (ie, is a simple calculation) then it won't even call process. It will just set c to be the return value of process(35), saving you a function call.

share|improve this answer
Great answer, these are the kind of solutions I'm looking for, for example.. –  onaclov2000 Mar 26 '10 at 16:44

If you declare something as a constant, and then accidentally attempt to modify its value in your code, the compiler will tell you about your mistake. This form of static type checking is actually the main reason for using constants.

share|improve this answer
This is by far the most important reason for constants! The performance stuff is nice, but not more and also heavily depends on the compiler. But when parts of the code assume something always has the same value and it suddenly changes it might break the execution! So you decide what is more important the fact that under very specific circumstances code runs minimally faster or that code executes properly at all ;) –  ntziolis Mar 31 '11 at 11:38

A lot of this depends on how good your optimizer is.

A good optimizer will replace const references with literal values during compilation. This saves processor cycles since the generated machine code is working with immediate values instead of having to load a value from memory.

Some optimizers will recognize that a value is not modified after it is declared, and convert it to a constant for you. Do not rely on this behavior.

Also, whenever possible, your code should enforce the assumptions you've made during development. If a "variable" should never be changed, declaring it as a constant will help ensure that neither yourself nor any other developers that come along later will unwittingly modify a "constant".

share|improve this answer

Marking a variable as constant declares your intent as a programmer that this will be a consistent value whenever it's accessed during the execution of the code. Consider it a form of documentation that also causes the compiler to enfore your design.

share|improve this answer

As you point out, you may not gain any direct benefit from changing the unchanging variables into explicit constants. However, in analysing a program one check that is made is to look at the point of declaration of a variable to the point of reference of the variable. So metrics such as variables that are being accessed before declaration, or set and reset before reference etc can indicate probably bugs.

By explicitly declaring constants as constants the compiler and analysis tools know that you do not intend to reset the variable at any time.

This is also true for other developers that work with your code. They may inadvertently set a variable and you may not be aware of it. Declaring constants will avoid these types of errors.

share|improve this answer

It's possible that the compiler could reduce code size .. for example, in package System you'll find (on an x86 machine)

type Bit_Order is (High_Order_First, Low_Order_First);
Default_Bit_Order : constant Bit_Order := Low_Order_First;

so that given

case System.Default_Bit_Order is
   when System.High_Order_First =>
      --  Big-endian processing
   when System.Low_Order_First =>
      --  Little-endian processing
end case;

the compiler can completely eliminate the 'wrong' branch while your code retains its portability. With GNAT you need to use non-default optimisation for this to happen: -O2 I think.

Both branches have to be compilable -- this is an optimisation, not #ifdef processing.

share|improve this answer

One benefit is that if it is truly a constant value, you wouldn't accidentally change it. The constant keeps you from screwing stuff up later. As a variable, anyone could come along and change it later when updating the code.

It should be clear which values can never change and which values can change. Constants reinforce your intention.

Real world example from my youth:

We didn't have a built-in PI value on a system I was working on so someone created a VARIABLE called PI and somewhere along the way, someone (me) modified that value to 3.14519 (or something there abouts) in a procedure I wrote... not the approximation of pi 3.14159). It had been set elsewhere in the code, and all sorts of calculations were off from that point forward. Had that PI been a constant (it was changed later, of course), I wouldn't have been able to make that error... at least not easily.

share|improve this answer
I agree wholeheartedly with your statement, and I see the benefit in that respect, I was just thinking more on the lines of the actual running of the code when I asked the question. –  onaclov2000 Mar 26 '10 at 16:07

In addition to whatever has been already said, declaring the variable as a constant gives more freedom for the optimizer. It can eliminate reading its values, it can eliminate need to create a temporary copy, it can eliminate the variable itself (this is especially true for the numeric constants).

Another big use case for the constants is constant objects. Having a constant object (or giving away a reference to a constant object in a function) you can be sure your object is not modified, and only methods (called const methods) of that object are allowed to be called. This is however true for C++, I am not sure if the same concept is valid in Ada as well.

share|improve this answer

Another possibility, depending on the language, is that the compiler may be able to do some optimizations in a multi-threading environment that would not otherwise be possible. Like if you say:

int b=x*f;
int c=y*f;

In a multi-threaded environment, if f is a variable, the compiler may have to generate a reload of f before the second operation. If f is a constant and the compiler knows it's still in the register, it wouldn't need to reload.

share|improve this answer

Certainly for a language like C and Ada, the compiler will put the value from the constant directly into the assembler instruction, meaning that no swapping of registers or reading from memory will be necessary over and above what is required to run the program. This means two things: the main one is speed (probably not so noticeably in many applications, unless they are embedded) and the second is memory usage (of both the program's final binary size and its runtime memory footprint).

This behaviour will come down to the language and the compiler, as the language will dictate any assumptions made by you (the programmer) and therefore the constraints to the efficiency of the language; and the compiler because its behaviour could change from treating your constant like any other variable to pre-processing your code and optimising the binary speed and footprint as much as possible.

Secondly, as was stated by itsmatt and jball, it enables you to logically consider the item as a constant configuration item rather than a 'variable'; especially in higher level programming languages and interpreted languages.

share|improve this answer

There is another benefit, stack and data segment sizes.


function Recurser(i : Integer) return Integer is
  ia : array(0..9) of Integer
          := (1, 2, 3, 4, 5, 6, 7, 8, 9, 1000);
  r : Integer;
   if i = 0 then return 0; end if;
   r := ia(i mod 10);
   return r + Recurser(i - 1);

Every time that function recurses you create a 320 byte structure on the Stack. But since the value of a doesn't change the stack is increasing to hold a variable that is constant. This can be very important on embedded platforms with small stacks.

Package level variables also increase the size of the data segment. Pushing up your memory requirements.

share|improve this answer

This isn't really an Ada-specific question.

The general benifits of constants over variables:

  • Prevents code errors from "constant" accidentally getting modified.
  • Informs the compiler that it can assume the value will not change when optimizing.

Ada specific benifits:

  • For numeric constants, you don't have to specify a type (named numbers). If you declare it this way, it will be usable in any expression for that kind of number. If you use a variable instead, it can only be used in expressions of that variable's exact type.


Seconds_Per_Minute : constant := 60;
Secs_Per_Min       : Integer  := 60;

type Seconds_Offset is 0 .. Integer'last; --'

Min1, Secs1 : Integer;
Min2, Secs2 : Seconds_Offset;

--// Using the named number, both of these compile no problem.
Secs1 := Min1 * Seconds_Per_Minute;
Secs2 :=  Min2 * Seconds_Per_Minute;

--// The second line here gives an error, since Integer is a 
--// different type than Seconds_Offset.
Secs1 := Min1 * Secs_Per_Min;
Secs2 := Min2 * Secs_Per_Min;
share|improve this answer
Errm, since Positive is a subtype of Integer there is no error here; and I think you meant to divide rather than multiply! –  Simon Wright Mar 27 '10 at 11:39
@Simon - Wow, good catches. I guess my streak of written Ada code without a compiler error remains, as always, at 0. Reworked to show what I intended (I hope). –  T.E.D. Mar 29 '10 at 13:00
Well I am still learning Ada, but that's very interesting you can create a constant variable without a type....I didn't know that! –  onaclov2000 Aug 27 '10 at 3:35

Constants are usually stored in Read Only Memory, which prevents changing them during the execution and accessing them might be faster, or at least as fast as accessing RAM.

share|improve this answer
I suppose this is dependent on the system that this particular program is being loaded to, I'm not sure about this, but looks interesting, I'll look into it on my side. –  onaclov2000 Mar 26 '10 at 16:02

Constants are immutable values which are known at compile time and do not change for the life of the program.

Constants differ from variables in one significant way in that once a value has been assigned to a constant it cannot subsequently be changed.

At runtime you can be sure that the value defined in a constant won't change and consequently your program won't break.

share|improve this answer

Your Answer


