In article <dp27tj$19f5$1@digitaldaemon.com>, John Reimer says...
>Okay, now I see why there is so much confusion going on with the addition of this feature.  There are two problems to be solved: one is the issue of implementation hiding; the other is the issue of compiler performance.  I think most of us mistook the di file generator to be a solution for implementation hiding for closed source projects. Obviously we got the wrong idea about the whole thing.
>
>If di files serve the same purpose as "precompiled headers," obviously there is no consideration whatsoever for implementation hiding (and there never was any such intention).
>
>Good to know.  Personally, I was less interested in compile performance and more interested in implementation hiding.  The -H flag, therefore, will not be of much use to me.
>
>-JJR

I have to say as fast as DMD compiles files, I was more interested in seeing headers stripped to the bone than optimally stripped, too (I really don't want that to sound as weird as it does, but I think "stripped aggressively" would be worse). I doubt that I would personally use it for hiding code (my code isn't interesting enough to bother hiding), but it seems like a neat thing to do.

But I was thinking... If the magic happens in the (open source) front-end, it might not be that hard for an enterprising individual to alter the compiler to leave out the optimizations. I found in "mars.c" where the command line option "-H" is detected, and I followed the program flow to "hdrgen.c". But that's as far as I got before I lost interest. Time for sleep anyway. ;)

jcc7

John Reimer wrote:
> Walter Bright wrote:
> 
>> "Derek Parnell" <derek@psych.ward> wrote in message news:zqfcc85x3d7z$.1n4xv1fmu7njt$.dlg@40tude.net...
>>
>>> In other words, let's enhance the language so we can support the needs of
>>> developers who want closed-source development *and* the needs of the
>>> compiler to generate correctly performing code. This would mean we need to
>>> resolve the issue of class member offsets, inlining, and const
>>> declarations. These are not impossible to resolve.
>>
>>
>> There's more than that, there are template bodies. At some point, we have to ask if we've just got the wrong approach to implementation hiding. I suggest that interface classes are the way to get true implementation hiding, not di files. di files' main advantage is improving build speeds for large projects.
>>
>> They work a lot like "precompiled headers" do in C++.
>>
> 
> 
> Okay, now I see why there is so much confusion going on with the addition of this feature.  There are two problems to be solved: one is the issue of implementation hiding; the other is the issue of compiler performance.  I think most of us mistook the di file generator to be a solution for implementation hiding for closed source projects. Obviously we got the wrong idea about the whole thing.
> 
> If di files serve the same purpose as "precompiled headers," obviously there is no consideration whatsoever for implementation hiding (and there never was any such intention).
> 
> Good to know.  Personally, I was less interested in compile performance and more interested in implementation hiding.  The -H flag, therefore, will not be of much use to me.
> 
> -JJR

Right on John. Walter, what is your answer for closed source implementation hiding?

Walter Bright wrote:
> This incorporates a new 'header' generator capability, written by Dave
> Fladebo, now working!
> 
> http://www.digitalmars.com/d/changelog.html
> 
> 


