Menu
Search
Language Reference

table of contents

Report a bug
If you spot a problem with this page, click here to create a Bugzilla issue.
Improve this page
Quickly fork, edit online, and submit a pull request for this page. Requires a signed-in GitHub account. This works well for small changes. If you'd like to make larger changes you may want to consider using a local clone.

Better C

Contents
  1. Retained Features
    1. Running unittests in -betterC
  2. Unavailable Features

It is straightforward to link C functions and libraries into D programs. But linking D functions and libraries into C programs is not straightforward.

D programs generally require:

  1. The D runtime library to be linked in, because many features of the core language require runtime library support.
  2. The main() function to be written in D, to ensure that the required runtime library support is properly initialized.

To link D functions and libraries into C programs, it's necessary to only require the C runtime library to be linked in. This is accomplished by defining a subset of D that fits this requirement, called BetterC.

Implementation Defined: BetterC is typically enabled by setting the -betterC command line flag for the implementation.

When BetterC is enabled, the predefined version D_BetterC can be used for conditional compilation.

An entire program can be written in BetterC by supplying a C main() function:

extern(C) void main()
{
    import core.stdc.stdio : printf;
    printf("Hello betterC\n");
}

> dmd -betterC hello.d && ./hello
Hello betterC

Limiting a program to this subset of runtime features is useful when targeting constrained environments where the use of such features is not practical or possible.

BetterC makes embedding D libraries in existing larger projects easier by:

  1. Simplifying the process of integration at the build-system level
  2. Removing the need to ensure that Druntime is properly initialized on calls to the library, for situations when an initialization step is not performed or would be difficult to insert before the library is used.
  3. Mixing memory management strategies (GC + manual memory management) can be tricky, hence removing D's GC from the equation may be worthwhile sometimes.

Retained Features

Nearly the full language remains available. Highlights include:

  1. Unrestricted use of compile-time features
  2. Full metaprogramming facilities
  3. Nested functions, nested structs, delegates and lambdas
  4. Member functions, constructors, destructors, operating overloading, etc.
  5. The full module system
  6. Array slicing, and array bounds checking
  7. RAII (yes, it can work without exceptions)
  8. scope(exit)
  9. Memory safety protections
  10. Interfacing with C++
  11. COM classes and C++ classes
  12. assert failures are directed to the C runtime library
  13. switch with strings
  14. final switch
  15. unittest

Running unittests in -betterC

While, testing can be done without the -betterC flag, it is sometimes desirable to run the testsuite in -betterC too. unittest blocks can be listed with the getUnitTests trait: 
unittest
{
   assert(0);
}

extern(C) void main()
{
    static foreach(u; __traits(getUnitTests, __traits(parent, main)))
        u();
}

> dmd -betterC -unittest -run test.d
dmd_runpezoXK: foo.d:3: Assertion `0' failed.
However, in -betterC assert expressions don't use Druntime's assert and are directed to assert of the C runtime library instead.

Unavailable Features

D features not available with BetterC:

  1. Garbage Collection
  2. TypeInfo and ModuleInfo
  3. Classes
  4. Built-in threading (e.g. core.thread)
  5. Dynamic arrays (though slices of static arrays work) and associative arrays
  6. Exceptions
  7. synchronized and core.sync
  8. Static module constructors or destructors
Vector Extensions