Andrzej's C++ blog

As someone who has deliberately avoided C++ for the last 20 years (in favour of functional programming) I find the discussions of "reference semantics" and "value semantics" (let alone "mutable value semantics") to be quite opaque. It is as if the C++ community has become an enclave of folks who put up with the extreme complexity of C++ and speak a correspondingly tortuous theoretical language. What the seem to be saying here is that the "subscripting" operation returns a view into its argument, not entirely unlike the concept of a lens. The only thing that view can be used for is directly accessing the the part of the value that is in focus—the view is not itself a first class value, which means that so-called "reference semantics" don't come into the picture. I don't think they're being evasive or promoting their idea in bad faith. They are just operating in a characteristically arcane way for C++ language design people. The following blog post helped me start to grasp what this aspect of C++ talk is actually about: https://akrzemi1.wordpress.com/2012/02/03/value-semantics/

Way more history than you asked for about how we got into this situation with noexcept: Up to 2011: https://akrzemi1.wordpress.com/2011/06/10/using-noexcept/ As of '17: https://devblogs.microsoft.com/oldnewthing/20180928-00/?p=99855 (I think this is the final word; I don't see any changes to exceptions in high-level release notes for c++20 and c++23 -- did I miss anything?)

When it comes to std::optional, the answer is no. In fact, std::optional<T&> is explicitly forbidden (see here: https://www.fluentcpp.com/2018/10/05/pros-cons-optional-references/) It is used in some other places though. For instance, std::string implementations typically employ small-string optimization (SSO) which means that there might be a limit on string::size() since some of the bits inside that value are used for different purposes (example: https://akrzemi1.wordpress.com/2014/04/14/common-optimizations/). The "niche" in this case is the realization that strings are unlikely to be exabytes in size, so there is no reason to always store zeros in high bits of _size.

Fastest to develop, yes. Portable, yes. Safest? Well, only in as much most of the errors will be blamed on the programmer for not doing the correct modern C++. I mean, seriously, understanding the borrow checker is nowhere near as hard as understanding this: https://akrzemi1.wordpress.com/2013/10/10/too-perfect-forwarding/ There's a No True Scotsman aspect to C++ advocacy. Anything that is obviously dumb either is because the programmer did it wrong, because it belongs to the ever-growing list of features you avoid or "doesn't come up that often".

Read this: [1] In C++11, exceptions in destructors have defined semantics, but those semantics are very complicated. Prior to C++11, the semantics were not well defined. [1] https://akrzemi1.wordpress.com/2011/09/21/destructors-that-throw/

> I give my brain a break by using std::unique_ptr<HugeObject>. Unfortunately this comes at a cost. Most notably, now you're unnecessarily stressing the allocator. But worse, you no longer enjoy the benefits of value semantics [1]. [1] https://akrzemi1.wordpress.com/2012/02/03/value-semantics/

This seems like a nice article series on the subject http://akrzemi1.wordpress.com/2013/11/18/type-erasure-part-i/ Just getting started on it, it seems that the theme is that you can't have the same binary code work on different types without having a run-time indirection in there somewhere. But, you can use templates to keep that indirection convenient and type safe. And, you can structure your templates to only specialize a minimal amount of code necessary to interface your type into a non-specialized algorithm.

C++11 has user-defined literals: http://akrzemi1.wordpress.com/2012/08/12/user-defined-literals-part-i/ http://en.wikipedia.org/wiki/C%2B%2B11#User-defined_literals

C++11 has some tricky changes which are way not obvious at the first glance. A few useful resources I found: * http://thbecker.net/articles/rvalue_references/section_01.html * https://en.wikipedia.org/wiki/Copy_elision * http://en.cppreference.com/w/cpp/language/eval_order * https://akrzemi1.wordpress.com * https://dl.dropboxusercontent.com/u/13100941/C%2B%2B11.pdf Understanding the combination of copy elision and move semantics (when and how they are applied) can require one to read the standard. C++11 is not simpler than older C++, but using it is easier, if you have a good understanding of it.

"The rules for conditional operator are quite sophisticated and one of them says that if one of the sub-expressions is a throw expression, the type of the entire conditional operator is that of the other sub-expression." [1] [1] http://akrzemi1.wordpress.com/2011/05/06/compile-time-computations/

I kinda like the way Boost did error_code[1], which got incorporated into C++11[2]. Essentially you got a generic error_code struct which has two members, an int to hold a given error value or zero if there's no error, and a reference to an error category which helps interpret the error value. Effectively the error category is an interface, so in C terms it would be a reference to an error_category struct filled with function pointers. There's then some machinery which allows you to compare specific error codes to generic error conditions like "file not found", abstracting away the specifics of the error code. It's not problem free[3], but I've used this pattern in languages like Pascal and felt it worked well for me. [1]: https://www.boost.org/doc/libs/1_82_0/libs/system/doc/html/system.html [2]: https://en.cppreference.com/w/cpp/header/system_error [3]: https://akrzemi1.wordpress.com/2017/10/14/error-codes-some-clarificati…

A quick test-run on the pages linked from the hackernews front page: hackernews svg logo doesn't render youtube embed on the servo homepage doesn't load https://github.com/tpope/timl -> reloads/rerenders infinitely, uses 100% of 1 core https://akrzemi1.wordpress.com/2023/04/23/the-obvious-final-step/ -> hangs while loading the page, uses 100% of 1 core https://equalitytime.github.io/FlowersForTuring/ -> loads/renders fine https://github.com/reactos/reactos -> reloads/rerenders infinitely, uses 100% of 1 core https://dolphin-emu.org/blog/2023/05/27/dolphin-steam-indefinitely-pos… -> loads fine but css rendering/placement is off on breadcrumbs and article https://xcp-ng.org/blog/2023/05/23/new-xen-updates-on-risc-v/ -> very long load then hangs while loading javascript/content. Not a great batting average - seems like sites need to be purpose built for this or leverage little/no modern javascript libraries for it to render accurately. Servo has been in this state for the last 5 or 6 years since I first discovered it.

> WG21 seems to dearly wish this wasn't so, offering Concepts which pretend to semantics they don't have, such as std::totally_ordered and I'm glad to see your "CanBlah" concept doesn't do this, to be sure all things which match this requirement can, indeed blah() although we've no idea what that can or should do. I don't understand how random assumptions on what WG21 may or may not think counts as an example (or anything to be honest) > If something satisfies a Concept, but does not model the Concept then the C++ program is not well formed and no diagnostic is required. uh... no ? I think that you are referring to this blog post: https://akrzemi1.wordpress.com/2020/10/26/semantic-requirements-in-con… for which I entirely disagree with the whole premise - the only, only thing that matters is what the compiler understands. The standard can reserve itself the right to make some cases UB, such as when trying to sort un-sortable things just like it can state that adding to numbers can cause UB and that's fine: it's the language's prerogative and is all to be treated as unfortunate special-cases ; for the 99.99999% remaining user code, only the code matters and it makes no sense to ascribe a deeper semantic meaning to what the code does. > In which case it's your responsibility to ensure you can log this, which of course CanBlah didn't express. A metric ton of side concerns should not be part of the spec, such as logging, exceptions, etc - everyone saw how terrible and…

Regarding Rust: > There is another thing I noticed, and I hope someone from the Rust community can correct me if I'm wrong, but it looks like Rust also special cased format_args! in the compiler by making it a built-in. If my understanding is correct, this would make Zig stand out as the only language of the three mentioned here which does not special case string formatting in the compiler and instead exposes enough power to accomplish this task in userland. It depends what you mean by "userland". Rust has long supported procedural macros, albeit not on stable compiler versions until recently (and still only hackily there). Procedural macros, a.k.a. compiler plugins, are written in Rust, but work differently from compile-time function evaluation. With CTFE, the code running at compile time lives in the same "world" as the rest of the code being compiled, in a sort of pretend version of the target environment where you can't do things like call external functions. Rust compiler plugins are just separate libraries that get compiled for the host architecture and loaded into the compiler process (which is less scary than it sounds; the build process "just works" thanks to Cargo, and Rust's safety ensures you don't stomp on random compiler state). You have access to the full language and can call whatever you want, even do things like file I/O if needed; on the other hand, you're in a separate environment and can't just name variables, functions, etc. from the runtime…