"Walter Bright" <newshound@digitalmars.com> wrote
[snip]
>> unfortunately, this is what I get when using the -H option:
>> dmd.exe has encountered a problem and needs to close. We are sorry for
>> the inconvenience.
>
> I'd like an example of that, so I can fix it.

Uh, the very example was included right above your comment?


>> GPF's aside, I imagine that -H would expose the content of both the createSearchEngine() factory method, and whatever else is in there (such as the static ctor). This means that the all relevant proprietary import modules will also need to be shipped with this module :-)
>
> No, it won't if the function is too complex to be inlined, which is the usual case.

I see. But, surely that makes it non-deterministic in a variety of manners? Thus, one could not always depend on such a header being generated correctly?

"Kris" <fu@bar.com> wrote in message news:dp27jl$19bc$1@digitaldaemon.com...
> "Walter Bright" <newshound@digitalmars.com> wrote
> [snip]
>>> unfortunately, this is what I get when using the -H option:
>>> dmd.exe has encountered a problem and needs to close. We are sorry for
>>> the inconvenience.
>>
>> I'd like an example of that, so I can fix it.
>
> Uh, the very example was included right above your comment?

Ok. I didn't realize that. Thanks!

>>> GPF's aside, I imagine that -H would expose the content of both the createSearchEngine() factory method, and whatever else is in there (such as the static ctor). This means that the all relevant proprietary import modules will also need to be shipped with this module :-)
>>
>> No, it won't if the function is too complex to be inlined, which is the usual case.
> I see. But, surely that makes it non-deterministic in a variety of manners? Thus, one could not always depend on such a header being generated correctly?

The code and header are still correct whether it is inlined or not.

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

Walter Bright wrote:
> "Kris" <fu@bar.com> wrote in message news:dp1tf9$13ds$1@digitaldaemon.com...
>> While I always applaud your progress with the language and the compiler, don't you think this stands alone as blatant feature-creep? With respect, I think we'd all be better off without -H until an actual need for it arises ~ at that point we might even have some /useful/ requirements for it, since implementation hiding (what we all requested) is apparently not what it's intended for :-)
> 
> Since Dave had already implemented it, and it would be needed eventually anyway, there was good reason to put it in. Furthermore, most of the work involved improving the pretty-printing capability of the compiler, much of which was stubbed out or kludged and needed to be done properly anyway. The pretty-printing capability is used for things like formatting of error messages and the doc generator.
> 
> (For example, now expressions get properly parenthesized when printed, and numerous problems printing numeric and string literals were fixed.)
> 
> These fixes weren't necessary for DMD to compile programs successfully, but they do contribute to it looking like a polished, presentable product. 
> 
> 

That's definitely a plus.  If these are the only benefits of the addition, I can appreciate them.

-JJR

"Walter Bright" <newshound@digitalmars.com> wrote
> "Kris" <fu@bar.com> wrote
>> Can you perhaps illustrate with a working example, please? I think that would help a lot :)
>
> .di files aren't necessarilly going to help you here. But in another post in this thread, I gave an example of FooFactory() that is the usual way of generating an instance of an interface.


As did I, which showed two things:

a) -H is of little realistic value (if any) for exposing factories used for purposes of code hiding. In fact, it just gets in the way and should not be used for said purpose.

b) -H currently fails if you try to do the above (example in the prior post).

I think there's been a total miscommunication here. Seems like most everyone was expecting some form of code-hiding per the long-standing requests for closed-source support (certainly I was thoroughly misguided). Instead, what -H does is some form of source-munging that makes it questionably faster for the compiler to parse?

I recall something from a long time back noting that just such a facility would be implemented via a binary format? As such, it would very likely be much faster than the current -H approach (which requires full lexing and parsing of the exposed source).

Without wishing to offend anyone, it seems like what's been implemented will be unlikely to make a /blind bit of difference/ to compile times (in contrast to that binary-format version you had mentioned so long ago). Yes, it's great that you took an opportunity to clean up a bunch of output-formatting issues, but  ....  this new 'feature' appears to exist simply and only because it can? I guess one could split hairs over that, all day.

What this feature /does/ do is give the user yet another darned file-type to bother about, and provides a non-deterministic means to reformat ones source-code. That just doesn't seem like such a great idea, somehow. Oh well.

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.

-JJR

On Thu, 29 Dec 2005 18:13:03 -0800, Walter Bright wrote:

> I'd like an example of that, so I can fix it.

  module cf;
  interface iFoo{}
  class Foo: iFoo{}

C:\> dmd -c -H cf.d

... ABEND ...

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"A learning experience is one of those things that says,
 'You know that thing you just did? Don't do that.'" - D.N. Adams
30/12/2005 3:36:47 PM

On Thu, 29 Dec 2005 18:13:03 -0800, Walter Bright wrote:


> I'd like an example of that, so I can fix it.
Here are two more examples that cause DMD to crash ...

 module cf;
 class Foo
 {
     this(){}
 }


-----------------

  module cf;
  static this()
  {
  }


-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"A learning experience is one of those things that says,
 'You know that thing you just did? Don't do that.'" - D.N. Adams
30/12/2005 3:40:41 PM

Thanks for the examples. I'll take care of it.

Thanks Walter this import file is a nice feature. :D

And I agree - the pretty printing is usefull to have in the front end. I noticed while playing around in the front end that you have stubbed out the posibility of using 'precompiled symbol files' as imports - do you still have plans for this and do you expect it to be in version 1?