Sign into an existing account

https://pomf2.lain.la/f/tgq4c86w.png
C++ gives the programmer extremely broad power over data types and how they behave. You can create a custom type and define whether and how it can be added, multiplied, compared, iterated, printed as output, called as a function, transformed into another type—all of which then interacts with the C++ language and enables its use elsewhere.

Developers of other languages whine and cope about this, notably Java maintainers calling it too confusing to read code where custom types can be added together; it's nonsense at best, if not an insult in assuming people aren't intelligent enough for that feature. A type representing a 3D vector can have a perfectly clear meaning associated with adding them together. As usual, to stand against that because it could be abused is yet another case of trying to protect programmers from themselves, a mistake which so many maintainers just cannot resist making.

That is, especially when abusing it is such a good way to demonstrate it! Suppose we are creating a new type to represent integers for nigger math, which I'll call "nigint" for nigger integer. We can start by making a "wrapper" which stores a normal integer:


The private section stores data and functions only to be accessible internally, so outside interaction will be forced to work via definitions we'll add to the public section. That public function is a constructor which stores a normal int directly, and has an implicit return-type (a finished object of our nigint type). The default value of zero allows for omitting it, in effect defining two constructors with and without the parameter, which has various compatibility advantages. The braces are an empty constructor body, because there isn't anything else to do and it cannot be absent.

Good so far, albeit lacking interaction and functionality, so code won't yet compile if it attempts to use or output one of these. At minimum, we can tell the compiler that our type can at least be cast to an integer by defining the corresponding operator, with this placed in the public section:


The keyword operator is used for defining functions which interact with the language. Cast-operations are special in also having an implicit return type, but otherwise the syntax is just like a normal function, including const to indicate that the function does not modify our object.

A quick test before continuing:


That at least outputs "4" rather than failing to compile. Actually, commenting out the operator definition can be illustrative here, it causes this compile error:


Ultimately the iostream interface wants a way to output a nigint using the << syntax, but it's happy without that as long as it has an implicit way available, which the cast to int provides.

Niggers don't know how to write or speak proper numbers though, so let's actually implement that operator to control directly what it does for our type. We need a function header for operator<< which takes references to a std::ostream and a nigint, and returns the std::ostream reference back. We also need access to the underlying int though, so first declare this function within the nigint class as a "friend":


This is a deliberate mechanism to give that function access to the private members within our type, in this case the underlying int value. Now we can implement it outside the class, using full access:


Placing that just after the nigint class, the previous program now outputs "fo". The return reference there is just part of how iostream works, allowing multiple << operations to be chained together. Note that the attempt to access ni.i only works because the function was declared as a friend, otherwise the compiler error will say private within this context.

Now we can use the type as a number and impose that output logic:


Output is "fo" and "sen", as expected. The expression ni + 3 is using the implicit cast to int, for which the result will be another int and the normal output would be "7", but we're telling the compiler to make a temporary nigint instance of it first before the output stream gets to see it.

Niggers also can't add properly though. No problem; we can also define what happens when we add to a nigint object. This we can do entirely within the nigint class:


In this case, the object itself is the value to the left when the operator is used, and the argument x is the value to the right. The return expression is just three normal integers added together, which the compiler casts implicitly to nigint due to the function return type, and it knows how to do that because the correct constructor exists.

Because that operation returns a nigint, we can now also test the summation directly without the explicit constructor:


Now we get "fo" and "aid", great. Some niggers know at least a few of the tens-place numbers though, let's add those into the operator<< overload. We can check for some known cases and output those words first:


This is where the const protection is good to keep in mind; the operator is not allowed to modify the object being printed, but it can use that read-only access to make a mutable copy of the integer. That then lets us subtract off any part of it accounted first before handing the remainder to the switch statement.

Test:


Output:


If there's one way that nigger math is useful, it's being an example!

https://pomf2.lain.la/f/819ag2cg.png
The linked image has formatting as intended originally; for the post text I had to use alternative characters to avoid triggering the site formatting, which REALLY needs a proper pre-formatted code feature.

Where most other languages have rules about passing primitive types by value and objects by reference, C/C++ builds subtle control of that into its language. This is no simple quirk; passing by value is also known as copying, and that comes with a real performance cost, such that learning a language which controls it is the nature of achieving good performance in and of itself.

Consider a simple and fairly useless class representing a square with a width and a height, entirely public to ignore encapsulation for now. We store the width and height, and we provide an area calculation and a function to scale its size:


This works at least, but neither as optimally nor with as much freedom as it could have.

The freedom point is good to address first; consider how that area function. Despite only reading the class variables without changing them, the entire function will be treated as if it can conceivably change the Square object on which it is called. Due to that, the area function will be inaccessible given a const Square object, even though it makes no changes.

The area function should be specified like this:


Shoving const in the function header makes the object fields read-only within the function—in return for being allowed to call the function on a const version of the object. Use of const is both a means of object protection and also a precursor to compiler optimisations such as avoiding copying and reloads.

Now to be more optimal, consider the scale function. It modifies the object and thus cannot be const, but this is about the scale factor parameter. Calling that function will supply it with a copy of the factor, which can be appropriate if it genuinely needs a temporary copy it can modify without affecting the calling code, but clearly it doesn't change the factor. In one sense, it would be better to accept a reference instead:


This bypasses the overhead of copying, although now that function cannot be used with a const double, because it could conceivably change the value (even though in practice it doesn't). This applies to calls with literal number as the factor, such as scale(1.5)—that 1.5 is itself a const double.

The scale function should be specified like this:


Introducing that guarantee now allows literal numbers and any named values (const or otherwise), while also avoiding copying anything.

Even though this example involves only a double weighing in at 8 bytes, that is nonetheless both how to talk to the C/C++ compiler and also how to avoid unnecessary copying. It is not an early optimisation mistake; it is a basic part of the language which should be in continual use, it just so happens that the language and the optimisation are one and the same!