techMusings

..and make it donkey easy to build your projects. I was looking for C/C++ JSON libraries. JsonCpp seemed to fit the bill, but has silly build bits. They do have the amalgamated version, but it's not in the latest stable release. They seem to use scons python build tool for the normal src build. Hadn't heard of that one, so not a great start. Fortunately, the amalgamated one just needed:

g++ main.cpp jsoncpp.cpp -I . -DJSON_IS_AMALGAMATION

I have some chunky JSON files (> 100MB), so wanted a streaming API. I found YAJL, but it failed to build on cygwin.  A symlink (api/yajl -> api), a file copy (yajl_version.h.cmake -> yajl_version.h), with a single line change (defining YAJL_VERSION to be a number), and presto:

gcc *.c -I api

It's much easier to understand the dependencies like this, I reckon, than trying to work out why the build system is breaking.

Labels: build tools, c++

I've no idea why this information is not easily findable on microsoft.com: http://www.cygnus-software.com/papers/precompiledheaders.html

Worked perfectly, with the only caveat that I had some C files (in a mainly C++ project) which are fairly standalone (and 3rd party) so didn't want to add stdafx.h to them -- selecting the .c files in the solution, right clicking and (for all configs again) switching off precompiled headers for these files gave me a clean build at 10% of the time.

The double level pch appeals to some degree for when we have a stable code base and just the plugins/leaf nodes are changing -- then again, that's probably time for a library / real plugin design. Right now compiles are fast enough to not bother I reckon.

Labels: c++, pch, precompiled headers, stdafx.h, VS, VS2010

I'll try to avoid a tirade about the state of C++ build tools, but I was having a problem persuading the https://github.com/fsaintjacques/disruptor-- project to build. Given that the code is mainly headers (which I like since I consider most cpp files a code smell), the pain was disproportionate. Anyway, here's a compile command for those who just want to run the code (save as a script):

#! /bin/bash

export LD_LIBRARY_PATH=/opt/gcc-4.6.2/lib64/:$LD_LIBRARY_PATH

g++ -I .. \
    -I /opt/boost/linux64/1.48.0/   \
    -std=gnu++0x \
    -D_GLIBCXX_USE_SCHED_YIELD -D_GLIBCXX_USE_NANOSLEEP \
    -lboost_unit_test_framework -L /opt/boost/linux64/1.48.0/lib \
    -O3 -march=native -DNDEBUG \
    -o ${1%.*} $1

Labels: autoconf, automake, c++, disruptor

Just created this, and thought it worth preserving (not sure about lifespan of: http://pastie.org/981696):

public class ${argType}Event extends GwtEvent<${argType}Event.${argType}EventHandler> {

 public interface ${argType}EventHandler extends EventHandler {
  void on${argType}(${argType}Event ${argType});
 }
 
 public static final Type<${argType}EventHandler> TYPE = new Type<${argType}EventHandler>();
 private final String reason;

 public ${argType}Event(String reason) {
  this.reason = reason;
 }

 @Override
 protected void dispatch(${argType}EventHandler handler) {
  handler.on${argType}(this);
 }

 @Override
 public com.google.gwt.event.shared.GwtEvent.Type<${argType}EventHandler> getAssociatedType() {
  return TYPE;
 }

 public String getReason() {
  return reason;
 }
 
 public String toString() {
  return "${argType}Event:"+reason+":"+super.toString();
 }

}

GWT events are key to building a maintainable GUI I think, but it's a pain to cut'n'paste code for it.

Labels: Eclipse, event, GWT

Good article on looming bandwidth issues in mobile data (via @timbray).