Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 06:31:13 UTC, Mike Parker wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug (I've
been unable to turn up anything in Bugzilla), could someone in
the know explain the rationale behind this?
What about:
import std.stdio;
void printVal(T)(T t) {
static if (is(T : U*, U))
printVal(*t);
else
writeln(t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);
}
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 06:31:13 UTC, Mike Parker wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug (I've
been unable to turn up anything in Bugzilla), could someone in
the know explain the rationale behind this?
---
import std.stdio;
void printVal(T)(T t) {
writeln(t);
}
void printVal(T: T)(T* t) {
writeln(*t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);
}
---
here it's selected correctly without explicit instantiation. But
honestly i don't know why since the asterisk is removed from the
T it looks quite incorrect.
Template type deduction and specialization
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug (I've
been unable to turn up anything in Bugzilla), could someone in
the know explain the rationale behind this?
Re: DMD Symbol Reference Analysis Pass
On Wednesday, 20 May 2015 at 08:52:23 UTC, Per Nordlöw wrote:
Does DMD currently do any analysis of references to a symbol in
a given scope? If not where could this information be extracted
(in which visitor/callback) and in what structure should it, if
so, be stored?
I'm guessing
Scope::insert(Dsymbol*s)
{
if (VarDeclaration *vd = s-isVarDeclaration())
{
// ..
is of interest. Is there another member function called everytime
a Dsymbol is referenced?
I'm guessing MODFlags plays a role here aswell.
Re: Template type deduction and specialization
On 5/20/2015 6:35 PM, Daniel Kozak wrote:
DOCS: http://dlang.org/template.html#function-templates
says: Function template type parameters that are to be implicitly
deduced may not have specializations:
Thanks. For the record, the example there is the exact same case.
void Foo(T : T*)(T t) { ... }
int x,y;
Foo!(int*)(x); // ok, T is not deduced from function argument
Foo(y); // error, T has specialization
I was looking for the answer in higher up the page in the
Specializations section under Argument Deduction. Didn't think to look
for it under Function Templates.
Re: ddbc: MySQL/MariaDB: Access Violation
On Monday, 18 May 2015 at 18:54:20 UTC, Suliman wrote: GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; p.s. this command return my: Affected rows: 0 Do you see some stack trace on crash? No. I checked on 2 PC and it's not look like my issue, because result is totally same. If I change void main() to vibed's static this() I get this error. Try running under debugger. See where it's crashed.
Re: Template type deduction and specialization
On 5/20/2015 6:35 PM, Jonathan M Davis via Digitalmars-d-learn wrote: I'm using a fairly recent version of dmd master, and it prints out the address for px in both cases when I compile your code. So, if it's printing out 100 for you on the second call, it would appear to be a bug that has been fixed at some point since 2.067 (or whatever version you're using) was released. - Jonathan M Davis I'm using 2.067.0, but according to the section of the docs Daniel pointer me to[1], printing 100 is the correct behavior in the second call. [1] http://dlang.org/template.html#function-templates
Re: ddbc: MySQL/MariaDB: Access Violation
On Monday, 18 May 2015 at 18:54:20 UTC, Suliman wrote: GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; p.s. this command return my: Affected rows: 0 Do you see some stack trace on crash? No. I checked on 2 PC and it's not look like my issue, because result is totally same. If I change void main() to vibed's static this() I get this error. Hi, There's are several related problems with vibe's static this; some needed variables are not initialized at the time static this is executed, that's why you get access violation ( it has nothing to do with permissions ). The solution is to use main(). here are some reported issues related to the problem you have described. https://github.com/mysql-d/mysql-native/issues/53 https://github.com/rejectedsoftware/vibe.d/issues/906
Re: Template type deduction and specialization
On Wed, 20 May 2015 06:31:11 +
Mike Parker via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug (I've
been unable to turn up anything in Bugzilla), could someone in
the know explain the rationale behind this?
Because it cannot deduce type T:
try this:
void printVal(T : T*)(T* t) {
writeln(*t);
}
void main() {
int x = 100;
int* px = x;
printVal(px);
}
It will print error.
My advise is not to use T:T* or T:T[] it works only when explicitly
instantiate. Is better use T:M*,M or T:M[], M because it works
automaticly and you have both types available.
import std.stdio;
void printVal(T)(T t) {
writeln(t);
}
void printVal(T:M*,M)(T t) {
writeln(*t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the 100
}
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 09:24:28 UTC, Daniel Kozák wrote:
On Wed, 20 May 2015 06:31:11 +
Mike Parker via Digitalmars-d-learn
digitalmars-d-learn@puremagic.com
wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug
(I've been unable to turn up anything in Bugzilla), could
someone in the know explain the rationale behind this?
Because it cannot deduce type T:
try this:
void printVal(T : T*)(T* t) {
writeln(*t);
}
void main() {
int x = 100;
int* px = x;
printVal(px);
}
It will print error.
My advise is not to use T:T* or T:T[] it works only when
explicitly
instantiate. Is better use T:M*,M or T:M[], M because it works
automaticly and you have both types available.
import std.stdio;
void printVal(T)(T t) {
writeln(t);
}
void printVal(T:M*,M)(T t) {
writeln(*t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the 100
}
DOCS: http://dlang.org/template.html#function-templates
says: Function template type parameters that are to be implicitly
deduced may not have specializations:
Re: GC Destruction Order
On Tuesday, 19 May 2015 at 22:15:18 UTC, bitwise wrote: Thanks for confirming, but given your apparent tendency toward pinhole view points, it's unsurprising that you don't understand what I'm asking. And what you're asking. Just for the record: C++ memory management techniques are not designed to work in GC environment. On Wednesday, 20 May 2015 at 03:44:58 UTC, bitwise wrote: Basically, I can't design a struct and be sure the destructor will be called on the same thread as where it went out of scope. If your resource finalization code has some specific threading requirements, you implement those yourself in a way your code requires it. Or instead freeing resources normally in due time.
Re: Template type deduction and specialization
On 5/20/2015 4:36 PM, Namespace wrote:
What about:
import std.stdio;
void printVal(T)(T t) {
static if (is(T : U*, U))
printVal(*t);
else
writeln(t);
}
Thanks, but I'm not looking for alternatives. I'm trying to figure out
why it doesn't work as expected.
DMD Symbol Reference Analysis Pass
Does DMD currently do any analysis of references to a symbol in a given scope? If not where could this information be extracted (in which visitor/callback) and in what structure should it, if so, be stored? Reason: After having read about Rust's data-flow (and in turn escape) analysis I'm very curious about how difficult it would be to add more clever type inference, of for example symbol mutability, based on this analysis. I'm asking again because of the work recently done in DIP-25, that may be related to this problem.
Re: Template type deduction and specialization
On Wednesday, May 20, 2015 06:31:11 Mike Parker via Digitalmars-d-learn wrote:
I don't understand why this behaves as it does. Given the
following two templates:
```
void printVal(T)(T t) {
writeln(t);
}
void printVal(T : T*)(T* t) {
writeln(*t);
}
```
I find that I actually have to explicitly instantiate the
template with a pointer type to get the specialization.
```
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);// prints the address
printVal!(int*)(px) // prints 100
}
```
Intuitively, I would expect the specialization to be deduced
without explicit instantiation. Assuming this isn't a bug (I've
been unable to turn up anything in Bugzilla), could someone in
the know explain the rationale behind this?
Well, if
printVal!(int*)(px);
prints 100, then that's a bug. It should print the address. In fact, it
should be _impossible_ for the second overload of printVal to ever be
instantiated. Think about it. What does T : T* mean? It means that T is
implicitly convertible to T*. And when is a type ever implicitly convertible
to a pointer to itself?
int x = 100;
int y = x;
isn't going to compile, so neither should that second overload ever end up
being used. Use std.traits.isPointer if you want to test for whether a type
is a pointer or not.
I'm using a fairly recent version of dmd master, and it prints out the
address for px in both cases when I compile your code. So, if it's printing
out 100 for you on the second call, it would appear to be a bug that has
been fixed at some point since 2.067 (or whatever version you're using) was
released.
- Jonathan M Davis
Re: DMD Symbol Reference Analysis Pass
On Wednesday, 20 May 2015 at 09:27:06 UTC, Per Nordlöw wrote: Two cases come to my mind: A: Non-Templated Function: must be @safe (or perhaps @trusted) pure and parameter must qualified as const (or in). B: Templated Function: Usage of parameter in body must be non-mutating; meaning no lhs of assignment op (=, +=, ...), and calls to functions that take parameter as argument must be transitively fulfill A and B.
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 07:27:53 UTC, jklp wrote:
---
import std.stdio;
void printVal(T)(T t) {
writeln(t);
}
void printVal(T: T)(T* t) {
writeln(*t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);
}
---
here it's selected correctly without explicit instantiation.
But honestly i don't know why since the asterisk is removed
from the T it looks quite incorrect.
No it is correct it is same as:
void printVal(T: int)(T* t) {
writeln(*t);
}
Re: Template type deduction and specialization
On Wednesday, May 20, 2015 07:36:21 Namespace via Digitalmars-d-learn wrote:
What about:
import std.stdio;
void printVal(T)(T t) {
static if (is(T : U*, U))
printVal(*t);
else
writeln(t);
}
void main() {
int x = 100;
printVal(x);
int* px = x;
printVal(px);
}
That mostly works, but you it runs the classic risk of running into problems
with alias this (which is why checking for implicit conversions in static if
or template constraints is so incredibly dangerous if you're not _very_
careful). std.traits defines isPointer as follows:
enum bool isPointer(T) = is(T == U*, U) !isAggregateType!T;
which avoids the alias this problem. Regardless, it's more idiomatic to just
use isPointer.
- Jonathan M Davis
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 09:35:48 UTC, Jonathan M Davis wrote:
Well, if
printVal!(int*)(px);
prints 100, then that's a bug. It should print the address. In
fact, it
should be _impossible_ for the second overload of printVal to
ever be
instantiated
IMHO thats not true, it should print 100. This is what spec say.
void printVal(T : T*)(T* t) {
writeln(*t);
}
T is deduce to be int so we have
void printVal(int* t) {
writeln(*t);
}
which will print value not address
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 09:35:43 UTC, Daniel Kozak wrote:
DOCS: http://dlang.org/template.html#function-templates
says: Function template type parameters that are to be
implicitly deduced may not have specializations:
OK, having reread this, I'm not clear at all what's going on.
Here, I'm instantiating the templates such that the types are
implicitly deduced from the function arguments and they pick up
the specializations just fine.
```
T sum(T : ulong)(T lhs, T rhs) {
writeln(Integrals);
return cast(T)(lhs + rhs);
}
T sum(T : real)(T lhs, T rhs) {
writeln(Floating Point);
import std.math : round;
return round(lhs + rhs);
}
void main() {
writeln(sum(10L, 20L));
writeln(sum(10.11, 3.22));
}
```
If the documentation is correct, then this shouldn't work, but it
does. It breaks only when specializing on pointers and arrays, in
which case I have to implicitly instantiate.
Re: GC Destruction Order
On Wednesday, 20 May 2015 at 08:01:46 UTC, Kagamin wrote: On Tuesday, 19 May 2015 at 22:15:18 UTC, bitwise wrote: Thanks for confirming, but given your apparent tendency toward pinhole view points, it's unsurprising that you don't understand what I'm asking. And what you're asking. Just for the record: C++ memory management techniques are not designed to work in GC environment. Yes, but D claims to support manual memory management. It seems to get second class treatment though. I'm pretty sure I can PInvoke malloc in C# too ;) On Wednesday, 20 May 2015 at 03:44:58 UTC, bitwise wrote: Basically, I can't design a struct and be sure the destructor will be called on the same thread as where it went out of scope. If your resource finalization code has some specific threading requirements, you implement those yourself in a way your code requires it. Or instead freeing resources normally in due time. AFAIK D does not provide any built in functionality like Objective-C's 'runOnMainThread', which makes this a painful option.
Re: Template type deduction and specialization
DOC say `may not have` not `must not have` ;-)
On Wed, 20 May 2015 13:24:22 +
Mike Parker via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
On Wednesday, 20 May 2015 at 09:35:43 UTC, Daniel Kozak wrote:
DOCS: http://dlang.org/template.html#function-templates
says: Function template type parameters that are to be
implicitly deduced may not have specializations:
OK, having reread this, I'm not clear at all what's going on.
Here, I'm instantiating the templates such that the types are
implicitly deduced from the function arguments and they pick up
the specializations just fine.
```
T sum(T : ulong)(T lhs, T rhs) {
writeln(Integrals);
return cast(T)(lhs + rhs);
}
T sum(T : real)(T lhs, T rhs) {
writeln(Floating Point);
import std.math : round;
return round(lhs + rhs);
}
void main() {
writeln(sum(10L, 20L));
writeln(sum(10.11, 3.22));
}
```
If the documentation is correct, then this shouldn't work, but it
does. It breaks only when specializing on pointers and arrays, in
which case I have to implicitly instantiate.
Assertion failure without line
core.exception.AssertError@stackext.d(0): Assertion failure how to handle this? -manfred
Re: Assertion failure without line
My first gut idea is to check the file for an assert inside a mixed in string.
Re: LuaD + VisualD link issue
On Tuesday, 12 August 2014 at 22:25:24 UTC, Johnathan Sunders wrote: I'm having an issue with building programs that link with LuaD using VisualD. If I use Dub, it builds without an issue, but generating a project file and compiling it through VisualD results in Error 162: Bad Type Index reference to type 84A9 when linking luad.lib(base). Anyone has any ideas on what may cause this? I've also tried building using the VisualD project on LuaD's GitHub in case it was a missing configuration setting but that has the same issue (running Windows 8 64 bit in case it's relevant). I wondered if you ever found a solution to this issue? I am having exactly the same problem. Basically I did this 1. Generated a simple app with dub and added luad as a dependency. 2. Compiling the app with dub works fine. Can call Lua ok. 3. Asking dub to generate a VisualD project file and then trying to compile the same app in VisualD fails, in my case the error is Error 162: Bad Type Index reference to type 5C55. I have tried copying the VisualD project from the dub's Luad folder into my own solution and compiling it manually, but I run into the same problem. As an aside, I should add that this is an attempt to workaround my original problem - I want to use a dub package (LuaD) in an existing VisualD project that I created using VisualD - not sure if that is possible? Wild guess: There is an enigmatic README.md in the LuaD distribution https://github.com/JakobOvrum/LuaD/blob/master/extlib/README.md which might contain a clue as to the problem. I am running Windows 8 64 bit, the VisualD project is Win32 configuration. Changing the configuration to Win64 yields error ..\luad-master\extlib\lua5.1.lib : fatal error LNK1136: invalid or corrupt file
Re: partialShuffle only shuffles subset.
On Tuesday, 19 May 2015 at 14:31:21 UTC, Ivan Kazmenko wrote: On Tuesday, 19 May 2015 at 10:00:33 UTC, BlackEdder wrote: The documentation seems to indicate that partialShuffle: Partially shuffles the elements of r such that upon returning r[0..n] is a random subset of r, (which is what I want), but it seems that partialShuffle actually only shuffles the first subset of the range (which you could do probably also do by [0..n].randomShuffle). This different behaviour was problem created since: https://issues.dlang.org/show_bug.cgi?id=11738. Does anyone know what the intended behaviour is/was? Reading the current documentation and unittests, I now also believe the fix was a mistake. Reopened the issue for now with a comment: https://issues.dlang.org/show_bug.cgi?id=11738#c2 I hope Joseph Rushton Wakeling looks into it soon. Reading the documentation it does appear that the function behaviour is at odds with what is described. I don't know how I came to that misunderstanding. In the short term, if you want a randomly-shuffled random subset of a range, you could get it via something like, original_range.randomSample(n).array.randomShuffle; or maybe better original_range.randomShuffle.randomSample(n);
Re: Assertion failure without line
Adam D. Ruppe wrote:
assert inside a mixed in string.
None praesent:
private import star, stack;
class StackExtended( T): Stack!T{
Star!T stacked;
this(){ stacked= new Star!T;}
auto opOpAssign( string op, T)( T node){
stacked+= node;
return super+= node;
}
auto opUnary( string op)(){
stacked -= super.max;
return super--;
}
bool opBinaryRight( string op, Tquote)( Tquote elem)
if( is( Tquote:T) ( in==op ))
{
return elem in stacked;
}
}
-manfred
Re: Template type deduction and specialization
On 05/20/2015 04:10 PM, Mike Parker wrote: On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote: DOC say `may not have` not `must not have` ;-) OK, if that's the intent, it needs to be reworded. As it stands, it looks more like it's saying specialization is not permissible, rather than what might be possible. That's the only meaning that I get: The doc means must not. Yet, as you've shown, the behavior does not match the doc. Ali
Re: Template type deduction and specialization
On Wednesday, 20 May 2015 at 13:46:22 UTC, Daniel Kozák wrote: DOC say `may not have` not `must not have` ;-) OK, if that's the intent, it needs to be reworded. As it stands, it looks more like it's saying specialization is not permissible, rather than what might be possible. As in: Employees may not bring unauthorized individuals into the work space. It's very rare to use must not when denying permission.
Re: Assertion failure without line
Adam D. Ruppe wrote: My first gut idea Turns out: it is the usage of a variable - not newed, and - of a type declared in the file. -manfred
Re: Template type deduction and specialization
On Wednesday, May 20, 2015 19:20:19 Mike Parker via Digitalmars-d-learn wrote: On 5/20/2015 6:35 PM, Jonathan M Davis via Digitalmars-d-learn wrote: I'm using a fairly recent version of dmd master, and it prints out the address for px in both cases when I compile your code. So, if it's printing out 100 for you on the second call, it would appear to be a bug that has been fixed at some point since 2.067 (or whatever version you're using) was released. - Jonathan M Davis I'm using 2.067.0, but according to the section of the docs Daniel pointer me to[1], printing 100 is the correct behavior in the second call. [1] http://dlang.org/template.html#function-templates Hmmm. It looks like when : is used directly in the template parameter list, it doesn't mean the same thing as when it's used in an is expression. I _never_ use : directly in the template parameter list, so I misunderstood what it did. And looking over what it says, your printVal(T : T*) should be used when explicitly calling printVal!(int*) but that printVal(px) will print the address, because for whatever reason, IFTI doesn't work with the : syntax directly in the template parameter list (I have no idea why, but that section in the spec is pretty clear about that). So, the fact that it's printing the address for me in both cases is bug. But if you're seeing it print 100 for printVal!(int*)(px) and the address for printVal(px), then that would be correct per the spec. Personally, I wish that template specializations like this just didn't exist in the language, because they're redundant with template constraints and just add more complication to the language, but it's not like we're going to get rid of them at this point, unfortunately. But because I think that they're pointless, I never use them, and clearly am not familiar enough with how they work. - Jonathan M Davis
Re: GC Destruction Order
On Wednesday, 20 May 2015 at 13:54:29 UTC, bitwise wrote: Yes, but D claims to support manual memory management. It seems to get second class treatment though. It's WIP. There were thoughts to run finalizers on the thread where the object was allocated (I doubt it's a good idea, though). Anyway, if you're doing manual memory management, how GC popped up? If you have your manual memory managed with GC, it means you have a memory leak: manually managed memory shouldn't become garbage without being freed. I suppose it will be a long way before D rediscovers .net practices. I'm pretty sure I can PInvoke malloc in C# too ;) I use Marshal.AllocHGlobal. Basically, I can't design a struct and be sure the destructor will be called on the same thread as where it went out of scope. If your resource finalization code has some specific threading requirements, you implement those yourself in a way your code requires it. Or instead freeing resources normally in due time. AFAIK D does not provide any built in functionality like Objective-C's 'runOnMainThread', which makes this a painful option. You asked for destructor being called on the thread where it went out of scope, which is not necessarily the main thread.
