View mode: basic / threaded / horizontal-split · Log in · Help
November 03, 2006
Re: DMD 0.173 release [Name mangling]
Walter Bright wrote:
> Don Clugston wrote:
>> "Template instantiations can now accept alias parameters for local 
>> variables and nested functions."
>>
>> which is of great interest to me, since now meta.prettynameof!() can 
>> work with local variables; this will be significant for DDL and 
>> probably things like PyD as well.
>> But, the name mangling is really weird. It's totally different to the 
>> name mangling for static variables, for example.
> 
> What happens is when one of the parameters is an alias to a local, the 
> template becomes a *nested* class/function, and is mangled like one.

OK, that makes sense -- that should prevent the alias from 'leaking out' 
from the function. Might take me a while to get my head around all the 
consequences, though <g>. Opens up lots of possibilities.
November 04, 2006
Re: DMD 0.173 release [Name mangling]
Walter Bright wrote:
> Don Clugston wrote:
>> "Template instantiations can now accept alias parameters for local 
>> variables and nested functions."
>>
>> which is of great interest to me, since now meta.prettynameof!() can 
>> work with local variables; this will be significant for DDL and 
>> probably things like PyD as well.
>> But, the name mangling is really weird. It's totally different to the 
>> name mangling for static variables, for example.
> 
> What happens is when one of the parameters is an alias to a local, the 
> template becomes a *nested* class/function, and is mangled like one.

I think I've found a bug in a corner case:

template t (alias A) {...}

void g() {
  void f() {
//    t!(f);   // CASE 1 --->  template t is nested in both g and f.
 }
   t!(f);    // CASE 2 ---> template t is nested in g but not f.
}

If case 1 appears anywhere (even in a pragma(msg)), it changes the name 
mangling of case 2.
I think case 1 is wrong: an inner function is not inside itself.
November 05, 2006
Re: DMD 0.173 release
Walter Bright wrote:
> Major new stuff! But please, let's discuss that over in the 
> digitalmars.D group.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.173.zip

The file phobos/std_outofmemory.html is still missing from the dmd package.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
November 05, 2006
Re: DMD 0.173 release
Walter Bright wrote:
> Major new stuff!

Belated congrats!!

At this rate we're well past 2.0 at end of year! :-)

And for anybody contemplating a book on D, don't include the last 
chapter! Reason is, the back cover of the book runs away from you at 
precisely the speed you're writing the next-to-last chapter!  :-)
November 05, 2006
Re: DMD 0.173 release
Ok, so this one is about a feature of some releases ago, but you're 
releasing new features faster than what we can keep up and look at :P

Regarding array literals, it concerns me that each new literal 
"evaluation" will create a new instance. For example a literal inside a 
function will allocate a new instance every time the function is called. 
Likewise a literal inside a loop will allocate a new instance for every 
cycle of the loop!
This strikes me as both inefficient (as there is no simple way to use 
the opposite behavior: static/global instances) and inconsistent: other 
kinds of literals, like string literals, are not instanced per 
"evaluation" but instead are single/global/static instances.
Is there any particular reason for this behavior? Because if not I'm 
inclined to think it would be better that array literals work as string 
literals (global/static instances). If the new'ed-instance behavior is 
needed it could be easily emulated with dup'ing:
  ar = [1, 4, 9].dup;

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
November 05, 2006
Re: DMD 0.173 release
Bruno Medeiros wrote:
> Ok, so this one is about a feature of some releases ago, but you're 
> releasing new features faster than what we can keep up and look at :P

Aint that the truth. :)

> 
> Regarding array literals, it concerns me that each new literal 
> "evaluation" will create a new instance. For example a literal inside a 
> function will allocate a new instance every time the function is called. 
> Likewise a literal inside a loop will allocate a new instance for every 
> cycle of the loop!
> This strikes me as both inefficient (as there is no simple way to use 
> the opposite behavior: static/global instances) and inconsistent: other 
> kinds of literals, like string literals, are not instanced per 
> "evaluation" but instead are single/global/static instances.
> Is there any particular reason for this behavior? Because if not I'm 
> inclined to think it would be better that array literals work as string 
> literals (global/static instances). If the new'ed-instance behavior is 
> needed it could be easily emulated with dup'ing:
>   ar = [1, 4, 9].dup;
> 

I'm afraid that things have to be that way. It would make sense for 
array literals to be allocated only once if they were made of only 
constant values, but in cases like:

