Creating a static library is actually a very easy process that consists in just two simple steps:

1. Compiling source code into object code.
2. Archiving all the generated object code into a single file that represents the library.

Assume we have the following C source files that declare a 3-element vector type and a dot function that calculates the dot product among two vectors:

/** algebra.h **/

#ifndef ALGEBRA_H
#define ALGEBRA_H

typedef struct
{
	float x, y, z;
} Vec3;

void vec3Init(Vec3* v, float x, float y, float z);

float dot(Vec3* a, Vec3* b);

#endif //ALGEBRA_H

/** algebra.c **/

#include "algebra.h"

void vec3Init(Vec3* v, float x, float y, float z)
{
	v->x = x;
	v->y = y;
	v->z = z;
}

float dot(Vec3* a, Vec3* b)
{
	return a->x * b->x + a->y * b->y + a->z * b->z;
}

We can use the following two commands to create a static library:

gcc -static -c algebra.c -o algebra.o
ar -rcs libalgebra.a algebra.o

Please notice we have named our static library “libalgebra.a”. This is not just a random choice as a static library’s name must begin with “lib” and end with “.a” in order to be able to have GCC link new programs against it.

Now that our library is ready, we can redistribute it with the header file “algebra.h” so other programmers can use it in their applications.

In order to illustrate this point further, let’s write a simple C program that includes the header and links against our library:

#include <stdio.h> /* printf */
#include "algebra.h" /* our library's header */

int main()
{
	Vec3 a;
	Vec3 b;
	vec3Init(&a, 1.0f, 2.0f, 3.0f);
	vec3Init(&b, 3.0f, 2.0f, 1.0f);
	printf("<a,b> = %.2f\n", dot(&a,&b));
}

In the above example you can notice how we can liberally use data types and functions declared in our library as if they where part of this very same program.

Now, in order to compile, all we need is the “algebra.h” header, however, in order to have this program link, we have to use the “-l” (lowercase L) flag of the GCC compiler to specify our shared library, like so:

gcc main.c -L. -lalgebra
$ ./a.out
<a,b> = 10.00

Given the “-lalgebra” flag, GCC will look for a file called “libalgebra.a” (hence the importance in the library’s naming convention). The “-L” flag tells GCC where this file is located.

In this post I talk about a feature which is not frequently discussed, but must be taken into account when implementing a class hierarchy that leverages polymorphism as part of its design.

Let’s suppose we have a base class (conveniently named “Base”) and a derived class (conveniently called “Derived”) that extends “Base” through Public Inheritance.

If you don’t know what “Public Inheritance” means, all you really need to know for the purpose of this article is that there are three different kinds of inheritance in C++: public, protected and private. Public Inheritance is akin to inheritance in other programming languages such as Java, Python, Objective-C and C#.

Going back to our example, I’ve coded the Base and Derived classes’ interfaces in the following snippet:

#include <iostream>
using std::cout;
using std::endl;

class Base
{
	public:
		Base();
		virtual ~Base();
		virtual void printClassName() = 0; // =0 means "abstract"
};

class Derived : public Base
{
	public:
		Derived();
		virtual ~Derived();
		virtual void printClassName();

};

Now, for the implementation, I want to have every object whose class is derived from “Base” to have its classname printed upon creation. So, what I am going to do is add a call to printClassName() in Base’s constructor.

Base::Base()
{
	this->printClassName();
}

Base::~Base()
{
}

Derived::Derived() : Base()
{
}

Derived::~Derived()
{
}

void Derived::printClassName()
{
	cout << "\"Derived\"" << endl;
}

This is the program entry point:

// program entry point
int main()
{
	Derived* d = new Derived(); //print "Derived"
	delete d;
	return 0;
}

If you know your Patterns, by now you’ll probably have noticed by now that this example is just an implementation of the Factory Method pattern, where I’m relying in a virtual method for leveraging derived-class-specific behavior in the Base class.

