View mode: basic / threaded / horizontal-split · Log in · Help
November 29, 2011
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.
November 29, 2011
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.
November 29, 2011
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 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).
December 01, 2011
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.
December 02, 2011
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.
December 03, 2011
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.
December 03, 2011
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 :-(
December 03, 2011
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.
December 04, 2011
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
Next ›   Last »
3 4 5 6 7
Top | Discussion index | About this forum | D home