www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - boost crowd.

reply so <so so.so> writes:
Whenever i see articles like  
http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ i keep  
wondering why they are so silent in this newsgroup,
I am sure they keep an eye on D. I would expect some kind of contribution  
(as in suggestions, proposes...).
They are the top C++ developers, pushing language's capabilities. So, if  
someone is annoyed by the limits of C++, that would be them.
Forget everything, i was thinking that the generic capabilities of D alone  
is enough to attract all the boost crowd.

Phew, had to get it out.
Nov 27 2011
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 27.11.2011 17:32, schrieb so:
 Whenever i see articles like
 http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ i keep
 wondering why they are so silent in this newsgroup,
 I am sure they keep an eye on D. I would expect some kind of
 contribution (as in suggestions, proposes...).
 They are the top C++ developers, pushing language's capabilities. So, if
 someone is annoyed by the limits of C++, that would be them.
 Forget everything, i was thinking that the generic capabilities of D
 alone is enough to attract all the boost crowd.

 Phew, had to get it out.

Why switch state of the art C++ compilers with years of optimizations built-in and tooling by D? This is the type of questions I sometimes have to answer, and as much as I would like to have a language like D replace C++, myself I end up using C++ when the need for native code on our applications arise. -- Paulo
Nov 27 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/27/2011 9:53 AM, so wrote:
 Even Herb Sutter broke his silence and mentioned D here and there,

Herb is a very nice (and very smart) guy, and when I've heard him talk about D he's been very complimentary about our efforts.
Nov 27 2011
prev sibling next sibling parent so <so so.so> writes:
On Sun, 27 Nov 2011 19:13:46 +0200, Paulo Pinto <pjmlp progtools.org>  
wrote:

 Why switch state of the art C++ compilers with years of optimizations  
 built-in and tooling by D?

Tool and compilers come eventually, especially after big players attend in discussions. I don't understand this reasoning really, what everyone expect from language evolution? Are we expecting some big company do this? Without any feedback from programmer community, in their inner circles? We know there are many like that and none of them fulfilling our needs.
 This is the type of questions I sometimes have to answer, and as much as
 I would like to have a language like D replace C++, myself I end up  
 using C++ when the need for native code on our applications arise.

So do i, but that doesn't mean one should remain silent at the time of big developments to very problems C++ is facing. Even Herb Sutter broke his silence and mentioned D here and there, considering his position on the development of another language/compiler, shouldn't others be more vocal? This is not a fantasy anymore, we have working compilers and a grand community.
Nov 27 2011
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/27/11 10:32 AM, so wrote:
 Whenever i see articles like
 http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ i keep
 wondering why they are so silent in this newsgroup,
 I am sure they keep an eye on D. I would expect some kind of
 contribution (as in suggestions, proposes...).
 They are the top C++ developers, pushing language's capabilities. So, if
 someone is annoyed by the limits of C++, that would be them.
 Forget everything, i was thinking that the generic capabilities of D
 alone is enough to attract all the boost crowd.

 Phew, had to get it out.

The dynamics and psychology at play are, IMHO, a fair amount more complex. I'm saying this as one who has lived such. Mastering a difficult language (and probably skill in general) is to some extent like acquiring some power or money - it puts the subject in a conservative position where she'd try to expand the use of the language for tasks not playing into the language's strength, as opposed to achieving the tasks by escaping the language. That explains e.g. why people are willing to use C++'s preprocessor for tasks that would be trivial for m4 or even bash, or that people try all sorts of systems-level coding in languages not adequate for that. I've had a sort of awakening during my first year in grad school. A professor was teaching constraint logic programming (CLP) and I noted to him that many CLP constructs could be expressed in C++ templates quite nicely. (That prediction was correct, see http://www.mpprogramming.com/cpp.) He (knowing my past) suggested kindly that I'd do good to think more broadly instead of trying to emulate everything I come across in C++. And right he was. Many C++ programmers have heard about D, but it would be naive to think they'd just stop looking solutions to problems in C++, just because those problems have a good solution in D. Andrei
Nov 27 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
 "D has a true module system that supports separate compilation and
 generates and uses module summaries (highbrowspeak for "header files")
 automatically from source, so you don't need to worry about
 maintaining redundant files separately, unless you really wish to, in
 which case you can. Yep, that stops that nag right in mid-sentence."

 But it is not true...

How is it not true?
Nov 27 2011
next sibling parent reply Jude <10equals2 gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


 
 I tried to write a lib and a project, which used that lib
 separately, but came to conclusion that the best choice it to pull
 lib code to project one. And it is not a biggest problem, because
 dmd produces 700 kb executable for hello word program.

what..? I don't know how you are managing to get 700kb for hello world... mine clocks in a 283.7kb with dmd with no optmizations, and holy crap 1.6MB for same file with gdmd. WTF is going on there I wonder...? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO01xIAAoJENcHIWLyQiSlSqEIAITGvcwx7MlNMIg2nHAk1W7e e0sO0vts/lT/Sr1kwlvmXmNtBMUN6aU/HIXWR+Rse3RjKglFFGy2xvpQwboZC0yY eD7aKZOflCuOc86crVaTRWQbNJDn+Fa4tLvN4uCd80fCVVXuGMsuoixbEyX5QoZb azhQZw5S65kMPXMbU6ViP6VlJJZeEvjVu0CrJYsO/Doxwolqw54xBSKAIlIOt5xU H5L0pguJ+mNkuw4BMsYfrywYH/pIWKRkxtr3JMnFfSmhknkSCYWqvkctZuq94PcP QCWWrxcxhquzq8SWWg++97KbkqsDWhEjZcLDaTKdSiH+BOFebfi2YvXbS42GUSE= =qrO4 -----END PGP SIGNATURE-----
Nov 28 2011
parent reply Peter Alexander <peter.alexander.au gmail.com> writes:
On 29/11/11 2:12 AM, Marco Leise wrote:
 Am 28.11.2011, 14:42 Uhr, schrieb Maxim Fomin <maxim maxim-fomin.ru>:

 2011/11/28 Marco Leise <Marco.Leise gmx.de>:
 Am 28.11.2011, 11:02 Uhr, schrieb Jude <10equals2 gmail.com>:

 I tried to write a lib and a project, which used that lib
 separately, but came to conclusion that the best choice it to pull
 lib code to project one. And it is not a biggest problem, because
 dmd produces 700 kb executable for hello word program.

what..? I don't know how you are managing to get 700kb for hello world... mine clocks in a 283.7kb with dmd with no optmizations, and holy crap 1.6MB for same file with gdmd. WTF is going on there I wonder...?

