Yes I enjoy the "nasty header include" feature. Thats not to say its for everybody, but its a feature that I enjoy very much and 'modern languages' appear to be dropping.

#define FOO 100+1
int foo = FOO * 2; // does not do what any sane person would expect

If that's what you want it to do then it's very useful. Otherwise, use parenthesis. Oooh, hard.

// bar.h
#include "foo.h"

// foo.h
#include "bar.h"

I don't quite understand this part... Those are useless comments and equally useless comments could be applied in D.

import foo.bar; // zoo.car
import zoo.car; // foo.bar

I don't understand the Java package system... Where the hell do they come from and how do I make mine available on the system!? The answer seems to be with the classpath which means I have to do the same thing as include it, but instead I have to add it to the system's classpath or I have to pass it everytime I compile. I think... Stupid! In college when we built GUI apps using NetBeans everything was automatically set up so the programs would run from the IDE... If you tried to compile and run outside the IDE the classpath was missing a ton of packages and that basically meant we couldn't actually use them...

How does D's (C♭'s) package system work? Where do the packages come from and how do you add them to a build?

P.S. In the time I've spent trying to learn how D does things I've learned that D's documentation sucks.

He's mentioning the circular logic of bar.h including foo.h and vice versa, which is confusing. It's like trying to define a word by using a word that is defined by the word you are trying to define. Wha?

[edit] see above post.

No, it doesn't work. Unless you take care. That's his point.
At some point, this thread moved from "look how nice D is" to "see, C++ isn't THAT bad, see? SEE?!"

One could argue, no docs are better than bad/incomplete/incorrect docs. If you're not willing to take the time to make proper documentation, the "documentation" is generally not worth reading (just look at ALSA).

Its called an example. Pseudo code even.

Not really:

const int foo = 1+2;
int bar = foo * 2;

You can do that now, and should. But people like their pre processor

An unclear example is a poor example. Take a second to make your point clear or expect to clarify. And your example was code. Pseudocode is...

bar.h...
include foo.h

foo.h...
include bar.h
Not that included files necessarily belong in pseudocode in the first place.

Which you can do in C++ as well... You don't need D for that.

I'm busy with other things. I assumed you were capable of expressing ideas. And "everyone" in this case is like 4 people. Maybe they're just used to interpreting your posts.

bamccaig: What are you, mentally challenged? The example is perfectly clear. If you have two files, foo.h and bar.h, each one including the respective other, then you are in a nasty situation. Each file is, by itself, perfectly OK, and you cannot see by looking at any one of them that something is wrong. But use them together, and the compiler will yell at you. And while the example is overly simple (as to clarify things: it is boiled down to the essential part), it illustrates the problem in a way that everybody who has encountered circular dependency issues before will recognize it.
Of course it only becomes a problem when a project grows huge, and it isn't obvious at a glance which files exactly cause the problem. And the solution, while simple and easy, isn't a very satisfactory one. Consider these classes:
(parent.h)

#include "child.h"

class cParent {
  protected:
    cChild* child;
    int bar;
  public:
    int get_bar() const { return bar; }
    int get_child_foo() const { if (child) return child->get_foo(); else return 0; }
};

(child.h)

#include "parent.h"

class cChild {
  protected:
    cParent* parent;
    int foo;
  public:
    int get_foo() const { return foo; }
    int get_parent_bar() const { if (parent) return parent->get_bar(); else return 42; }
};

The solution in this scenario would be to put the function bodies of one class into a separate .cpp file, at least those that use an instance of the other class by value, or dereference a pointer to one.

There are 2 problems with this:
- Performance; the out-sourced member functions cannot be inlined. Not a major issue usually, but still.
- Limited templating. If both classes are templates, then we have a problem. Though one might argue that this may be a sign of over-using templates.

Please PM me when we start comparing penis sizes.

Exactly! and D dumbs down the linking interface so circular dependencies are harder to solve.

On a personal note my style prefers to have the class skeleton in its own file (keeping file size down is an ongoing problem for me).

Are circular dependencies even an issue in D? I thought the whole point was that D eliminates that problem...

I need an adult! I need an adult!