The problem here is that, when we try to compile this program, we get the following error:

ale@syaoran factory]$ g++ main.cpp -Wall
Undefined symbols:
  "Base::printClassName()", referenced from:
      Base::Base()  in ccNxv98U.o
      Base::Base()  in ccNxv98U.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

GCC is warning us that there is no implementation for the abstract method “printClassName” in class “Base”, and it aborts!

Why does this happen? The compiler certainly should not be trying to find an implementation for an abstract method after all. The reason this happens is because of how inheritance works in C++.

When an object whose class is derived from another class is instantiated, what happens in C++ is that, in order to create this object, an inner instance of its base class is created first. In our example, when calling Derived’s constructor, Base’s constructor is called first.

This actually implies that the derived object does not exist until the the inner base object is created.

In turn, this means that the derived object’s vtable (used for implementing Polymorphism in C++) does not exist when the base class’ constructor is executing, so the compiler assumes that the base class’ implementation of the method has to be invoked, and that triggers the link error.

Even worse would be the case if the method was not abstract (but still virtual). In this case the program would build fine, but, at runtime you would find out that the base class’ implementation is being called instead of the derived class’.

How can you fix this problem?

Fortunately, the solution is simple, all you have to do is adopt the following gold rule:

Never call virtual methods on a partially-created object.

In order to fix our program, what I’m going to do first is to remove the printClassName call from Base’s constructor.

So, where should I place it now? Well, depending on the application it could be someplace or another. Since I would not like to change my design, what I’m going to do here is to separate the object construction into two phases: construction and initialization.

Construction will be carried out by the constructors, and initialization will be carried out by a special init() method that we can call once all the base objects have been created.

This separation will allow us to work safely, as all constructors will have executed when init() is called.

Applying these changes, the program will now look like this: the header for the Base class will include a new init() method:

#include <iostream>
using std::cout;
using std::endl;

class Base
{
	public:
		Base();
		virtual ~Base();
		virtual void init(); // new: two-phase initialization
		virtual void printClassName() = 0; // =0 means "abstract"
};

And the base class’ implementation will implement init() as to call our virtual method:

void Base::init()
{
    printClassName();
}

At this point the program should build fine and, when run, should produce the following result:

[ale@syaoran factory]$ ./a.out
"Derived"

As a final note, it would be possible to hide the call to init() into the Derived class’ constructor, but this will only work as long as Derived is the last class is the hierarchy.

As soon as we add a “Derived2″ class that inherits from Derived, we will have to refactor the call to init() into Derived2′s constructor, and so forth.

It would be interesting to see whether this problem arises in other programming languages. This will be left as an exercise for the reader.

You can find more information on abstract (pure virtual) methods and problems related to them here.

In my University, the programming language used for teaching how to program is Java. I was discussing with a colleague the disadvantages I saw in using it as a language for teaching programming basics and why, in my mind, it didn’t stack up against teaching a language such as plain C. The following story aims to reproduce the high points in the conversation.

Suppose you are a first year professor, teaching programming fundamentals, and I’m one of your students.

How would you start? If you’re anything like me, the first “hands-on” lab, you’ll probably write a classic “Hello World” program on the whiteboard and ask your students to copy that.

In order to do so, you instruct them to open up their “IDEs”, create a new class and copy that into a “method”…

Wait… what? As your student, chances are that by now, I’m probably wondering what an “IDE” is anyway.

As a teacher on a basic programming course, you’ll probably just tell me that IDEs are used for programming and that I’ll most likely have to use that every time I want to write a program (otherwise, what are we using it for?)

Okay, but “why don’t I have to use an IDE every time I want to use an application in my Windows”? Bam… now you must either explain the difference between code “in development” and code “in production” or ask me just to trust you and please focus on the example on the board for now.