for(int i=0; i<100; i++)
{
   f( [i, i*i] );
}

I would expect a new instance to be created at each step in the loop.
November 05, 2006
Re: DMD 0.173 release
Bruno Medeiros wrote:
> Ok, so this one is about a feature of some releases ago, but you're 
> releasing new features faster than what we can keep up and look at :P
> 
> Regarding array literals, it concerns me that each new literal 
> "evaluation" will create a new instance. For example a literal inside a 
> function will allocate a new instance every time the function is called. 
> Likewise a literal inside a loop will allocate a new instance for every 
> cycle of the loop!
> This strikes me as both inefficient (as there is no simple way to use 
> the opposite behavior: static/global instances) and inconsistent: other 
> kinds of literals, like string literals, are not instanced per 
> "evaluation" but instead are single/global/static instances.
> Is there any particular reason for this behavior? Because if not I'm 
> inclined to think it would be better that array literals work as string 
> literals (global/static instances). If the new'ed-instance behavior is 
> needed it could be easily emulated with dup'ing:
>   ar = [1, 4, 9].dup;
> 

Agreed.  It also makes life interesting in that things that depend of an 
array having compile-time constant value fail:

  const bool[3] a = [true,false,true];
  static if(a[0]) {}

(and fail with the misleading error message "expression (a)[0] does not 
evaluate to a boolean").

This is ok though:
  static if([true,false,true][0]) {}

Another thing that should work is:

   static const int[3] a = [4,5,6];
   static const int[a[0]] b = [1,2,3,4];

test.d(17): a is used as a type
test.d(17): can't have associative array key of void[0]

Ok, that's maybe a different issue... but I bet if it weren't trying to 
interpret the above as an associative array it would be complaining that 
the value a[0] isn't constant.  :-)

Ah, here's a better example:

  static const int[2] sizes = [2,4];
  static const int[2] use_sizes = [sizes[0], sizes[1]];

>> staticdata.d(19): non-constant expression (sizes)[0]
>> staticdata.d(19): non-constant expression (sizes)[1]

--bb
November 05, 2006
Re: DMD 0.173 release
Ivan Senji wrote:
> Bruno Medeiros wrote:
> 
>> Ok, so this one is about a feature of some releases ago, but you're 
>> releasing new features faster than what we can keep up and look at :P
> 
> 
> Aint that the truth. :)
> 
>>
>> Regarding array literals, it concerns me that each new literal 
>> "evaluation" will create a new instance. For example a literal inside 
>> a function will allocate a new instance every time the function is 
>> called. Likewise a literal inside a loop will allocate a new instance 
>> for every cycle of the loop!
>> This strikes me as both inefficient (as there is no simple way to use 
>> the opposite behavior: static/global instances) and inconsistent: 
>> other kinds of literals, like string literals, are not instanced per 
>> "evaluation" but instead are single/global/static instances.
>> Is there any particular reason for this behavior? Because if not I'm 
>> inclined to think it would be better that array literals work as 
>> string literals (global/static instances). If the new'ed-instance 
>> behavior is needed it could be easily emulated with dup'ing:
>>   ar = [1, 4, 9].dup;
>>
> 
> I'm afraid that things have to be that way. It would make sense for 
> array literals to be allocated only once if they were made of only 
> constant values, but in cases like:
> 
> for(int i=0; i<100; i++)
> {
>    f( [i, i*i] );
> }
> 
> I would expect a new instance to be created at each step in the loop.
> 

It doesn't even need to be dynamic values.  Given

for(int i=0; i<100; i++)
{
   f( [1, 42] );
}

You might have f modifying the array since D doesn't have good support 
for const:

void f(int[2] v) {
      v[0]++;
}

And then f([1,42]) after the first call becomes equivalent to f([2,42]) 
which would be bad.

--bb
November 06, 2006
Re: DMD 0.173 release
Walter Bright wrote:
> Major new stuff! But please, let's discuss that over in the 
> digitalmars.D group.
> 
> http://www.digitalmars.com/d/changelog.html
> 
> http://ftp.digitalmars.com/dmd.173.zip

The relaxed rules for template alias parameters aren't documented in the 
spec. The example under 'global names' compiles now <g>.
November 06, 2006
Re: DMD 0.173 release
Bruno Medeiros wrote:
> The file phobos/std_outofmemory.html is still missing from the dmd package.

I'll fix.
1 2 3 4
Top | Discussion index | About this forum | D home