Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Const Doesn't Make C Code Faster

theartofmachinery.com

Post reply on HN
Print view View original

71–80 of 197 posts

Re: Why Const Doesn't Make C Code Faster

#71

Post by Jach »

wnevets wrote: post #11
xhkkffbf wrote: post #8

I've worked with JavaScript weenies who are in love with the const declaration. They don't have an answer, though, when I ask, "Shouldn't the compiler be able to notice that a variable isn't changed in it's lifetime?" Most of the const values are just local and never leave the function but the weenies continue to stomp their feet when I use "var". The compilers are smart. Let them do their thing.

const doesn't actually stop data from changing, just reassignment. const user = {id: 1, status: 'active'}; user.status = 'disabled'; is valid javascript

I've wondered why the JS people didn't call their keyword for this purpose "final" like Java did.

Re: Why Const Doesn't Make C Code Faster

#72

Post by haberman »

> So, what’s const for? For all its flaws, C/C++ const is still useful for type safety.

Const variables can also be mapped read-only. This gives you hardware protection against modifications, and also uses less RAM if the const variable is in a shared library (multiple processes can share the same mappings).

Re: Why Const Doesn't Make C Code Faster

#73

Post by jasonzemos »

I wish there was a C++ compiler flag which made everything const by default and required the mutable keyword otherwise. This is obviously non-standard and would break included headers, but alternatively a #pragma could scope that option for project code coming after non-project includes.

Re: Why Const Doesn't Make C Code Faster

#74

Post by jsd1982 »

mrpippy wrote: post #41

On some microcontrollers, marking variables/arrays as const allows the compiler to access them directly from flash rather than having to copy them into RAM at startup. I used this to great effect on a PIC24 with 256KB flash/16KB RAM.

Though this becomes incredibly annoying using const pointers when you didn't mean to refer to ROM but instead meant a read-only pointer to RAM.

Re: Why Const Doesn't Make C Code Faster

#75

Post by MauranKilom »

not2b wrote: post #18

Unfortunately in C++, the compiler is not allowed to assume that if it passes a const reference to a function, that function will not change the object. The function is allowed to cast away const and modify the object. I'm not happy that they did it that way; I would have preferred it if cast-away-const were more restricted (for example, allowed when calling a child function that takes a char* but doesn't modify the…

> The function is allowed to cast away const and modify the object.

Correct, but only if the original (referenced) object is not const itself. Casting away constness to modify an object that was declared const is 100% UB.

Re: Why Const Doesn't Make C Code Faster

#76

Post by Someone » 

  // x is just a read-only pointer to something that may or may not be a constant
  void constFunc(const int *x)
Is that correct? I read that as “x is a pointer to a const int”

If you want “x is a read-only pointer to an int”, you would need

  void constFunc(int * const x)
The article also doesn’t mention the case “x is a read-only pointer to a constant int”. To state that, you would use

  void constFunc(const int * const x)
(https://stackoverflow.com/a/1143272)

Re: Why Const Doesn't Make C Code Faster

#77

Post by Kranar »

worik wrote: post #60
not2b wrote: post #18

Unfortunately in C++, the compiler is not allowed to assume that if it passes a const reference to a function, that function will not change the object. The function is allowed to cast away const and modify the object. I'm not happy that they did it that way; I would have preferred it if cast-away-const were more restricted (for example, allowed when calling a child function that takes a char* but doesn't modify the…

Cast away const. One of the many reasons I gave up on C++. What is const if it can be cast away?

const should have been renamed to readonly, because that's what it means. It means that a variable only has readonly access to a value, but it is possible that another variable has write permissions, and so a compiler can not assume that just because one variable has readonly permission, that all variables have readonly permission except for in very limited circumstances.

Re: Why Const Doesn't Make C Code Faster

#78

Post by WalterBright »

MaximumYComb wrote: post #70
WalterBright wrote: post #66

Earlier quoted context omitted.

Here's another failure of marketing on my part. We included full library source with the compiler, for free. No reviewer ever noticed that. One day, Borland decided to make source code for their library, sans the floating point stuff, available for an extra charge. This generated headlines in the next compiler roundup article. No mention that complete library source code, including floating point, came with my compil…

By attaching a price to it, did people assume it was higher quality?

At the time, people assigned no value to bundled things. Most did not appear to be aware it was even there.

With it being packaged separately, people noticed its existence, and did assign value to it commensurate with its price.

It was attractively priced, and almost everyone buying the compiler also bought the library source.

Re: Why Const Doesn't Make C Code Faster

#79

Post by MauranKilom »

jcelerier wrote: post #55
not2b wrote: post #18

Unfortunately in C++, the compiler is not allowed to assume that if it passes a const reference to a function, that function will not change the object. The function is allowed to cast away const and modify the object. I'm not happy that they did it that way; I would have preferred it if cast-away-const were more restricted (for example, allowed when calling a child function that takes a char* but doesn't modify the…

> Unfortunately in C++, the compiler is not allowed to assume that if it passes a const reference to a function, that function will not change the object. how could it make that assumption ? there is nothing that prevents you to implement the function in fortran or even in raw assembly

You have it backwards. const is your promise to the compiler that the object won't change. It doesn't care whether you const_cast, implement the function in fortran or use raw assembly to mess with that object - it assumes that you don't. If you modify a const object in any way you have violated the C++ standard and get UB in return.

Now, the tricky part is that const objects (i.e. objects declared as const) enjoy these optimization benefits, but the compiler usually cannot prove that a reference or pointer to const actually refers/points to a const object. Taking a const pointer to a non-const object, casting away the constness again and then modifying the object is totally legal.

Since the former case (objects declared const) is much rarer than the latter case (working on const object pointers/references) the compiler cannot often optimize based on const.

Re: Why Const Doesn't Make C Code Faster

#80

Post by MauranKilom »

jforberg wrote: post #65
kmadento wrote: post #29

Shouldn't the test instead be: const int * const Haven't profiled it but would make more sense to have the pointer also be const instead of having a non const pointer as input?

It rarely makes sense. Pointer to const is a contact between caller and callee. A signature like char strdup(const char ) says "I take a pointer to memory that I promise not to modify, and you get a pointer to memory that you may modify". Const pointer is a statement about the internal variables of a function definition, usually not of any interest outside the function itself and therefore rarely used.

> Const pointer is a statement about the internal variables of a function definition, usually not of any interest outside the function itself and therefore rarely used.

...and in fact not even part of the name mangling (for the exact reason you mentioned): https://godbolt.org/z/1pjecq

Post reply on HN