Okay, let’s move on. You said I had to copy what you wrote into a “class’ main method”… What is a “class” and what is a “method”? Ahh, okay. Here, you are trapped. Clearly these are OOP concepts, and you certainly don’t want to start digging into that before your students even write their first “Hello World” application. All you can do here is to ask them, once again, to just trust you by saying that “that’s the way things work in Java”.

So, your students have finally created a project in an “IDE”, created a “class”, defined a “public static” “method” and wrote the snippet you typed at the whiteboard in their IDE’s text editor.

The final code looks something like this:

public class HelloWorld
{
    public static void main(String[] args)
    {
        System.out.println("Hello, world!");
    }
}

They press “Play” on their “IDEs” and it just works. Everything is good.

Quick question: how many things in this code do you think are completely strange to your students? Probably all of it, since it’s the first time they’ve seen a program being coded. That’s okay, but how many of these things do you think are feasible to be explained in a programming 101 course? just println, maybe?

Why? Because in order to explain what a “class” is, what a “method” is, what “public”, “static”, “String[]“, “System” and “out” mean, you have to start digging into OOP concepts from day one. And you don’t want to do that, because chances are 1) you’ll end up confusing everyone and 2) most of that stuff will not really be useful for the course at all!

So… if teaching this way seems to be so complicated, why are we using Java for teaching programming? Well, I think we shouldn’t. C would be a much better candidate.

Compare the previous Java program with the following C equivalent:

#include <stdio.h>
int main()
{
    printf("Hello, world!");
    return 0;
}

Which one do you think is easier to explain? At most, what your will probably end up asking is “what does #include mean?”. You can just answer that it’s a file where printf is defined. That’s it. No strings attached. No “public static void Main(String[] args)”. Just a plain and simple printf.

What about all that “IDE” mess? Well, it turns out you can just use a plain text editor with some syntax highlighting and a C compiler and you are good to go. Compiling C code is extremely simple, if the system is correctly configured. Just issuing a command like the following will be enough for producing an executable file:

gcc hello.c -o hello.exe

It’s that easy. And best of all is that you get an executable. A plain .exe file on Windows. That’s what your students are expecting. That’s what a program is to them. An .exe file! In Java, your compiler would’ve generated a “.class” file, and then you would have to teach your students how to invoke the Java Virtual Machine, explain what a Runtime is and why is it needed to have your code (which is already complied, isn’t it?) run.

Another final advantage? By asking them to compile their code by hand, you indirectly have them learn how to use the Terminal application (believe me, most students don’t know what that is or how it’s used nowadays) and you are laying the foundation for them to learn how to use a non-GUI operating system.

You can achieve all this (and more) without having to ask them to “trust you” or to hold their questions for one to two years, until they have their first OOP course.

You could argue that, even though Java might seem more complicated at first, it’s more popular and thus it could never be a mistake to teach it. I completely agree, but I think it should be taught as a second or third language, not as the first one. Not only does Java require the student to wait until he or she goes through 2 or 3 programming courses in order to be able to fully “get” the language, but also, there are some concepts that they will just never learn this way, such as memory management or pointers.

So, please, if you’re a programming 101 teacher who’s doing Java, I ask you to reconsider. C does not have to be hard, and your students will thank you for conducting a exhaustive, self-contained course.

Although the compiler most commonly used on Mac OS X is the GCC compiler, the version supplied by Apple has a handful of modifications which are specific for OS X. In particular, the -shared compiler flag, used to create Shared Objects under GNU/Linux based systems, has no effect.

In spite of this, Apple did introduce its own mechanism for creating Shared Objects along its GCC extensions. Assuming we have a file called mylibrary.c, which contains the source code for our library, we should invoke GCC like so:

gcc -dynamiclib mylibrary.c -o mylibrary.dylib

If the compiling process succeeds, this command should create a file called mylibrary.dylib, which can now be dynamically linked from other applications.

