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
  2. Not Available

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 (Phobos) 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, when an initialization step is not performed 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 a good solution.

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. Dynamic arrays, 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

Not Available

D features not available with BetterC:

  1. Garbage Collection
  2. Thread-local storage
  3. TypeInfo and ModuleInfo
  4. Classes
  5. Built-in threading (e.g. core.thread)
  6. Dynamic arrays (but not slices) and associative arrays
  7. Exceptions
  8. switch with strings
  9. final switch
  10. synchronized and core.sync
  11. Static module constructors or deconstructors
  12. Struct deconstructors
  13. unittest (testing can be done without the -betterC flag)
Vector Extensions