Reading good code is essential to be a better developer. Searching good code is also important. Here are two good starters to begin with:
If you have a C# project and want to manage the assembly version info during automation build process such as the msbuild with Jenkins, then two options are available:
Here is a python build script to manage the version string within AssemblyInfo.cs and Package.appxmanifest.
Deferred caller, delegator implementation with variadic template
Recently I started playing with a small toy project – tiny web server with C++. The first requirement I wanted to implement was the ‘static type routing handler’ as shown from the crow project.
Which means, users should be able to register its routing handlers as the following manner:
In order to do that, two things come up to the list:
Regarding #2 issue, people would agree it should have been called ‘delegator’ or ‘deferred caller’. Its concept is basically same. Accepts a functor, saves it and calls it later. Then, how can I save functor which can have variadic number and types without using variant?
I got a hint from the Codeproject article, and implemented as follows. The routing_delegator structure is a container owns a pointer to the routing_record interface pointer.
‘to(F&& f)’ is lambda subscribing function. If user tries to pass a lambda to the function, you can figure out the lambda’s parameters by specifying operator() functor signature to a specialized template below. (refer to this SO link)
The typed_routing_recored is the template class, and lambda signature will be deduced, and the typed figured out all will be saved to the std::function.
How about calling the saved functors? The routing_record is an interface and declares one abstract function – which is ‘handle(void*)’. As you might guess from its name, void* is the key point to enable accept variadic sized, typed arguments.
If user calls ‘handle’ with parameters, routing_delegator::handle(Args&&… args) wconverterts those parameters into tuple and passes it to the routing_record::handle(void*) with its address
And finally child class’s handle(void*) implementation will casts into tuple again and delivers it to the actual std::function functor.
You can check out the all code here, https://github.com/heejune/tinyweb-cppserver/blob/develop/router.h
Please be warned, it’s still in development and all experimental code. Thanks!
Updated June 8th, 2017. This post was introduced to the Reddit /r/cpp soon after I posted and immediately got a feedback saying “both semantically wrong as well as poorly optimized” which is quite true. 🙂 So I’d like to recommend visiting the Reddit link and consider the comments before preceding or even better, refer to the better example introduced here.
Let’s talk about prime numbers. As an application/system software developer, it’s not often to deal with prime numbers in daily working environments. For me, I came across it while solving the Project Euler’s questions.
There’re a lot of good reads on the net describing what prime numbers are, how to get the numbers. So instead of a basic introduction, I’d like to talk about few tricks which can improve the performance of getting prime numbers.
Let’s first talk about the very basic approach to get prime numbers to compare with optimized version later.
You can check whether it’s a prime number or not when a number is given by following:
You’ll also get the Nth prime number based on the isPrime() function above by incrementing the counter when it returns true.
It’s self-descriptive and easy.
Can we improve the performance? Sure! There’s a ‘Sieve of Eratosthenes‘ algorithm, and basically, it does pre-calculate all the non-prime numbers when it found a new prime number by removing all multiples.
Here’s the implementation of the algorithm and its example.
And Lastly, can we improve the Sieve of Eratosthenes algorithm better? Yeah, it’s possible. I first saw the optimized implementation from one of the answers here: http://qa.geeksforgeeks.org/3090/how-to-find-nth-prime-number It’s tricky to understand at first glance in fact. So that I rewrote a little bit and here’s the result:
Comments are still Koreans and will be translated into English soon. Few tricks used to improve the performance are like following:
#1. Check against odd numbers only from line 26 – if (j & 1
#2. Getting the odd number index when an odd number n is given: (n – 3) >> 1
If I changed the unit into ns…
“date”: “06/05/17 01:06:32”,
You can access the sample here: https://github.com/heejune/SieveOfEratosthenes
It’ll require the google benchmark and few modifications to correctly link and search headers and libraries to build.
I’d like to share my short episode regarding UWP app debugging which happened today. Recent days I’ve developed a WinRT dynamic library which is based on cppwinrt. Most of time, I tested it with an unittest project and everything went fine. However, when I used the WinRT dll from actual .exe UWP application then very strange problem showed up.
As you see the below screenshots, the Visual Studio 2017 debugger shows nothing about local variables, auto and even watch window variables during the UWP app debugging.
Moreover, if I tried to type specific variables into Watch window or immediate window, the debugger shows ‘Internal error in the C# compiler‘ error message!
Later I noticed that the strange problem starts just right after the following output messages come up from Output window.
‘Example.exe’ (CoreCLR: CoreCLR_UWP_Domain): Loaded ‘Anonymously Hosted DynamicMethods Assembly’.
‘Example.exe’ (Win32): Loaded ‘C:\src\Example\build\Win32\Debug\AppX\Example.winmd’. Module was built without symbols.
‘Example.exe’ (CoreCLR: CoreCLR_UWP_Domain): Loaded ‘C:\src\Example\build\Win32\Debug\AppX\Example.winmd’. Module was built without symbols.
How just loading .winmd file could affect the weird debugger problem? Then I realized I used the same name(‘Example’) for the application and the WinRT module both. Which means I created the WinRT dll component as ‘Example.DLL’ and along with ‘Example.winmd’ as its descriptive winmd file name, of course. But I also named the target UWP application as ‘Example’.
So while debugging, the debugger tried to load the winmd file for it’s target WinRT component which was being debugged and suddenly the namespace seemed clashed within between the app and debugee DLL.
So, I changed the name of the WinRT component as ‘Example.Library.dll’ and problem solved!
Wrote this post in Jan 2015 as a quick draft, and remained as it is still today. I thought it’s not that useful so tried to delete it, but changed mind and released here. Hope it helps.
Recently I developed a logging server based on C#/asp.net on Windows 2008 R2 server. The server primarily does receiving log files from clients and write into database and also drop files to that server. After I released it to production, I met some unexpected issues.
1. Huge(99.9%) memory consumption issue
The logging server writes huge excessive IO to the disk and it instantly caused the os SYSTEM process to consume almost all physical memories. I searched online and analyzed it through the Sysinternals’ RAMMap. It turns out the OS’s system cache takes all the memories. You can find out details from following links:
http://www.microsoft.com/en-us/download/details.aspx?id=9258 Windows Dynamic Cache Service
KB article http://support.microsoft.com/kb/976618/
Lesson learned: Reduce the file IO as much as you can!
3. Deleting files from disk will take longer than you expect
Lesson learned: Does your server collect a number of files? Store it into the database directly.
As we discussed through Part I, co_wait keyword requires sort of “resumable thing”. So what if we want to use co_await with time delta?
For example, you can see the code which the co_await takes std::chrono::duration in order to suspend for the specified time from here: https://github.com/Microsoft/cppwinrt/blob/master/10.0.14393.0/Samples/JustCoroutines/Main.cpp#L31
The answer is the fact that vc++ compiler allows co_await to be overloaded. So, we can overload the co_await keyword and returns the “resumable thing” within the overloading implementation.
If you follow the resume_after(), then you’ll clearly see it actually returns the instance of resumable thing struct which contain implementations of await_ready, await_suspend, and await_resume.
Let’s test with another test sample here. https://github.com/heejune/wrl-cppwinrt-sample/blob/async-support/SampleLib.Shared/DemoCore.cpp#L81
In this sample, I called the winrt’s co_await as the above sample illustrated.
And if I step into the co_await… we hit the overloaded co_await.
Step in again, then finally it creates resume_after struct instance and calls the await_suspend.
It spawns timer thread with specified time, and finally resume_after::callback static callback is being called.
The callback will finally call resume().
And the resume() transfers its context into where the co_await being called.
And lastly, the coroutine function hits the co_return keyword after looping 5 times,
And reached the end.
Next time, I’d like to talk about another co_await adapter ‘await_adapter’ which makes winrt IAsync.. types possible to be awaitable. Thanks.