Author: Martin

Multi-threading has been the theme of my previous two classes where I discussed thread-pools and producer-consumer queues. Let’s talk about the fundamental aspects of multi-threading and some of its most basic building blocks: spinlocks, automatic and manual events, and semaphores.
In this week’s class I will show you how to implement these building blocks using only standard C++ components: std::atomic_flag, std::mutex, std::condition_variable.

---

Code from the class:
lesson_spinlock_event_semaphore_how_to.cpp
Complete implementation:
mutex.hpp | event.hpp | semaphore.hpp

---

The question of case insensitive strings has been, and continues to be asked a lot, and equally many answers can be found all over the internet. The go-to solution is to create a char_traits policy class with eq, lt, and compare methods implemented using std::toupper before comparing characters, then instantiate std::basic_string with it using istring = std::basic_string<char, char_itraits<char>> This works well until you try to use your new type anywhere near code designed with std::string in mind. Then what?

I guess what I am trying to say is that I never found a complete solution to this, so I decided to create one myself. I wanted the case insensitive string to play nicely and seamlessly with its standard counterpart. I wanted the ability to pass it as a parameter anywhere std::string is accepted; to convert between istring and std::string in both directions; push it to output stream; read it from input stream; compare it using all six operators, ==, !=, <, <=, >, >=, with std::string whether it appeared on the left or right side of the operation; and to declare literals of its type: "std::string literal"s.
In other words have it be indistinguishable from std::string except when comparisons are needed, like this:

The starting point was the character traits policy class mentioned earlier, but instead of using it with std::basic_string I inherited publicly from std::basic_string template configured with case insensitive traits policy; this pulled all its methods into the derived class scope, I only had to pull base class constructors:

All this derived class needed now was a constructor which would allow it to be created from any other type of std::basic_string as long as the character type was the same; implicit type cast operator to seamlessly convert it to std::string, and 4 comparison operators: == and <=> declared twice with istring as the first or second parameter. The constructor and comparison operators needed to be selectively enabled only for strings with different character traits policy, otherwise they would cause ambiguity and compilation errors. Final step was declaring operator >>, operator <<, and operator""_is.

P.S. Everything I just described also applies to wchar_t aka std::wstring.

---

The implementation on my GitHub page: istring.hpp, example program: istring.cpp.

---

I would like to extend a warm welcome to fellow C++ enthusiast, and blog contributor, Kobi! Many of you know him from his Twitter account or as the organizer of San Diego C++ Meetup.

We have been exchanging likes and occasional comments on Twitter ever since I started this blog. He has always been encouraging and supportive in my blogging journey and I am happy he accepted my invitation to share knowledge and wisdom on this page (his first post).

Kobi will have permanent presence here posting news and updates about the San Diego C++ Meetup.

Welcome!

std::deep_ptr aka deep copying smart pointer has not yet been introduced to the STL though several C++ experts have proposed an implementation in the past. See n3339.pdf for one such proposal and a list of possible implementations.

In this post I want to share my implementation of deep copying pointer I recently came up with. Its interface is virtually identical to std::unique_ptr with the exception of additional cloner template parameter (a policy class) that specifies how deep copies are to be made. By default the pointer is copied by doing return (p ? new T{ *p } : nullptr); that is by invoking the copy constructor of T.

My example program illustrates how to create a cloning policy for polymorphic types; in other words how to make deep copies when deep_ptr<Base> actually points to some struct Derived : Base and types in a given inheritance hierarchy implement virtual S* clone():

Finally, and just like the std::unique_ptr, my pointer type can be used with a custom deleter:

del will be called on a pointer managed by p when it goes out of scope or when p is assigned to.

---

Example program on my GitHub account: deep_ptr.cpp. The implementation: deep_ptr.hpp.

---

Good friend asked me a while ago how to round float or double to N digits of precision. Given 0.0123456789 and N = 7 how to get 0.0123457000 as the result. The only way to round numbers (inside a machine) I could think of was to multiply them by 10 ^ N (ten raised to the power of N), cast the result to some type of int effectively stripping the fractional part, followed by a cast back to a floating point representation and division by same 10 ^ N:

Or something to that effect. Translated to C++:

Then he added the dreaded do it fast,… and just as I was about to tell him to take a long walk off a short pier I remembered something about constexpr and doing arithmetic at compile time.

Looking at the implementation above I decided to start with computing the power of 10 at compile time. My first approach was a recursive template struct power_of with a partial specialization, the recursion stop, for the power of zero case (and a helper power_of_v variable declaration):

