Re: Unable to instantiate template with same name as function
@AliCehreli: you may consider including Jonathan's trick in your book in the
para above this heading:
http://ddili.org/ders/d.en/const_and_immutable.html#ix_const_and_immutable.variable,
%20immutable
Jonathan M Davis via Digitalmars-d-learn wrote:
> yes, having
>
> enum s = ta("s)";
>
> and using s all over the place will result in an allocation each time that
> s is used. However, you can combine the two and avoid that problem. e.g.
>
> enum e = ta("s");
> string s = e;
>
> The ta is run at compile time, and it's only evaluated once.
--
Shriramana Sharma, Penguin #395953
Re: Unable to instantiate template with same name as function
ag0aep6g wrote:
> On 03.03.2016 07:12, Shriramana Sharma wrote:
>> string ta(string s) { return s ~ "1"; }
>> template ta(string s) { enum ta = ta(s); }
>
> In `ta(s)` here, `ta` is the enum itself again. It's similar to `int x =
> x;`. Can't do that, of course.
>
> Add a leading dot to refer to the module level `ta` symbols instead:
> `enum ta = .ta(s);`.
Wonderful! So it's just a scope issue and not a "can't do that" issue!
Although it would seem that the compiler 'should' be able to identify a
different kind of ta, I can't expect too much of it and the D compiler is
much more powerful syntax-wise than other language compilers.
I confirm that the following outputs "s1" as expected with the function call
inside the template having the dot added in front:
string ta(string s) { return s ~ "1"; }
template ta(string s) { enum ta = .ta(s); }
void main()
{
import std.stdio;
writeln(ta!"s");
}
--
Shriramana Sharma, Penguin #395953
Re: efficient and safe way to iterate on associative array?
On Friday, 4 March 2016 at 16:46:35 UTC, Steven Schveighoffer
wrote:
You cannot add or remove keys. You can modify values for
existing keys.
Note, in your code, this would not cause a problem, since
setting hash to null just removes the reference from the local
variable 'hash', it does not alter the AA in any way.
In dcollections, all containers support "purging", or iterating
through elements, removing the current element if desired
before moving to the next. But I haven't touched this library
in ages, I don't know if it still compiles even.
-Steve
Thank you for it. Now I know.
I will copy and modify AA source to customize. (src/rt/aaA.d)
I wonder what if D support safe variant like safeByKeyValue.
Actually it seems easy (in aaA.d):
bool _aaRangeEmpty(Range r)
{
return r.impl is null || r.idx == r.dim;
}
can be changed to:
bool _aaRangeEmptySafe(Range r)
{
if(r.impl is null || r.idx >= r.dim) return true;
if (!r.buckets[r.idx].filled) throw xxxException();
return false;
}
It can become safe by a cost of small overhead.
-- Aki.
Re: Unable to instantiate template with same name as function
cym13 wrote:
> Note that parentheses are optional when no argument is provided.
Yes I know that but the point is I expected the compiler to identify
ta!"string" to refer to a different symbol than ta("string") where the one
is obviously a template and the other is obviously a function call. The fact
that parantheses are optional for invocations of zero-arity functions or for
templates taking a single argument or able to infer its arguments is
irrelevant.
Anyhow, this is all moot, since actually the compiler *is* able to make the
difference at the point of invocation and the problem was just a limitation
in name lookup within the template itself:
string ta(string s) { return s ~ "1"; }
template ta(string s) { enum ta = .ta(s); }
void main()
{
import std.stdio;
writeln(ta("a"), ' ', ta!"b");
}
outputs a1 b1 as expected.
Filed https://issues.dlang.org/show_bug.cgi?id=15764 just for the record.
--
Shriramana Sharma, Penguin #395953
Re: D thinks it is OK to mess around with TypeInfo
On 05/03/16 10:35 AM, Yuxuan Shui wrote:
For example
struct A{}
@safe void main(){
import std.stdio;
A a, b;
auto y = typeid(a);
y.name = "Nope, I'm not A";
auto x = typeid(b);
writeln(x);
}
Make changes to TypeInfo will affect all the future typeid() results!
And D is OK with that?
IMO, TypeInfo returned by typeid() should be immutable.
Yeah TypeInfo and friends needs a lot of work done to it.
But that means modifying the compiler + druntime.
D thinks it is OK to mess around with TypeInfo
For example
struct A{}
@safe void main(){
import std.stdio;
A a, b;
auto y = typeid(a);
y.name = "Nope, I'm not A";
auto x = typeid(b);
writeln(x);
}
Make changes to TypeInfo will affect all the future typeid()
results! And D is OK with that?
IMO, TypeInfo returned by typeid() should be immutable.
Re: Is it safe to use 'is' to compare types?
On Friday, 4 March 2016 at 15:18:55 UTC, Steven Schveighoffer wrote: On 3/3/16 6:58 PM, Yuxuan Shui wrote: On Thursday, 3 March 2016 at 23:51:16 UTC, Adam D. Ruppe wrote: On Thursday, 3 March 2016 at 23:46:50 UTC, Yuxuan Shui wrote: Will typeid(a) is typeid(b) yield different results than typeid(a) == typeid(b)? No. Indeed, opEquals on TypeInfo just calls is itself. But opEquals also has extra comparison: auto ti = cast(const TypeInfo)o; return ti && this.toString() == ti.toString(); This makes me feel they are not the same. In some cases, for instance using DLLs, the TypeInfo for an object allocated in one way may be identical, but be a different instance from the TypeInfo allocated in another way. This is why the string comparison occurs. Note that comparing ANY object will first check if they are the same instance before calling any functions (this is in object.opEquals) -Steve Thanks for answering. But I still don't understand why TypeInfo would need to be allocated. Aren't typeid() just returning references to the __DxxTypeInfo___initZ symbol?
Re: std.range: Lockstep vs. Zip
On Thursday, 3 March 2016 at 15:00:10 UTC, Alex Parrill wrote:
On Wednesday, 2 March 2016 at 08:51:07 UTC, Manuel Maier wrote:
Hi there,
I was wondering why I should ever prefer std.range.lockstep
over std.range.zip. In my (very limited) tests std.range.zip
offered the same functionality as std.range.lockstep, i.e. I
was able to iterate using `foreach(key, value;
std.range.zip(...)) {}` which, according to the docs, is what
std.range.lockstep was supposed to be designed for. On top of
that, std.range.zip is capable of producing a
RandomAccessRange, but std.range.lockstep only produces
something with opApply.
Cheers
zip uses the InputRange protocol, and bundles up all the values
in a Tuple.
lockstep uses the opApply protocol, and doesn't bundle the
values.
Lockstep is useful for foreach loops since you don't need to
unpack a tuple, but zip is compatible with all of the std.range
and std.algorithm functions that take ranges.
That helps a lot - it is funny that the documentation shows an
example with foreach an `zip`. Your insights also helped me and I
thought it should also help other people, so I made a PR ;-)
https://github.com/D-Programming-Language/phobos/pull/4054
Re: In language tooling
On Wednesday, 2 March 2016 at 02:36:50 UTC, Charles wrote: is this something that could be accomplished in D with CTFE? I think I've heard him say that tools should be part of the language. However, I haven't watched that video and anyway am not sure how important CTFE would be to this effort. Anyway, D has things like dfix, dfmt, dscanner, dcd, dustmite, digger. I think there was some discussion about including these along with compilers. I recall some comparison to gofmt which will format go code. Maybe that was in Blow's talk...
Re: efficient and safe way to iterate on associative array?
On 3/4/16 8:53 AM, aki wrote:
Is it okay to modify associative array while iterating it?
import std.stdio;
void main() {
string[string] hash = [ "k1":"v1", "k2":"v2" ];
auto r = hash.byKeyValue();
while(!r.empty) {
auto key = r.front.key;
auto value = r.front.value;
r.popFront();
writefln("key=%s, value=%s", key, value);
// may not modify 'hash' here ?
hash = null;
}
}
I guess probably it's not.
Then, my question is are there an efficient and safe way to iterate on
an associative array even if there are possibility to be modified while
iterating?
I'm writing interpreter and want to make my language to be safe; even
malicious script cannot fall it in 'core dump' state. It is okay if it
causes undefined behavior like throw or instant exit from loop, but not
crash.
Thanks, Aki.
You cannot add or remove keys. You can modify values for existing keys.
Note, in your code, this would not cause a problem, since setting hash
to null just removes the reference from the local variable 'hash', it
does not alter the AA in any way.
In dcollections, all containers support "purging", or iterating through
elements, removing the current element if desired before moving to the
next. But I haven't touched this library in ages, I don't know if it
still compiles even.
-Steve
Re: efficient and safe way to iterate on associative array?
On Friday, 4 March 2016 at 13:53:22 UTC, aki wrote:
Is it okay to modify associative array while iterating it?
import std.stdio;
void main() {
string[string] hash = [ "k1":"v1", "k2":"v2" ];
auto r = hash.byKeyValue();
while(!r.empty) {
auto key = r.front.key;
auto value = r.front.value;
r.popFront();
writefln("key=%s, value=%s", key, value);
// may not modify 'hash' here ?
hash = null;
}
}
I guess probably it's not.
Then, my question is are there an efficient and safe way to
iterate on an associative array even if there are possibility
to be modified while iterating?
I'm writing interpreter and want to make my language to be
safe; even malicious script cannot fall it in 'core dump'
state. It is okay if it causes undefined behavior like throw or
instant exit from loop, but not crash.
It is not safe to modify an aa when iterating with .byKey,
.byValue, or .byKeyValue. You can safely do it with .keys and
.values, but these allocate so it isn't likely to be the most
efficient. Your best bet if it's something you need to do
frequently is probably what JR recommended.
Re: Is it safe to use 'is' to compare types?
On 3/3/16 6:58 PM, Yuxuan Shui wrote: On Thursday, 3 March 2016 at 23:51:16 UTC, Adam D. Ruppe wrote: On Thursday, 3 March 2016 at 23:46:50 UTC, Yuxuan Shui wrote: Will typeid(a) is typeid(b) yield different results than typeid(a) == typeid(b)? No. Indeed, opEquals on TypeInfo just calls is itself. But opEquals also has extra comparison: auto ti = cast(const TypeInfo)o; return ti && this.toString() == ti.toString(); This makes me feel they are not the same. In some cases, for instance using DLLs, the TypeInfo for an object allocated in one way may be identical, but be a different instance from the TypeInfo allocated in another way. This is why the string comparison occurs. Note that comparing ANY object will first check if they are the same instance before calling any functions (this is in object.opEquals) -Steve
Re: efficient and safe way to iterate on associative array?
On Friday, 4 March 2016 at 14:16:55 UTC, Minas Mina wrote: On Friday, 4 March 2016 at 13:53:22 UTC, aki wrote: I think what you can do is extract its contents to an array, iterate it and modify it as you like, and then insert back to another associative array. I don't think it's efficient but I don't know if it's possible to do something else. You can populate an array of key values (here string, so string[]) of the entries to delete, then iterate through it afterwards and call .remove to clean up. http://dpaste.dzfl.pl/b63a8e8e5c3b
Re: efficient and safe way to iterate on associative array?
On Friday, 4 March 2016 at 13:53:22 UTC, aki wrote:
Is it okay to modify associative array while iterating it?
import std.stdio;
void main() {
string[string] hash = [ "k1":"v1", "k2":"v2" ];
auto r = hash.byKeyValue();
while(!r.empty) {
auto key = r.front.key;
auto value = r.front.value;
r.popFront();
writefln("key=%s, value=%s", key, value);
// may not modify 'hash' here ?
hash = null;
}
}
I guess probably it's not.
Then, my question is are there an efficient and safe way to
iterate on an associative array even if there are possibility
to be modified while iterating?
I'm writing interpreter and want to make my language to be
safe; even malicious script cannot fall it in 'core dump'
state. It is okay if it causes undefined behavior like throw or
instant exit from loop, but not crash.
Thanks, Aki.
I think what you can do is extract its contents to an array,
iterate it and modify it as you like, and then insert back to
another associative array. I don't think it's efficient but I
don't know if it's possible to do something else.
efficient and safe way to iterate on associative array?
Is it okay to modify associative array while iterating it?
import std.stdio;
void main() {
string[string] hash = [ "k1":"v1", "k2":"v2" ];
auto r = hash.byKeyValue();
while(!r.empty) {
auto key = r.front.key;
auto value = r.front.value;
r.popFront();
writefln("key=%s, value=%s", key, value);
// may not modify 'hash' here ?
hash = null;
}
}
I guess probably it's not.
Then, my question is are there an efficient and safe way to
iterate on an associative array even if there are possibility to
be modified while iterating?
I'm writing interpreter and want to make my language to be safe;
even malicious script cannot fall it in 'core dump' state. It is
okay if it causes undefined behavior like throw or instant exit
from loop, but not crash.
Thanks, Aki.
Re: In language tooling
On Wednesday, 2 March 2016 at 03:41:57 UTC, sigod wrote: Very interesting. I wonder what Walter would say about it. Yeah, I'm curious what others' thoughts on it are for sure.