I play OpenTTD all night and in the morning see what happens :)
Seriously. I won't participate in the dispute because I am not 100% sure I fully understand it (I am weak with all these programming terms :), but I wish to support Walter in some way. As much as I understand the new feature helps speeding up the compiler but it isn't hiding all the code wich comes to be a problem for people wanting close source projects. From the posts I almost thought nobody feels the slow compilition a problem and it is the "people vs Walter". I want to say that this was exactly what I needed, because the compilation speed is a big issue to me. Once I started a thread about this. (Now I am shooting in the dark sorry if I am wrong) It seems that many people are using the build tool (which I've never used but I guess it works this way) or even if they are not they pass all the source files to the compiler. In this case the speed is optimal but if you compile each file separately it becomes like 15 times slower (for my project). And I do it because I have more control over the process this way.

So I just wanted to support Walter and say that this is a very useful feature for me. Thank you, Walter (with much help from Dave Fladebo ;).

P.S. I didn't undestand how you control if the compiler is importing .d or .di . I looked in the docs but I didn't find any info on that. I mean if they have the same name?

On Fri, 30 Dec 2005 21:10:52 +1100, bobef <bobef@lessequal.com> wrote:
> P.S. I didn't undestand how you control if the compiler is importing .d or .di . I looked in the docs but I didn't find any info on that. I mean if they have the same name?

If you code "import xyz" the compiler looks first for xyz.d, and if it can't find that it tries to find xyz.di and if that's not found it errors.

-- 
Derek Parnell
Melbourne, Australia

"John Reimer" <terminal.node@gmail.com> wrote in message news:dp29ai$1a9l$1@digitaldaemon.com...
> Zz wrote:
>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dp1s4k$12ev$1@digitaldaemon.com...
>>> "Derek Parnell" <derek@psych.ward> wrote in message news:zqfcc85x3d7z$.1n4xv1fmu7njt$.dlg@40tude.net...
>>>> In other words, let's enhance the language so we can support the needs
>>>> of
>>>> developers who want closed-source development *and* the needs of the
>>>> compiler to generate correctly performing code. This would mean we need
>>>> to
>>>> resolve the issue of class member offsets, inlining, and const
>>>> declarations. These are not impossible to resolve.
>>> There's more than that, there are template bodies. At some point, we have to ask if we've just got the wrong approach to implementation hiding. I suggest that interface classes are the way to get true implementation hiding, not di files. di files' main advantage is improving build speeds for large projects.
>>>
>>> They work a lot like "precompiled headers" do in C++.
>>>
>>
>> I'm not suggesting that the solution below in worth using but it's a good idea to look into.
>>
>> Quite some time ago I used to do some work in Modula2 and the way implementation and interface were divided was very intutive, over time I've got used to other methods and eventually felt comfortable with them.
>>
>> This link gives a short overview http://www.csc.twu.ca/rsbook/Ch6/Ch6.5.html
>>
>> Oberon2 which came later on removed this concept but it was later on re-introduced.
>>
>> for eg in Modula2:
>> DEFINITION MODULE MyRealMath;
>>
>> CONST
>>   root2 = 1.414213562;
>>
>> PROCEDURE log (x : REAL) : REAL;
>>
>> END MyRealMath.and in another file:IMPLEMENTATION MODULE MyRealMath;  (* note same name *)
>>
>> FROM RealMath IMPORT
>>   ln;
>>
>> PROCEDURE log (x : REAL) : REAL;
>> (* returns the base 10 logarithm of x *)
>> BEGIN
>>   RETURN (ln (x)) / (ln (10.0) )
>> END log;
>>
>> END MyRealMath.user file:MODULE Client;
>>
>> FROM MyRealMath IMPORT
>>   root2, log;
>
> I studied some Modula 2 more than 10 years ago, so I don't remember too much.  But I do remember the implementation/definition file separation. Were those given different file endings? I think Modula 3 (which does somewhat the same, I believe) uses i3 for interface and m3 for implementation.  It does look like an effective solution, although I don't know how such a solution would fit into a modern language like D, that has features that none of these early languages ever had.
>

Stony Brook and Topspeed Modula2 used .MOD for Implementation and .DEF for
Definition.
As for fitting within a modern language like D, I wonder why not (at least
it's better than the -H option).

In Stonnt Brook M2 the libs were generated from the DEF and lib and all the user needed was the lib and def to do any thing, the def module did not contain anything (just like D's interface but in a separate file with the option to include other def's).

Here is an example of  ctrl3d.

First the DEF module:

DEFINITION MODULE CTL3D;

(* Notice that you can include other Modules here*)
FROM WIN32 IMPORT
    HWND;

(* functions to interface with the CTL3D32.DLL for Windows NT *)
(* most function do nothing on WIN95, actually any Windows version 4.x *)

PROCEDURE Ctl3dLoaded() : BOOLEAN;
(* returns TRUE if CTL3D32 is loaded and initialized *)
(* CTL3D32 will not be loaded if system supports DS_3DLOOK dialogs *)

PROCEDURE MakeAllDialogs3d;
(* if Ctl3dLoaded() = TRUE, then forces all dialogs to 3D *)

END CTL3D.

and now the MOD (implementation) module.
Here I pasted more just to give you more detail on what is going on.

IMPLEMENTATION MODULE CTL3D;
<*/NOWARN:F/INLINE:N*>

FROM SYSTEM IMPORT
    ADDRESS;

FROM WIN32 IMPORT
    HWND, DWORD, BOOL, HINSTANCE, FARPROC,
    LoadLibrary, FreeLibrary, GetProcAddress,
    OSVERSIONINFO, GetVersionEx;

FROM WINUSER IMPORT
    GetWindowLong, GWL_STYLE, DS_3DLOOK;

FROM WINX IMPORT
    Instance, NULL_HINSTANCE;

VAR
    Have3dDll  : BOOLEAN;
    Dll   : HINSTANCE;

    C3DRegister  : PROCEDURE(HINSTANCE) : BOOL [WIN32SYSTEM];
    C3DUnregister : PROCEDURE(HINSTANCE) : BOOL [WIN32SYSTEM];
    C3DAutoSubclass : PROCEDURE(HINSTANCE) : BOOL [WIN32SYSTEM];
    C3DSubclassDlgEx : PROCEDURE(HWND, DWORD) : BOOL [WIN32SYSTEM];
    C3DColorChange : PROCEDURE() : BOOL [WIN32SYSTEM];

PROCEDURE Load3dDll;
BEGIN
    Dll := LoadLibrary("CTL3D32");
PROCEDURE MakeAllDialogs3d;
BEGIN
    IF Have3dDll THEN
 C3DAutoSubclass(Instance);
    END;
END MakeAllDialogs3d;

BEGIN
    Have3dDll := FALSE;
    IF NOT Builtin3d() THEN
 Load3dDll;
    END;

FINALLY
    IF Have3dDll THEN
 C3DUnregister(Instance);
 FreeLibrary(Dll);
    END;
END CTL3D.

Regards
Zz

In article <dp35ru$1vle$1@digitaldaemon.com>, Zz says...
>
>
>"John Reimer" <terminal.node@gmail.com> wrote in message news:dp29ai$1a9l$1@digitaldaemon.com...
>> Zz wrote:
>>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dp1s4k$12ev$1@digitaldaemon.com...
>>>> "Derek Parnell" <derek@psych.ward> wrote in message news:zqfcc85x3d7z$.1n4xv1fmu7njt$.dlg@40tude.net...
>>>>> In other words, let's enhance the language so we can support the needs
>>>>> of
>>>>> developers who want closed-source development *and* the needs of the
>>>>> compiler to generate correctly performing code. This would mean we need
>>>>> to
>>>>> resolve the issue of class member offsets, inlining, and const
>>>>> declarations. These are not impossible to resolve.
>>>> There's more than that, there are template bodies. At some point, we have to ask if we've just got the wrong approach to implementation hiding. I suggest that interface classes are the way to get true implementation hiding, not di files. di files' main advantage is improving build speeds for large projects.
>>>>
>>>> They work a lot like "precompiled headers" do in C++.
>>>>
>>>
>>> I'm not suggesting that the solution below in worth using but it's a good idea to look into.
>>>
>>> Quite some time ago I used to do some work in Modula2 and the way implementation and interface were divided was very intutive, over time I've got used to other methods and eventually felt comfortable with them.
>>>
>>> This link gives a short overview http://www.csc.twu.ca/rsbook/Ch6/Ch6.5.html
>>>
>>> Oberon2 which came later on removed this concept but it was later on re-introduced.
>>>
>>> for eg in Modula2:
>>> DEFINITION MODULE MyRealMath;
>>>
>>> CONST
>>>   root2 = 1.414213562;
>>>
>>> PROCEDURE log (x : REAL) : REAL;
>>>
>>> END MyRealMath.and in another file:IMPLEMENTATION MODULE MyRealMath;  (* note same name *)
>>>
>>> FROM RealMath IMPORT
>>>   ln;
>>>
>>> PROCEDURE log (x : REAL) : REAL;
>>> (* returns the base 10 logarithm of x *)
>>> BEGIN
>>>   RETURN (ln (x)) / (ln (10.0) )
>>> END log;
>>>
>>> END MyRealMath.user file:MODULE Client;
>>>
>>> FROM MyRealMath IMPORT
>>>   root2, log;
>>
>> I studied some Modula 2 more than 10 years ago, so I don't remember too much.  But I do remember the implementation/definition file separation. Were those given different file endings? I think Modula 3 (which does somewhat the same, I believe) uses i3 for interface and m3 for implementation.  It does look like an effective solution, although I don't know how such a solution would fit into a modern language like D, that has features that none of these early languages ever had.
>>
>
>Stony Brook and Topspeed Modula2 used .MOD for Implementation and .DEF for
>Definition.
>As for fitting within a modern language like D, I wonder why not (at least
>it's better than the -H option).
>
>In Stonnt Brook M2 the libs were generated from the DEF and lib and all the user needed was the lib and def to do any thing, the def module did not contain anything (just like D's interface but in a separate file with the option to include other def's).
>
>Here is an example of  ctrl3d.
>
>First the DEF module:
>
>DEFINITION MODULE CTL3D;
>
>(* Notice that you can include other Modules here*)
>FROM WIN32 IMPORT
>    HWND;
>
>(* functions to interface with the CTL3D32.DLL for Windows NT *)
>(* most function do nothing on WIN95, actually any Windows version 4.x *)
>
>PROCEDURE Ctl3dLoaded() : BOOLEAN;
>(* returns TRUE if CTL3D32 is loaded and initialized *)
>(* CTL3D32 will not be loaded if system supports DS_3DLOOK dialogs *)
>
>PROCEDURE MakeAllDialogs3d;
>(* if Ctl3dLoaded() = TRUE, then forces all dialogs to 3D *)
>
>END CTL3D.
>
>and now the MOD (implementation) module.
>Here I pasted more just to give you more detail on what is going on.
>
>IMPLEMENTATION MODULE CTL3D;
><*/NOWARN:F/INLINE:N*>
>
>FROM SYSTEM IMPORT
>    ADDRESS;
>
>FROM WIN32 IMPORT
>    HWND, DWORD, BOOL, HINSTANCE, FARPROC,
>    LoadLibrary, FreeLibrary, GetProcAddress,
>    OSVERSIONINFO, GetVersionEx;
>
>FROM WINUSER IMPORT
>    GetWindowLong, GWL_STYLE, DS_3DLOOK;
>
>FROM WINX IMPORT
>    Instance, NULL_HINSTANCE;
>
>VAR
>    Have3dDll  : BOOLEAN;
>    Dll   : HINSTANCE;
>
>    C3DRegister  : PROCEDURE(HINSTANCE) : BOOL [WIN32SYSTEM];
>    C3DUnregister : PROCEDURE(HINSTANCE) : BOOL [WIN32SYSTEM];
>    C3DAutoSubclass : PROCEDURE(HINSTANCE) : BOOL [WIN32SYSTEM];
>    C3DSubclassDlgEx : PROCEDURE(HWND, DWORD) : BOOL [WIN32SYSTEM];
>    C3DColorChange : PROCEDURE() : BOOL [WIN32SYSTEM];
>
>PROCEDURE Load3dDll;
>BEGIN
>    Dll := LoadLibrary("CTL3D32");
>PROCEDURE MakeAllDialogs3d;
>BEGIN
>    IF Have3dDll THEN
> C3DAutoSubclass(Instance);
>    END;
>END MakeAllDialogs3d;
>
>BEGIN
>    Have3dDll := FALSE;
>    IF NOT Builtin3d() THEN
> Load3dDll;
>    END;
>
>FINALLY
>    IF Have3dDll THEN
> C3DUnregister(Instance);
> FreeLibrary(Dll);
>    END;
>END CTL3D.
>
>Regards
>Zz
>
>


i am his opinion. boy, would it be nice getting someting like the modula definition file system.

rko

In article <dp35ru$1vle$1@digitaldaemon.com>, Zz says...
>
>
>"John Reimer" <terminal.node@gmail.com> wrote in message news:dp29ai$1a9l$1@digitaldaemon.com...
>> Zz wrote:
>>> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dp1s4k$12ev$1@digitaldaemon.com...
>>>> "Derek Parnell" <derek@psych.ward> wrote in message news:zqfcc85x3d7z$.1n4xv1fmu7njt$.dlg@40tude.net...
>>>>> In other words, let's enhance the language so we can support the needs
>>>>> of
>>>>> developers who want closed-source development *and* the needs of the
>>>>> compiler to generate correctly performing code. This would mean we need
>>>>> to
>>>>> resolve the issue of class member offsets, inlining, and const
>>>>> declarations. These are not impossible to resolve.
>>>> There's more than that, there are template bodies. At some point, we have to ask if we've just got the wrong approach to implementation hiding. I suggest that interface classes are the way to get true implementation hiding, not di files. di files' main advantage is improving build speeds for large projects.
>>>>
>>>> They work a lot like "precompiled headers" do in C++.
>>>>
>>>
>>> I'm not suggesting that the solution below in worth using but it's a good idea to look into.
>>>
>>> Quite some time ago I used to do some work in Modula2 and the way implementation and interface were divided was very intutive, over time I've got used to other methods and eventually felt comfortable with them.
>>>
>>> This link gives a short overview http://www.csc.twu.ca/rsbook/Ch6/Ch6.5.html
>>>
>>> Oberon2 which came later on removed this concept but it was later on re-introduced.
>>>
>>> for eg in Modula2:
>>> DEFINITION MODULE MyRealMath;
>>>
>>> CONST
>>>   root2 = 1.414213562;
>>>
>>> PROCEDURE log (x : REAL) : REAL;
>>>
>>> END MyRealMath.and in another file:IMPLEMENTATION MODULE MyRealMath;  (* note same name *)
>>>
>>> FROM RealMath IMPORT
>>>   ln;
>>>
>>> PROCEDURE log (x : REAL) : REAL;
>>> (* returns the base 10 logarithm of x *)
>>> BEGIN
>>>   RETURN (ln (x)) / (ln (10.0) )
>>> END log;
>>>
>>> END MyRealMath.user file:MODULE Client;
>>>
>>> FROM MyRealMath IMPORT
>>>   root2, log;
>>
>> I studied some Modula 2 more than 10 years ago, so I don't remember too much.  But I do remember the implementation/definition file separation. Were those given different file endings? I think Modula 3 (which does somewhat the same, I believe) uses i3 for interface and m3 for implementation.  It does look like an effective solution, although I don't know how such a solution would fit into a modern language like D, that has features that none of these early languages ever had.
>>
>
>Stony Brook and Topspeed Modula2 used .MOD for Implementation and .DEF for
>Definition.
>As for fitting within a modern language like D, I wonder why not (at least
>it's better than the -H option).
>
>In Stonnt Brook M2 the libs were generated from the DEF and lib and all the user needed was the lib and def to do any thing, the def module did not contain anything (just like D's interface but in a separate file with the option to include other def's).
>
>Here is an example of  ctrl3d.
>
>First the DEF module:
>
>DEFINITION MODULE CTL3D;
>
>(* Notice that you can include other Modules here*)
>FROM WIN32 IMPORT
>    HWND;
>
>(* functions to interface with the CTL3D32.DLL for Windows NT *)
>(* most function do nothing on WIN95, actually any Windows version 4.x *)
>
>PROCEDURE Ctl3dLoaded() : BOOLEAN;
>(* returns TRUE if CTL3D32 is loaded and initialized *)
>(* CTL3D32 will not be loaded if system supports DS_3DLOOK dialogs *)
>
>PROCEDURE MakeAllDialogs3d;
>(* if Ctl3dLoaded() = TRUE, then forces all dialogs to 3D *)
>
>END CTL3D.
>
>and now the MOD (implementation) module.
>Here I pasted more just to give you more detail on what is going on.
>
>IMPLEMENTATION MODULE CTL3D;
><*/NOWARN:F/INLINE:N*>
>
>FROM SYSTEM IMPORT
>    ADDRESS;
>
>FROM WIN32 IMPORT
>    HWND, DWORD, BOOL, HINSTANCE, FARPROC,
>    LoadLibrary, FreeLibrary, GetProcAddress,
>    OSVERSIONINFO, GetVersionEx;
>
>FROM WINUSER IMPORT
>    GetWindowLong, GWL_STYLE, DS_3DLOOK;
>
>FROM WINX IMPORT
>    Instance, NULL_HINSTANCE;
>
>VAR
>    Have3dDll  : BOOLEAN;
>    Dll   : HINSTANCE;
>
>    C3DRegister  : PROCEDURE(HINSTANCE) : BOOL [WIN32SYSTEM];
>    C3DUnregister : PROCEDURE(HINSTANCE) : BOOL [WIN32SYSTEM];
>    C3DAutoSubclass : PROCEDURE(HINSTANCE) : BOOL [WIN32SYSTEM];
>    C3DSubclassDlgEx : PROCEDURE(HWND, DWORD) : BOOL [WIN32SYSTEM];
>    C3DColorChange : PROCEDURE() : BOOL [WIN32SYSTEM];
>
>PROCEDURE Load3dDll;
>BEGIN
>    Dll := LoadLibrary("CTL3D32");
>PROCEDURE MakeAllDialogs3d;
>BEGIN
>    IF Have3dDll THEN
> C3DAutoSubclass(Instance);
>    END;
>END MakeAllDialogs3d;
>
>BEGIN
>    Have3dDll := FALSE;
>    IF NOT Builtin3d() THEN
> Load3dDll;
>    END;
>
>FINALLY
>    IF Have3dDll THEN
> C3DUnregister(Instance);
> FreeLibrary(Dll);
>    END;
>END CTL3D.
>
>Regards
>Zz
>
>


here is a def file for a class (i took out some of the stuff):

DEFINITION MODULE database;
FROM SQL IMPORT *;
IMPORT EXCEPTIONS;

TYPE
SQL_ENV;
CONST
XALLOCERROR         = -2001;

CLASS DATABASE;
REVEAL StrBaseToCard64, .... , Commit;

TYPE
NumberType = (Annex, Filter);

VAR
myConnection: SQL_ENV;
dbUsed      : DBTYPE;
ExSource    : EXCEPTIONS.ExceptionSource;

PROCEDURE MakeGenericNewNumber(tableName: ARRAY OF CHAR) : CARDINAL64;
....
PROCEDURE Commit() : INTEGER32;
END DATABASE;
END database.

bobef wrote:
> Walter Bright wrote:
> 
>> This incorporates a new 'header' generator capability, written by Dave
>> Fladebo, now working!
>>
>> http://www.digitalmars.com/d/changelog.html
>>
>>
> 
> 
> I play OpenTTD all night and in the morning see what happens :)

Wow! It is one of the *best* games I ever played. It is great to see there are more fans.

>
> i am his opinion. boy, would it be nice getting someting like the modula definition file system.
>
> rko
>
>
Good to see another person with M2 background.

It would be a good feature to have but I don't believe it will ever be
available in D.
Whenever someone hears of a language that Wirth designed they assume that we
are talking about Pascal and don't look any furher.

Stonny Brook M2 used this system to do their cross platform stuff and in use it worked perfectly, and I don't ever recall having a problem with it.

On the other hand D is a new language which and I really do enjoy doing small quick and dirty things with it (I would never dream of doing a large project with it witout some form of separation, maybe it's just me but I can't see it happening).

Note: I have some stuff done in D running in a commercial production enviroment, but they were small programs.

Regards,
Zz

John Reimer escribió:
> 
> Okay, now I see why there is so much confusion going on with the addition of this feature.  There are two problems to be solved: one is the issue of implementation hiding; the other is the issue of compiler performance.  I think most of us mistook the di file generator to be a solution for implementation hiding for closed source projects. Obviously we got the wrong idea about the whole thing.
> 
> If di files serve the same purpose as "precompiled headers," obviously there is no consideration whatsoever for implementation hiding (and there never was any such intention).
> 
> Good to know.  Personally, I was less interested in compile performance and more interested in implementation hiding.  The -H flag, therefore, will not be of much use to me.
> 
> -JJR

Same here. I mean, I also agree with all of you guys that -H should do something different.

BTW, IIRC, digc did something like that. Does anybody know if it still compiles? Did it really do that?

-- 
Carlos Santander Bernal