This allowed me to write power_of_v<10, 3, float> to compute at compile time the 3rd power of 10 stored as type float.
I also created a recursive constexpr function since those too can be evaluated at compile time:

With it I could write power_of_f<float>(10, 3) and it would be the equivalent of using the recursive template struct above.
I decided to think big and used std::uint64_t as the base and unsigned char as the exponent type of the computation. Hopefully overflow was not going to be an issue…

Next I moved onto rounding the floating point number to an integer type (after it has been multiplied by 10 ^ N) and quickly realized a simple type cast was not going to cut it. std::round does much more than that; it considers how close the number to be rounded is to the integer representation of it, ex.: given 0.49 is it closer to 0 or 1. It then rounds it to the closest whole number. Moreover, it considers the sign and rounds in different direction if the number is positive vs negative.

This meant I needed to determine (at compile time) whether the number is positive or negative:

Compute the absolute value of a given number:

And round the number based on the proximity to its integer representation while considering the sign:

Putting it all together and adding some sanity checks resulted in this floating point, compile time (as long as all parameters are constexpr), rounding function which produced the same exact results as its runtime equivalent:

The if statements are there to guard against number overflows. It is better to not round at all in such cases than to return garbage values, or at least this is my attitude regarding error handling in this case.

Here is a test program I created while testing my implementation; it allowed me to easily compare compile time results against the reference std::round based approach.

1: 0.0000000000
2: 0.0100000000
3: 0.0120000000
4: 0.0123000000
5: 0.0123500000
6: 0.0123460000
7: 0.0123457000
8: 0.0123456800
9: 0.0123456790
10: 0.0123456789

Test program output.

The example program on GitHub: round.cpp. The floating point rounding implementation (sprinkled with comments and decorated with template concepts for good measures): round.hpp.

---

Given the way float and double are represented on the level of bits it is impossible to round them exactly. You can only do so much and come so close to being exact. Playing with the example program’s value and type of variable v as well as different parameters to setprecision stream modifier will illustrate what I mean…

---

---

UPDATE

Shout out to Ben from thoughts-on-coding.com for suggesting another runtime solution (code below)!

The purpose of this post is not to teach you about posix sockets; there’s plenty of that already. Instead I want to share two simple classes I implemented last night which encapsulate two types of tcp sockets: listening server socket and a client socket. These sockets as well as my recent serializer code will be the foundation of a light-weight RPC system I plan on designing and teaching to my colleagues at work and elsewhere.
I will try to illustrate what happened under the hood of frameworks like gRPC, Thrift, or a much simpler XML-RPC…

The server’s socket only job is to bind to a local port and listen for incoming connections. The client socket represents a connection to a server. It can be created either by the server socket using its private constructor, or by the user with its public constructor.

The difference between my implementation and what I commonly see online is that my design (not necessarily better than others) is event driven, meaning you do not pull on the client socket to receive incoming data. Instead the receive function dispatches an event when data arrives; all you have to do is put the method in a while loop to keep receiving incoming packets. Here’s the event handler and the receive loop:

Here the socket’s event handler converts the incoming bytes to a string, and if not empty prints it to standard output. The loop blocks until more data arrives, dispatches the event when it does, then goes back to sleep. This is a part of a simple echo client and server I created to test the socket code; it will be shown further down this post.

The server’s handler for incoming connections is a bit more complicated; it defines what to do with the newly created connection socket, as well as what that socket should do when it received data. You’ve been warned:

Upon receiving a new connection the handler prints out some basic info about the connecting machine, like host name, IP address, and the originating port number. It then tells this socket that, when data arrives on it from the client machine, it should convert it to a string, print it, and send the data right back to where it came from. It is not a true echo server, because the string is reversed before being sent to the client, but for the purpose of this exercise it will suffice. It only prints and sends the data back if it is not an empty string. Finally it looks for a special keyword ‘die’ that instructs the server to shut down.

The client on the other hand waits for incoming data from the server on the main thread, while a background thread reads user input, line by line, checks if it isn’t an empty line, checks for keyword ‘q’ which instructs it to disconnect from the server, and finally sends the data and waits for an event. This event is signaled only once the response comes back from the server, so that the keyboard input and programs output stay nicely separated on their own lines. Client loop below:

---

The socket code is located on my GitHub page: sockets.hpp, along with the echo client: echo_c.cpp and server: echo_s.cpp.