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 reply 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
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 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 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
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
parent reply 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
next sibling parent reply 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
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 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
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 parent reply "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
parent reply 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
parent reply "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
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 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
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 parent reply 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
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 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
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 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 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
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 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
next sibling parent reply 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
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 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 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 parent reply 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
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 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 next sibling parent reply Caligo <iteronvexor gmail.com> writes:
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.
Nov 28 2011
parent reply 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
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?



in the library, no need for separate headers.
Nov 28 2011
parent reply 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?



 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
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?



 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 reply 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
next sibling parent reply 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
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 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.

autogenerated docs and sources.
Nov 28 2011
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 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.

 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.

 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 parent reply 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 

irrelevant to the fact.


happens that its compilation model is superior.
Nov 28 2011
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  

 irrelevant to the fact.


They are mostly libraries so it is more than relevant.
Nov 28 2011
prev 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?



 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=


l

 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=


o

 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=


eader

 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 ...


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.


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.

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 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 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?



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 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?



 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 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.


 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.

 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 next sibling parent Kagamin <spam here.lot> writes:
Maxim Fomin Wrote:





Maxim Fomin Wrote:





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

in a user-accessible format.


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.




 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.




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


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


ing,

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