This incorporates a new 'header' generator capability, written by Dave Fladebo, now working!

http://www.digitalmars.com/d/changelog.html

Walter Bright wrote:
> This incorporates a new 'header' generator capability, written by Dave Fladebo, now working!
> 

Thanks for the release, but "partly" is missing from before "working" (as usual when it comes to programming <g>). I presume bugs related to the header generator still belong in digitalmars.D.bugs?

I'll post my report here anyway since it's so short. The following crashes DMD completely when compiled with -H, on Windows (XP) at least:

this() {}

In or outside a class, doesn't matter, it still doesn't work.

Deewiant wrote:
> this() {}
> 
> In or outside a class, doesn't matter, it still doesn't work.

I should probably correct myself somewhat: if it's inside a class the header file is correctly generated, but DMD still crashes.

On Fri, 30 Dec 2005 06:11:54 +1100, Walter Bright <newshound@digitalmars.com> wrote:

> This incorporates a new 'header' generator capability, written by Dave
> Fladebo, now working!

Well it might be working, but it doesn't do what I was expecting.

This source file ...

//--------------------------------
import std.stdio;

private int qwerty;
class A
{
    private int x;
    void ths()
    {
      x = 1;
      }
}

void xpub()
{
    A a = new A;
    qwerty = 1;
}

private void xpriv()
{
    A b = new A;
    qwerty = 2;
}
//--------------------------------


was turned into this 'header' ...

// D import file generated from 'test.d'
import std.stdio;
private
{
    int qwerty;
}
class A
{
    private
{
    int x;
}
    void ths()
{
x = 1;
}
}
void xpub()
{
A a = new A;
qwerty = 1;
}
private
{
    void xpriv()
{
A b = new A;
qwerty = 2;
}
}
//-------------------------

but I was expecting something more like this ...

// D import file generated by hand
import std.stdio;
class A
{
    void ths(){}
}
void xpub(){}
//-------------------------


In other words, why does the generated header show implementation code and why does it show private members? Currently, all it seems to do is reformat the original source by placing braces around private sections.
-- 
Derek Parnell
Melbourne, Australia

"Derek Parnell" <derek@psych.ward> wrote in message news:op.s2kab6y06b8z09@ginger.vic.bigpond.net.au...
> In other words, why does the generated header show implementation code and why does it show private members?

It shows implementation code for functions that are candidates for inlining. It shows private members because they might be used in const initializers and in inline functions.

If a function cannot be inlined, its implementation will not be included.

"Deewiant" <deewiant.doesnotlike.spam@gmail.com> wrote in message news:dp1epm$nta$1@digitaldaemon.com...
> Deewiant wrote:
>> this() {}
>>
>> In or outside a class, doesn't matter, it still doesn't work.
>
> I should probably correct myself somewhat: if it's inside a class the
> header
> file is correctly generated, but DMD still crashes.

Thanks, I'll take care of it.

Walter Bright wrote:
> "Derek Parnell" <derek@psych.ward> wrote in message news:op.s2kab6y06b8z09@ginger.vic.bigpond.net.au...
>> In other words, why does the generated header show implementation code and why does it show private members?
> 
> It shows implementation code for functions that are candidates for inlining. It shows private members because they might be used in const initializers and in inline functions.
> 
> If a function cannot be inlined, its implementation will not be included. 
> 
> 

This really doesn't look right.  I realize the need to make private data visible for inlining purposes, but this appears to defeat the main purpose of the interface file -- hiding private members and implementation details.

The need to accommodate inlining seems wrong too.  Don't you think it's better, at this point, to disable inlining for interface files and document it well so nobody is surprised by the absence of it.

Maybe, later on, a better solution can be concocted.

-JJR

On Fri, 30 Dec 2005 07:40:24 +1100, Walter Bright <newshound@digitalmars.com> wrote:

>
> "Derek Parnell" <derek@psych.ward> wrote in message
> news:op.s2kab6y06b8z09@ginger.vic.bigpond.net.au...
>> In other words, why does the generated header show implementation code and
>> why does it show private members?
>
> It shows implementation code for functions that are candidates for inlining.

Thanks for explaining this. I don't like it one bit, though. The DI file can be used instead of the original source when the implementation is in a library right? How does the compiler know if something has been inlined or not in the library object? Just because a specific edition of DMD reckons that a function is a candidate for inlining, it cannot know that some other edition of some other D compiler has actually inlined it. Also I thought that a DI file is not being used to generate object code, but just to get information about how to compile the other (non) DI fi

> It shows private members because they might be used in const initializers
> and in inline functions.

But 'private' means that I don't want other modules knowing about this.

> If a function cannot be inlined, its implementation will not be included.

So we must make functions we want to hide deliberately complex to prevent inlining? This just sounds wrong. Isn't there a way to turn off inlining if I don't want it?

I wanted to use DI files to *HIDE* implementation details. Your definition of DI does not do this.

-- 
Derek Parnell
Melbourne, Australia

On Thu, 29 Dec 2005 15:40:24 -0500, Walter Bright <newshound@digitalmars.com> wrote:

>
> "Derek Parnell" <derek@psych.ward> wrote in message
> news:op.s2kab6y06b8z09@ginger.vic.bigpond.net.au...
>> In other words, why does the generated header show implementation code and
>> why does it show private members?
>
> It shows implementation code for functions that are candidates for inlining.
> It shows private members because they might be used in const initializers
> and in inline functions.
>
> If a function cannot be inlined, its implementation will not be included.
>

Perhaps it should only do this if -inline is present.

Chris Miller wrote:
> On Thu, 29 Dec 2005 15:40:24 -0500, Walter Bright <newshound@digitalmars.com> wrote:
> 
>>
>> "Derek Parnell" <derek@psych.ward> wrote in message
>> news:op.s2kab6y06b8z09@ginger.vic.bigpond.net.au...
>>> In other words, why does the generated header show implementation code and
>>> why does it show private members?
>>
>> It shows implementation code for functions that are candidates for inlining.
>> It shows private members because they might be used in const initializers
>> and in inline functions.
>>
>> If a function cannot be inlined, its implementation will not be included.
>>
> 
> Perhaps it should only do this if -inline is present.

What happens, then, if you use "-inline" on the library and no "-inline" on the project that uses the library?  You get an interface file that's prepared for inline code per the library build (with all the extra private and function implementation details), but a project file that uses an interface file that won't be inlined in the project.  Kind of complicated.  I think it's just better to disable inlining on libraries that generate an interface file and on projects that uses that interface file.

-JJR