Andre's Blog
Perfection is when there is nothing left to take away
CSS font size - it's not what it seems

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.

Node vs. JS

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.

Is C++ slower than C?

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.

Building Google v8

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.

You #include'd!

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.

std::wstringstream vs. swprintf

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.

Moving blogs to ASP.Net

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.

Break, break, dammit!

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;
STL matchmaking gone bad

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"