Don Clugston wrote:
> Now that's truly spectacular.
> Metaprogramming is dead. Long live metaprogramming!
> How on Mars did you do it that fast?

I realized I could leverage the existing constant folding code. Sometimes the obvious isn't so obvious <g>.

I predict that it won't be long before other compiled languages will seem antiquated if they don't have such capability.

Walter Bright wrote:
> I predict that it won't be long before other compiled languages will seem antiquated if they don't have such capability.

Mmmm, the smell of world domination in the morning.

Brad Anderson wrote:
> Walter Bright wrote:
>> I predict that it won't be long before other compiled languages will
>> seem antiquated if they don't have such capability.
> 
> Mmmm, the smell of world domination in the morning.

Good thing I brought my surfboard.

Brad Anderson wrote:
> Walter Bright wrote:
>> I predict that it won't be long before other compiled languages will
>> seem antiquated if they don't have such capability.
> 
> Mmmm, the smell of world domination in the morning.

How times have changed. When I started paying attention to D (Aug 2005), the website and spec had a defensive feel ("not as powerful as C++, but much  simpler"). And there was a link to the very first D announcement, which had a list of "Features to drop from C++", which included "templates".

Henning Hasemann wrote:
>> This seems a sensible change. Version.Major.Minor is very common and very intuitive. Version for code incompatible changes, Major for new additions to the spec, minor for bug fixes. You can keep your current numbering scheme for minor ticks. Thus 1.0.001, 1.0.002, etc. As Miles suggests, you could even retroactively bump the new "major" version to reflect the new features (mixins and compile time functions).
> 
> votes++

same here

Don Clugston wrote:
> Brad Anderson wrote:
>> Walter Bright wrote:
>>> I predict that it won't be long before other compiled languages will
>>> seem antiquated if they don't have such capability.
>>
>> Mmmm, the smell of world domination in the morning.
> 
> How times have changed. When I started paying attention to D (Aug 2005), the website and spec had a defensive feel ("not as powerful as C++, but much  simpler"). And there was a link to the very first D announcement, which had a list of "Features to drop from C++", which included "templates".

Yes, it is pretty amazing how powerful D was at 1.0 compared to Walter's earlier ideas.

From 2001/08/14:
"I know that templates likely will be a big issue. I intend to address it in version 2 of the language. The way C++ does it is simply too complicated for me, I am trying to find a simpler way, so much more thought needs to be expended there."
(http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=D&artnum=15)

-- 
jcc7

* Codeview for classes now gives correct LF_CLASS

i'd say that this issue is only partially solved in 1.006.
type strings for classes now get the correct LF_CLASS, but symbols of
those types are still marked as pointers to structs. hence they cannot
have the LF_CLASS leafs associated with them, but use the (obsolete?)
struct leafs (marked as forward refs) that exist for each class leaf.

example:

module mymodule;
class class1 { ... }
// ...
class1 myclass = new class1;
// ...

will generate two CV type strings:

class 0x1004 'mymodule.class1' field list: 0x1001 properties: 0x0 struct 0x100b 'class1' field list: 0x0 properties: 0x80

the symbol "myclass" will be marked as a pointer to struct 0x100b. besides the (probably obsolete) indirection, i think there is no clean way to tell that 0x100b and pointer-to-0x1004 describe the same type.

Walter Bright wrote:
> Compile time function execution! (Please discuss in the corresponding
> thread in digitalmars.D)
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.1.006.zip

>>
>> votes++
>
> same here

bump

Saaa wrote:
>>> votes++
>> same here
> 
> bump 
> 
> 
ditto :)

kris wrote:
> Sean Kelly wrote:
> 
>> Walter Bright wrote:
>>
>>> kris wrote:
>>>
>>>> This release increases the resultant executable size of a trivial HelloWorld program, by around 12KB. What happened?
>>>
>>>
>>>
>>> I don't know. Which platform?
>>
>>
>>
>> Win32.  We're still investigating, but building the same code with DMD 1.0 gives us a HelloWorld EXE of 90,652 bytes.  With 1.005 the same code gives us a HelloWorld EXE of 113,180 bytes.  I have yet to try 1.006 but reports indicate that the size is roughly the same as 1.005.  I think no one simply noticed this until 1.006 experimentation began today.  If I had to hazard a guess, I'd say most of the size change is probably a result of the TypeInfo changes post-1.0, but it will take a while to dig through object files to sort all this out.
>>
>>
>> Sean
> 
> 
> with 1006, the result is 114,716. That's 26% larger than 1.0 ?

With 1007, this dropped by a half-kb to 114,204. Possibly due to a little code motion.

Now that typeinfo et al are isolated in separate segments, how do we get the linker to drop all the unused ones?

I ask, since the example used for tracking down the lib issues has the following characteristics:

code ~120kb
data ~60kb

Looking at what's represented by data, a rough guess is that an elimination of unused data would reduce it by perhaps as much as 75%