eC

eC - short for Ecere C - is an object-oriented programming language defined as a superset of C. It was designed in 2004 by Jerome Jacovella-St-Louis as the implementation language for the Ecere cross-platform SDK, a project he had already been building for seven years. The stated goal is narrow and unusually clear: add object-oriented constructs, reflection, properties and dynamic modules on top of C while keeping C compatibility and native performance, and while getting rid of header files and prototypes.

The result is a language that looks like C, links like C, and compiles down to C - the eC compiler emits C source and hands it to GCC or Clang for the final steps - but which offers classes with single inheritance, polymorphism, properties, generics, unit types, bit classes, reflective instantiation by name, and a container library, all with no virtual machine and no garbage collector. It is a small, coherent design that never found a large audience, and it is one of the more complete examples of a one-person language that shipped a real toolchain, a real GUI framework, a real IDE, and a commercial product built on top of itself.

History and Origins

The SDK came first. Jacovella-St-Louis founded the Ecere cross-platform SDK project in 1997, initially as a 2D and 3D graphics library for games; his own account describes reorganizing an existing 3D engine and real-time strategy game behind an abstraction layer so the same source could target DOS, Windows and Linux. Over the following years the project accumulated a GUI toolkit, networking, audio and database integration.

Writing a large cross-platform framework in plain C makes the missing pieces obvious - and the natural fix, C++, brought costs that the project did not want: header files, separate declaration and definition, no reflection, and an ABI that does not travel. So in 2004 the author designed eC instead: object orientation and reflection layered onto C89, with the C ABI preserved so that eC objects and C objects are the same kind of thing to the linker.

Ecere Corporation was founded in 2005, and is the origin of the 2005 date sometimes attached to the language; the design of eC itself is consistently dated to 2004 by both the project’s own site and by third-party references. The SDK’s copyright notices span 1996-2025 for the author personally and 2005-2025 for the corporation, which is a fair summary of the two eras.

For its first decade eC was effectively private infrastructure. Public development moved to GitHub in May 2011, and on 9 March 2012 version 0.44 “Ryoan-ji” was announced as the first complete open-source release of the SDK - compiler included - under a revised BSD license. Two more notable releases followed: 0.44.10 in August 2014 (64-bit support, compiler performance and correctness work that the release announcement describes as “tremendous” - no benchmark figures were published alongside it - and Clang support) and 0.44.15 “Ryoan-Ji” Web Edition in August 2016 (Emscripten and WebGL, shaders, ECON configuration). No numbered SDK release has appeared since.

Design Philosophy

A superset, not a successor

eC is a superset of C89 in close to the strict sense - the documented exceptions are collisions with the handful of new keywords such as class. Standard C can be written anywhere inside an eC module, and object modules compiled from C can be linked into eC code as if they were eC. This is the single decision that shapes everything else: eC never asks you to abandon a C codebase, only to start writing new files in a slightly larger language.

Because the ABI is C’s, there is no name mangling problem, no exception model to interoperate with, and no runtime to initialize before C code can call into eC.

Imports instead of headers

There are no header files. A module says import "ecere" and the compiler resolves symbols across files itself. Visibility is expressed with three access levels rather than by what you choose to declare in a .h:

Eliminating the declaration/definition split is arguably the most immediately felt difference for a C programmer trying eC: you write a function once.

Reflection as a first-class goal

Object-oriented eC code is built around a reflective object model. Type information about the programming interfaces is available dynamically at runtime, so classes can be instantiated and methods invoked using textual names, modules can be loaded from shared libraries at runtime as plugins, and - in the SDK - a form designer can inspect and manipulate live objects. The same machinery underlies the SDK’s distributed objects, where a remote instance is used with the same syntax as a local one.

Key Features

Instantiation syntax

eC’s most recognizable syntactic move is its use of braces for instantiation, deliberately echoing C’s list initialization:

Point p { 123, 23 };          // declare and instantiate
DoSomething(Point { 10, 20 }); // an instance as an expression

Members can also be set by name inside the braces, which makes the same syntax serve as object construction and as a declarative description of a UI or a scene.

Classes, structs and the space in between

The type system distinguishes what you pay for:

• class - heap-allocated, with a virtual method table, runtime type information and reference counting.
• struct - a plain C struct: stack-allocatable, no overhead, no polymorphism.
• class : struct - an individually allocated instance without the class overhead, for when you want reference semantics but not a vtable.

Properties

Properties look like data members at the point of use but run accessor code:

class Temperature
{
   double celsius;

public:
   property double fahrenheit
   {
      get { return celsius * 9 / 5 + 32; }
      set { celsius = (value - 32) * 5 / 9; }
   }
}

Throughout the Ecere GUI toolkit, properties are what make declarative window definitions work - assigning caption or size inside a class body is a property write, and the designer can round-trip those assignments between source code and a live form.

Unit types and conversion properties

A scalar type can be declared as a unit, and conversion properties define how units relate. The compiler can precompute conversions for constants:

class Meters : double;

class Feet : double
{
   property Meters
   {
      get { return this / 3.280839895; }
      set { return value * 3.280839895; }
   }
}

