Overhead of const modifier for built-in types in C++

Question

I prefer to add const modifier to all built-in arguments in functions I write. E.g.:

void foo(const int arg1, const double arg2);

is better for me than:

void foo(int arg1, double arg2);

After code review I was told that const modifier brings an overhead when it is applied for integer and built-in types. Is that true and why?

Thanks,

Answer 1

It has no more overhead than a typedef does. Your coworker is wrong.

If you want to convince him, print out the disassembly of both variants, and show your coworker that they're the same.

However, adding the const qualifier to primitive types like this is utterly pointless and futile. They're copied anyway, and there's no harm in modifying them. There's nothing to be gained by making them const.

Answer 2

There's no overhead with const, I guess your coworkers are just confused with the use as it is (unfortunately) not so common. Personally I prefer to const as many local variables as possible since it increases readability.

Of course it's always easy to disprove, take the following program and compile with assembly output:

#include <stdio.h>

void foo1(int a, double b)
{
  printf("Not const %d, %g\n", a, b);
}

void foo2(const int a, const double b)
{
  printf("Const %d, %g\n", a, b);
}


int main()
{
  for(int i = 0; i < 10; ++i)
  {
    foo1(i, 5.5 * i);
    foo2(i, 12.8 * i);
  }
  return 0;
}

The assembly code generated for those functions is exactly the same (using VS2010 release-build):

For foo1 (without const-specifiers):

; 4    : {

push    ebp
mov     ebp, esp

; 5    :    printf("Not const %d, %g\n", a, b);

fld     QWORD PTR _b$[ebp]
sub     esp, 8
fstp    QWORD PTR [esp]
push    eax
push    OFFSET ??_C@_0BC@FACFPKBC@Not?5const?5?$CFd?0?5?$CFg?6?$AA@
call    DWORD PTR __imp__printf
add     esp, 16                 ; 00000010H

; 6    : }

For foo2 (with const-specifiers):

; 9    : {

push    ebp
mov     ebp, esp

; 10   :    printf("Const %d, %g\n", a, b);

fld     QWORD PTR _b$[ebp]
sub     esp, 8
fstp    QWORD PTR [esp]
push    eax
push    OFFSET ??_C@_0O@LOLEPDHC@Const?5?$CFd?0?5?$CFg?6?$AA@
call    DWORD PTR __imp__printf
add     esp, 16                 ; 00000010H

; 11   : }

Answer 3

That is not true.

Independent of that, you should not put const into the function declaration, since it is an implementation detail: it only qualifies the local variable in the function scope. So you can write it like this:

double foo(unsigned int a, double b);  // declaration

double foo(unsigned int const a, double b)  // implementation
{
    b *= a;
    return bar(b);   // silly example
}

Answer 4

After code review I was told that const modifier brings an overhead when it is applied for integer and built-in types. Is that true and why?

Who you gave your code to review it? A junior programmer?

The above is not true. Quite the contrary. Using const might apply some optimization.

Answer 5

It's not true.¹

Or, more precisely, I can't think of a reason why it could be true. All const does is force the compiler to check that you're not changing the value of the variable; but that's a compile-time check.

---

_{1. Assuming we're using the traditional definition of "overhead" that relates to runtime performance or compiled code size.}

Answer 6

No, that's not true.

I think you/they confused const with passing by reference.

Answer 7

What type of overhead do you mean? Overhead for compiled binary or overhead of compiler? I'm sure that compiled binary is identicall for the first and the second code samples you've added. For compiler - maybe. Const adds additional conditional, that must be checked in compile-time.

Answer 8

It can bring overhead, if it forces you to create an additional local variable.

Without const

void foo(const int arg1, double arg2)
{
    if (arg1 == 1)
        arg2 += 5.0;

    // use arg2
}

With const

void foo(const int arg1, const double arg2)
{
    double arg2Copy;
    if (arg1 == 1)
        arg2Copy = arg2 + 5.0;
    else
        arg2Copy = arg2;

    // use arg2Copy
}

But this really depends on the compiler. If you're concerned about the overhead, you should compare the generated code.