Unlike Linux based Operating Systems, Mac OS X seems to automatically add the current working directory to the DYLD_LIBRARY_PATH environment variable (an equivalent to Linux’s own LD_LIBRARY_PATH), thus it should not be required to modify this variable in order to have our applications link against the newly created library at runtime, unless, of course, we wanted to move the Shared Object to a directory different from where our process will be executing.

Finally, it should be taken into account that this mechanism is just a simplified example. A correct way to manage the library creation process would be by means of make or equivalent software construction applications, which provide several advantages to software developers.

Accessing a computer from your local network usually just means assigning an static IP address to your desktop and have it though that IP address every time. The peculiarity with desktop Linux distributions -such as Ubuntu or Fedora- is that they now ship with an utility called NetworkManager which tries to make it “simple” to manage networks. The problem with NetworkManager is that, in my opinion, it was designed mostly for a mobile scenario, where a laptop moves around and tries to join different networks along the way, but this is rarely the case for a desktop computer, which just connects to the same network every time. Furthermore, depending on your router configuration, it may prove difficult to impossible to have a NetworkManager-enabled desktop PC to have the same IP address assigned every time the computer joins the DHCP network.

In this post we will present a method for completely disabling NetworkManager from your Ubuntu desktop system and, using the old-school Linux networking facilities, have your desktop computer’s network connection set up your way, offering services to other computer without sacrificing Internet access.

This article has been tested on Ubuntu 8.04.

Step 1 – Disabling NetworkManager

NetworkManager handles all network connections, preventing us from manually configuring our host the way we want to. The first step to take consists in disabling NetworkManager once and for all. We use the following Terminal commands (as root):

sudo service NetworkManager stop

sudo rm `find /etc/rc* -name “*NetworkManager”`

The first command stops NetworkManager, whereas the second one removes every NetworkManager entry from the Linux runlevels, effectively preventing it from automatically starting the next time the system is started.

Although it is not strictly necessary, it would be “elegant” to remove the GNOME NetworkManager applet from the desktop environment as well. This can be disabled from the “System -> Preferences -> Sessions” configuration panel just by unchecking the corresponding entry. This will prevent the applet from automatically staring the next time we log in. If we wanted to stop the currently executing applet without having to logout and log in again, we could stop the “nm-applet” or “nm-gnome-applet” process from the Terminal using the kill command.

Step 2 – Configuring our Network Interface

Without NetworkManager in the way, we can define and configure our Network Interface the way we want to. We just need to edit the /etc/network/interfaces file and add the following configuration. We will name our interface “eth0″ and assign an IP address of “192.168.1.50/24″, but you can set the interface to any values you desire. This has to be done as root.

auto eth0

iface eth0 inet static

address 192.168.1.50

netmask 255.255.255.0

broadcast 192.168.1.255

gateway 192.168.1.1

The first line is of special importance. It declares eth0 as an interface that has to be enabled automatically when the system is booting. Now we must set the DNS servers this host will use for resolving domain names. In order to set this servers, we must edit the file: /etc/resolv.conf (again as root) and we add the following lines (this is Uruguay-specific):

nameserver 200.40.30.245

nameserver 200.40.220.254

Once the changes have been written to disk, we can restart the network in order to make sure our changes were correct:

sudo service networking restart

Having restarted the host’s network configuration, we can verify the active interfaces using the “ifconfig” command. If our changes were correct, we should now be connected to the network, being able to browse the Internet without difficulties and with an static IP address of 192.168.1.50.

About three years ago, I decided Spanish was the way to go (being my Mother Tongue after all), but at times, I couldn’t stop wondering if I was sort of crippling my blog by limiting it to the Hispanic society exclusively.

All this wondering was more than just occasional thoughts it seems, since as of today, I finally decided to launch an English blog.

I wanted to consolidate several websites and ideas under the same “roof “, and this is it. Here I plan to publish tutorials, personal info, and thoughts about technology (specifically Computer Graphics and Linux and Mac development) as well as about my company, Algorithmia.

Feel free to look around. I hope you find the site useful. Welcome.