I like Java as a language. Kind of. It\u00e2\u20ac\u2122s strongly and statically typed, has object oriented syntax, reflection, exceptions, and interfaces (interfaces being one of the few features that I think C++ is missing). Dynamically typed languages encourage sloppiness, and don\u00e2\u20ac\u2122t help you avoid sloppiness, and the overriding feature of all good software is that it is readable (i.e.\u00c2\u00a0not sloppy). However, like many languages, I feel that it\u00e2\u20ac\u2122s been designed because \u00e2\u20ac\u0153C++ is too hard\u00e2\u20ac\u009d. Further, like many languages that do this, they end up in difficulties that are created because fundamentally you can\u00e2\u20ac\u2122t hide complexity. As Einstein said, \u00e2\u20ac\u0153Make things as simple as possible; but not simpler.\u00e2\u20ac\u009d<\/p>\n
This article is a discussion of one of those difficulties.<\/p>\n
Consider this Java code:<\/p>\n
class<\/span> SomeClass extends<\/span> SomeOtherClass {\n private<\/span> final<\/span> String NAME = "SomeClass"<\/span>;\n\n @Override<\/span>\n public<\/span> String getName<\/span>() {\n return<\/span> NAME;\n }\n }<\/code><\/pre>\nHere\u00e2\u20ac\u2122s the same in C++11:<\/p>\n
class SomeClass : public SomeOtherClass {\n public:\n const<\/span> string &getName() const<\/span> override {\n return<\/span> NAME;\n }\n private:\n static<\/span> const<\/span> string NAME;\n };\n const<\/span> string SomeClass::NAME = "SomeClass"<\/span>;<\/code><\/pre>\nThese, while superficially similar, are very different. In C++ we have a way of defining constants. We have a way of returning references to constants, and a way of saying a particular method doesn\u00e2\u20ac\u2122t alter the object. In Java we have none of those.<\/p>\n
This lack of expressive ability is, presumably, to keep things simple. Unfortunately, wanting to keep things simple, doesn\u00e2\u20ac\u2122t make them so. Imagine this code:<\/p>\n
public<\/span> class<\/span> references {\n abstract<\/span> static<\/span> class<\/span> SomeOtherClass {\n abstract<\/span> public<\/span> String getName<\/span>();\n }\n \n static<\/span> class<\/span> SomeClass extends<\/span> SomeOtherClass {\n private<\/span> final<\/span> String NAME = "SomeClass"<\/span>;\n \n @Override<\/span>\n public<\/span> String getName<\/span>() {\n return<\/span> NAME;\n }\n }\n \n public<\/span> static<\/span> void<\/span> main<\/span>(String[] args) {\n SomeClass x;\n String someString = x.getName<\/span>();\n \n System.out<\/span>.println<\/span>(x.getName<\/span>());\n someString[0<\/span>] = 's';\n System.out<\/span>.println<\/span>(x.getName<\/span>());\n }\n }<\/code><\/pre>\nThis is invalid. Java String<\/code>s are immutable. so the attempt to alter the first character isn\u00e2\u20ac\u2122t supported. Instead we have to reach for StringBuilder<\/code> or String.replace()<\/code> to create a new string from an existing string. In this case, that\u00e2\u20ac\u2122s exactly what\u00e2\u20ac\u2122s necessary \u00e2\u20ac\u201c we can\u00e2\u20ac\u2122t be allowed to modify constants.<\/p>\nExcept, what if we want to modify a non-const string? Since all String<\/code>s are immutable, we have to copy every<\/em> string before we modify it. Worse, the immutability of a String<\/code> only comes about because String<\/code> has been carefully coded so that it is immutable. We will have the same problem with any container type we might create of our own. We\u00e2\u20ac\u2122ll have to make it immutable, and then remember to supply all the methods that might have modified in place with versions that self-copy then modify the copy.<\/p>\nAll to avoid \u00e2\u20ac\u0153const\u00e2\u20ac\u009d, and all because Java only understands references to objects.<\/p>\n
C++11\u00e2\u20ac\u2122s new move semantics, strangely, let C++ go in the opposite direction \u00e2\u20ac\u201c avoiding references. I say \u00e2\u20ac\u0153strangely\u00e2\u20ac\u009d because at first sight, and for the experienced C++ programmer, references are what let you write fast software. Everyone knows you shouldn\u00e2\u20ac\u2122t, where possible, copy data. You should pass around references. We end up passing pointers or references (pointers in disguise) around. The problem is that that had its own pitfalls:<\/p>\n
SomeClass &manipulateSomeClasses(const<\/span> SomeClass &A, const<\/span> SomeClass &B)\n {\n SomeClass *result = new SomeClass();\n \/\/ ... Combine A and B into result ...<\/span>\n return<\/span> *result;\n }<\/code><\/pre>\nWho is responsible for freeing up the memory allocated here? We\u00e2\u20ac\u2122re returning a reference, so unless the caller immediately takes the address of this return value, it\u00e2\u20ac\u2122s not going to happen. Further, unless they assign the answer as part of a reference construction, there is no reasonable way to get at the returned reference:<\/p>\n
SomeClass &reference( manipulateSomeClasses(A,B) );\n \/\/ ... work on reference ...<\/span>\n delete &reference;<\/code><\/pre>\nYuck, deleting with the address-of operator. Notice as well that the caller of manipulateSomeClasses()<\/code> has to know implementation detail \u00e2\u20ac\u201c that its storage is allocated on the free store rather than automatic storage. Most of us have simply given in at this point and either passed a destination object in as a parameter, or returned a pointer and taken over ownership of it. Neither of which is pretty (passing a destination parameter is classic C, but makes the code less self documenting), and still requires far too much knowledge of internals.<\/p>\nSo what do we do instead? Return by value?<\/p>\n
SomeClass manipulateSomeClasses(const<\/span> SomeClass &A, const<\/span> SomeClass &B)\n {\n SomeClass result;\n \/\/ ... Combine A and B into result ...<\/span>\n return<\/span> result;\n }<\/code><\/pre>\nAssuming SomeClass<\/code> has all the requisite copy constructors and assignment operators, this will at least protect us from a memory leak. If SomeClass<\/code> holds a lot of data though, returning results like this is slow. The returned value has to be copy-constructed into its target in the caller from the automatic result<\/code> that\u00e2\u20ac\u2122s about to be destructed.<\/p>\nOr at least it was in C++98. C++11 lets you create a move constructor. We\u00e2\u20ac\u2122ve seen previously how useful that is for construction, but it might not be entirely clear that a move constructor can be called implicitly in these return-by-value situations. The above return-by-value example, provided a C++11 move-constructor has been implemented, is not slow. In fact it\u00e2\u20ac\u2122s wonderfully fast.<\/p>\n
SomeClass x( manipulateSomeClasses(A,B) );<\/code><\/pre>\nx<\/code> here in the old days would be copy-constructed. Now, the compiler notes that the return value of manipulateSomeClasses()<\/code> is a temporary, and so the move-constructor can be used. The move constructor effectively reassigns the storage of that temporary to the non-temporary, x<\/code> \u00e2\u20ac\u201c nothing is copied.<\/p>\nWe now have no worries about speed, and no worries about remembering to free up resources.<\/p>\n
Let\u00e2\u20ac\u2122s return to where we started then.<\/p>\n
#include <iostream><\/span>\n #include <string><\/span>\n using namespace std;\n\n class SomeOtherClass {\n public:\n virtual const<\/span> string &getName() const<\/span> = 0<\/span>;\n };\n\n class SomeClass : public SomeOtherClass {\n public:\n const<\/span> string &getName() const<\/span> override {\n return<\/span> NAME;\n }\n private:\n static<\/span> constexpr string NAME {"SomeClass"<\/span>};\n };\n const<\/span> string SomeClass::NAME = "SomeClass"<\/span>;\n\n int<\/span> main()\n {\n SomeClass x;\n string name(x.getName());\n cerr << "name = "<\/span> << name << " "<\/span> << x.getName() << endl;\n name[0<\/span>] = 's';\n cerr << "name = "<\/span> << name << " "<\/span> << x.getName() << endl;\n\n \/\/ outputs:<\/span>\n \/\/ name = SomeClass<\/span>\n \/\/ name = someClass<\/span>\n\n return<\/span> 0<\/span>;\n }<\/code><\/pre>\nThis one will work exactly as you might expect, with no need for builder classes or unnecessary copies (in fact the copy here is<\/em> necessary, but the compiler will know that and do the right thing). In other words: our code is more readable than the Java equivalent, and will be faster when it\u00e2\u20ac\u2122s possible to be faster. Importantly, the user of SomeClass<\/code> doesn\u00e2\u20ac\u2122t need to care about its internals, it could be complex or simple, use lots of storage or none. The caller treats it as they would any built-in type.<\/p>\n","protected":false},"excerpt":{"rendered":"I like Java as a language. Kind of. It\u00e2\u20ac\u2122s strongly and statically typed, has object oriented syntax, reflection, exceptions, and interfaces (interfaces being one of the few features that I think C++ is missing). Dynamically typed languages encourage sloppiness, and don\u00e2\u20ac\u2122t help you avoid sloppiness, and the overriding feature of all good software is that\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":[66,82,79,83,6],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1078"}],"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=1078"}],"version-history":[{"count":4,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1078\/revisions"}],"predecessor-version":[{"id":1198,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1078\/revisions\/1198"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1078"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1078"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1078"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}