Blog Image

MikeK's software notebook

What you will find

This used to be the place where I wrote stuff I was thinking about while working on the Mozilla project.

Maybe in the near future I'll start to update it again as I'm involved in a couple of new open-source projects - updates pending...


Mozilla coding hints Posted on 22 Apr, 2009 23:14:28

Looking at the Mozilla code, you have probably come across the NS_DECL_ISUPPORTS and NS_DECL_ISUPPORTS_INHERITED macros. These are actuall not Mozilla specific but rather part of XPCOM.

The purpose of these macros are reference counting and interface detection.

So instead of implementing the:

NS_IMETHOD QueryInterface(REFNSIID aIID, void** aInstancePtr);
NS_IMETHOD_(nsrefcnt) AddRef(void);
NS_IMETHOD_(nsrefcnt) Release(void);

functions that are declared in nsISupports, you add the NS_DECL_ISUPPORTS macro to your class definition, like:

class nsMyBasicClass : public nsISupports
// Basic refcount and interface detection macro

Now, if you inherit from an interface that inherits from nsISupports, then you need to specify this interface too:

class nsMyInterfaceImplementerClass : public nsIMyGreatInterface
// Basic refcount and interface detection macro

If you inherit from multiple interfaces then you just list them all instead of NS_DECL_NSIMYGREATINTERFACE in the example above.

The above “macros” take care of the prototyping of the functions, you also need to use some “macros” to implement the body of the functions.

In the case where there is a direct inheritance from nsISupports the “macro” should be:


(Just put it anywhere in your source file)

If you implement multiple interfaces you replace the 0 in the end of the name with the number of interfaces that you implement, and list the names of these interfaces after the name of the class that implements them:

NS_IMPL_ISUPPORTS1(nsMyInterfaceImplementerClass, nsIMyGreatInterface)

In the case where you inherit from multiple classes that already implement the nsISupports interface, you can get an ambugity as to which functions to call to do the reference counting – to solve this you must use the NS_DECL_ISUPPORTS_INHERITED “macro” instead of the plain NS_DECL_ISUPPORTS “macro”

Remember that all pointers to interfaces/classes should use a reference with the type:


rather than a nsMyType*, as you don’t wan’t to take care of the reference counting manually.

Build systems part2

Random Posted on 22 Apr, 2009 00:20:17

As I posted some hours ago, I was quite frustrated about the build system, it haven’t lessened in the meantime smiley So initially I got it linking again on my system back home, but as that is a 64-bit Ubuntu and my laptop is only running a 32-bit version it didn’t help me much except for verifying that the source code was OK. (My outgoing internet connection is too slow for me to run any GUI apps remotely, gotta upgrade it when I come back home)

So knowing it could be the build system I tried about every trick that I knew of to trigger what ever it is that needs to be triggered – deleting the objdir, deleting the generated/cached files in the source tree…. but still I got the same linker error smiley I even went to the point where I started using a hex-editor to verify that the version of the libraries that I was linking with did indeed have the name in them that the linker was complaining about – they did…

So in a last desperate attempt to bypass the problem I changed the order of the packages in the “” file, so the package (“gstreamer-base-0.10”) that contained the lib (“libgstbase-0.10”) that had the symbol (“gst_push_src_get_type”) became the first packaged mentioned. A rebuild later (now on my fast-but-slow-compared-to-my-desktop laptop) the error had gone – the software now linked smiley

Guess I shouldn’t have been that surprised, as it was the same pattern I saw earlier today. Being curius, I tried to move it back, and guess what…. it still compiled and linked – one word: ARggggghhh – another day almost wasted smiley