C’s secret operator: goes to

krzaq 2 Comments

Consider the following code:

1
2
3
4
5
6
7
8
9
10
11

#include <iostream>
 
using namespace std;
 
int main()
{
	int n = 10;
 
	while(n --> 0)
		cout << "n: " << n << endl;
}

Should it compile? If your answer is yes, what should be its output?

So I was cold last night…

krzaq Leave a comment 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

#include <atomic>
#include <chrono>
#include <iomanip>
#include <iostream>
#include <string>
#include <thread>
#include <vector>
 
using namespace std;
 
int main()
{
	auto known_cores = thread::hardware_concurrency();
	auto cores = max(known_cores-1,decltype(known_cores){1});
 
	volatile bool done = false;
 
	auto f = [&](){	while(!done); };
 
	vector<thread> v;
	for(decltype(cores) i{0}; i < cores-1; ++i){
		v.push_back(thread{f});
	}
 
	string temp;
	getline(cin,temp);
 
	done = true;
 
	for(auto&& t : v){
		t.join();
	}
 
	return 0;
}

Switch on strings with C++11

krzaq 5 Comments

Many programmers new to C++, especially those coming from languages that focus on programmer productivity instead of performance per Watt, are surprised by the fact that one cannot use the switch statement with anything other than constant integers, enums or classes that have a single non-explicit integer or enum conversion operator. It’s a fairly reasonable concern – after all, there are lots of use cases for such a feature.

With the introduction of constexpr in C++11 last year it could be expected that such expressions of any type would become legit expression for the case label, but alas, they aren’t. That being said, it’s not impossible to do – at least in some form – or I wouldn’t be writing this post. With use of two very nifty C++11 features a very similar result can be achieved.

On destructors, interfaces and memory leaks

krzaq 3 Comments

Over the last month and a half* one of the things I’ve been tasked with was removing memory leaks from our software. At first, it looked like as if I was presented with a daunting responsibility, with the VLD spewing several thousands of apparent memory leaks after just a sample test-run of our main program. Fortunately for me, the vast majority of the leaks seemed to originate from three interface classes.