One of the longest unresolved arguments among developers is whether you should use tabs or spaces in your code. It is also difficult to find good discussion on the topic because it gets sidetracked by non-issues. This post makes two assumptions, so we can focus on what matters:
Abstract: This document teaches you from the very basics to advanced features such as std::launder how pointers in C++ work.
It is aimed at developers of any skill level.
However, it links to the C++ standard so that advanced readers can verify the information and investigate further.
Motivation: Most tutorials on pointers are aimed at beginners, and present a simplified model. Some tutorials perpetuate an explanation of pointers that is solely based on their implementation (pointer = memory address). This tutorial aims to provide a comprehensive explanation of pointers that is in line with how they actually work from a language perspective.
P0847: Deducing this has introduced explicit object member functions. These greatly empower the developer, but come at a cost of added verbosity. This proposal offers two independent ways of reducing this verbosity.
This proposal aims to improve the ergonomics of the std::byte type by allowing the conversion of an integer-literal
to std::byte.
This would simplify initialization and comparison of std::byte, which would encourage its use,
and make it feel more like a fundamental type.
I've been writing C++ for half a decade now, and auto has always been a great source of discomfort to me.
Whenever I came back to a past project that makes extensive use of it, I found myself confused,
and first had to look at all the types before I could make sense of it.
Similarly, I've worked as an intern at a company that had a AAA policy for its code base. Whenever something didn't work, and I had to debug some code, half the time was spent just looking up types.
A C++2b proposal.
I propose a provable if statement which never incurs run-time cost, and utilizes either constant evaluation, or constant folding and constant propagation to determine whether its condition is true. Such a statement is useful for choosing alternative forms of algorithms if some constants are known, as well as improving diagnostics for failed assertions without any run-time cost.
All code you write is ultimately designed to read and write memory. One aspect of this is the memory model of the language; something which is accompanying us as developers, but we rarely have to think about.
How come, for example, the following code does what we expect it to?
int x = 1;
x = 5;
inline is redundant for inline definitions, except when modules are used.
In that case, inline would make the function part of the module interface as usual.
C++ currently offers only truncating integer division. As a consequence, the remainder operator's sign is same as the sign of the dividend. Alternative rounding modes and remainder sign behaviour are useful.
This proposal adds an <intdiv> header containing free functions for obtaining the quotient and remainder for different rounding modes, such as rounding towards the nearest integer, towards the infinities, etc.
| /* Long division, unsigned (64/32 ==> 32). | |
| This procedure performs unsigned "long division" i.e., division of a | |
| 64-bit unsigned dividend by a 32-bit unsigned divisor, producing a | |
| 32-bit quotient. In the overflow cases (divide by 0, or quotient | |
| exceeds 32 bits), it returns a remainder of 0xFFFFFFFF (an impossible | |
| value). | |
| The dividend is u1 and u0, with u1 being the most significant word. | |
| The divisor is parameter v. The value returned is the quotient. | |
| Max line length is 57, to fit in hacker.book. */ |