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
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
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
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
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) {
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
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
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
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) {
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) {
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
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.
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
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
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
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
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*
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
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,
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
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:
core.exception.AssertError@stackext.d(0): Assertion failure
how to handle this?
-manfred
My first gut idea is to check the file for an assert inside a
mixed in string.
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
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
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(
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
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:
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
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
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).
31 matches
Mail list logo
