enum Json {\n Null,\n Boolean(bool),\n Number(f64),\n String(String),\n Array(Vec<Json>),\n Object(Box<HashMap<string, Json>),\n}<\/pre><\/div>\n\n\n\nSo if you have a Number<\/code> then there is an associated floating point,\nif you have an Array<\/code> there is an associated vector of Json<\/code> values.\nThere is simple control flow available to use this to access the right data at the right time.\nComing from a C++ background this seems surprising but I can see the benefits.<\/p>\n\n\n\nNext the book shows some C++ code to do the same thing:<\/p>\n\n\n\n
class JSON {\nprivate:\n enum Tag {\n Null, Boolean, Number, String, Array, Object\n };\n union Data {\n bool boolean;\n double number;\n shared_ptr<string> str;\n shared_ptr<vector<JSON>> array;\n shared_ptr<unordered_map<string, JSON>> object;\n \n Data() {}\n ~Data() {}\n ...\n };\n \n Tag tag;\n Data data;\n\npublic:\n bool is_null() const { return tag == Null; }\n bool is_boolean() const { return tag == Boolean; }\n bool get_boolean() const {\n assert(is_boolean());\n return data.boolean;\n }\n void set_boolean(bool value) {\n this->~JSON(); \/\/ clean up string\/array\/object value\n tag = Boolean;\n data.boolean = value;\n }\n ...\n};<\/pre><\/div>\n\n\n\nThat’s bigger and is taking more code to do the same sort of thing.<\/p>\n\n\n\n
Is that really what someone writing good C++ would do?\nI would have been tempted to expose the enum Tag<\/code> type and a getter for it.\nThat would allow a switch-statement to choose the right control pathway\nwithout having to both with individual methods to check each tag type.\nThe std::shared_ptr<\/code> wrappers are probably unnecessary.\nI’m not sure how much space std::string<\/code>, std::vector<\/code> and std::unordered_map<\/code> take up but\nmost of their data will be stored elsewhere.\nIt might have been done to give a uniform destructor behaviour.<\/p>\n\n\n\nAll that seems insignificant when you consider that C++17 introduced std::variant<\/code>.\nThe code could have looked something like this:<\/p>\n\n\n\nstruct JSON {\n using Data = std::variant<\n bool,\n double,\n std::string,\n std::vector<JSON>,\n std::unordered_map<std::string, JSON>\n >;\n\n Data data;\n};<\/pre><\/div>\n\n\n\nYou can access the variant via type, e.g. json.data.get<std::string>()<\/code>, or index.\nNo enum by default but you could add one and some helpers methods to facilitate things.\nOr, much like Rust, other flow control options are available:<\/p>\n\n\n\n std::visit(overloaded{\n [](bool boolean) { std::cout << boolean << std::endl; },\n [](double number) { std::cout << number << std::endl; },\n [](const std::string& string) { std::cout << string << std::endl; },\n [](const std::vector<JSON>& array) {\n for (const auto& json : array) {\n output(json.data);\n }\n },\n [](const std::unordered_map<std::string, JSON>& object) {\n for (const auto& [key, json] : object) {\n output(json.data);\n }\n },\n }, data);<\/pre><\/div>\n\n\n\nThis isn’t as elegant as Rust can manage but it is a much closer match than the book presented.<\/p>\n\n\n\n
The first edition of this book was written in 2018 and the second edition in 2021.\nstd::variant<\/code> was introduced before either of these were published.\nMaybe it hadn’t been noticed when the first book was written and\nthen the sample was just reproduced for the second book.\nThe writers may well not have been as up to date with C++ as they are with Rust.\nMaybe they did know and just wanted to present a great contrast between the two languages.\nWas that necessary?\nRust would still manage to do the same thing with less code.<\/p>\n\n\n\nIf I spot something like this it just make me mistrust the rest of the book.\nI’m going to take everything else that’s said with a pinch of salt.\nEven things where the author does have a good point.<\/p>\n\n\n\n
On balance<\/h2>\n\n\n\n
This could be taken as a lesson to avoid putting too much trust in what you read.\nJust because someone says one thing is good and one thing is bad doesn’t make it so.<\/p>\n\n\n\n
However I think this is about anyone, ourselves included, comparing apples with oranges:<\/p>\n\n\n\n
\n- If you’ve got an old and new rendering algorithm for a game should they both be tested on the same scene? Is it an old or new test scene? Is there going to be an advantage for one algorithm or another. Should they each get a scene custom built according to their advantages and disadvantages.<\/li>\n\n\n\n
- If you switch to a new language and your bug count goes up what does that mean? Maybe the new language has an inherent problem. Maybe you just aren’t as familiar with the language. Maybe it’s easier to do testing so the bugs are being found faster but still fixed at the same rate.<\/li>\n<\/ul>\n\n\n\n
If have<\/em> to compare apples and oranges because that’s all there is then try to be aware of it.<\/p>\n","protected":false},"excerpt":{"rendered":"In some of my recent reading I’ve been frustrated at authors making poor comparisons. The typical behaviour is to showcase an example of good coding with their preferred language \/ methodology against an example of bad coding with the competitor. It’s not, say, the language which is making the difference. It’s whether the code has […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_import_markdown_pro_load_document_selector":0,"_import_markdown_pro_submit_text_textarea":"","footnotes":""},"categories":[1],"tags":[20],"class_list":["post-151","post","type-post","status-publish","format-standard","hentry","category-general","tag-books"],"_links":{"self":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/151","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/comments?post=151"}],"version-history":[{"count":3,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/151\/revisions"}],"predecessor-version":[{"id":195,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/posts\/151\/revisions\/195"}],"wp:attachment":[{"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/media?parent=151"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/categories?post=151"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/permutationcity.co.uk\/bp\/wp-json\/wp\/v2\/tags?post=151"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}