Ddoc

$(D_S $(TITLE),

        $(P The same questions keep cropping up, so the obvious thing to do is
        prepare a FAQ.)

        $(P See also:)

        * $(DDLINK articles/const-faq, const(FAQ), const(FAQ)) for `const` and `immutable`.
        * $(LINK2 http://www.prowiki.org/wiki4d/wiki.cgi?FaqRoadmap, The D wiki FAQ page)
        * $(LINK2 http://www.digitalmars.com/d/1.0/faq.html, D 1.0 FAQ)
        * $(LINK2 http://www.digitalmars.com/faq.html, C++ FAQ)

$(H2 D 2.0 FAQ)

        $(UL
        $(LI Where is my simple language?)

        $(LI What other cool features are in the plans for D 2.0?)

        $(LI I suggested a great feature. Why was the suggestion ignored?)

        $(LI I want to contribute to D 2.0. How can I effect that?)

        $(ITEMR case_range, Why doesn't the case range statement
         use the $(D case X..Y:) syntax?)

        $(ITEMR shared_guarantees, What guarantees is shared supposed to provide?)

        $(ITEMR shared_synchronized, What does shared have to do with synchronization?)

        $(ITEMR shared_memory_barriers, What does shared have to do with memory barriers?)

        $(ITEMR casting_to_shared, What are the semantics of casting FROM unshared TO shared?)

        $(ITEMR casting_from_shared, What are the semantics of casting FROM shared TO unshared?)

        $(ITEMR bss, Why does a large static array bloat my executable file size?)
        )

$(H2 General D FAQ)

        $(UL
        $(LI $(LINK2 $(ROOT_DIR)comparison.html, What does D have that C++ doesn't?))
        $(ITEMR q1, Why the name D?)
        $(ITEMR q1_1, Could you change the name? D is kind of hard to search for on search engines.)
        $(LI $(LINK2 http://dlang.org/download.html, Where can I get a D compiler?))
        $(ITEMR q1_2, Is there linux port of D?)
        $(ITEMR gdc, Is there a GNU version of D?)
        $(ITEMR backend, How do I write my own D compiler for CPU X?)
        $(ITEMR gui, Where can I get a GUI library for D?)
        $(ITEMR ide, Where can I get an IDE for D?)
        $(ITEMR q4, Why is [expletive deleted] printf left in?)
        $(ITEMR q5, Is D open source?)
        $(ITEMR q5_2, Why does the standard library use the boost license? Why not public domain?)
        $(ITEMR q6, Why $(I no) fall through on switch statements?)
        $(ITEMR q7, Why should I use D instead of Java?)
        $(ITEMR q7_2, Doesn't C++ support strings, etc. with STL?)
        $(ITEMR q7_3, Can't garbage collection be done in C++ with an add-on library?)
        $(ITEMR q7_4, Can't unit testing be done in C++ with an add-on library?)
        $(ITEMR q8, Why have an asm statement in a portable language?)
        $(ITEMR real, What is the point of 80 bit reals?)
        $(ITEMR anonymous, How do I do anonymous struct/unions in D?)
        $(ITEMR printf, How do I get printf() to work with strings?)
        $(ITEMR nan, Why are floating point values default initialized to NaN rather than 0?)
        $(ITEMR assignmentoverloading, Why is overloading of the assignment operator not supported?)
        $(ITEMR keys, The $(SINGLEQUOTE ~) is not on my keyboard?)
        $(ITEMR omf, Can I link in C object files created with another compiler?)
        $(ITEMR regexp_literals, Why not support regular expression literals
                with the /foo/g syntax?)
        $(ITEMR cpp_to_D, Why aren't all Digital Mars programs translated to D?)
        $(ITEMR foreach, When should I use a foreach loop rather than a for?)
        $(ITEMR cpp_interface, Why doesn't D have an interface to C++ as well as C?)
        $(ITEMR reference-counting, Why doesn't D use reference counting for garbage collection?)
        $(ITEMR gc_1, Isn't garbage collection slow and non-deterministic?)
        $(ITEMR pure, Can't a sufficiently smart compiler figure out that a function is pure automatically?)
        $(ITEMR minimum precision, Why allow $(D cast(float)) if it isn't supposed to work?)
    $(ITEMR nested_forward_references, Why can't nested functions be forward referenced?)
        )

$(ITEM case_range, Why doesn't the case range statement
         use the $(D case X..Y:) syntax?)

        $(P See the $(DDSUBLINK spec/statement, CaseRangeStatement, case range statement).)

        $(P The usages of .. would then be:
        $(OL
        $(LI $(D case X..Y:))
        $(LI $(D foreach(e; X..Y)))
        $(LI $(D array[X..Y]))
        )
        Case (1) has a VERY DIFFERENT meaning from (2) and (3).
        (1) is inclusive of Y, and (2) and (3) are exclusive of Y.
        Having a very different meaning means it should have a distinctly different syntax.
        )

$(ITEM shared_guarantees, What guarantees is shared supposed to provide?)

        $(P Shared means that multiple threads can access the data. The guarantee is that if it is
        not shared, and not immutable, that only the current thread can see it.
        )

$(ITEM shared_synchronized, What does shared have to do with synchronization?)

        $(P Only shared data can be synchronized. It makes no sense to synchronize thread local
        data.
        )

$(ITEM shared_memory_barriers, What does shared have to do with memory barriers?)

        $(P Currently the compiler does not insert memory barriers around shared variables.
        )

$(ITEM casting_to_shared, What are the semantics of casting FROM unshared TO shared?)

        $(P Make sure there are no other unshared references to that same data.
        )

$(ITEM casting_from_shared, What are the semantics of casting FROM shared TO unshared?)

        $(P Make sure there are no other shared references to that same data.
        )

$(ITEM bss, Why does a large static array bloat my executable file size?)

        $(P Given the declaration:)
---
char[1024 * 1024] arr;
---
        $(P the executable size increases by a megabyte in size. In C, this would not
        as $(CODE arr) would be stored in the BSS segment.
        In D, $(CODE arr) is not stored in the BSS segment because:
        )

        $(UL
        $(LI The $(CODE char) type is initialized to 0xFF, not 0. Non-zero data
        cannot be placed in BSS.)
        $(LI Statically allocated data is placed in thread local storage. The BSS
        segment is not thread local, and there is no thread local equivalent of BSS.)
        )

        $(P The following will be placed in BSS:)

---
__gshared byte[1024 * 1024] arr;
---

        $(P as $(CODE byte)s are 0 initialized and $(CODE __gshared) puts it in the
        global data.)

        $(P There are similiar issues for $(CODE float), $(CODE double), and $(CODE real)
        static arrays. They are initialized to NaN (Not A Number) values, not 0.
        )

        $(P The easiest way to deal with this issue is to allocate the array dynamically
        at run time rather than statically allocate it.
        )

$(ITEM q1, Why the name D?)

        $(P The original name was the Mars Programming Language. But my friends
        kept calling it D, and I found myself starting to call it D.
        The idea of D being a successor to C goes back at least as far as 1988,
        as in this
        $(LINK2 https://groups.google.com/group/comp.lang.c/browse_thread/thread/cb4b868fab477b61/d4b5407644d16806, thread).
        )

$(ITEM q1_1, Could you change the name? D is kind of hard to search for on search engines.)

        $(P No. We understand it can be frustrating but it's far too late for a
        name change at this point. We recommend using "dlang", "d programming",
        "d language", or "d programming language" in your search terms.  Doing so
        should yield substantially better search results.
        )

        $(P Most publicly available D code has "// Written in the D programming
        language" as its first comment.
        )

$(ITEM q1_2, Is there a linux port of D?)

        $(P Yes, the D compiler includes a $(DDLINK dmd-linux,
            DMD Compiler for Linux, linux version).
        )

$(ITEM gdc, Is there a GNU version of D?)

        $(P Yes,
        $(LINK2 https://bitbucket.org/goshawk/gdc/wiki/Home, gdc - the D frontend with GCC).
        )

$(ITEM backend, How do I write my own D compiler for CPU X?)

        $(P Burton Radons has written a
        $(LINK2 http://www.opend.org/dli/DLinux.html, back end).
        You can use as a guide.
        )

$(ITEM gui, Where can I get a GUI library for D?)

        $(P Since D can call C functions, any GUI library with a C interface is
        accessible from D. Various D GUI libraries and ports can be found at
        $(LINK2 https://wiki.dlang.org/GUI_Libraries, the D wiki).
        )

$(ITEM ide, Where can I get an IDE for D?)

        $(P Lists of $(LINK2 https://wiki.dlang.org/Editors, editors) and
        $(LINK2 https://wiki.dlang.org/IDEs, IDEs) that support D can be found on
        the D wiki.
        )

$(ITEM q4, Why is printf in D?)

        $(P $(LINK2 http://www.digitalmars.com/rtl/stdio.html#printf, printf)
        is not part of D, it is part of C's standard
        runtime library which is accessible from D.
        D's standard runtime library has
        $(REF writef, std,stdio)
        which is as powerful as $(LINK2 http://www.digitalmars.com/rtl/stdio.html#printf, printf)
        but is much easier to use.
        )


$(ITEM q5, Is D open source?)

    $(P The $(LINK2 http://dlang.org/download.html, $(B dmd)) D
    compiler and the runtime library are completely open source using
    the $(LINK2 http://boost.org/LICENSE_1_0.txt, Boost License 1.0).
    All development takes place publicly on
    $(LINK2 https://github.com/dlang, github).
    There are also the $(LINK2 http://dlang.org/download.html, $(B gdc))
    and the $(LINK2 http://dlang.org/download.html, $(B ldc)) D compilers
    who come with the GCC- or LLVM-backend and the DMD front end.
    )

$(ITEM q5_2, Why does the standard library use the boost license? Why not public domain?)

    $(P Although most jurisdictions use the concept of Public Domain, some
    (eg, Japan) do not.
    The $(LINK2 http://boost.org/LICENSE_1_0.txt, Boost License)
    avoids this problem. It was chosen because, unlike almost all other open
    source licenses, it does not demand that the license text be included on
    distributions in binary form.
    )

$(ITEM q6, Why $(I no) fall through on switch statements?)

        $(P Many people have asked for a requirement that there be a break between
        cases in a switch statement, that C's behavior of silently falling through
        is the cause of many bugs.
        )

    $(P In D2, implicit fall through is disallowed. You have to add a
    $(DDSUBLINK spec/statement, GotoStatement, goto case;) statement to explicitly
    state the intention of falling through.
    )

        $(P There was further request that the $(B break) statement be made
    implicit.
    The reason D doesn't change this is for the same reason that integral
        promotion rules and operator precedence rules were kept the same - to
        make code that looks the same as in C operate the same. If it had subtly
        different semantics, it will cause frustratingly subtle bugs.
        )


$(ITEM q7, Why should I use D instead of Java?)

        $(P D is distinct from Java in purpose, philosophy and reality.
        See this $(LINK2 $(ROOT_DIR)comparison.html, comparison).
        )

        $(P Java is designed to be write once, run everywhere. D is designed for writing
        efficient native system apps. Although D and Java share the notion that
        garbage collection is good and multiple inheritance is bad, their
        different design goals mean the languages have very different feels.
        )

$(ITEM q7_2, Doesn't C++ support strings, etc. with STL?)

        $(P In the C++ standard library are mechanisms for doing strings,
        dynamic arrays, associative arrays, and bounds-checked
        arrays.
        )

        $(P Sure, all this stuff can be done with libraries,
        following certain coding disciplines, etc. But
        object oriented programming can also be done in C (it's been done).
        Isn't it incongruous that something like strings,
        supported by the simplest BASIC interpreter, requires a very
        large and complicated infrastructure to support?
        Just the implementation of a string type in STL is over two
        thousand lines of code, using every advanced feature of templates.
        How much confidence can you have that this is all working
        correctly, how do you fix it if it is not, what do you do with the
        notoriously inscrutable error messages when there's an error
        using it, how can you be sure you are using it correctly
        (so there are no memory leaks, etc.)?
        )

        $(P D's implementation of strings is simple and straightforward.
        There's little doubt about how to use it, no worries about memory leaks,
        error messages are to the point, and it isn't hard to see if it
        is working as expected or not.
        )

$(ITEM q7_3, Can't garbage collection be done in C++ with an add-on library?)

        $(P Yes, I use one myself. It isn't part of the language, though, and
        requires some subverting of the language to make it work.
        Using gc with C++ isn't for the standard or casual C++ programmer.
        Building it into the
        language, like in D, makes it practical for everyday programming chores.)

        $(P GC isn't that hard to implement, either, unless you're building one
        of the more advanced ones. But a more advanced one is like building
        a better optimizer - the language still works 100% correctly even
        with a simple, basic one. The programming community is better served
        by multiple implementations competing on quality of code generated
        rather than by which corners of the spec are implemented at all.)

$(ITEM q7_4, Can't unit testing be done in C++ with an add-on library?)

        Sure. Try one out and then compare it with how D does it.
        It'll be quickly obvious what an improvement building it into
        the language is.

$(ITEM q8, Why have an asm statement in a portable language?)

        $(P An asm statement allows assembly code to be inserted directly into a D
        function. Assembler code will obviously be inherently non-portable. D is
        intended, however, to be a useful language for developing systems apps.
        Systems apps almost invariably wind up with system dependent code in them
        anyway, inline asm isn't much different. Inline asm will be useful for
        things like accessing special CPU instructions, accessing flag bits, special
        computational situations, and super optimizing a piece of code.)

        $(P Before the C compiler had an inline assembler, I used external assemblers.
        There was constant grief because many, many different versions of the
        assembler were out there, the vendors kept changing the syntax of the
        assemblers, there were many different bugs in different versions, and even
        the command line syntax kept changing. What it all meant was that users
        could not reliably rebuild any code that needed assembler. An inline
        assembler provided reliability and consistency.)

$(ITEM real, What is the point of 80 bit reals?)

        More precision enables more accurate floating point computations
        to be done, especially when adding together large numbers of small
        real numbers. Prof. Kahan, who designed the Intel floating point
        unit, has an eloquent
        <a href="https://people.eecs.berkeley.edu/~wkahan/JAVAhurt.pdf">paper</a>
        on the subject.

$(ITEM anonymous, How do I do anonymous struct/unions in D?)

$(RUNNABLE_EXAMPLE
-----------------------
import std.stdio;

struct Foo
{
    union { int a; int b; }
    struct { int c; int d; }
}

void main()
{
    writefln(
        "Foo.sizeof = %d, a.offset = %d, b.offset = %d, c.offset = %d, d.offset = %d",
        Foo.sizeof,
        Foo.a.offsetof,
        Foo.b.offsetof,
        Foo.c.offsetof,
        Foo.d.offsetof);
}
-----------------------
)

$(ITEM printf, How do I get printf() to work with strings?)

        $(P In C, the normal way to printf a string is to use the $(D %s)
        format:)

$(CCODE
char s[8];
strcpy(s, "foo");
printf("string = '%s'\n", s);
)

        $(P Attempting this in D:)

$(RUNNABLE_EXAMPLE_FAIL
---------------------------------
import core.stdc.stdio;
string s;
s = "foo";
printf("string = '%s'\n", s); // Error
---------------------------------
)
        $(P The call gets flagged at compile-time (see
        $(DDSUBLINK spec/pragma, printf, `pragma(printf)`))
        because in general, `string` is not compatible with the `%s` specifier.
        This prevents garbage being printed, or an access violation.)

        $(P In D, a string is an array, so it has a length and a pointer.
        In C, a string is a pointer to memory terminated by a 0 character.
        The $(D %s) format prints until a 0 is encountered.
        In D, strings in general are not 0-terminated, the size is determined
        by a separate length value. So, strings are printf'd using the
        $(D %.*s) format:)

$(RUNNABLE_EXAMPLE
---------------------------------
import core.stdc.stdio;
string s;
s = "foo";
printf("string = '%.*s'\n", cast(int) s.length, s.ptr);
---------------------------------
)
        $(P which will behave as expected, for that input data.
        There are pitfalls:)
        * printf's $(D %.*s) will print until the length
          is reached or a 0 is encountered, so D strings with embedded 0's
          will only print up to the first 0.
        * printf's length argument is an int, so ensure `s.length <= int.max`.

        $(P D string literals are actually 0-terminated, so `%s` can be used
        with the `.ptr` property and printf will work for those.
        However, non-literal strings often are not 0-terminated:)

        $(RUNNABLE_EXAMPLE
        ---
        import core.stdc.stdio;
        printf("string = '%s'\n", "bar".ptr); // OK, 0-terminated

        string s = "food";
        s = s[0..3]; // foo, not 0-terminated
        printf("string = '%.*s'\n", cast(int) s.length, s.ptr);

        s ~= "ie"; // s is still not 0-terminated
        ---
        )

        $(P Of course, the easier solution is just to use $(REF writef, std, stdio)
        which works correctly with D strings.
        )

$(ITEM nan, Why are floating point values default initialized to NaN rather than 0?)

        A floating point value, if no explicit initializer is given,
        is initialized to NaN (Not A Number):

---------------------------------
double d;   // d is set to double.nan
---------------------------------

        $(P NaNs have the interesting property in that whenever a NaN is
        used as an operand in a computation, the result is a NaN. Therefore,
        NaNs will propagate and appear in the output whenever a computation
        made use of one. This implies that a NaN appearing in the output
        is an unambiguous indication of the use of an uninitialized
        variable.)

        $(P If 0.0 was used as the default initializer for floating point
        values, its effect could easily be unnoticed in the output, and so
        if the default initializer was unintended, the bug may go
        unrecognized.)

        $(P The default initializer value is not meant to be a useful value,
        it is meant to expose bugs. Nan fills that role well.)

        $(P But surely the compiler can detect and issue an error message
        for variables used that are not initialized? Most of the time,
        it can, but not always, and what it can do is dependent on the
        sophistication of the compiler's internal data flow analysis.
        Hence, relying on such is unportable and unreliable.)

        $(P Because of the way CPUs are designed, there is no NaN value for
        integers, so D uses 0 instead. It doesn't have the advantages of
        error detection that NaN has, but at least errors resulting from
        unintended default initializations will be consistent and therefore more
        debuggable.)

$(ITEM assignmentoverloading, Why is overloading of the assignment operator not supported?)

        $(P Overloading of the assignment operator for structs is supported
        in D 2.0.)

$(ITEM keys, The $(SINGLEQUOTE ~) is not on my keyboard?)

        $(P On PC keyboards, hold down the [Alt] key and press the 1, 2, and 6
        keys in sequence on the numeric pad. That will generate a $(SINGLEQUOTE ~)
        character.
        )

$(ITEM omf, Can I link in C object files created with another compiler?)


        $(P DMD produces OMF (Microsoft Object Module Format) object
        files while other compilers such as VC++ produce COFF object
        files.
        DMD's output is designed to work with DMC, the Digital Mars C
        compiler, which also produces object files in OMF format.)

        $(P The OMF format that DMD uses is a Microsoft defined format based on an
        earlier Intel designed one. Microsoft at one point decided to abandon it
        in favor of a Microsoft defined variant on COFF.)

        $(P Using the same object format doesn't mean that any C library in that
        format will successfully link and run. There is a lot more compatibility
        required - such as calling conventions, name mangling, compiler helper
        functions, and hidden assumptions about the way things work. If DMD
        produced Microsoft COFF output files, there is still little chance that
        they would work successfully with object files designed and tested for
        use with VC. There were a lot of problems with this back when
        Microsoft's compilers did generate OMF.)

        $(P Having a different object file format makes it helpful in identifying
        library files that were not tested to work with DMD. If they are not,
        weird problems would result even if they successfully managed to link
        them together. It really takes an expert to get a binary built with a
        compiler from one vendor to work with the output of another vendor's
        compiler.)

        $(P That said, the linux version of DMD produces object files in the ELF
        format which is standard on linux, and it is specifically designed to
        work with the standard linux C compiler, gcc.)

        $(P There is one case where using existing C libraries does work - when
        those libraries come in the form of a DLL conforming to the usual C ABI
        interface. The linkable part of this is called an "import library", and
        Microsoft COFF format import libraries can be successfully converted to
        DMD OMF using the
        <a href="http://www.digitalmars.com/ctg/coff2omf.html">coff2omf</a>
        tool.)

$(ITEM regexp_literals, Why not support regular expression literals
        with the $(D /foo/g) syntax?)

        $(P There are two reasons:
        )

        $(OL

        $(LI The $(D /foo/g) syntax would make it impossible to separate
        the lexer from the parser, as / is the divide token.)

        $(LI There are already 3 string types; adding the regex literals
        would add 3 more. This would proliferate through much of the compiler,
        debugger info, and library, and is not worth it.)

        )

$(ITEM cpp_to_D, Why aren't all Digital Mars programs translated to D?)

        $(P There is little benefit to translating a complex, debugged, working
        application from one language to another. But new Digital Mars apps are
        implemented in D.)


$(ITEM foreach, When should I use a foreach loop rather than a for?)

        $(P Is it just performance or readability?
        )

        $(P By using foreach, you are letting the compiler decide on the
        optimization rather than worrying about it yourself. For example - are
        pointers or indices better?
        Should I cache the termination condition or not?
        Should I rotate the loop or not?
        The answers to these questions are not easy, and can vary from machine
        to machine. Like register assignment, let the compiler do the
        optimization.)

---
for (int i = 0; i < foo.length; i++)
---

or:

---
for (int i = 0; i < foo.length; ++i)
---

or:

---
for (T* p = &foo[0]; p < &foo[length]; p++)
---

or:

---
T* pend = &foo[length];
for (T* p = &foo[0]; p < pend; ++p)
---

or:

---
T* pend = &foo[length];
T* p = &foo[0];
if (p < pend)
{
    do
    {
        ...
    } while (++p < pend);
}
---

and, of course, should I use size_t or int?

---
for (size_t i = 0; i < foo.length; i++)
---

Let the compiler pick!

---
foreach (v; foo)
    ...
---

$(P Note that we don't even need to know what the type T needs to be, thus
avoiding bugs when T changes. I don't even have to know if foo is an array, or
an associative array, or a struct, or a collection class. This will also avoid
the common fencepost bug:)

---
for (int i = 0; i <= foo.length; i++)
---

$(P And it also avoids the need to manually create a temporary if foo is a
function call.)

$(P The only reason to use a for loop is if your loop does not fit in the
conventional form, like if you want to change
the termination condition on the fly.)


$(ITEM cpp_interface, Why doesn't D have an interface to C++ as well as C?)

        $(P D 2.0 does have a
        $(DDLINK spec/cpp_interface, Interfacing to C++,
            limited interface to C++ code.)
        ) Here are some reasons why it isn't a full interface:


        $(P Attempting to have D interface with C++ is
        nearly as complicated as writing a C++ compiler, which would destroy the
        goal of having D be a reasonably easy language to implement.
        For people with an existing C++ code base that they must work with, they are
        stuck with C++ (they can't move it to any other language, either).)

        $(P There are many issues that would have to be resolved in order for D
        code to call some arbitrary C++ code that is presumed to be unmodifiable. This
        list certainly isn't complete, it's just to show the scope of the
        difficulties involved.
        )

        $(OL
        $(LI D source code is unicode, C++'s is ASCII with code pages. Or not.
        It's unspecified. This impacts the contents of string literals.)

        $(LI std::string cannot deal with multibyte UTF.)

        $(LI C++ has a tag name space. D does not. Some sort of renaming would
        have to happen.)

        $(LI C++ code often relies on compiler specific extensions.)

        $(LI C++ has namespaces. D has modules. There is no obvious mapping
        between the two.)

        $(LI C++ views source code as one gigantic file (after preprocessing). D
        sees source code as a hierarchy of modules and packages.)

        $(LI Enum name scoping rules behave differently.)

        $(LI C++ code, despite decades of attempts to replace macro features
        with inbuilt ones, relies more heavily than ever on layer after layer of
        arbitrary macros. D does not always have an analog for token pasting and
        stringizing.)

        $(LI Macro names have global scope across #include files, but are local
        to the gigantic source files.)

        $(LI C++ has arbitrary multiple inheritance and virtual base classes. D
        does not.)

        $(LI C++ does not distinguish between in, out and ref (i.e. inout) parameters.)

        $(LI The C++ name mangling varies from compiler to compiler.)

        $(LI C++ throws exceptions of arbitrary type, not just descendants of
        Object.)

        $(LI C++ overloads based on const and volatile. D overloads
        based on const and immutable.)

        $(LI C++ overloads operators in significantly different ways - for
        example, `operator[]()` overloading for lvalue and rvalue is based on
        const overloading and a proxy class.)

        $(LI C++ overloads operators like &lt; completely independently of
        &gt;.)

        $(LI C++ does not distinguish between a class and a struct object.)

        $(LI The vtbl[] location and layout is different between C++ and D.)

        $(LI The way RTTI is done is completely different. C++ has no
        classinfo.)

        $(LI D does not have two phase lookup, nor does it have Koenig (ADL)
        lookup.)

        $(LI C++ relates classes with the 'friend' system, D uses packages and
        modules.)

        $(LI C++ class design tends to revolve around explicit memory allocation
        issues, D's do not.)

        $(LI D's template system is very different.)

        $(LI C++ has 'exception specifications'.)

        $(LI C++ has global operator overloading.)

        $(LI C++ name mangling depends on const and volatile being type
        modifiers.
        D name mangling depends on const and immutable being type modifiers.
        D's const is also transitive, unlike C++. One cannot have a const
        pointer to mutable in D.
        )

        )

        $(P The bottom line is the language features affect the design of the code. C++
        designs just don't fit with D. Even if you could find a way to automatically
        adapt between the two, the result will be about as enticing as the left side of
        a honda welded to the right side of a camaro.
        )

$(ITEM reference-counting, Why doesn't D use reference counting for garbage collection?)

        $(P Reference counting has its advantages, but some severe
        disadvantages:
        )

        $(UL

        $(LI Cyclical data structures won't get freed.)

        $(LI Every pointer copy requires an increment and a corresponding
        decrement - including when simply passing a reference to a function.)

        $(LI In a multithreaded app, the incs and decs must be synchronized.)

        $(LI Exception handlers (finally blocks) must be inserted to handle all the
        decs so there are no leaks. Contrary to assertions otherwise, there is
        no such thing as "zero overhead exceptions.")

        $(LI In order to support slicing and interior pointers, as well as
        supporting reference counting on arbitrary allocations of non-object
        data, a separate "wrapper" object must be allocated for each allocation
        to be ref counted. This essentially doubles the number of allocations
        needed.)

        $(LI The wrapper object will mean that all pointers will need to be
        double-dereferenced to access the data.)

        $(LI Fixing the compiler to hide all this stuff from the programmer will
        make it difficult to interface cleanly with C.)

        $(LI Ref counting can fragment the heap thereby consuming more memory
        just like the gc can, though the gc typically will consume more memory
        overall.)

        $(LI Ref counting does not eliminate latency problems, it just reduces
        them.)

        )

        $(P The proposed C++ shared_ptr&lt;&gt;, which implements ref counting,
        suffers from all these faults. I haven't seen a heads up benchmark of
        shared_ptr&lt;&gt; vs mark/sweep, but I wouldn't be surprised if shared_ptr&lt;&gt;
        turned out to be a significant loser in terms of both performance and
        memory consumption.
        )

        $(P That said, D may in the future optionally support some form of ref
        counting, as rc is better for managing scarce resources like file
        handles.
    Furthermore, if ref counting is a must, Phobos has the
    $(REF RefCounted, std,typecons) type
    which implements it as a library, similar to C++'s shared_ptr&lt;&gt;.
        )

$(ITEM gc_1, Isn't garbage collection slow and non-deterministic?)

        $(P Yes, but $(B all) dynamic memory management is slow and
        non-deterministic, including malloc/free.
        If you talk to the people who actually do real time
        software, they don't use malloc/free precisely because they are not
        deterministic. They preallocate all data.
        However, the use of GC instead of malloc enables advanced language
        constructs (especially, more powerful array syntax), which greatly
        reduce the number of memory allocations which need to be made.
        This can mean that GC is actually faster than explicit management.
        )

$(ITEM pure, Can't a sufficiently smart compiler figure out that a function is pure automatically?)

    $(P The compiler infers purity (and safety, and nothrow) for delegate and function
    literals. It doesn't do this for normal functions for several reasons:
    )

        $(OL
        $(LI most functions call other functions, which call other functions,
        until one of them calls a library routine whose source is not available
        to the compiler. So it will have to assume it is not pure.
        With a pure function attribute, external library functions that are pure
        can be marked as pure, and then the analysis can work for enough cases
        to be useful.
        )

        $(LI Since virtual functions (and by extension delegates and function
        pointers) can be extended by the user at times the compiler won't see
        it, they have to be assumed to be impure.
        )

        $(LI If the programmer intends for a particular function to be pure
        and the compiler detects it is not, this may go unnoticed by the
        programmer. Even worse, if the programmer does notice it, it may
        be arbitrarily difficult to determine why the compiler thinks it is
        impure - is it a programming mistake or a compiler bug?
        )

        )

$(ITEM minimum precision, Why allow $(D cast(float)) if it isn't supposed to work?)

        $(P The floating point rules are such that transforming $(D cast(real)cast(float)) to
        $(D cast(real)) is a valid transformation.
        This is because the floating point rules are written with the following principle in
        mind:
        )

        $(BLOCKQUOTE An algorithm is invalid if it breaks if the floating point precision is
        increased. Floating point precision is always a minimum, not a maximum.)

        $(P Programs that legitimately depended on maximum precision are:)

        $(OL
        $(LI compiler/library validation test suites)
        $(LI ones trying to programmatically test the precision)
        )

        $(P (1) is not of value to user programming, and there are alternate ways to test
        the precision.)

        $(P (2) D has .properties that take care of that.)

        $(P Programs that rely on a maximum accuracy need to be rethought and reengineered.)


$(ITEM nested_forward_references, Why can't nested functions be forward referenced?)

        $(P Declarations within a function are different from declarations at module scope.
    Within a function, initializers for variable declarations are guaranteed to run in
    sequential order. Allowing arbitrary forward references to nested functions would
    break this, because nested functions can reference any variables declared above them.
    )
----
int first() { return second(); }
int x = first();   // x depends on y, which hasn't been declared yet.
int y = x + 1;
int second() { return y; }
----

    $(P But, forward references of nested functions are sometimes required (eg, for
    mutually recursive nested functions). The most general solution is to declare a local,
    nested struct. Any member functions (and variables!) of that struct have
    non-sequential semantics, so they can forward reference each other.
    )


$(COMMENT
        > Single inheritance may be easier to implement, but you are losing
        >something.  It's a little concerning how often folks here take the
        >opinion that "Feature X has problems and I never use it anyway, so no
        >body else 'really' needs it."  I'm not specificly blaming you, but i've
        >lost track of how many time if seen that reasoning tonight.  I'm afraid
        >I'll see it a lot in the 275 I still have to read.


        Your reasoning has merit. The counterargument (and I've discussed
        this at length with my colleagues) is that C++ gives you a dozen ways
        and styles to do X. Programmers tend to develop specific styles and do
        things in certain ways. This leads to one programmer's use of C++ to
        be radically different than another's, almost to the point where
        they are different languages.  C++ is a huge language, and C++
        programmers tend to learn particular "islands" in the language
        and not be too familiar with the rest of it.

        Hence one idea behind D is to *reduce* the number of ways X can be
        accomplished, and reduce the balkanization of programmer expertise.
        Then, one programmer's coding style will look more like another's,
        with the intended result that legacy D code will be more maintainable.
        For example, over the  years I've seen dozens of different ways that
        debug code was inserted into a program, all very different. D has one
        way - with the debug attribute/statement. C++ has a dozen string
        classes plus the native C way of doing strings. D has one way of
        doing strings.

        I intend to further help this along by writing a D style guide,
        "The D Way". There's a start on it all ready with the document
        on how to do error handling:

            www.digitalmars.com/d/errors.html

)

)

Macros:
        TITLE=D 2.0 FAQ
        ITEMR=$(LI $(RELATIVE_LINK2 $1, $+))
        ITEM=<hr>$(H3 <a name="$1">$+</a>)
        SUBNAV=$(SUBNAV_ARTICLES)
