Tag Archives: c

C++ as a scripting language

Jussi Pakkanen of Canonical writes:

With the release of C++11 something quite extraordinary has happened. Its focus on usable libraries, value types and other niceties has turned C++, conceptually, into a scripting language.

I don’t necessarily agree with everything on that post, but one thing’s clear: C++ isn’t what it used to be. With C++11 things have changed, a lot.

If I was to write a script it’d be python or a shell script, I wouldn’t even consider C++. But then again, if that is some script you need to run every once in a while or one that has to be run over and over again within a short period of time, why not just write it in C++ and compile to native code? It would run faster than any other scripting language would, without waiting for some runtime or VM to load up.

And now you don’t need to learn the ins and outs of pointer arithmetic to do this. 😉

print statement for C++

print-stmt is a Python-like print statement for C++. It’s damn easy to add it to the project:

The easiest way to use this is to clone this repo and copy the file print.h into your project. Then simply

#include "print.h"

at the top of the file, but after the system #includes.

This is pretty handy. Some example features:

  • bool prints ‘true’ or ‘false’
  • A type that defines a member function called c_str() is converted to a string by calling this function.
  • A type that has a begin() member function that returns in iterator but does not have a c_str() member function is printed like a list, e.g. [“one”, “two”].

On comparing languages, C++ and Go

Implementing the business card-sized raytracer in your favorite language and benchmarking it against other languages is the trend these days. It all started with Fabien Sanglard beautiful breakdown of the ray tracer written in C++.

Whilst the raytracer has been written in many languages since then, the major heat seems to be between C++ and Go. Henrik writes:

Because when you actually do code for performance, in those small bits of code in inner loops where it’s warranted to do so, your priorities change. The language you code in ends up being… less relevant, abstractions fade away and you try to divine communication directly with the hardware that will be running your code.

All these benchmarking might be a fanboy-thing, but they have certainly paved way to lots of insights.

Printing is not supported in this printer

This was posted in r/linux three days back. Turns out it’s actually been written by a human. And someone has spoiled the fun by sending a patch to gnome with the correct version of the error message: PostScript is not supported on this printer. That makes sense anyway.

Also discussed in the Comments section is the famous error message “Error: Success”. Apparently this mistake is common due to the fact that errors are communicated via a global errorno variable [source].

if (some_c_function() < 0) {
    some_other_c_function();
    print_error(errno);
}

This can be fixed without much hassle though.