The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog. It was a crazy year with relocating the whole family to the USA and trying to find a the best location and company to work for. The blog was not that active during 2013 but will be more active in 2014.
Coming up is the pending, official, release for G3log with some C++11 concurrency tech that might interest some coders.
A whole other story that is in the queue of tales to write is the whole moving process and what we learned from it. There should be some goodies there for other people who is in the process of moving across the pond.
Below is an excerpt of the blog report.
Happy New Years!
The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 28,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 10 sold-out performances for that many people to see it.
Click here to see the complete report.
At reddit I found that it was possible to get futures and std::thread to play nice on Linux/Clang.
I have updated my previous post “g2log with Clang++” with the details so that you can get Linux/Clang (and g2log) with all the bells and whistles of C++11.
All the clang limitations on G2log is therefore removed and Clang users can now enjoy the fully featured G2log.
I am currently working with G3log and Clang. So far G3log supports Windows (VS2013, mingw) and Linux (g++) and I hope to get Clang up and running.
After several requests to release g2log with Clang support I finally yielded. From today g2log will have experimental support for Clang. Why the Clang support is experimental is just because I have no OSX machine to test it on. So all Clang testing was done on Linux.
Clang users on Linux and OSX are welcome to try it out: https://bitbucket.org/KjellKod/g2log.
For the last couple of months I have tried to study up for coming job interviews. This typically means finding an area where I am rusty and make it shine. As I do this I find myself going through my old favorite IDEs and discarding them.
Instead I find myself using IDE combos that I never would have considered before and as a result I am starting to visualize the way I would like to work with my IDE.
C++11 time, part II. Part I you can read here:
Several of the time functions in C++ are not thread-safe and using for example
std::localtime or std::asctime can have unwanted side-effects. Other thread unsafe c-library functions that come to mind are std::ctime and std::gmtime. The compiler will likely point out any use of these unsafe functions by generating warnings.
It is nice to know that there is an easy way to make your time code thread-safe and as a bonus getting rid of the compiler warnings.
Depending on your platform the
std::localtime can be replaced for platform dependent
std::ctime have _r and _s equivalents but a much better option is to use the
std library functions
That is really all you need to avoid problems. Do you want to know details? If so, read on …
In 2009 I wrote about a horrid lock-free Single Producer, Single Consumer Circular Fifo that I had seen in use in the industry. I tried to pick it apart and see what made it tick. Was it broken beyond reason or could it actually work? It was an attempt to understand without recommending the sketchy platform hack.
Of the C++ topics I have written that first article seemed to attract the biggest crowd at CodeProject. A double-edged sword to say the least since I liked the feedback but did not like the thought of happy coders using something that was not at all kosher. Something that could break their shiny code when they least expected it.
Now with C++11 <atomic> it is a snap to write the wait-free, lock-free simple Single Producer, Single Consumer CircularFifo. Of all the lock-free structures out there, this got to be the easiest to grasp.
I just finished overwriting my old article. The old article is still saved with a nice revision tag but you have to dig to get to it.
For early reviewers here is my own snapshot of the revitalized article. Its’ not yet spell corrected mirror but with nicer formatting can be found here CodeProject: Lock-Free Single Producer [...]
My obstinate anti-LinkedList blog entry which turned into a CodeProject article recently took some heat from a former college, David.
I think his objections were smart, to the point and important. Many of his objections came up earlier at CodeProject but instead of expecting the reader to read through all the comments there and here I decided to take a different approach. Instead of doing an easy-to-miss reply in the comments I decided to do a blog sort-of reply here. I am sure many has the same objections and questions as the ones earlier asked, and it is good to bring them into the light (questions + people ;). This blog post will highlight some issues that were not clearly explained or could be misinterpreted.
Some cut and paste from the reply gives a nice picture of what we should all strive for:
What you should do is to look at your problem and create the most suitable solution for it
I would try to encourage them choose the correct one [kjell: data structure choice] for the specific problem! [...]
Well put. I could not agree more.
Some of the irate comments I have received I can sympathize with. My anti-LinkedList entry can be argued used somewhat contrived examples, even if I actually used real-life examples that I have encountered.
David was so kind as to suggest a few examples when LinkedList should shine. Let us look at them and compare. Let us also quickly do a recap of what the article showed.