View mode: basic / threaded / horizontal-split · Log in · Help
November 28, 2011
Re: boost crowd.
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.
November 28, 2011
Re: boost crowd.
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.
November 28, 2011
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.
November 28, 2011
Re: boost crowd.
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.
November 28, 2011
Re: boost crowd.
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.
November 28, 2011
Re: boost crowd.
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?
November 28, 2011
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.
November 28, 2011
Re: boost crowd.
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.
November 28, 2011
Re: boost crowd.
> 
> 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...?
November 28, 2011
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).
1 2 3 4 5 6
Top | Discussion index | About this forum | D home