November 28, 2011 Re: boost crowd. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alexey Veselovsky | 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; } -------------------------------- |
November 28, 2011 Re: boost crowd. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jude | 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< - - - - - - - - - - - - - - - - - - -
|
November 28, 2011 Re: boost crowd. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | >> 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.
|
November 28, 2011 Re: boost crowd. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Alexey Veselovsky | 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 ... } } --------------------------------- |
November 28, 2011 Re: boost crowd. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | > 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.
|
November 28, 2011 Re: boost crowd. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | 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.
|
November 28, 2011 Re: boost crowd. | ||||
---|---|---|---|---|
| ||||
Posted in reply to so | On 11/28/2011 11:44 AM, so wrote:
> On Mon, 28 Nov 2011 11:42:24 +0200, Caligo <iteronvexor@gmail.com> wrote:
>
>> On Sun, Nov 27, 2011 at 6:44 PM, Alexey Veselovsky <
>> alexey.veselovsky@gmail.com> wrote:
>>
>>> I'm trying to switch from C++ to D. But I can't find some things that
>>> I love in C++. For example in C++ I can separate module specification
>>> and implementation. Advertising article "The Case for D" says that it
>>> is real in D too:
>>>
>>> "D has a true module system that supports separate compilation and
>>> generates and uses module summaries (highbrowspeak for "header files")
>>> automatically from source, so you don't need to worry about
>>> maintaining redundant files separately, unless you really wish to, in
>>> which case you can. Yep, that stops that nag right in mid-sentence."
>>>
>>> But it is not true...
>>>
>>
>> The separation of specification and implementation in C/C++ is not some
>> feature that they came up. I would call it a design defect. Having to
>> split up code between header files and source files is one of the
>> things I
>> dislike about C/C++. As for why anyone would be in love with such a
>> thing,
>> well that's just beyond me.
>
> How would you write libraries?
The way they do, for example, in C# - interface definitions are stored in the library, no need for separate headers.
|
November 28, 2011 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 specification&implementation conformance. |
November 28, 2011 Re: boost crowd. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Max Samukha | On Mon, 28 Nov 2011 13:58:25 +0200, Max Samukha <maxter@spambox.com> wrote: >> How would you write libraries? > > The way they do, for example, in C# - interface definitions are stored in the library, no need for separate headers. Are we talking about the same thing? Something like http://msdn.microsoft.com/en-us/library/ms236403(v=vs.80).aspx? So it does what auto-generated .di files does, and turns it into an abomination, it relies on an IDE feature? Amazing, so now "programmer" means VisualStudio user? Probably this is why everyone using only C/C++ for serious library development. (Please don't take it personal, this is my usual tone) |
November 28, 2011 Re: boost crowd. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Maxim Fomin | 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 |
Copyright © 1999-2021 by the D Language Foundation