*drum roll* 148,2 kB (dmd 2.054, Linux) *tadaa* - 8< - - - - - - - - - - - - - - - - - - - import std.stdio; void main() { writeln("Hello, world!"); } - 8< - - - - - - - - - - - - - - - - - - -

------ import std.stdio; class dummy { this() { writeln("ctor");} ~this() { writeln("dtor"); } } void main() { auto dm = new dummy(); } ------- dmd main.d -o 377,9 kb It is not 700 as i told, but yesterday i upgraded to 2.056. But definitely i saw that it produces 700 kb elf for a small program. Anyway, is 400 kb for dummy program too much?

Be aware that classes and structs have .init blocks that can grow huge if you declare large static arrays in them. So the source code may be small, but the executable bloats. And every template instantiation adds to it as well. I think even just using writeln with different parameters all over the place adds up, but thats a vague guess.

A couple of other things I noticed that can massively bloat your code using DMD: Range case statements: switch(c) { case 0: .. case 255: foo(); break; } Expands to if(c == 0) goto L1; if(c == 1) goto L1; if(c == 2) goto L1; ... if(c == 255) goto L1; etc. Which means you also get a horrible O(n) algorithm for something that should be a couple of compares. Why DMD does this is beyond me. There's a few function in Phobos that are massively bloated due to this (I've filed a bug report before anyone asks). ---- Global float arrays can bloat executables as well: __gshared int[1_000_000] thisGoesInBss; // barely adds anything __gshared float[1_000_000] thisGoesInData; // adds 4MB to exec float arrays are initialised to NaN in D (in C they init to 0.0f), so they can't go in the .bss section (unless you explicitly init to 0.0f).
Nov 29 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/29/2011 1:46 AM, Peter Alexander wrote:
 Which means you also get a horrible O(n) algorithm for something that should be
 a couple of compares. Why DMD does this is beyond me.

I did it to get it up and running, and haven't revisited that yet.
 Global float arrays can bloat executables as well:

 __gshared int[1_000_000] thisGoesInBss; // barely adds anything
 __gshared float[1_000_000] thisGoesInData; // adds 4MB to exec

 float arrays are initialised to NaN in D (in C they init to 0.0f), so they
can't
 go in the .bss section (unless you explicitly init to 0.0f).

True, but using large statically allocated arrays of any sort is usually a suboptimal solution. It's better to new or malloc them.
Dec 01 2011
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-11-28 10:01, Maxim Fomin wrote:
 I tried to write a lib and a project, which used that lib separately,
 but came to conclusion
 that the best choice it to pull lib code to project one.
 And it is not a biggest problem, because dmd produces 700 kb
 executable for hello word program.

Neither the standard library or runtime is dynamically linked, which is the case for C/C++. If you dynamically link the standard library and the runtime a Hello World application takes around 16KB (D1, Tango on Mac OS X), the same as a Hello World application written in C takes. -- /Jacob Carlborg
Nov 28 2011
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/28/2011 09:01 AM, so wrote:
 On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
 "D has a true module system that supports separate compilation and
 generates and uses module summaries (highbrowspeak for "header files")
 automatically from source, so you don't need to worry about
 maintaining redundant files separately, unless you really wish to, in
 which case you can. Yep, that stops that nag right in mid-sentence."

 But it is not true...

How is it not true?

I don't know if .di generation from .d or .h is any good or bad, but the comparison of auto-generated .di files to hand crafted .h files doesn't make sense.

Nobody stops you from hand crafting *.di files.
Nov 28 2011
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/28/2011 06:41 PM, Maxim Fomin wrote:
 2011/11/28 Timon Gehr<timon.gehr gmx.ch>:
 On 11/28/2011 09:01 AM, so wrote:
 On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright
 <newshound2 digitalmars.com>  wrote:

 On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
 "D has a true module system that supports separate compilation and
 generates and uses module summaries (highbrowspeak for "header files")
 automatically from source, so you don't need to worry about
 maintaining redundant files separately, unless you really wish to, in
 which case you can. Yep, that stops that nag right in mid-sentence."

 But it is not true...

How is it not true?

I don't know if .di generation from .d or .h is any good or bad, but the comparison of auto-generated .di files to hand crafted .h files doesn't make sense.

Nobody stops you from hand crafting *.di files.

And what sense is in hand crafting .di files? What would you do different? Remove method definitions/private members?

