Consider the declarations of various pointer-to-an-O-accepting functions:<\/p>\n
f( O * )<\/code><\/li>\nf( const O * )<\/code><\/li>\nf( O * const )<\/code><\/li>\nf( const O * const )<\/code><\/li>\n<\/ul>\nWhat is the author of f()<\/code> telling us about what the function will do with the O<\/code> we reference in each of these cases? This, and subsequent articles, will discuss why you would choose between these various argument types. Essentially we\u00e2\u20ac\u2122re talking about what you are implying to the caller of your function when you pick a particular pointer declaration.<\/p>\nf(O*)<\/code><\/h2>\nWe\u00e2\u20ac\u2122re passing a pointer by value, it\u00e2\u20ac\u2122s so common that it\u00e2\u20ac\u2122s easy to forget that passing a pointer, while it\u00e2\u20ac\u2122s a pass-by-reference to the pointed to object, is still<\/em> pass by value as far as the parameter is concerned. It should be obvious that this does nothing:<\/p>\n void<\/span> f(O* p) {\n p = nullptr;\n }<\/code><\/pre>\np<\/code> has been passed-by-value, so is just another local variable. *p<\/code> on the other hand is a reference to some external object and we certainly can modify that inside f()<\/code>.<\/p>\n void<\/span> f(O* p) {\n if<\/span>(p == nullptr)\n return<\/span>;\n p->modify();\n }<\/code><\/pre>\nThe above is, fundamentally, what the function declaration f(O*)<\/code> says about f()<\/code> \u00e2\u20ac\u201c it will modify the object given to it, and the object need not exist (passing a pointer means you have to allow that the pointer points at nothing, null). There is, unfortunately, nothing to stop f()<\/code> modifying not just the content, but the lifetime of O<\/code>.<\/p>\n void<\/span> f(O* p) {\n delete p;\n \/\/ The following has no effect, we've established that the<\/span>\n \/\/ p has been passed by value<\/span>\n p = nullptr;\n }\n\n \/\/ ... elsewhere in the forest ...<\/span>\n myObject = new O;\n f( myObject );\n \/\/ f() has destroyed myObject, so we have to remember to do this<\/span>\n myObject = nullptr;\n \/\/ ... if we forget then when we try this, we could be hiding a<\/span>\n \/\/ disaster for later.<\/span>\n myObject->modify();<\/code><\/pre>\nWe\u00e2\u20ac\u2122ll come to the correct way to modify an object lifetime within a function later. For now, here\u00e2\u20ac\u2122s a rule: never<\/em> delete an object via a raw pointer passed-by-value to a function. Let\u00e2\u20ac\u2122s look at why:<\/p>\n void<\/span> f(O* p) {\n delete p;\n \/\/ The following has no effect, we've established that the<\/span>\n \/\/ p has been passed by value<\/span>\n p = nullptr;\n }\n\n \/\/ ... elsewhere in the forest ...<\/span>\n O myObject;\n \/\/ This will go very, very badly, as f() assumes that the passed<\/span>\n \/\/ object is allocated on the free-store. It isn't.<\/span>\n f( &myObject );<\/code><\/pre>\nBy using delete<\/code> in a function, we\u00e2\u20ac\u2122ve forced all objects of that type to be allocated on the free-store; and we\u00e2\u20ac\u2122ve forced the caller to come and read our API in order to know that fact. We should, as far as possible, not inform of limitations by comment. We should limit by language, and let the compiler give errors when those limits aren\u00e2\u20ac\u2122t obeyed. Unfortunately, C offers no such facility.<\/p>\nf(const O*)<\/code><\/h2>\nOne standard limit, is that of const<\/code>. Here we are telling the caller that f()<\/code> will not modify the pointed-to object, and that the object is allowed not to exist. The compiler will warn us if we try to use any non-const member function of O<\/code>.<\/p>\n int<\/span> f(const<\/span> O* p) {\n if<\/span>(p == nullptr)\n return<\/span> DEFAULT;\n return<\/span> p->query();\n }<\/code><\/pre>\nA function that takes a const O*<\/code> would be pointless if it didn\u00e2\u20ac\u2122t return something. Since const O*<\/code> can\u00e2\u20ac\u2122t be modified, if f()<\/code> doesn\u00e2\u20ac\u2122t return something, then it would have zero effect. Here we\u00e2\u20ac\u2122re using f()<\/code> as a null-safe wrapper around an O<\/code>.<\/p>\nWe needn\u00e2\u20ac\u2122t worry about lifetime in this case, delete<\/code> requires a non-const pointer, so the compiler will not let us call delete p<\/code> here.<\/p>\nIt\u00e2\u20ac\u2122s important to remember what const O*<\/code> means \u00e2\u20ac\u201c that the pointed-to<\/em> object cannot be modified. The pointer itself can<\/em> be modified. As in the previous section though, it would serve no purpose. However, the compiler will not stop you.<\/p>\n int<\/span> f(const<\/span> O* p) {\n if<\/span>(p == nullptr)\n return<\/span> DEFAULT;\n int<\/span> ret = p->query();\n p = nullptr;\n return<\/span> ret;\n }<\/code><\/pre>\nf(O * const)<\/code> and f(const O * const)<\/code><\/h2>\nI\u00e2\u20ac\u2122ve included this one for completeness; but you will never see it. This is a nonsense declaration. O * const<\/code> is our way of telling the compiler that the pointer<\/em> is itself const<\/code> and cannot be modified. The thing pointed to is fair game. Still remembering that the pointer is passed by value, we are talking only about the function-scoped copy of the pointer that can\u00e2\u20ac\u2122t be modified. We\u00e2\u20ac\u2122ve already seen that modifying the pointer within the function does absolutely nothing, so why would it matter to the caller that we\u00e2\u20ac\u2122ve told the compiler to prevent us from doing that? From the perspective of the caller these two declarations are identical:<\/p>\n\nf( O * )<\/code><\/li>\nf( O * const )<\/code><\/li>\n<\/ul>\nThe caller doesn\u00e2\u20ac\u2122t care whether the function modifies it\u00e2\u20ac\u2122s local copy of the pointer or not, it only cares that f()<\/code> can modify the pointed-to object, which in both these cases it can.<\/p>\nBy extension then, the following two declarations are identical from the point of view of the caller.<\/p>\n
\nf( const O * )<\/code><\/li>\nf( const O * const )<\/code><\/li>\n<\/ul>\nThe caller knows that neither modifies the pointed-to-object.<\/p>\n
\nNext time, C++.<\/p>\n","protected":false},"excerpt":{"rendered":"
Consider the declarations of various pointer-to-an-O-accepting functions: f( O * ) f( const O * ) f( O * const ) f( const O * const ) What is the author of f() telling us about what the function will do with the O we reference in each of these cases? This, and subsequent articles,\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[65,42,6],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1184"}],"collection":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1184"}],"version-history":[{"count":3,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1184\/revisions"}],"predecessor-version":[{"id":1195,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1184\/revisions\/1195"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1184"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1184"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1184"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}