Re: boost crowd.
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
Re: boost crowd.
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.
Re: boost crowd.
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.
Re: boost crowd.
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 :-(
Re: boost crowd.
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.
Re: boost crowd.
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.
Re: boost crowd.
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.
Re: boost crowd.
On 29/11/11 2:12 AM, Marco Leise wrote:
Am 28.11.2011, 14:42 Uhr, schrieb Maxim Fomin ma...@maxim-fomin.ru:
2011/11/28 Marco Leise marco.le...@gmx.de:
Am 28.11.2011, 11:02 Uhr, schrieb Jude 10equa...@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).
Re: boost crowd.
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.
Re: boost crowd.
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.
Re: boost crowd.
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 specificationimplementation 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).
Re: boost crowd.
On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright newshou...@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.
Re: boost crowd.
2011/11/28 so s...@so.so: On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright newshou...@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.
Re: boost crowd.
On Mon, 28 Nov 2011 11:01:31 +0200, Maxim Fomin ma...@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.
Re: boost crowd.
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.
Re: boost crowd.
On Mon, 28 Nov 2011 11:01:31 +0200, Maxim Fomin ma...@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.
Re: boost crowd.
On Sun, Nov 27, 2011 at 6:44 PM, Alexey Veselovsky alexey.veselov...@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.
Re: boost crowd.
On Mon, 28 Nov 2011 11:42:24 +0200, Caligo iteronve...@gmail.com wrote: On Sun, Nov 27, 2011 at 6:44 PM, Alexey Veselovsky alexey.veselov...@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?
Re: boost crowd.
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. 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.
Re: boost crowd.
On Mon, 28 Nov 2011 09:40:06 +0200, Alexey Veselovsky
alexey.veselov...@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.
Re: boost crowd.
-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-
Re: boost crowd.
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).
Re: boost crowd.
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; }
Re: boost crowd.
Am 28.11.2011, 11:02 Uhr, schrieb Jude 10equa...@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 - - - - - - - - - - - - - - - - - - -
Re: boost crowd.
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.
Re: boost crowd.
module foo;
struct Foo {
void foo();
}
-- .d file -
module foo;
struct Foo {
void foo() { ... code ... }
}
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.
Re: boost crowd.
On Mon, 28 Nov 2011 13:32:12 +0200, Walter Bright
newshou...@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.
Re: boost crowd.
On 11/28/2011 11:44 AM, so wrote: On Mon, 28 Nov 2011 11:42:24 +0200, Caligo iteronve...@gmail.com wrote: On Sun, Nov 27, 2011 at 6:44 PM, Alexey Veselovsky alexey.veselov...@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.
Re: boost crowd.
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 specificationimplementation conformance.
Re: boost crowd.
On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha max...@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)
Re: boost crowd.
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
Re: boost crowd.
On 11/28/2011 02:29 PM, so wrote:
On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha max...@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.
Re: boost crowd.
2011/11/28 Marco Leise marco.le...@gmx.de:
Am 28.11.2011, 11:02 Uhr, schrieb Jude 10equa...@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?
Re: boost crowd.
On Mon, 28 Nov 2011 15:34:19 +0200, Max Samukha max...@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?
Re: boost crowd.
On Mon, 28 Nov 2011 15:52:51 +0200, so s...@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.
Re: boost crowd.
2011/11/28 Max Samukha max...@spambox.com:
On 11/28/2011 02:29 PM, so wrote:
On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha max...@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.
Re: boost crowd.
On 11/28/2011 03:52 PM, so wrote:
On Mon, 28 Nov 2011 15:34:19 +0200, Max Samukha max...@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.
Re: boost crowd.
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.
Re: boost crowd.
On Mon, 28 Nov 2011 18:21:03 +0200, Max Samukha max...@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.
Re: boost crowd.
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.
Re: boost crowd.
On 11/28/2011 06:07 PM, Maxim Fomin wrote: In conclusion, I find D module support the worst one. Sad but true.
Re: boost crowd.
On Mon, 28 Nov 2011 18:41:30 +0200, Alexey Veselovsky alexey.veselov...@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 :)
Re: boost crowd.
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.
Re: boost crowd.
On 11/28/2011 09:01 AM, so wrote: On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright newshou...@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.
Re: boost crowd.
On Mon, 28 Nov 2011 19:26:23 +0200, Timon Gehr timon.g...@gmx.ch wrote: Nobody stops you from hand crafting *.di files. My point exactly.
Re: boost crowd.
2011/11/28 Timon Gehr timon.g...@gmx.ch: On 11/28/2011 09:01 AM, so wrote: On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright newshou...@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?
Re: boost crowd.
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.
Re: boost crowd.
On 11/28/2011 05:07 PM, Maxim Fomin wrote:
2011/11/28 Max Samukhamax...@spambox.com:
On 11/28/2011 02:29 PM, so wrote:
On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukhamax...@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.
Re: boost crowd.
On 11/28/2011 06:41 PM, Maxim Fomin wrote:
2011/11/28 Timon Gehrtimon.g...@gmx.ch:
On 11/28/2011 09:01 AM, so wrote:
On Mon, 28 Nov 2011 03:44:23 +0200, Walter Bright
newshou...@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(xint.max);}
/// maybe documentation comment on out contract
out(result){assert(resultx);}
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.
Re: boost crowd.
so Wrote: http://cpp-next.com/archive/2011/11/having-it-all-pythy-syntax/ o.O overload a lambda?
Re: boost crowd.
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.
Re: boost crowd.
On Mon, 28 Nov 2011 21:12:32 +0200, Kagamin s...@here.lot wrote: In Java separation is done with interfaces. I think it is right. For Java, yes.
Re: boost crowd.
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.)
Re: boost crowd.
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 specificationimplementation conformance.
Yes, that's correct.
Re: boost crowd.
so Wrote: On Mon, 28 Nov 2011 21:12:32 +0200, Kagamin s...@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.
Re: boost crowd.
Walter: On 11/28/2011 4:00 AM, Alexey Veselovsky wrote: Compiler doesn't know anything about specification files. So, he did't check specificationimplementation conformance. Yes, that's correct. And this is positive because? See also Timon answer: http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=150164 Bye, bearophile
Re: boost crowd.
bearophile Wrote: And this is positive because? You say it as if it's negative.
Re: boost crowd.
-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-
Re: boost crowd.
Am 28.11.2011, 14:42 Uhr, schrieb Maxim Fomin ma...@maxim-fomin.ru:
2011/11/28 Marco Leise marco.le...@gmx.de:
Am 28.11.2011, 11:02 Uhr, schrieb Jude 10equa...@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.
Re: boost crowd.
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
Re: boost crowd.
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
Re: boost crowd.
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...
Re: boost crowd.
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?
Re: boost crowd.
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.
Re: boost crowd.
-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-
Re: boost crowd.
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 copypaste. 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