Once declared, a Feet value can be used where Meters is expected. The classic examples in the documentation are Radians/Degrees and Meters/Feet - exactly the confusions that cause real bugs in graphics and geospatial code, which is where this language spends its life.

Bit classes

Bit classes replace the traditional thicket of shift-and-mask macros: the whole value lives in a single integer, but members are reached with dot notation. The documentation’s motivating example is color format conversion between bit depths.

Generics and containers

eC supports parametric polymorphism with angle-bracket syntax (class A<class T>), and the runtime ships generic containers - Array, List, LinkList, Map, AVLTree - with initialization literals and a compact iteration form:

Array<int> squares { [ 1, 4, 9, 16 ] };

for(v : squares)
   PrintLn(v);

Memory management

Global and member instances are reference counted automatically; anything you new you delete yourself. The SDK includes integrated memory error detection for tracking leaks and buffer overruns during development. There is no tracing garbage collector, which is consistent with the language’s positioning against C++ rather than against Java or C#.

A minimal program

An eC console application is typically a class deriving from Application with a Main method:

import "ecere"

class HelloApp : Application
{
   void Main()
   {
      PrintLn("Hello, World!");
   }
}

Because eC is a C superset, a plain C main() in a .ec file compiles too - the class form is what the SDK’s runtime and its cross-platform entry points expect.

Evolution

The visible arc of the language is unusual because most of it happened before the public could see it. Between 2004 and 2011 eC evolved privately as the SDK’s implementation language; the 2012 open-source release presented a language that was already mature enough to have built a GUI toolkit, a 3D engine and an IDE.

Public evolution since then has come in three strands:

1. Compiler quality and reach - 64-bit support and compiler performance work in 0.44.10 (2014), reported by the project without published benchmarks, plus Clang support and improved C99 compatibility.
2. New targets - the 2016 release added deployment to the web by compiling through Emscripten; project documentation also describes targeting WebAssembly via Binaryen, and the eC repository contains WebAssembly build configuration.
3. Repackaging - in April 2025 the language, compiler and core runtime were split out of the SDK into a standalone ecere/eC repository under the BSD 3-Clause license, with its own tags (0.0.2 through 0.0.5, the last dated October 2025). This separates “the eC language” from “the Ecere application framework” for the first time - a meaningful change for anyone who wanted the former without the latter.

Platform claims should be read with the dates attached. The SDK’s own overview lists Windows, Linux, OS X, FreeBSD and Android as supported, with iOS and the web described as planned and under way at the time of writing (the page’s copyright runs to 2016); the 2016 release then delivered web support through Emscripten and WebGL.

Current Relevance

eC is best described as quietly maintained rather than actively promoted. The last tagged release of the combined SDK was in 2016, the Debian package was removed from testing in 2018, and the language has never had a package ecosystem, a conference or a visible user community outside the project’s own forums and mailing list. By the usual measures it is dormant.

But the code is not abandoned. Both GitHub repositories have reportedly continued to receive commits into 2026, and the reason is commercial: GNOSIS, Ecere’s geospatial platform, is written in eC, and its map server is certified compliant with several OGC API standards. That gives the language something most hobby languages never get - a paying product that depends on it, and standards-body deadlines that keep the compiler honest. It also explains the shape of recent work, which is weighted toward graphics, tiling, coverages and web deployment rather than toward language features.

For a newcomer, the practical picture is: build from source, expect the documentation to be a mix of a website last styled around 2016 and the source tree itself, and expect to be one of a small number of people writing the language outside Ecere.

Why It Matters

eC is worth knowing for three reasons.

It answers a real question about C++. C++ is not the only way to add objects to C, and eC is a well-developed argument for a different set of trade-offs: keep the C ABI, drop headers, add reflection, keep the object model small enough that a runtime can describe it fully. Whether or not you would choose it, it maps out a design point that mainstream languages left unexplored.

Reflection without a VM. Most languages that let you instantiate a class from a string are running on a managed runtime. eC gets there with static native compilation and reference counting, by making the compiler emit rich metadata rather than by making the runtime dynamic - an approach that other statically compiled languages have since arrived at independently, with no documented line of influence from eC.

It is a complete one-person stack. A language, a self-hosting compiler, a container and I/O runtime, a GUI toolkit with a form designer, 2D and 3D engines, a networking layer, a database access layer, an IDE with a debugger, and a certified commercial product on top - all originating from one author’s project begun in 1997. Whatever eC’s standing in the wider language landscape, that is a rare demonstration of how far a single coherent design can be pushed.

Sources

• eC Programming Language - official site and Overview
• ecere/eC on GitHub and ecere/ecere-sdk on GitHub
• The Ecere Cross-Platform SDK and SDK Overview
• Ecere release announcements on Launchpad
• Ecere SDK 0.44.15 “Ryoan-Ji” Web Edition release notes
• ecere-sdk in the Debian Package Tracker
• Ecere SDK: A cross-platform toolkit for GUIs and graphics - Opensource.com
• GNOSIS Map Server - OGC compliance product record
• Jerome Jacovella-St-Louis - OSGeo wiki