boost crowd.

[Walter Bright]

On 11/28/2011 8:07 AM, Maxim Fomin wrote:
> Probably i am mistaken that this post supports D modules
> (in a way, showing that header files are crap), but ...
>
> In C# no headers are required, because it includes metadata in dynamic library.
> In your example you link code to compiled library without header files.
> However, this is not possible in D. Programmer have to compile his
> code with library code,
> which also should include all private members, which supposed to be hidden.
> In attempt to eliminate "header crap" D breaks modularization.

This is superficially correct, but in practice is not so. I considered a 
"metadata" solution for D. It turns out, that D is so fast at parsing, that the 
"metadata" can simply be the source file stripped of comments. Hence, the 
genesis of the .di file. The .di file IS the metadata. There really is no 
difference between that an the C# metadata, except that the C# metadata is not 
in a user-accessible format.

In particular, the C# metadata still has the private members in it. (If it 
didn't, you couldn't have inline functions, or value types.)

It's too bad there's no way to 'bind' arbitrary data to shared executable 
library files, but I have considered making it possible for dmd to read .zip 
files, so you could stuff all the .di files into a .zip, call it a "library", 
and voila!

It is possible to stuff .di files into linkable .lib or .a files, however. It 
wouldn't be a big deal to do that.


> Some comparison of C/C++/C#/D writing libraries.
> C: write in separate .c file, declare exported object as opaque
> structure/void*. No need to recompile program,
>      when library implementation changes.  Program does not know
> anything about private members.

That's the PIMPL idiom, and D supports it as well as C/C++ do. D's associative 
arrays are implemented using PIMPL.


>     Lib files are no longer required on program compilation. Code can
> be separated though many files.
>     Negative: make changes in min 3 files (program, header, library)
> when interface is changed.
> C++ :  one negative difference  comparing with C is that private
> members are known, and you need recompilation, when you change
> something
>     related to them.

C doesn't hide private members because it has no notion of private members. This 
is therefore not a 'negative' of C++ relative to C.


> C#: as example above. No headers. Private members are not known. Just
> link program upon compiling to already compiled .dll

This is one of the advantages of deferring compilation until runtime.


>     No GC issues across libraries/program.
>     Actually, this is the best modularization support comparing these 4
> languages.
> D: currently difficulties when generating dynamic libraries in linux.

True, but that's not a defect in the language design.

> Also GC issue when calling D code from D
>      (from http://d-programming-  language.org/dll.html). Programmer
> should ship library code with program (Walter Bright showed simple
> example
>      with function exporting. And what about a class, its methods and
> private members?). Recompile everything when implementation/interface
>      is changed. No way to put class code in separate files. Wired
> "interface file" generation which knows implementation better than its
> author.
>
> In conclusion, I find D module support the worst one.