Tag Archives: ae

ae.utils.funopt

ae.utils.funopt is a std.getopt enhancer:

import std.stdio, ae.utils.funopt;

int run(bool verbose, string input, string output)
{
	// ...
	return 0;
}

int main(string[] args)
{
	try
		return funopt!run(args);
	catch (Exception e)
	{
		stderr.writeln("Error: ", e.msg);
		return 1;
	}
}

Running program --verbose input.txt output.txt will cause run to be called with the appropriate arguments. Continue reading

Functional image processing in D

I’ve recently completed an overhaul of the graphics package of my D library. The goals for the overhaul were inspired by D’s std.algorithm and std.range modules:

  • Present everything as small, composable components
  • Avoid implicit copying and prefer lazy evaluation
  • Use templates for efficient code

From its first iteration, all components of the image processing package were templated by the color type. This is not a conventional way to implement graphics libraries – most libraries abstract away the exact color type the image uses behind an OOP interface, or they simply convert all images to a single in-memory pixel format. However, for most cases, this is wasteful and inefficient – usually, the programmer already knows the exact format that an image will be in, with notable exceptions being applications in which the image data comes from user input (e.g. image editors). Instead, this library declares all image types as templates, with the type indicating the image’s color being a template parameter.

I’m rather pleased with the result of this overhaul, so I’d like to share some highlights in this article. Continue reading

Low-overhead components

My personal dream of an ideal programming language is one that allows defining flexible, configurable components that can be coupled together with very little overhead, producing in the end code that, if reverse-engineered, would appear to be hand-written and optimized for the specific task at hand. Preconfigured component configurations / presets would be available for common use, favoring safety and feature-completeness, but for performance-critical cases, the programmer could break them down and strip out unneeded features to reduce overhead, or customize by injecting their own components into the mix. Continue reading