StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><i>"I added "const" to the dict argument in get() so that the compiler warns me if I try to change the address dict is pointing to"</i></p> <p>In that case you meant <code>Dict *const dict</code>, not <code>const Dict *dict</code>. You've declared the struct as const, not the pointer to it.</p> <p><i>"Why do I also need to have const for currPtr"</i></p> <p>Because otherwise you could use currPtr to modify the dictionary struct itself, which is supposed to be const in this function.</p> <p><i>"The line currPtr = currPtr->next; is changing the currPtr pointer, so, why doesn't the compile warn me about that if I added a const to currPtr"</i></p> <p>Same reason: it's not an error if the const is in the place you put it. It would be if the const were in the other place for currPtr.</p> <p><i>otherwise I won't be able to access the dictionary in the main program cause I lost the address I was pointing too</i></p> <p>No - when the main program calls get, it passes a pointer value into the routine, and this becomes the value of dict in the get function. But get has its own pointer variable, separate from the one in the main program. Even if they just so happen to both be called "dict", changing one pointer won't change the other.</p> <p>Both variables point to the same struct, so if you use the variable to modify any of the fields in the struct, then of course the results will affect both bits of code. Usually, a function called "get" would be a read-only operation, so you're right to make the parameter <code>const Dict *</code>. But I think the reason this is right, is slightly different from what you think. It's to protect the contents of the dictionary from change, not to protect your record of the address of it.</p> <p>However, const-safety is slightly awkward for linked lists like this one. Even when you have a const Dict, its "next" field still doesn't point to const. So although you can't modify the first node, the const-system won't protect you from modifying other nodes in the list. C++ addresses this with function overloading, so you can have a "getnext" function which returns a const output if the input is const, but a non-const output if the input is non-const. You could achieve a similar thing in C with a "getnext" and "getnext_c", the latter having a const parameter and return. But most people don't bother, including standard library functions like strchr, which in C takes const char* but returns non-const char*. strchr can therefore be accidentally used in C to convert a const string into a non-const one, without any warning. Or deliberately, in which case it's a bit like laundering money through a "legit" business ;-)</p> <p><i>the del() function does not require me to add a const before currPtr and prevPtr?</i></p> <p>I confess I'm stumped on that. I would expect the same warning as in "get" - are you sure it isn't there? But the parameter to del shouldn't be const anyway, because you're potentially modifying the fields.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload