In the good old C++, types are distinct based on just their names, so one could have two empty classes A and B and instances of each could not be mixed up in function calls expecting one type or another. A template class instantiated with two different types, such as X<A> and X<B>, would also yield two distinct template instantiations that could not be mixed up in function calls and assignments.

Nowadays, structural typing in TypeScript focuses on what the type contains, and the type name doesn't play as much of a role in assignments. This logic extends to type parameters, which only have meaning when they are referenced in specific ways in their contexts.

This arrangement makes it quite tricky to figure out some of the typing errors, which sometimes sound more like puzzles rather than meaningful errors.

Ever since I started using a 4K monitor, I noticed that I have to adjust browser zoom almost for every site where I wanted to read content and not just glance at some excerpt. Looking closer at CSS styles on some of those sites I found that most of them used pixel unit sizes for pretty much everything, including fonts. I was puzzled at first by the widespread use of a technique that cannot compute sizes in a predictable way across various displays and devices, but further investigation confirmed that it was done on the advice of the CSS specification.

Being able to run server-side JavaScript predates Node.js by quite a bit. In early 2000's I was working on an application server called Tango and one of its features was the ability to run server-side JavaScript code in Mozilla's JavaScript engine, SpiderMonkey. Later on, I started using ASP with JavaScript, which worked just fine on its own for smaller tasks and for heavy workloads I interfaced ASP/JavaScript via COM with C++.

Eventually, Classic ASP got too slow and too outdated and the choice was either to move to ASP.Net or Node.js, which was picking up steam at the time. I ran a number of performance tests while trying to figure out a good path for transitioning a large application off Classic ASP and without concurrency Node ran JavaScript code incredibly fast, leaving equivalent ASP.Net tests far behind, but multiple concurrent requests made it evident that the more JavaScript is in a Node application, the slower it runs. This pretty much is still the case today.

This question seems silly on the surface, to put it mildly, as both languages are compiled to produce most optimal code, often by the same compiler engine using the same optimization techniques. However, if widely-used programming practices and common libraries are factored into this mix, the result is not as straightforward as it may seem.

Google's JavaScript engine is a wonderful C++ library that works on many platforms and runs JavaScript code with speeds that are comparable with a natively built and fully optimized C++ code. Awesome. Sign me up. All I need to do now is to build this wonderful library, which should be as easy as saying: "Hey, Google!". Right? I wish... Once you start the process, you quickly learn that writing up-to-date documentation isn't one of the qualities Google excels at.

The C++ #include directive is probably the most commonly misused construct of the language. Generally accepted and rarely disputed practice today is to use angle brackets for standard headers and double quotes for internal header files and, sometimes, for 3rd-party libraries, which at the first glance is well-aligned with the C++ standard that suggests the following use of the #include directive:

Note: Although an implementation may provide a mechanism for making arbitrary source files available to the < > search, in general programmers should use the < > form for headers provided with the implementation, and the " " form for sources outside the control of the implementation.

A few days ago a developer asked me if we intend to replace all archaic printf-style calls within the project with modern, object-oriented string stream equivalents. I heard this sentiment many times over the years, often substantiated by the fact that buffered stream operations are faster than frequent parsing of the format string. Let's test this theory and format a simple string in a loop using both methods.

This site was originally written in ASP JavaScript, which worked great, but lacked a couple of things, like being able to upload files without having to parse multipart HTTP requests. So, I decided to move the site to ASP.Net to take advantage of the new functionality offered by the .Net framework, while keeping the implementation written in JavaScript.

A couple of days ago a developer asked me why their Visual Studio 2005 debugger no longer breaks when a C++ exception is thrown, even though C++ exceptions were not suppressed in the exception configuration and the debugger was attached to an IIS worker process to debug native code.

Thinking that something might be wrong with how C++ exceptions were handled, I stuck a statement dereferencing a NULL pointer into the code:

*(char*) 0 = 0;

Some STL containers, such as std::map, are designed to use std::pair to maintain keys and values. A special convenience function, std::make_pair, is often used to create pairs without having to specify template argument types. Typical code that makes use of an STL map looks like this:

std::map<std::string, std::string> m;		// map<key,value>
m.insert(std::make_pair("1", "one"));
m.insert(std::make_pair("2", "two"));
printf("%s", m.find("1")->second.c_str());	// prints "one"

While most content management systems, such as blogs, allow users edit HTML directly, more specialized ones, such as discussion forums, allow users to use alternative syntax that is easier to control and adapt to particular needs. BBCode, which stands for Bulletin Board Code, is one example of such alternative.

A couple of days ago I came across JavaScript code in which a developer replaced an array object with a string and forgot to change the subscripting operator to a charAt() call, so the code looked like this:

var s = new String("0123456789");
var c = s[4];

Much to my surprise, the code appeared to work just fine when compiled in ASP and it also worked in FireFox, Opera, Chrome and Safari, although failed in Internet Explorer.

FCK editor comes with a neat file browser that comes in very handy when adding images or links to other files located on the server. The editor ships with source files in all poplar scripting languages making it possible to use the feature with a minimal effort. However, ASP code was written in VBScript and didn't integrate well into my security model, so I decided to write my own one weekend.

Sometimes C++ enum's are used to define bit flags, such as read/write attributes, which can provide better type checking at compile time. However, when performing bitwise operations on enum values, one has to cast resulting int's back to enum's, which bypasses strict type checking and makes enum definitions somewhat pointless.

I was working on a 64-bit VC8 project and the executable built in release configuration kept crashing at run time with evident traces of stack corruption. A debug build or even a release build with all optimizations disabled worked fine and so did a fully-optimized 32-bit build.

The problem with debugging optimized release builds is that many variables are passed through registers and stack frames are omitted, making it more difficult to trace parameters and local variables. Debugging x64 builds is even more difficult because the optimizer heavily uses additional 64-bit registers and hardly puts any parameters on stack.