View mode: basic / threaded / horizontal-split · Log in · Help
November 28, 2011
Re: boost crowd.
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?
>>
>> 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.
November 28, 2011
Re: boost crowd.
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?
November 28, 2011
Re: boost crowd.
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?
November 28, 2011
Re: boost crowd.
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.
November 28, 2011
Re: boost crowd.
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?
>>>
>>> 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.
November 28, 2011
Re: boost crowd.
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 
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.
November 28, 2011
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.
November 28, 2011
Re: boost crowd.
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  
> developed in C# for obvious reasons, and compilation models are  
> irrelevant to the fact.

They are mostly libraries so it is more than relevant.
November 28, 2011
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.
November 28, 2011
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.
1 2 3 4 5 6 7
Top | Discussion index | About this forum | D home