IfcPlusPlus: a C++ IFC class model and STEP reader kept for existing projects

The README's own verdict: keep it, do not start with it

The most useful line in this repository is the first one. The README states plainly that the repository is not actively developed any more, and that support and customization for existing projects is still available through the contact address on the ifcquery.com site.

That single sentence defines the project as it exists today. It is a mature artifact with a maintenance-only posture. The repository is not archived, and the last push was on 2026-10-15, so code still moves through the tree even though the README asks you not to start something new on it.

The README then goes further and names a follow-up. For new projects it recommends xeoIFC, describing it as newer and built on the latest WebAssembly and WebGPU technology, with better geometry quality than IfcSplitAndMerge in this repository. It points to a browser viewer that loads the Garabit viaduct model directly in the browser with nothing installed, and it reports that the command-line converter processed more than 2,200 real-world IFC files, 95 GB in total, in under 20 minutes on one workstation. Those are the project's own published figures for the successor, not for IfcPlusPlus, and they are the reason to look elsewhere before writing new code.

So the correct reading of this repository is as a dependency to inherit rather than a platform to bet on.

What the library actually gives you: a class model, a reader and a writer

IfcPlusPlus is described as an open source C++ class model that is also a reader and a writer for IFC files in STEP format. IFC is the open building model standard, and the class model is the part that mirrors the standard's entities as C++ types.

Three technical claims are made about the implementation. Memory management is handled with smart pointers, so entity lifetime does not depend on manual delete calls at every call site. Parsing is parallel, which the description attributes to multi-core CPUs and presents as fast parsing. And there is a simple IFC viewer application built with Qt and OpenSceneGraph, which the project positions as a starting point for applications built around IFC.

The viewer point deserves more attention than it usually gets. A class model plus a file format library is the invisible half of an IFC toolchain, because reading a file is only the beginning of what an application does with a building model. The repository ships an example directory named SimpleViewerExampleQt, which shows what it means to turn the library into an application without building one from nothing.

The structure of the repository reflects that split: a main IfcPlusPlus directory for the core library, an examples directory, and a set of platform and build helper files at the top level, including CMakeLists.txt, a Dockerfile, a Visual Studio solution, an optimbuild.patch and small runCmake scripts for both Windows and Unix shells.

Reading IFC from C++: three example programs

The examples directory carries three programs, and their names tell you what each is for.

CreateIfcWallAndWriteFile is the write path. It builds an IFC entity in memory and serializes it, which is the example to read when you need to author building data rather than consume it.

LoadFileExample is the read path. It takes an existing STEP file and gives you the entities, which is the common case for a tool that receives models from elsewhere.

SimpleViewerExampleQt is the presentation path, and it uses Qt together with OpenSceneGraph, the same stack as the viewer application described in the project description.

Between them, the three examples cover the cycle a BIM developer actually needs: author a model, load a model, display a model. Since these are named example directories rather than a documented tutorial, the examples are also the closest thing to an onboarding path the project offers, and they are worth reading in that order.

What the repository does not offer is a command line tool for the core library, a package published to a language registry, or a set of API stability guarantees. The library is consumed as source that you build yourself, which is a different adoption model from installing a dependency and pinning a version.

Building it means provisioning an old Linux toolchain by hand

The Dockerfile is the clearest description of what the build needs, because it installs everything explicitly rather than relying on a base image that already has it.

The base is ubuntu:18.04, which is long out of support. The first stage installs software-properties-common, cmake and libboost-dev, then adds the ubuntu-toolchain-r test repository to obtain g++-8, and finally uses update-alternatives to point /usr/bin/gcc and /usr/bin/g++ at gcc-8 and g++-8.

The second stage installs a long list of development packages in one apt-get call:

