C++ Dependency Injection

Frequently Asked Questions

What's Wallaroo?

Wallaroo is basically a dependency injection library for C++. It provides a way to build and wire the objects you need in your application using strings and/or loading a configuration file. With Wallaroo, you get rid of new constructs. In this way, the name of the concrete classes you want to use are no more carved in the stone (i.e. in your code). Your classes can be created starting from a specifications of some kind (configuration files, DBs, environment variables, or a mix of them).

Is it multiplatform?

Of course it is. Wallaroo is implemented by using standard C++ and (optionally) boost libraries and does not make assumptions on the underlying system. Thus, you can use it on every platform providing it has a decent C++ compiler.

Then, why do you provide the .zip and .tgz version in the download page?

Wallaroo is delivered in a ZIP file for Windows users and in a compressed TAR file (.tgz) for Unix/Linux users. Both archives contain the same files, the only difference is that all text files in the ZIP files have line endings suitable for Windows (CR-LF), while the text files in the TAR file have line endings suitable for Unix/Linux (LF only).

Do I need to compile the library?

No, wallaroo is a header-only library, so you don't need to compile it.

Can I use Wallaroo into an embedded system?

Of course. I'm using it in several embedded projects, and it works great.

I also used Wallaroo with the cross-compiler for the ppc 6xx architecture.

Does Wallaroo use C++11?

Of course. Wallaroo can use some of the new C++11 features instead of boost libraries.

Do I need boost to use wallaroo?

Short answer: no.

Long answer: it depends. To get rid of boost libraries, your compiler must support C++11 features (basically smart pointers) and you must not use XmlConfiguration nor JsonConfiguration classes.

How can I tell wallaroo not to use boost?

Wallaroo should automatically detect if your compiler is C++11 compliant. If it is, wallaroo interface will use std smart pointers (e.g.: std::shared_ptr) instead of boost smart pointers (e.g.: boost::shared_ptr).

By now, wallaroo automatically detects only gcc and visual C++ versions (if you're working with another compiler, please contact me to help me verify the auto-detection mechanism).

You can change the default behaviour of wallaroo by using two compile time symbols. To impose the use of boost libraries, you can define the symbol WALLAROO_FORCE_USE_BOOST. In the same way, to impose the use of std smart pointers in wallaroo interface, you can define the symbol WALLAROO_FORCE_USE_STD.

I have some trouble with constructor parameters

Maybe you've encountered the limit on the number of parameters you can have in your wallaroo::Part- derived classes.

For classes defined in the main address space, you can have up to 2 constructor parameters. For classes defined in a shared library, your classes cannot have constructor parameters.

The right way to deal with this limit is to use wallaroo attributes instead of constructor parameters. Basically, you can substitute the constructor parameters with wallaroo::Attribute data members: they're typed and wallaroo can initialize them through the usual DSL or the configuration file.

Can I register template classes?

Yes, you can register all the template specializations you need. E.g.:

WALLAROO_REGISTER( Foo< double > )

Then, you can use the strings Foo< int > and Foo< double > in wallaroo DSL, XML and JSON.

Pay attention that:

But you have the two following alternatives (valid in general).



typedef Foo< int > IntFoo;
typedef Foo< double > DoubleFoo;

Then, you will use the strings IntFoo and DoubleFoo in wallaroo DSL, XML and JSON.

Manually create your classes in the DSL


catalog.Add( "double_foo", make_shared< Foo< double > >() );
catalog.Add( "int_foo", make_shared< Foo< int > >() );

I put my classes in shared libraries, and I get a WrongType exception!

If you get a WrongType exception when you try to extract an object from a catalog, maybe you're using an old version of gcc. In that case, you should tell the compiler to provide RTTI across process boundaries, by using the flag -E:

# extract from roulette sample Makefile:

# NOTE you need to pass -E to the linker to provide RTTI across process boundaries!
$(EXE): $(OBJ)
    $(LINK.cc) -Wl,-E -o $@ $^

# NOTE you need to pass -E to the linker to provide RTTI across process boundaries!
%.so: %.cpp %consolefactory.cpp %.h %consolefactory.h
    $(LINK.cc) -fPIC -shared -Wl,-E -Wl,-soname,$@ -o $@ $^ $(LFLAGS) $(CFLAGS)

If I put my classes in static libraries, Wallaroo does not find them!

The linker does not link static libraries if the main program does not explicitly reference any symbol contained inside them. However, Wallaroo registration mechanism requires the linker to put everything inside the final executable, even those symbols that are never referenced. That's why your executable can't find your classes.

When you put your files in a static library, you are asking the linker to use only those files which resolve an undefined external. That's what a library does. On the contrary, wallaroo main goal is exactly to not specify in code which concrete classes (i.e. linker symbols) you want to use. So, maybe a static library is not what you want: you should consider the use of shared libraries or linking object files directly.

However, if you really need to put your classes in static libraries you have two options:

    gcc -Lmy_libs_path -lmain -Wl,--whole-archive -lMyLib1 -lMyLib2 -Wl,--no-whole-archive -o exe_name
  • with every compiler you can add a dummy symbol to your library and explicitly use it inside your main program.
  • // static library
    #include "wallaroo/registered.h"
    // define a dummy symbol (unique per library)
    int PullInMyLibrary() { return 0; }
    class MyPlugin : public wallaroo::Part
    // main program
    // force the linker to import the library
    int PullInMyLibrary();
    static int dummy = PullInMyLibrary();
    int main()
        Catalog catalog;
        catalog.Create( "plugin", "MyPlugin" );

    Which compilers are supported?

    Wallaroo should work on every recent compiler.

    Anyway, I have personally tested the library with the following compilers:

    If you tried the library with another compiler, please let me know.

    Can I use wallaroo in a commercial product?

    Of course, you can. Wallaroo is released under BOOST software license that states you can do basically everything with my library.

    Does Wallaroo need custom preprocessors / code generators?

    No, Wallaroo does not need any custom build step. This was a basic criteria driving the design of the whole library. Unfortunately, when you try to develop dependency injection in C++ without custom preprocessors / code generators, you end up building an intrusive library.

    Is Wallaroo intrusive?

    Yes it is. This basically means that you need to derive your classes from wallaroo::Part in order to be managed by wallaroo. If you only need to manage 3rd party classes (that you cannot modify) and you just need the "creation" feature, you can actually solve the problem by writing a wrapper of 3rd party classes (the usual indirection layer that solve every CS problem :-) . However, in this way you cannot exploit the "wiring" feature of wallaroo. I'm planning to add an option to use a non-intrusive mechanism at least for the creation feature in wallaroo.

    Can I contribute to the project?

    There are several ways you can contribute to wallaroo. You can:

    Please let me know if you'd like to contribute.

    Why is it called "Wallaroo"?

    Because I love Australia :-)

    I'd like to thank you for the great library you wrote :-)

    Great. I'd like you to star my project and share it on Twitter, Facebook, Linkedin and other social networks (you can use the buttons below). In addition, you can also let me know you're using wallaroo and tell me how can I improve it.