The main point is that some people want to have separate specification and implementation. If you don't separate the two, they risk being confused. (as is often the case with the D programming language and its reference implementation.) In such a setting, the .di file can eg. act as a contract between library implementer and library user. Eg: // .di, this is the specification module awesomeLibrary; /** * Documentation comment */ int foo(in int x) /// maybe documentation comment on in contract in{assert(x<int.max);} /// maybe documentation comment on out contract out(result){assert(result>x);} class Bar { int foo(int x) in{...} out{...} } // .d, the implementation int foo(int x) { // (contract automatically read from .di file) return x+1; } class Bar{ int foo(int x){ return x + y; } private int y; } And that is the kind of stuff that does not work yet.
Nov 28 2011
prev sibling next sibling parent reply Jude <10equals2 gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/27/2011 06:44 PM, Alexey Veselovsky wrote:
 I'm trying to switch from C++ to D. But I can't find some things
 that I love in C++. For example in C++ I can separate module
 specification and implementation. Advertising article "The Case for
 D" says that it is real in D too:
 
 "D has a true module system that supports separate compilation and 
 generates and uses module summaries (highbrowspeak for "header
 files") automatically from source, so you don't need to worry
 about maintaining redundant files separately, unless you really
 wish to, in which case you can. Yep, that stops that nag right in
 mid-sentence."
 
 But it is not true...

dmd -H [file] -c generates the header file for you quite nicely. no offense, I think you need a little help.. if you are on linux, man dmd is your friend. tells you all of the options and what they do. if you are not on linux, get on linux. (or use dmd --help... but mainly get linux) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO0ur5AAoJENcHIWLyQiSljU4IAOpT+UzenxvZwh5VGItoGJRV XGea9f0hZkgOUe9+5ajnEOybDa83//e/WEABfjKPfHMea+I1lLySzLlUEbMAbuiD 6kELOEEc+cBAwLTdAb7h/Hmfj2jhfMimWZFeOD5bLBq9ZqMXSw7zOs7PPHc9iXXl CHSvdYTL5Xlvs5e/ELTrF7Dh/gj6pdjHWvBXaPbKbeWWklzzU+SLM/VCwRR2L7EK qz6p5knCxQbASECt6zrB2hWrMMHzhNpEZ2R7tZHxTRPN3YAKwcJxzBxAWdF+T/qq cNSM0dMzmuUfJMjIADdiekjx681AQ8REQpzU7NW08MXSKhavyyTCcVYVsl+qb5Y= =VF74 -----END PGP SIGNATURE-----
Nov 27 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/27/2011 11:40 PM, Alexey Veselovsky wrote:
 Also I can't
 write method implementation in different (implementation) file
 (without inheritance).

---------- .di file ------------ module foo; int bar(); ---------- .d file ------------- module foo; int bar() { return 3; } --------------------------------
Nov 28 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2011 3:19 AM, Alexey Veselovsky wrote:
 Also I can't
 write method implementation in different (implementation) file
 (without inheritance).

---------- .di file ------------ module foo; struct Foo { void foo(); } ---------- .d file ------------- module foo; struct Foo { void foo() { ... code ... } } ---------------------------------
Nov 28 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2011 3:41 AM, Alexey Veselovsky wrote:
 ok. What about:

 struct Foo {
      int a;
      int b;
      // 100 more fields
      ...
      void foo();
 }

 Did I must write in implementation all this 100+ fields in implementation?

Yes. (Unless you decide to use the PIMPL idiom.)
Nov 28 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/28/2011 4:00 AM, Alexey Veselovsky wrote:
 ok. I just removed from test.di all non public entities.

 // D import file generated from 'test.d'
 module test;
 public
 {
      void foo();

      struct Boo
      {
          public
          {
              void boo();
          }
      }
 }

 Now, let's build it:
 $ dmd test.di test.d main.d
 test.d: Error: module test from file test.d conflicts with another
 module test from file test.di

 di file not specification, but just another version of implementation?

You cannot compile with both the di and d file.
 Compiler doesn't know anything about "specification" files. So, he
 did't check specification&implementation conformance.

Yes, that's correct.
Nov 28 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 On 11/28/2011 4:00 AM, Alexey Veselovsky wrote:
 Compiler doesn't know anything about "specification" files. So, he
 did't check specification&implementation conformance.

Yes, that's correct.

And this is positive because? See also Timon answer: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=150164 Bye, bearophile
Nov 28 2011
parent reply Kagamin <spam here.lot> writes:
bearophile Wrote:

 And this is positive because?

You say it as if it's negative.
Nov 28 2011
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Kagamin Wrote:

 bearophile Wrote:
 
 And this is positive because?

You say it as if it's negative.

For me it is negative as what I understood from this discussion is that contrary to what is described in TDPL, D modules are not ready to prime time. At least at the level Modula-2(3), Ada, Delphi, .Net, among others, offer modules.
Nov 29 2011
parent Kagamin <spam here.lot> writes:
Paulo Pinto Wrote:

 Kagamin Wrote:
 
 bearophile Wrote:
 
 And this is positive because?

You say it as if it's negative.

For me it is negative as what I understood from this discussion is that contrary to what is described in TDPL, D modules are not ready to prime time. At least at the level Modula-2(3), Ada, Delphi, .Net, among others, offer modules.

And what .net modules provide you that D modules don't? Putting aside that I don't remember anything like D modules in .net. .Net has namespaces, which I prefer more, yes.
Nov 29 2011
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/28/2011 08:40 PM, Walter Bright wrote:
 On 11/28/2011 4:00 AM, Alexey Veselovsky wrote:
 ok. I just removed from test.di all non public entities.

 // D import file generated from 'test.d'
 module test;
 public
 {
 void foo();

 struct Boo
 {
 public
 {
 void boo();
 }
 }
 }

 Now, let's build it:
 $ dmd test.di test.d main.d
 test.d: Error: module test from file test.d conflicts with another
 module test from file test.di

 di file not specification, but just another version of implementation?

You cannot compile with both the di and d file.
 Compiler doesn't know anything about "specification" files. So, he
 did't check specification&implementation conformance.

Yes, that's correct.

Actually the first part is not correct. The compiler knows about interface files, and prefers those for imports in case the corresponding .d file is not compiled with the same command (what makes sense).
Nov 29 2011
prev sibling next sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
I come from the C++ world as well. I still do some C++ work, mostly related 
to my legacy applications... C++ has no modules. End of story. Header files 
are not modules, they are just... piece of source code. I also did some 
(toy) Modula-3 projects in the past, and must admit I adore the language. 
There this distinction is most obvious.
Nov 28 2011
prev sibling parent reply Max Samukha <maxter spambox.com> writes:
On 11/28/2011 11:44 AM, so wrote:
 On Mon, 28 Nov 2011 11:42:24 +0200, Caligo <iteronvexor gmail.com> wrote:

 On Sun, Nov 27, 2011 at 6:44 PM, Alexey Veselovsky <
 alexey.veselovsky gmail.com> wrote:

 I'm trying to switch from C++ to D. But I can't find some things that
 I love in C++. For example in C++ I can separate module specification
 and implementation. Advertising article "The Case for D" says that it
 is real in D too:

 "D has a true module system that supports separate compilation and
 generates and uses module summaries (highbrowspeak for "header files")
 automatically from source, so you don't need to worry about
 maintaining redundant files separately, unless you really wish to, in
 which case you can. Yep, that stops that nag right in mid-sentence."

 But it is not true...

The separation of specification and implementation in C/C++ is not some feature that they came up. I would call it a design defect. Having to split up code between header files and source files is one of the things I dislike about C/C++. As for why anyone would be in love with such a thing, well that's just beyond me.

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.
Nov 28 2011
parent reply Max Samukha <maxter spambox.com> writes:
On 11/28/2011 02:29 PM, so wrote:
 On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha <maxter 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 .
 Amazing, so now "programmer" means VisualStudio user? Probably this is
 why everyone using only C/C++ for serious library development.

Your information about "serious" programming is a bit outdated.
 (Please don't take it personal, this is my usual tone)

No problem.
Nov 28 2011
next sibling parent Max Samukha <maxter spambox.com> writes:
On 11/28/2011 03:52 PM, so wrote:
 On Mon, 28 Nov 2011 15:34:19 +0200, Max Samukha <maxter spambox.com> wrote:

 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:

I started to use vim/cmake "after" years of using IDEs, and one of the best if not the best VisualStudio.
 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

Now how do you know you have a "Lib", and it implements "hello", what rule enforces that? If this is all it does, you are overlooking the most important point of header files.

Could you clarify what is the most important part? If you want to use a library, you would need to read its docs anyway. The interface files won't be of much help (D's ones will, since dmd liberally pours implementations into them). If the docs are unavailable or outdated, you can always extract the declarations from the library: monop -a -r:lib.dll lib Version=0.0.0.0 Culture=neutral PublicKeyToken=null public class Lib { public Lib (); public static void hello (); } Creating separate interface files, taking trouble to push them around along with the library and then feeding them to the compiler are needlessly redundant steps. Or what am I missing?
 Your information about "serious" programming is a bit outdated.

What i mean by "serious" is that, if you "need" a specific language for some task what you are doing is serious. Because you are falling back to a less known and probably more complex tools/languages, it is much harder to replace you. I am still waiting for the next-gen game engine, next-gen video decoder/encoder, next-gen ... from those serious languages you mention. I am not ridiculing anything, aren't these the facts?

The fact is that apps with tight real-time requirements cannot be developed in C# for obvious reasons, and compilation models are irrelevant to the fact. Ok, I am not a C# advocate. I hate it no less than C++ or D. It just happens that its compilation model is superior.
Nov 28 2011
prev sibling next sibling parent reply Max Samukha <maxter spambox.com> writes:
On 11/28/2011 04:05 PM, so wrote:
 For the second part if library writer changes anything with
 "implementation", that would not affect the user.
 In your case it does, because there is no distinction between
 specification and implementation

There is, but the specification is bundled with the implementation.
Nov 28 2011
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 11/28/2011 05:41 PM, Alexey Veselovsky wrote:
 Separate hand written specification is rulez for human. It is best
 short module description (with some useful manually written comments).
 I like it more then autogenerated docs (by doxygen and so on).

 Autogenerated specifications (headers and so on) are worst and ugly.
 But in language like java and C# it is last chance if there is no
 autogenerated docs and sources.

The compiler _should_ enforce consistence between *.d and *.di files when compiling the *.d file. It just does not because nobody has implemented it. That is possibly because separate hand written specification is rarely used in D development. (alternatively, it could be the case that hand written specification is used rarely because DMD does not check .d and .di for consistence.) Autogeneration of *.di files does not have to be the normal case (and currently it is so buggy that I managed to find a segfault bug in the compiler while compiling a mis-generated *.di file!) Also, auto generation can hardly even work satisfactory in the general case, when there are many static if's/version statements or string mixin declarations on module scope.
Nov 28 2011
parent Hans Uhlig <hans.uhlig teamaol.com> writes:
On 11/28/2011 9:40 AM, Timon Gehr wrote:
 On 11/28/2011 05:41 PM, Alexey Veselovsky wrote:
 Separate hand written specification is rulez for human. It is best
 short module description (with some useful manually written comments).
 I like it more then autogenerated docs (by doxygen and so on).

 Autogenerated specifications (headers and so on) are worst and ugly.
 But in language like java and C# it is last chance if there is no
 autogenerated docs and sources.

The compiler _should_ enforce consistence between *.d and *.di files when compiling the *.d file. It just does not because nobody has implemented it. That is possibly because separate hand written specification is rarely used in D development. (alternatively, it could be the case that hand written specification is used rarely because DMD does not check .d and .di for consistence.) Autogeneration of *.di files does not have to be the normal case (and currently it is so buggy that I managed to find a segfault bug in the compiler while compiling a mis-generated *.di file!) Also, auto generation can hardly even work satisfactory in the general case, when there are many static if's/version statements or string mixin declarations on module scope.

Can we put this on the priority list. It would be nice to be able to define a specification and then be able to verify against it during unit tests, compilation etc.
Dec 02 2011
prev sibling next sibling parent Max Samukha <maxter spambox.com> writes:
On 11/28/2011 06:07 PM, Maxim Fomin wrote:
 In conclusion, I find D module support the worst one.

Sad but true.
Nov 28 2011
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 11/28/2011 05:07 PM, Maxim Fomin wrote:
 2011/11/28 Max Samukha<maxter spambox.com>:
 On 11/28/2011 02:29 PM, so wrote:
 On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha<maxter 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.
Nov 28 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.

Dec 02 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
Walter Bright Wrote:
 It's too bad there's no way to 'bind' arbitrary data to shared executable 
 library files

Would using the resource compiler work on Windows? I'm pretty sure dlls have icon resources just like exes, so having a string resource in there might work too. (I don't know that much about it though.) I know even less about the Linux format than I do the Windows one though :-(
Dec 02 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 12/2/2011 5:44 PM, Adam D. Ruppe wrote:
 Walter Bright Wrote:
 It's too bad there's no way to 'bind' arbitrary data to shared executable
 library files

Would using the resource compiler work on Windows? I'm pretty sure dlls have icon resources just like exes, so having a string resource in there might work too. (I don't know that much about it though.) I know even less about the Linux format than I do the Windows one though :-(

It's a good idea, I think that could work, actually.
Dec 02 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-12-03 02:44, Adam D. Ruppe wrote:
 Walter Bright Wrote:
 It's too bad there's no way to 'bind' arbitrary data to shared executable
 library files

Would using the resource compiler work on Windows? I'm pretty sure dlls have icon resources just like exes, so having a string resource in there might work too. (I don't know that much about it though.) I know even less about the Linux format than I do the Windows one though :-(

It's easy on Mac OS X with its concept of bundles. Just a regular directory with an extension and a specific layout that the applications and the tools recognizes. -- /Jacob Carlborg
Dec 04 2011
prev sibling next sibling parent Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
I'm trying to switch from C++ to D. But I can't find some things that
I love in C++. For example in C++ I can separate module specification
and implementation. Advertising article "The Case for D" says that it
is real in D too:

"D has a true module system that supports separate compilation and
generates and uses module summaries (highbrowspeak for "header files")
automatically from source, so you don't need to worry about
maintaining redundant files separately, unless you really wish to, in
which case you can. Yep, that stops that nag right in mid-sentence."

But it is not true...
Nov 27 2011
prev sibling next sibling parent Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
WB> How is it not true?
J> dmd -H [file] -c generates the header file for you quite nicely.

ok. Let's a see:

C++ code.

Specification:

// test.hpp file
#ifndef _test_hpp_
#define _test_hpp_

void foo();

struct Boo
{
public:
    void boo();
private:
    struct S {};
};

#endif

Implementation:

// file test.cpp
#include "test.hpp"

struct HelperStruct {}; // private struct for this module only

static void foo_helper() {HelperStruct s;}

void foo() { foo_helper(); }

void Boo::boo() { S ss; foo_helper(); } // method implementation in
implementation side, not in specification!

Module usage:

// file main.cpp
#include "test.hpp"

int main() {
    foo();          // ok
    Boo b;          // ok
    b.boo();        // ok
    Boo::S ss;      // error: struct Boo::S is private
    HelperStruct s; // error: HelperStruct was not declared in this scope
    return 0;
}

Now, let's try this on D:

// Implementation
module test;

public {
    void foo() {foo_helper();}

    struct Boo
    {
    public:
        void boo() {S ss; foo_helper();}
    private:
        struct S {};
    }
}

private {
    struct HelperStruct {};
    void foo_helper() {HelperStruct s;}
}

// Specification (generated by dmd -H test.d -c) -- test.di file
// D import file generated from 'test.d'
module test;
public
{
    void foo() {foo_helper();}

    struct Boo
    {
        public
        {
            void boo() {S ss; foo_helper();}
            private struct S{}
        }
    }
}

private
{
    struct HelperStruct{}
    void foo_helper(){HelperStruct s;}
}

Usage:
import test;

void main() {
    foo();          // ok
    Boo b;          // ok
    b.boo();        // ok
    Boo.S ss;       // ok (wtf?)
    HelperStruct s; // ok (wtf?!)
}


First of all I can't see difference between D's implementation and
generated specification. It looks like copy&paste. At second private
section not protect types from usage from other modules.  Also I can't
write method implementation in different (implementation) file
(without inheritance).

Also there are no compiler check for test.di & test.d conformance.

In D I expect real module system like in Modula or Ada. Or at least as
in C++ (or way to emulate it). But...

PS. DMD32 D Compiler v2.056
Nov 27 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
 "D has a true module system that supports separate compilation and
 generates and uses module summaries (highbrowspeak for "header files")
 automatically from source, so you don't need to worry about
 maintaining redundant files separately, unless you really wish to, in
 which case you can. Yep, that stops that nag right in mid-sentence."

 But it is not true...

How is it not true?

I don't know if .di generation from .d or .h is any good or bad, but the comparison of auto-generated .di files to hand crafted .h files doesn't make sense.
Nov 28 2011
prev sibling next sibling parent Maxim Fomin <maxim maxim-fomin.ru> writes:
2011/11/28 so <so so.so>:
 On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
 "D has a true module system that supports separate compilation and
 generates and uses module summaries (highbrowspeak for "header files")
 automatically from source, so you don't need to worry about
 maintaining redundant files separately, unless you really wish to, in
 which case you can. Yep, that stops that nag right in mid-sentence."

 But it is not true...

How is it not true?

I don't know if .di generation from .d or .h is any good or bad, but the comparison of auto-generated .di files to hand crafted .h files doesn't make sense.

It is true and makes sense until D will stop claiming .di files are interface files. I also was curious how should i replace C library style with .h and .c files. In D, when compiler generate "interface" it effectively dumps implementation in .di file. I see no difference (except braces and indentation) between generated .di code and manually written .d code. Furthermore, considering problems with libraries, written in GC language, and broken shared libraries support in linux (probably it is fixed now, i looked this issue several month ago) writing libraries in D is full of surprises. I tried to write a lib and a project, which used that lib separately, but came to conclusion that the best choice it to pull lib code to project one. And it is not a biggest problem, because dmd produces 700 kb executable for hello word program.
Nov 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 11:01:31 +0200, Maxim Fomin <maxim maxim-fomin.ru>  
wrote:

 In D, when compiler generate "interface" it effectively dumps
 implementation in .di file.

This is what i meant by saying it doesn't make sense, it is an auto-generated file. You can argue about .di shortcomings but you can't compare them to header files.
 Furthermore, considering problems with libraries, written in GC language,
 and broken shared libraries support in linux (probably it is fixed
 now, i looked this issue several month ago)
 writing libraries in D is full of surprises.

Other than having a big C++ code base, shared libraries were my biggest troubles with D as well. I am still waiting for a final solution (kept me from using D so far), which i think have the highest priority.
 I tried to write a lib and a project, which used that lib separately,
 but came to conclusion
 that the best choice it to pull lib code to project one.
 And it is not a biggest problem, because dmd produces 700 kb
 executable for hello word program.

AFAIK executable size problems was temporary. And dmd still lacks a shared standard library, everything is static linked.
Nov 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 11:01:31 +0200, Maxim Fomin <maxim maxim-fomin.ru>  
wrote:

 It is true and makes sense until D will stop claiming .di files are
 interface files.
 I also was curious how should i replace C library style with .h and .c  
 files.
 In D, when compiler generate "interface" it effectively dumps
 implementation in .di file.
 I see no difference (except braces and indentation) between generated
 .di code and manually written .d code.

I admit i didn't use auto-generated .di files much. (not sure if i used ever) Now thinking about it, it is obvious why auto-generation part of it exist. Because D can afford such a luxury, quite possibly everyone already knows by now. For i am the bravest of all, i shall state the obvious! Now when you write a .d file, if you don't want others access it, you would label it private: If you want module access, label it package, otherwise public. Then compiler can pick those that is required to expose. For a C/C++ header file you can't auto-generate something like that because you don't know the library writers intentions.
Nov 28 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
--20cf307c9fececfefd04b2c8512e
Content-Type: text/plain; charset=ISO-8859-1

On Sun, Nov 27, 2011 at 6:44 PM, Alexey Veselovsky <
alexey.veselovsky gmail.com> wrote:

 I'm trying to switch from C++ to D. But I can't find some things that
 I love in C++. For example in C++ I can separate module specification
 and implementation. Advertising article "The Case for D" says that it
 is real in D too:

 "D has a true module system that supports separate compilation and
 generates and uses module summaries (highbrowspeak for "header files")
 automatically from source, so you don't need to worry about
 maintaining redundant files separately, unless you really wish to, in
 which case you can. Yep, that stops that nag right in mid-sentence."

 But it is not true...

The separation of specification and implementation in C/C++ is not some feature that they came up. I would call it a design defect. Having to split up code between header files and source files is one of the things I dislike about C/C++. As for why anyone would be in love with such a thing, well that's just beyond me. --20cf307c9fececfefd04b2c8512e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sun, Nov 27, 2011 at 6:44 PM, Alexey = Veselovsky <span dir=3D"ltr">&lt;<a href=3D"mailto:alexey.veselovsky gmail.= com">alexey.veselovsky gmail.com</a>&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex;"> I&#39;m trying to switch from C++ to D. But I can&#39;t find some things th= at<br> I love in C++. For example in C++ I can separate module specification<br> and implementation. Advertising article &quot;The Case for D&quot; says tha= t it<br> is real in D too:<br> <br> &quot;D has a true module system that supports separate compilation and<br> generates and uses module summaries (highbrowspeak for &quot;header files&q= uot;)<br> automatically from source, so you don&#39;t need to worry about<br> maintaining redundant files separately, unless you really wish to, in<br> which case you can. Yep, that stops that nag right in mid-sentence.&quot;<b= r> <br> But it is not true...<br> </blockquote></div><br>The separation of specification and implementation i= n C/C++ is not some feature that they came up.=A0 I would call it a design = defect.=A0 Having to split up code between header files and source files is= one of the things I dislike about C/C++.=A0 As for why anyone would be in = love with such a thing, well that&#39;s just beyond me.=A0 <br> --20cf307c9fececfefd04b2c8512e--
Nov 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 11:42:24 +0200, Caligo <iteronvexor gmail.com> wrote:

 On Sun, Nov 27, 2011 at 6:44 PM, Alexey Veselovsky <
 alexey.veselovsky gmail.com> wrote:

 I'm trying to switch from C++ to D. But I can't find some things that
 I love in C++. For example in C++ I can separate module specification
 and implementation. Advertising article "The Case for D" says that it
 is real in D too:

 "D has a true module system that supports separate compilation and
 generates and uses module summaries (highbrowspeak for "header files")
 automatically from source, so you don't need to worry about
 maintaining redundant files separately, unless you really wish to, in
 which case you can. Yep, that stops that nag right in mid-sentence."

 But it is not true...

The separation of specification and implementation in C/C++ is not some feature that they came up. I would call it a design defect. Having to split up code between header files and source files is one of the things I dislike about C/C++. As for why anyone would be in love with such a thing, well that's just beyond me.

How would you write libraries?
Nov 28 2011
prev sibling next sibling parent Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
 The separation of specification and implementation in C/C++ is not some
 feature that they came up.=A0 I would call it a design defect.=A0 Having =

 split up code between header files and source files is one of the things =

 dislike about C/C++.=A0 As for why anyone would be in love with such a th=

 well that's just beyond me.

In Modula and Ada separation specification and implementation is the key feature. Ada was designed for large mission critical systems. I want be able to separate specification from implementation. Specification is primary and must be written manually. Compiler must check conformance implementation and specification.
Nov 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 09:40:06 +0200, Alexey Veselovsky  
<alexey.veselovsky gmail.com> wrote:

 Now, let's try this on D:

 // Implementation
 module test;

 public {
     void foo() {foo_helper();}

     struct Boo
     {
     public:
         void boo() {S ss; foo_helper();}
     private:
         struct S {};
     }
 }

 private {
     struct HelperStruct {};
     void foo_helper() {HelperStruct s;}
 }

 // Specification (generated by dmd -H test.d -c) -- test.di file
 // D import file generated from 'test.d'
 module test;
 public
 {
     void foo() {foo_helper();}

     struct Boo
     {
         public
         {
             void boo() {S ss; foo_helper();}
             private struct S{}
         }
     }
 }

 private
 {
     struct HelperStruct{}
     void foo_helper(){HelperStruct s;}
 }

 Usage:
 import test;

 void main() {
     foo();          // ok
     Boo b;          // ok
     b.boo();        // ok
     Boo.S ss;       // ok (wtf?)
     HelperStruct s; // ok (wtf?!)
 }

You are right, i can't see anything that requires "not one" of those private stuff to be exposed. This has to be a bug.
Nov 28 2011
prev sibling next sibling parent Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
I think that D should provide an opportunity for both styles: with or
without specification separation from implementation. In some cases I
prefer to not separate implementation (small programs / scripts), but
in some projects I really need to separate implementation from
manually written specification. (specification is primo/master,
implementation is secondary/slave).
Nov 28 2011
prev sibling next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 28.11.2011, 11:02 Uhr, schrieb Jude <10equals2 gmail.com>:

 I tried to write a lib and a project, which used that lib
 separately, but came to conclusion that the best choice it to pull
 lib code to project one. And it is not a biggest problem, because
 dmd produces 700 kb executable for hello word program.

what..? I don't know how you are managing to get 700kb for hello world... mine clocks in a 283.7kb with dmd with no optmizations, and holy crap 1.6MB for same file with gdmd. WTF is going on there I wonder...?

*drum roll* 148,2 kB (dmd 2.054, Linux) *tadaa* - 8< - - - - - - - - - - - - - - - - - - - import std.stdio; void main() { writeln("Hello, world!"); } - 8< - - - - - - - - - - - - - - - - - - -
Nov 28 2011
prev sibling next sibling parent Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
 Also I can't
 write method implementation in different (implementation) file
 (without inheritance).

---------- .di file ------------ module foo; int bar(); ---------- .d file ------------- module foo; int bar() { return 3; }

Method, not global function. struct Foo { void foo(); } I want write this in di. And in d i want write implementation.
Nov 28 2011
prev sibling next sibling parent reply Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
 =A0module foo;

 =A0struct Foo {
 =A0 =A0 =A0 void foo();
 =A0}

 =A0---------- .d file -------------

 =A0module foo;

 =A0struct Foo {
 =A0 =A0 =A0 void foo() { ... code ... }
 =A0}

ok. What about: struct Foo { int a; int b; // 100 more fields ... void foo(); } Did I must write in implementation all this 100+ fields in implementation? In Ada and Modula there is 2 languages: one for implementation and another for specification. (specification language not subset of implementation language). I think it is right.
Nov 28 2011
parent Kagamin <spam here.lot> writes:
Alexey Veselovsky Wrote:

 ok. What about:
 
 struct Foo {
     int a;
     int b;
     // 100 more fields
     ...
     void foo();
 }
 
 Did I must write in implementation all this 100+ fields in implementation?
 
 In Ada and Modula there is 2 languages: one for implementation and
 another for specification. (specification language not subset of
 implementation language). I think it is right.

In Java separation is done with interfaces. I think it is right.
Nov 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 13:32:12 +0200, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 11/28/2011 3:19 AM, Alexey Veselovsky wrote:
 Also I can't
 write method implementation in different (implementation) file
 (without inheritance).

---------- .di file ------------ module foo; struct Foo { void foo(); } ---------- .d file ------------- module foo; struct Foo { void foo() { ... code ... } } ---------------------------------

His example which i replied was to the point. Structs don't have any fields labeled private elsewhere, but the compiler still exposing private structs/functions which was used by function implementations.
Nov 28 2011
prev sibling next sibling parent Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
ok. I just removed from test.di all non public entities.

// D import file generated from 'test.d'
module test;
public
{
    void foo();

    struct Boo
    {
        public
        {
            void boo();
        }
    }
}

Now, let's build it:
$ dmd test.di test.d main.d
test.d: Error: module test from file test.d conflicts with another
module test from file test.di

di file not specification, but just another version of implementation?

ok. let's separate build.

$ dmd -c test.d
$ dmd main.d test.di
main.d(7): Error: no property 'S' for type 'Boo'
main.d(7): Error: Boo.S is used as a type
main.d(8): Error: undefined identifier HelperStruct

It seem like ok. Expected error. We fix it, and everybody happy. But
after years, someone changes test.d:

module test;

public {
    void foo() {foo_helper();}

    struct Boo
    {
    public:
        void booBar() {S ss; foo_helper();} // <---- method was renamed
    private:
        struct S {};
    }
}

private {
    struct HelperStruct {};
    void foo_helper() {HelperStruct s;}
}

He rename method, but forgot to change test.di. Let's build it:
$ dmd -c test.d
$ dmd main.d test.di
Undefined symbols for architecture i386:
  "_D4test3Boo3booMFZv", referenced from:
      __Dmain in main.o
  "_D4test3fooFZv", referenced from:
      __Dmain in main.o
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status

Oops. No compilation error. Only linker error. Welcome back to C!

Compiler doesn't know anything about "specification" files. So, he
did't check specification&implementation conformance.
Nov 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha <maxter 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? Amazing, so now "programmer" means VisualStudio user? Probably this is why everyone using only C/C++ for serious library development. (Please don't take it personal, this is my usual tone)
Nov 28 2011
prev sibling next sibling parent Maxim Fomin <maxim maxim-fomin.ru> writes:
2011/11/28 Marco Leise <Marco.Leise gmx.de>:
 Am 28.11.2011, 11:02 Uhr, schrieb Jude <10equals2 gmail.com>:

 I tried to write a lib and a project, which used that lib
 separately, but came to conclusion that the best choice it to pull
 lib code to project one. And it is not a biggest problem, because
 dmd produces 700 kb executable for hello word program.

what..? I don't know how you are managing to get 700kb for hello world... mine clocks in a 283.7kb with dmd with no optmizations, and holy crap 1.6MB for same file with gdmd. WTF is going on there I wonder...?

*drum roll* 148,2 kB (dmd 2.054, Linux) *tadaa* - 8< - - - - - - - - - - - - - - - - - - - import std.stdio; void main() { =A0 =A0 =A0 =A0writeln("Hello, world!"); } - 8< - - - - - - - - - - - - - - - - - - -

------ import std.stdio; class dummy { this() { writeln("ctor");} ~this() { writeln("dtor"); } } void main() { auto dm =3D new dummy(); } ------- dmd main.d -o 377,9 kb It is not 700 as i told, but yesterday i upgraded to 2.056. But definitely i saw that it produces 700 kb elf for a small program. Anyway, is 400 kb for dummy program too much?
Nov 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 15:34:19 +0200, Max Samukha <maxter spambox.com> wrote:

 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:

I started to use vim/cmake "after" years of using IDEs, and one of the best if not the best VisualStudio.
 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

Now how do you know you have a "Lib", and it implements "hello", what rule enforces that? If this is all it does, you are overlooking the most important point of header files.
 Your information about "serious" programming is a bit outdated.

What i mean by "serious" is that, if you "need" a specific language for some task what you are doing is serious. Because you are falling back to a less known and probably more complex tools/languages, it is much harder to replace you. I am still waiting for the next-gen game engine, next-gen video decoder/encoder, next-gen ... from those serious languages you mention. I am not ridiculing anything, aren't these the facts?
Nov 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 15:52:51 +0200, so <so so.so> wrote:

 Now how do you know you have a "Lib", and it implements "hello", what  
 rule enforces that?
 If this is all it does, you are overlooking the most important point of  
 header files.

It was obscure. A header enforces its contents for both library writer and library user. If library writer needs a change in header. Both writer and the user needs to change their code. For the second part if library writer changes anything with "implementation", that would not affect the user. In your case it does, because there is no distinction between specification and implementation, every implementation is the new spec.
Nov 28 2011
prev sibling next sibling parent reply Maxim Fomin <maxim maxim-fomin.ru> writes:
2011/11/28 Max Samukha <maxter spambox.com>:
 On 11/28/2011 02:29 PM, so wrote:
 On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha <maxter 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=3Dvs.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 too=

 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 t=

 create a mono app and library:

 1. Library:

 nano lib.cs
 ----
 using System;

 public class Lib
 {
 =A0 =A0public static void hello() { Console.WriteLine("We don't need no h=

 crap"); }
 }
 ----

 Compile that into a library, lib.dll:

 dmcs lib.cs -target:library

 2. Host:

 nano app.cs
 ----
 class App
 {
 =A0 =A0public static void Main()
 =A0 =A0{
 =A0 =A0 =A0 =A0Lib.hello();
 =A0 =A0}
 }

 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 libr= ary. 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.
Nov 28 2011
next sibling parent Adam Ruppe <destructionator gmail.com> writes:
Do you think it'd be a good thing to put the .di file in the
generated compiled lib?

That'd be somewhat similar to the c# example.

dmd myprog.d something.dll

searches something.dll for a .di reference, and adds it to the
compile command line if it's there.
Nov 28 2011
prev sibling parent Kagamin <spam here.lot> writes:
Maxim Fomin Wrote:

 C#: as example above. No headers. Private members are not known.

Maxim Fomin Wrote:
 C#: as example above. No headers. Private members are not known.

Hmm... Really? Though I remember something about "can't access private member" errors. And yes, metadata sells you everything including private classes (except for comments).
 link program upon compiling to already compiled .dll
    Actually, this is the best modularization support comparing these 4
 languages.

Ability to use shared assembly in .net comes from it's dynamic properties, not modularization. You can actually access non-existent members, these accesses are resolved at runtime and it will just throw MemberNotFoundException if the access actually occurs, but all other code around will work just fine.
     with function exporting. And what about a class, its methods and
 private members?). Recompile everything when implementation/interface
     is changed.

With visual studio recompilation is done whenever a referenced assembly changes, no matter what changed: private member or public.
Nov 29 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 18:21:03 +0200, Max Samukha <maxter spambox.com> wrote:

 Could you clarify what is the most important part?

As i tried in the above post, header files are specs, a contract between library writer and the user. A dll itself is not a spec, it is the implementation.
 If you want to use a library, you would need to read its docs anyway.
 The interface files won't be of much help (D's ones will, since dmd  
 liberally pours implementations into them). If the docs are unavailable  
 or outdated, you can always extract the declarations from the library:

 monop -a -r:lib.dll

 lib
 Version=0.0.0.0
 Culture=neutral
 PublicKeyToken=null

 public class Lib {
 	
 	public Lib ();
 	
 	public static void hello ();
 }

 Creating separate interface files, taking trouble to push them around  
 along with the library and then feeding them to the compiler are  
 needlessly redundant steps. Or what am I missing?

Well if you think that is redundant, you should neither comment nor document your code, Because i think they are less important than what header files trying to solve, they don't even give you any guaranties.
 The fact is that apps with tight real-time requirements cannot be  
 developed in C# for obvious reasons, and compilation models are  
 irrelevant to the fact.

They are mostly libraries so it is more than relevant.
Nov 28 2011
prev sibling next sibling parent Alexey Veselovsky <alexey.veselovsky gmail.com> writes:
Separate hand written specification is rulez for human. It is best
short module description (with some useful manually written comments).
I like it more then autogenerated docs (by doxygen and so on).

Autogenerated specifications (headers and so on) are worst and ugly.
But in language like java and C# it is last chance if there is no
autogenerated docs and sources.
Nov 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 18:41:30 +0200, Alexey Veselovsky  
<alexey.veselovsky gmail.com> wrote:

 Separate hand written specification is rulez for human. It is best
 short module description (with some useful manually written comments).
 I like it more then autogenerated docs (by doxygen and so on).

I agree for C/C++ and even for D, but D's module capabilities make auto-generation of the same thing possible, which is a very good thing. Now we need to make it work :)
Nov 28 2011
prev sibling next sibling parent so <so so.so> writes:
On Mon, 28 Nov 2011 19:26:23 +0200, Timon Gehr <timon.gehr gmx.ch> wrote:

 Nobody stops you from hand crafting *.di files.

My point exactly.
Nov 28 2011
prev sibling next sibling parent Maxim Fomin <maxim maxim-fomin.ru> writes:
2011/11/28 Timon Gehr <timon.gehr gmx.ch>:
 On 11/28/2011 09:01 AM, so wrote:
 On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright
 <newshound2 digitalmars.com> wrote:

 On 11/27/2011 4:44 PM, Alexey Veselovsky wrote:
 "D has a true module system that supports separate compilation and
 generates and uses module summaries (highbrowspeak for "header files")
 automatically from source, so you don't need to worry about
 maintaining redundant files separately, unless you really wish to, in
 which case you can. Yep, that stops that nag right in mid-sentence."

 But it is not true...

How is it not true?

I don't know if .di generation from .d or .h is any good or bad, but the comparison of auto-generated .di files to hand crafted .h files doesn't make sense.

Nobody stops you from hand crafting *.di files.

And what sense is in hand crafting .di files? What would you do different? Remove method definitions/private members?
Nov 28 2011
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
so Wrote:

 http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/

o.O overload a lambda?
Nov 28 2011
parent Jude <10equals2 gmail.com> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/28/2011 12:37 PM, Kagamin wrote:
 so Wrote:
 
 http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/

o.O overload a lambda?

....And now I see what all the hype is about with D's template system. Good lord. I've never really looked at C++ templates before. 0.0 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO1CWQAAoJENcHIWLyQiSlIIcH/A56cclkWm+4F42AWGUNvCmt sMffKN+1BbPc4ksEmRbPBwA4EzpAsaxMHpYaWW/OvHnoKqX578WAy3IWWOzp2xnn AKK5gocJ700DRgdKqPR1sv4wIrBGzk2a23YWmckV0bWCGi+JCtNiCjbRbLwIPF81 wyYAc2FgBYaj2P4lfKhvVuFMw5YP+uSaROkyVIiekWFR5XNOlhPPWVnq2FoaqlWi V6Xd6k/ry/QbmE0Dszmyybhvawc78hXfCwFgwv9NvwdDNhHUFfIw+hJipo7ObY3P dsN56yH8XFYY3NIzLMjRZGMaGWxhbnx61QWB1P4n1HvSR1agpFe2kowTjnt3/Zo= =03q7 -----END PGP SIGNATURE-----
Nov 28 2011
prev sibling next sibling parent reply so <so so.so> writes:
On Mon, 28 Nov 2011 21:12:32 +0200, Kagamin <spam here.lot> wrote:

 In Java separation is done with interfaces. I think it is right.

For Java, yes.
Nov 28 2011
parent Kagamin <spam here.lot> writes:
so Wrote:

 On Mon, 28 Nov 2011 21:12:32 +0200, Kagamin <spam here.lot> wrote:
 
 In Java separation is done with interfaces. I think it is right.

For Java, yes.

Java, D or C++, classes and structs are not a separation. Want a real separation? See COM: it doesn't even have notion of a field.
Nov 28 2011
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
Am 28.11.2011, 14:42 Uhr, schrieb Maxim Fomin <maxim maxim-fomin.ru>:

 2011/11/28 Marco Leise <Marco.Leise gmx.de>:
 Am 28.11.2011, 11:02 Uhr, schrieb Jude <10equals2 gmail.com>:

 I tried to write a lib and a project, which used that lib
 separately, but came to conclusion that the best choice it to pull
 lib code to project one. And it is not a biggest problem, because
 dmd produces 700 kb executable for hello word program.

what..? I don't know how you are managing to get 700kb for hello world... mine clocks in a 283.7kb with dmd with no optmizations, and holy crap 1.6MB for same file with gdmd. WTF is going on there I wonder...?

*drum roll* 148,2 kB (dmd 2.054, Linux) *tadaa* - 8< - - - - - - - - - - - - - - - - - - - import std.stdio; void main() { writeln("Hello, world!"); } - 8< - - - - - - - - - - - - - - - - - - -

------ import std.stdio; class dummy { this() { writeln("ctor");} ~this() { writeln("dtor"); } } void main() { auto dm = new dummy(); } ------- dmd main.d -o 377,9 kb It is not 700 as i told, but yesterday i upgraded to 2.056. But definitely i saw that it produces 700 kb elf for a small program. Anyway, is 400 kb for dummy program too much?

Be aware that classes and structs have .init blocks that can grow huge if you declare large static arrays in them. So the source code may be small, but the executable bloats. And every template instantiation adds to it as well. I think even just using writeln with different parameters all over the place adds up, but thats a vague guess.
Nov 28 2011