RUN apt-get install -y \
        cmake                   \
        qt5-qmake               \
        libqt5widgets5          \
        libqt5opengl5-dev       \
        qttools5-dev            \
        qtbase5-dev             \
        libxrandr-dev           \
        libtiff5-dev            \
        libpoppler-glib-dev     \
        librsvg2-dev            \
        libcairo2-dev           \
        libcurl4-gnutls-dev     \
        libgtkglext1-dev        \
        libgdal-dev             \
        libsdl1.2-dev           \
        libgstreamer1.0-dev     \
        libopenjp2-7-dev        \
        libopenscenegraph-dev

That list tells you the real scope of the project. Qt 5 for the viewer widgets and OpenGL, OpenSceneGraph for scene graph rendering, GDAL for geospatial raster support, Poppler and librsvg and cairo for document and image output, GStreamer and SDL for media, and libcurl for networking. OpenSceneGraph is the last entry and it is the one that matters most for the viewer, since that library is what turns parsed geometry into a rendered scene.

Two practical consequences. Building the viewer means installing every one of those packages, while the core library alone needs far less. And the gcc-8 pinning is a hard constraint on modern build hosts, where the system compiler is much newer. The CMakeLists.txt at the top level is the entry point for that build.

Release history and what the version numbers tell you

The project tags plain numeric versions rather than semantic ones. The recorded releases are 2.3 on 2024-03-20, 2.4 on 2024-04-30 and 2.5 on 2024-08-09.

Read that spacing carefully. Two of the three releases landed within about six weeks of each other in the spring of 2024, and the most recent one is from August 2024. The last push to the repository, on 2026-10-15, is considerably later than any tagged release, which tells you the tree continues to receive changes that have not been cut into a new version.

That is exactly what you would expect from a project whose README says it is not actively developed: maintenance happens, fixes land, but there is no release rhythm you can plan around and no version series to upgrade to. If you are inheriting this library, you are inheriting a source tree whose version you have to determine yourself, probably by reading the source rather than by checking tags.

The licence is MIT, held in a LICENSE.txt file, which is permissive enough that commercial use and modification are not a barrier. The homepage is http://www.ifcquery.com, and the support route named in the README runs through that site rather than through the repository's issue tracker.

For a team already using this code, the upgrade question is not which release to move to but which fork or vendor branch to track, because the upstream project itself has told you it is winding down.

Deciding between IfcPlusPlus and xeoIFC

The two projects solve the same problem from different directions, and the README makes the comparison explicit.

IfcPlusPlus is a compiled C++ library with a class model, a STEP reader and writer, and a desktop viewer built on Qt and OpenSceneGraph. You build it from source, you link against it, and you get direct object access to IFC entities. That suits a desktop application, a server side tool or a plugin inside a larger C++ product, and it suits teams that already write C++.

xeoIFC, as described in the README, runs in the browser, on the desktop and on a server, using WebAssembly and WebGPU. The published figure is a converter that handled more than 2,200 real-world IFC files totalling 95 GB in under 20 minutes on one workstation, and a viewer that loads a nine file model of the Garabit viaduct, 678,768 rivets, directly in a browser with nothing installed.

The practical difference for an engineering team is the deployment model. A browser based viewer needs no installation for end users, which changes who you can hand the tool to. A C++ library gives you the entities in your own process, which matters if the next step in your pipeline is analysis rather than viewing.

The README is unambiguous about the direction of travel and says as much when it calls the geometry quality and the handling better in the successor. The engineering question for you is narrower: does your existing code depend on IfcPlusPlus classes directly, in which case a rewrite is a project of its own, or would you start from the successor and keep the old library only for compatibility shims?

Editorial conclusion

Adopt IfcPlusPlus when you are extending an existing C++ codebase that already depends on it, because the class model, the STEP reader and the Qt viewer are all present and the licence is permissive. Do not start a new project on it, since the README states the repository is no longer actively developed and points to xeoIFC for that. Before you commit, verify the toolchain your build host actually has, since the Dockerfile pins Ubuntu 18.04 with g++-8 and a long list of Qt and OpenSceneGraph development packages, and confirm whether the parallel reader is enabled in the configuration you build.

Frequently asked questions

Official sources

1. ifcquery/ifcplusplus on GitHub
2. License: MIT
3. Project website
4. README
5. Releases