quote:Original post by Anonymous Poster
SabreMan:
"First off - const correctness."
Const correctness doesn''t allow you to optomize at all..
Yes it does, albeit only rarely. "ROMable" PODs can have better code generated.
quote:actually.. the opposite. Check out my function and try to replace it with a "const correct" function and see how much optomization it gives you.
By saying that String is to be constant, you are forcing yourself to create at least 1 variable to point or to count with.
Not at all. For a NTCS, at the very least you should pass a const char*. This copies the pointer, but ensures that it''s a pointer to const char. You don''t have to create another variable to point, you use the one passed by value, but you ensure you can''t accidentally modify the characters of the string.
quote:You could make this a static variable so it''s only created once.. but then you just wasted 4 bytes of memory and an assignment (the assignment per call). Const does help in some readability I guess, but don''t say that it can help optomize, because... well.. there is NOTHING you can''t do with a normal pointer that you can do with a const pointer,
On the contrary. The pointer to a const variable can point to ROM or otherwise read-only memory.
Why is this of consequence?
If you declare the function as taking const char*, you can pass any string -- including ones from, for instance, std::string::c_str(), and strings that are pooled in read-only memory (as most optimizing compilers will do) -- strings where you''re not allowed to modify the data.
If you declare the function as taking char*, you can''t -- not without casting away the constness, at least.
quote:inversely, there are things you can do with a non const pointer that you can''t do with a const one.
Which aren''t pertinent here. The pointer is being passed by value, we can modify that all we like. It''s modifying the pointed-at things which is dangerous, which is why we want to prevent it with a const-correct function.
