boost crowd.

[Timon Gehr]

On 11/28/2011 05:07 PM, Maxim Fomin wrote:
> 2011/11/28 Max Samukha<maxter at spambox.com>:
>> On 11/28/2011 02:29 PM, so wrote:
>>>
>>> On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha<maxter at spambox.com>
>>> wrote:
>>>
>>>>> How would you write libraries?
>>>>
>>>> The way they do, for example, in C# - interface definitions are stored
>>>> in the library, no need for separate headers.
>>>
>>> Are we talking about the same thing?
>>> Something like
>>> http://msdn.microsoft.com/en-us/library/ms236403(v=vs.80).aspx?
>>>
>>> So it does what auto-generated .di files does, and turns it into an
>>> abomination, it relies on an IDE feature?
>>
>> No, it has nothing to do with the IDE. The article describes a visual tool
>> for viewing meta-data stored in a .NET binary. You don't have to use it.
>>
>> Specially for you, die-hard IDE haters, this is how to use the terminal to
>> create a mono app and library:
>>
>> 1. Library:
>>
>> nano lib.cs
>> ----
>> using System;
>>
>> public class Lib
>> {
>>     public static void hello() { Console.WriteLine("We don't need no header
>> crap"); }
>> }
>> ----
>>
>> Compile that into a library, lib.dll:
>>
>> dmcs lib.cs -target:library
>>
>> 2. Host:
>>
>> nano app.cs
>> ----
>> class App
>> {
>>     public static void Main()
>>     {
>>         Lib.hello();
>>     }
>> }
>>
>> Compile and run the app:
>>
>> dmcs app.cs -reference:lib.dll
>> ./app.exe
>> We don't need no header crap
>>
>
> [skipped]
>
> 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.
>
> 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.
>     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#: as example above. No headers. Private members are not known. Just
> link program upon compiling to already compiled .dll
>     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.
> 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.

This is in no way related to the D module system, which is quite nicely 
designed. You are describing issues with the tool chain. Those indeed 
hamper modular compilation, and should be sorted out eventually. You 
might want to file a bug report.