I have recently come across a website that proposes a series of programming challenges throughout December, until Christmas. It’s called Advent of Code and this is the fourth year it runs this competition. Every day, a new challenge is made available, and each challenge has two parts. You only get the second part after completing the first. It does not matter what programming language you use for solving the challenge, nor how the code looks or how fast it executes. The only thing that matters is the result.
I recently migrated an old VC++ project to use the Visual Studio 2017 toolset and when compiling I run into the following errors about redefining the structure tagTOUCHINPUT.
The C++ community has worked hard in the past decade and more to move the language forward, to enrich but also simplify it, and to adopt new paradigms and coding styles. Yet, a single topic, a simple matter of style is splitting the community, in a pure Swiftian manner: the use of the const qualifier that some prefer it on the left of what it modifies, as it has been the de facto standard for decades, and which is now called West const, or to the right of that it modifies, that is a style that more and more people are adopting, and which is now called East const. I don’t particularly like this terms, I would rather use left const and right const, but if this is what the community prefers to use let’s call them so for consistency.
I have been working lately on a C++ library for handling monetary values, currencies, rounding and other related features. It is called moneycpp and it’s a C++ 17 header-only, cross-platform library available on GitHub.
The library is intended for being used in a variety of types of application including ERP systems, banking, finance, insurance, games, and others.
The following is a list of its core requirements:
Although this feature is available for years in Visual Studio, I only recently discovered this gem that allows rapid generation of C# classes from either JSON or XML.
Here is how it works:
- Copy the JSON or XML code to the clipboard.
- In Visual Studio, go to Edit > Past Special and chose either Paste JSON as classes or Paste XML as classes.
Unit testing is usually used for testing public types and members. However, there are cases when you might need to test types or members that are not public. These could be internal classes or private helper methods, for instance. Whether that is proper unit testing or beyond its scope is not a discussion that I want to get into here. However, in this post, I will show how you can unit test non-public types and members from .NET assemblies.
When faced with the need for testing non-public types and members you can use several approaches:
- change the accessibility to public; you can do that perhaps only for debug builds and keep the intended accessibility in release builds by using conditional compilation.
- provide public members of a class that invoke private ones;
- use reflection.
The first solutions involve changing the API only for the sake of the testing. The last solution avoids that but requires more work. To help with that, the Visual Studio unit testing framework provides some helper types that enable you to focus on the actual testing and be less concerned about the reflection details.
I recently installed a fresh copy of Visual Studio 2017 on a new machine and went on to build several projects some of them being VC++. The trouble was that I immediately run into a problem (actually the first problem was that MFC & ATL were missing because I forgot to check that in the list of Individual components so I had to install them separately). The problem was an error with a missing new.h header:
1>c:\program files (x86)\microsoft visual studio\2017\enterprise\vc\tools\msvc\14.15.26726\atlmfc\include\afx.h(62): fatal error C1083: Cannot open include file: 'new.h': No such file or directory
Here is my list of good reads from September:
Class template argument deduction is a useful feature in C++17 that helps developers to simplify the code by avoiding writing the template argument list when initializing objects of class templates (or when performing function-style casts). The compiler provides an implicit set of deduction guides, which are fictional function templates for a hypothetical class and uses them to perform template argument deduction and overload resolution. However, you can extend this set of deduction guides with your own, and in some cases, such as for aggregate types, you need to do so.
Here is my list of good reads from August: