Re: Can't understand templates
On 11/28/2014 10:26 PM, Sly wrote: I still don't understand how to read this signature: Point!T getResponse(T: Point!T)(string question) The following is what makes sense to me. Sorry for going step by step but I think it helped me understand your question. (See item 3 below.) 1) Point!T is the return type. Although T is unknown at this point, we will wait a little because it may be a template parameter. Also, according to the syntax of Point!T, Point is apparently a template. So, this function will return the T instantiation of Point, whatever T will be deduced to be in a moment. 2) getResponse is the name of the function 3) The first set of parameters is the template parameters: (T: Point!T) The meaning: T is a type and this specialization is for Point!T. Ok, I think I finally understand your original question. I agree that it doesn't make sense to say T is a type and this specialization is for Point!T. I think we need to read it backward in this case: This specialization is for Point!T. If so, deduce T from that. So, if getResponse is instantiated with Point!int, then T is deduced to be int. 4) The instances of this function template take string parameter. Ali
Re: Why does hello world not compile in safe?
On Saturday, November 29, 2014 07:24:55 Freddy via Digitalmars-d-learn wrote:
import std.stdio;
@safe:
void main()
{
writeln(Edit source/app.d to start your project.);
}
source/app.d(5): Error: safe function 'D main' cannot call system
function 'std.stdio.writeln!(string).writeln'
Well, as the error message says, writeln isn't @safe. It's @system. Now, in
this case, writeln really should be inferred as @safe, but it looks like
whatever work needs to be done to make it so that writeln is treated as
@safe when it can be hasn't been done yet (whether it can be or not depends
on what's passed to it, so implementing that properly could be rather
complicated, but mainly, the issue is that someone needs to take the time to
do it).
- Jonathan M Davis
Re: Can't understand templates
Ah, now I see. In C++ we would also need to supply template
parameters, but we'd put them before return type
(templatetypename T getResponsePointT); in D we put them
before the colon.
Now I'm trying to write a specialization for Pair. It seems that
this is the way to do it:
Pair!(A, B) getResponse(A, B: Pair!(A, B))(string question)
{
auto a = getResponse!A( a);
auto b = getResponse!B( b);
return new Pair!(A, B)(a, b);
}
auto pair = getResponse!(Pair!(int, int))(pair?);
But it doesn't work: this call resolves to a general version T
getResponse(T), and I get a compilation error because it tries to
instantiate readf!(Pair*).
What am I doing wrong?
On Saturday, 29 November 2014 at 08:06:33 UTC, Ali Çehreli wrote:
On 11/28/2014 10:26 PM, Sly wrote:
I still don't understand how to
read this signature:
Point!T getResponse(T: Point!T)(string question)
The following is what makes sense to me.
Sorry for going step by step but I think it helped me
understand your question. (See item 3 below.)
1) Point!T is the return type. Although T is unknown at this
point, we will wait a little because it may be a template
parameter.
Also, according to the syntax of Point!T, Point is apparently a
template. So, this function will return the T instantiation of
Point, whatever T will be deduced to be in a moment.
2) getResponse is the name of the function
3) The first set of parameters is the template parameters:
(T: Point!T)
The meaning: T is a type and this specialization is for Point!T.
Ok, I think I finally understand your original question. I
agree that it doesn't make sense to say T is a type and this
specialization is for Point!T. I think we need to read it
backward in this case: This specialization is for Point!T. If
so, deduce T from that. So, if getResponse is instantiated
with Point!int, then T is deduced to be int.
4) The instances of this function template take string
parameter.
Ali
Re: Still not D standard yet ?
On Saturday, 29 November 2014 at 02:43:14 UTC, Jonathan M Davis via Digitalmars-d-learn wrote: On Saturday, November 29, 2014 01:30:55 Ledd via Digitalmars-d-learn wrote: On Friday, 28 November 2014 at 12:35:28 UTC, Kagamin wrote: What is missing? an ISO standard ? Someday, maybe, but most languages don't have an ISO standard, and I really on't see what it would buy us. What we're generally missing most is manpower. Putting a bunch of effort into formalizing it in a standard wouldn't really help us. If anything, it would just take away manpower from actually getting code written, getting bugs fixed, etc. And even if getting an ISO standard for D were a goal, C++ was something like 20 years old before it got an ISO standard, so even those languages that do have standards didn't generally get them very early in their development, meaning that we're not necessarily slow about getting a standard in comparison to those languages that do. - Jonathan M Davis It depends on what kind of languages you are talking about . There are de facto standards that basically don't need any standard mostly because there isn't even a real competition so the users that want to code and solve a certain problem can't even look at real alternatives, for example what are the alternatives when it comes to Postscript or TeX/LaTeX ? They are basically de facto standards . There are also languages that are linking their lifetime to a main language, for example languages that transcode to other languages don't really need a standard because they are just an extra layer on top of another language. There are examples of languages that have source-to-source compilers to C, Javascript and Lua for example . Given the ambitions of D I can't see how you can pretend to be a relevant language without a standard, it also boils down to creating a reliable ecosystem and make a contract with the community. Do you think that this situation is doing any good to D ? For example there is a significant lack of tools in D where C/C++ have plenty of tools for anything since forever, especially in the last years with llvm . Name even just 1 tool in D that is comparable with the counterpart in C/C++, or try to rate the ecosystem for D after 13 years of existence . Do you really think that a system language, or just a language that aims to be popular, can possibly discard the idea of getting into an international standard ? I still can't recall any major language that doesn't have a standard, what is the language/s you are thinking about ?
Re: Can't understand templates
On 11/29/2014 12:41 AM, Sly wrote:
Ah, now I see. In C++ we would also need to supply template
parameters, but we'd put them before return type
(templatetypename T getResponsePointT); in D we put them
before the colon.
Now I'm trying to write a specialization for Pair. It seems that
this is the way to do it:
Pair!(A, B) getResponse(A, B: Pair!(A, B))(string question)
{
auto a = getResponse!A( a);
auto b = getResponse!B( b);
return new Pair!(A, B)(a, b);
}
auto pair = getResponse!(Pair!(int, int))(pair?);
But it doesn't work: this call resolves to a general version T
getResponse(T), and I get a compilation error because it tries to
instantiate readf!(Pair*).
What am I doing wrong?
I wish I could formalize these definitions better or consistently but
here my art, which works: :)
Pair!(A, B) getResponse(P : Pair!(A, B), A, B)(string question)
{
// ...
}
That template parameter reads:
- This template takes a single parameter (P)
- P must match Pair!(A, B)
- Where A and B are both types
So, getting back to Point, now the following is consistent with the above:
Point!T getResponse(P : Point!T, T)(string question)
{
// ...
}
Now, that means: This is a specialization for P, where it matches
Point!T and T is a type.
Maybe I should change the specialization examples in that chapter...
Ali
What am I missing? Pure constructor behaves differently when assigning string member
I can't find a way to use a pure constructor to create both
mutable and immutable instances of the same class, when one of
the fields I assign is a string.
This works fine:
class A
{
int value;
this(int value_) pure
{
this.value = value_;
}
}
auto a_mutable = new A(1);
auto a_immutable = new immutable A(2);
But if I change the field to a string, I get a compilation error:
class B
{
string value;
this(string value_) pure
{
this.value = value_;
}
}
auto b_mutable = new B(foo);
auto b_immutable = new immutable B(bar);
giving a compilation error for the last row:
Error: mutable method B.this is not callable using a immutable
object
forcing me to use two separate constructors, which works fine:
class B
{
string value;
this(string value_)
{
this.value = value_;
}
this(string value_) immutable
{
this.value = value_;
}
}
The question is: am I missing something that would make it
possible to use a pure constructor in this case, or is it simply
not possible?
Re: Still not D standard yet ?
On Saturday, 29 November 2014 at 09:03:13 UTC, Ledd wrote: Do you really think that a system language, or just a language that aims to be popular, can possibly discard the idea of getting into an international standard ? I still can't recall any major language that doesn't have a standard, what is the language/s you are thinking about ? C was standardized in 1989. C++ was standardized in 1998. I'm unaware of ISO (or any other) standardization for Go, Python, Perl, Objective C, or PHP. And as I recall there is no ISO standard Java, and only for some old version of C#. ISO standardization is very expensive. D is not even close to the popularity level necessary to begin thinking about that.
Re: Can't understand templates
On Saturday, 29 November 2014 at 09:11:51 UTC, Ali Çehreli wrote:
Point!T getResponse(P : Point!T, T)(string question)
{
// ...
}
This doesn't work because now this definition has 2 parameters P
and T. I have to specify both like this: auto pt =
getResponse!(Point!int, int)(point); which of course defeats
the purpose. Otherwise I have ambiguity error:
d.d:73: error: d.getResponse called with argument types (string)
matches both:
d.d(20): getResponse(T)(string question)
and:
d.d(31): getResponse(P : Point!T, T)(string question)
Same thing with specialization for Pair.
Actually what I wrote earlier about C++ is wrong because C++
doesn't allow partial specialization for functions. I wrote this
example in C++ using classes:
templatetypename T
struct Reader {
static T getResponse(const std::string question) {
std::cout question ( typeid(T).name() ):
;
T res;
std::cin res;
return res;
}
};
templatetypename T
struct Point {
T x, y;
};
templatetypename T
struct ReaderPointT {
static PointT getResponse(const std::string question) {
std::cout question \n;
PointT res;
res.x = ReaderT::getResponse( x);
res.y = ReaderT::getResponse( y);
return res;
}
};
templatetypename A, typename B
struct Readerstd::pairA, B {
static std::pairA, B getResponse(const std::string
question) {
std::cout question \n;
std::pairA, B res;
res.first = ReaderA::getResponse( first);
res.second = ReaderB::getResponse( second);
return res;
}
};
int main()
{
int i = Readerint::getResponse(int);
auto pt = ReaderPointint::getResponse(point);
auto pair = Readerstd::pairint, int::getResponse(pair);
return 0;
}
I translated it literally into D using your syntax and it worked!
class Reader(T) {
public static T getResponse(string question) {
writef(%s (%s): , question, T.stringof);
T response;
readf( %s, response);
return response;
}
}
class Reader(P: Point!T, T) {
public static Point!T getResponse(string question) {
writefln(%s (Point!%s), question, T.stringof);
auto x = Reader!T.getResponse( x);
auto y = Reader!T.getResponse( y);
return Point!T(x, y);
}
}
class Reader(P: Pair!(A, B), A, B) {
public static Pair!(A, B) getResponse(string question) {
writefln(%s (Pair!(%s, %s)), question, A.stringof,
B.stringof);
auto a = Reader!A.getResponse( a);
auto b = Reader!B.getResponse( b);
return new Pair!(A, B)(a, b);
}
}
void main()
{
auto i = Reader!int.getResponse(int);
auto pt = Reader!(Point!int).getResponse(point);
auto pair = Reader!(Pair!(int, int)).getResponse(pair);
}
My questions now are:
1. Apparently D has partial specializations of function
templates, but it uses a weird syntax (T: Point!T). How to extend
this syntax for multiple template parameters? (Basically, how to
write this example without wrapping the function into a class?)
2. Why is there a difference between partial specialization of
function templates and class templates: there's a compilation
error with function templates but not with class templates?
Re: What am I missing? Pure constructor behaves differently when assigning string member
On Saturday, 29 November 2014 at 09:41:00 UTC, jostly wrote: I can't find a way to use a pure constructor to create both mutable and immutable instances of the same class, when one of the fields I assign is a string. After poking around a bit, I believe it is caused by issue #10012 https://issues.dlang.org/show_bug.cgi?id=10012 : This is current dmd implementation limitation. In complex cases dmd cannot detect that the constructor generates unique object. So my question then becomes, how can I generate an unique object from the string? I tried using .idup on the incoming string, but that didn't help. Or is it simply still a problem of _detecting_ it for the compiler?
Re: What am I missing? Pure constructor behaves differently when assigning string member
On Saturday, 29 November 2014 at 09:41:00 UTC, jostly wrote:
I can't find a way to use a pure constructor to create both
mutable and immutable instances of the same class, when one of
the fields I assign is a string.
[...]
The question is: am I missing something that would make it
possible to use a pure constructor in this case, or is it
simply not possible?
I ran some tests, as far as I can tell, they should all work:
mixin template test(T)
{
class C
{
T value;
this(T value_) pure {this.value = value_;}
}
static assert(is(typeof({auto c = new C(T.init);})));
static if(!is(typeof(new immutable C(T.init
pragma(msg, T, : immutable construction fails);
static if(!is(typeof({immutable c = new C(T.init);})))
pragma(msg, T, : unique construction fails);
}
/* No indirections (and no (d/w)char): all fine */
mixin test!int;
mixin test!(int[3]);
/* With indirections:
immutable construction fails
unique construction works */
mixin test!string;
mixin test!(immutable int[]);
mixin test!(immutable Object);
mixin test!(immutable int*);
/* No indirections, but (d/w)char:
immutable construction works
unique construction fails
Wat. */
mixin test!dchar;
mixin test!wchar;
mixin test!char;
mixin test!(dchar[3]);
Re: Casting in Safe D
On Friday, 28 November 2014 at 22:54:42 UTC, Jonathan M Davis via
Digitalmars-d-learn wrote:
On Wednesday, November 26, 2014 16:27:53 David Held via
Digitalmars-d-learn wrote:
On 11/23/2014 3:12 PM, anonymous wrote:
[...]
And even pointer dereferencing is @safe. Invalid ones will
fail
with a segfault at run time:
void foo(int* a) @safe {*a = 13;}
Hmm...throwing an exception is a well-defined behavior, but is
segfaulting a well-defined behavior of correct D programs?
This seems
like a peculiar definition of safe to me...
@safe is about guaranteeing that memory will not be corrupted
and that any
memory that's accessed has not been corrupted. Segfaults don't
corrupt
memory and don't allow you to access corrupted memory. Rather,
it's the OS
catching that your program has accessed memory that it
shouldn't and then
essentially killing your program. The OS is _preventing_ any
possible
memory corruption. So, as much as robust programs shouldn't
segfault,
segfaults are perfectly safe with regards to memory - which is
what @safe is
all about.
- Jonathan M Davis
So what about forbidding this in nothrow functions? My vision
with D is to be able to get more guarantees about stability than
all other imperative languages. If the compiler cannot prove that
alignments and memory regions match then a safe nothrow function
doing these casts should IMO fail at compile time.
Re: Why the DMD Backend?
On Friday, 28 November 2014 at 19:59:40 UTC, Xinok wrote: Given that we have GDC with the GCC backend and LDC with the LLVM backend, what are the benefits of keeping the DMD compiler backend? It seems to me that GCC and LLVM are far more developed and better supported by their respective communities. They have superior optimizers and are better equipped for migrating D to new platforms. On the other hand, from what I gather, there's lots of work to be done on DMD on improving support for x64 Windows and ARM. The backend comes from the dmc and dmc++ compilers which Walter wrote, so he's always going to build against that, both because he knows it well and because he refuses to look at source for other compilers, for legal reasons. I don't know that there's much work left for Win64, certainly not on the backend. The dmc backend is for Intel only, ie i386 and x64. No support for ARM or any other arch and no plans to add them. It's a genuine question, which is why I posted this to D.learn. I don't follow development on the backend and overall I'm unfamiliar with compilers, so I'm not sure what the benefits are of the D community continuing to maintain it's own backend. What are the drawbacks? ldc and gdc have their own maintainers. I don't think it takes much work to maintain the dmc backend. On Friday, 28 November 2014 at 20:10:03 UTC, ketmar via Digitalmars-d-learn wrote: On Fri, 28 Nov 2014 19:59:39 + Xinok via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Given that we have GDC with the GCC backend and LDC with the LLVM backend, what are the benefits of keeping the DMD compiler backend? build time for the whole DMD compiler with standard library, using G++: 100 seconds. yea, no kidding. gdc: i don't even want to think about that, way t long. ldc: not that long as gcc, but still much longer than DMD. I haven't timed it, but compiling ldc feels about 50-100% longer to me, which isn't too bad. Unless you're including the time to compile llvm, which is a different story. On Friday, 28 November 2014 at 20:14:07 UTC, LeakingAntonovPlane wrote: DDMD, bootstraping. LDC and GDC are not written in D. That's not the reason, both those projects plan on moving to the new D frontend also. dmd isn't written in D either: they just plan on translating the common dmd frontend from C++ to D, then using it across all three compilers. There is a D frontend written from scratch in D, SDC, which also uses llvm as the backend: https://github.com/deadalnix/SDC
Re: Can't understand templates
On Saturday, 29 November 2014 at 11:07:34 UTC, Sly wrote:
On Saturday, 29 November 2014 at 09:11:51 UTC, Ali Çehreli
wrote:
Point!T getResponse(P : Point!T, T)(string question)
{
// ...
}
This doesn't work because now this definition has 2 parameters P
and T. I have to specify both like this: auto pt =
getResponse!(Point!int, int)(point); which of course defeats
the purpose. Otherwise I have ambiguity error:
Not true, T is inferred based on the the type Point has been
instantiated with, letting you emit the second template argument.
The following code works:
struct Point(T)
{
T x;
T y;
}
P getResponse(P: Point!T, T)(string message)
{
return P(T.init, T.init);
}
void main()
{
import std.stdio;
//T is inferred to be int automatically
writeln(getResponse!(Point!int)(test));
}
Re: Still not D standard yet ?
On Saturday, November 29, 2014 10:35:32 bachmeier via Digitalmars-d-learn wrote: On Saturday, 29 November 2014 at 09:03:13 UTC, Ledd wrote: Do you really think that a system language, or just a language that aims to be popular, can possibly discard the idea of getting into an international standard ? I still can't recall any major language that doesn't have a standard, what is the language/s you are thinking about ? C was standardized in 1989. C++ was standardized in 1998. I'm unaware of ISO (or any other) standardization for Go, Python, Perl, Objective C, or PHP. And as I recall there is no ISO standard Java, and only for some old version of C#. ISO standardization is very expensive. D is not even close to the popularity level necessary to begin thinking about that. According to wikipedia, this is the list: http://en.wikipedia.org/wiki/Category:Programming_languages_with_an_ISO_standard There aren't very many on the list, and most of them aren't used in serious production at this point. An ISO standard isn't even vaguely necessary for a language to succeed. It might be nice to have, but it's not required. Maybe someday, D will have an ISO standard, but at this point, our energies are best directed elsewhere. And not all aspects of the language are set in stone anyway. Yes, it's far more stable than it used to be, and we're trying very hard to avoid breaking existing code, but some features may require reworking to work the way we need them to, which could break code (e.g. shared is on the list of things that we need to rework on some level). Standarizing the language at this stage would harm those efforts, and we'd end up with a worse language as a result. - Jonathan M Davis
Re: Can't understand templates
You miss another definition which introduces a conflict:
T getResponse(T)(string question)
{...}
On Saturday, 29 November 2014 at 17:20:42 UTC, Meta wrote:
On Saturday, 29 November 2014 at 11:07:34 UTC, Sly wrote:
On Saturday, 29 November 2014 at 09:11:51 UTC, Ali Çehreli
wrote:
Point!T getResponse(P : Point!T, T)(string question)
{
// ...
}
This doesn't work because now this definition has 2 parameters
P
and T. I have to specify both like this: auto pt =
getResponse!(Point!int, int)(point); which of course defeats
the purpose. Otherwise I have ambiguity error:
Not true, T is inferred based on the the type Point has been
instantiated with, letting you emit the second template
argument. The following code works:
struct Point(T)
{
T x;
T y;
}
P getResponse(P: Point!T, T)(string message)
{
return P(T.init, T.init);
}
void main()
{
import std.stdio;
//T is inferred to be int automatically
writeln(getResponse!(Point!int)(test));
}
Re: Still not D standard yet ?
On Saturday, 29 November 2014 at 17:48:31 UTC, Jonathan M Davis via Digitalmars-d-learn wrote: On Saturday, November 29, 2014 10:35:32 bachmeier via Digitalmars-d-learn wrote: C was standardized in 1989. C++ was standardized in 1998. I'm unaware of ISO (or any other) standardization for Go, Python, Perl, Objective C, or PHP. C and C++ have improved by being faced with a standardization process, but they also had many implementations before they started. I don't think D qualifies for ISO standardization. But Python is a bad example. Several incompatible versions of Python are being used, this is bad for the Python community. Python 2.7 carries so much weight today that the commercial sector are developing JITs for it, and ignoring Python 3… It might have been easier to move forward with formal standardization since that would have given Python 3 more weight. Go is not standardized yet, probably because they aren't done? Google did standardize Dart with ECMA, so they clearly see the value. The ECMAScript standardization has been very important IMO. production at this point. An ISO standard isn't even vaguely necessary for a language to succeed. It might be nice to have, but it's not required. Standardization might be a requirement for use in larger governmental projects. Having a standard makes the language electible from an evaluation point of view. Standarizing the language at this stage would harm those efforts, and we'd end up with a worse language as a result. Yes, D is not ready for standardization, but a formal write up is needed. Having to write up a formal specification will put light on special cases and inconsistencies, so having a formal write up is probably more important than formal standardization at this point.
Re: Still not D standard yet ?
On Sat, 29 Nov 2014 10:35:32 + bachmeier via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Saturday, 29 November 2014 at 09:03:13 UTC, Ledd wrote: Do you really think that a system language, or just a language that aims to be popular, can possibly discard the idea of getting into an international standard ? I still can't recall any major language that doesn't have a standard, what is the language/s you are thinking about ? C was standardized in 1989. C++ was standardized in 1998. and both standards sux. i won't buy anything that contains undefined behavior in it as any kind of standard. this is pile of shit. i mean, so-called standardization by committee does nothing valuable. signature.asc Description: PGP signature
Re: Why the DMD Backend?
On Sat, 29 Nov 2014 15:37:32 + Joakim via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: build time for the whole DMD compiler with standard library, using G++: 100 seconds. yea, no kidding. gdc: i don't even want to think about that, way t long. ldc: not that long as gcc, but still much longer than DMD. I haven't timed it, but compiling ldc feels about 50-100% longer to me, which isn't too bad. Unless you're including the time to compile llvm, which is a different story. at least 80%-100% longer. this is noticable. besides, i don't want to use anything llvm-related. signature.asc Description: PGP signature
Re: Can't understand templates
On Saturday, 29 November 2014 at 18:19:40 UTC, Sly wrote:
You miss another definition which introduces a conflict:
T getResponse(T)(string question)
{...}
In that case, you're better off with a pair of declarations:
struct Point(T)
{
T x;
T y;
}
T getResponse(T)(string message)
if (!is(T == Point!U, U))
{
return T.init;
}
Point!T getResponse(T)(string message)
if (is(T == Point!U, U))
{
return Point!T(T.init, T.init);
}
void main()
{
auto t = getResponse!int(test);
auto p = getResponse!(Point!int)(test);
}
Re: Can't understand templates
This is clearly an incorrect way because it requires editing the
original definition every time a new class is introduced.
On Saturday, 29 November 2014 at 19:10:34 UTC, Meta wrote:
On Saturday, 29 November 2014 at 18:19:40 UTC, Sly wrote:
You miss another definition which introduces a conflict:
T getResponse(T)(string question)
{...}
In that case, you're better off with a pair of declarations:
struct Point(T)
{
T x;
T y;
}
T getResponse(T)(string message)
if (!is(T == Point!U, U))
{
return T.init;
}
Point!T getResponse(T)(string message)
if (is(T == Point!U, U))
{
return Point!T(T.init, T.init);
}
void main()
{
auto t = getResponse!int(test);
auto p = getResponse!(Point!int)(test);
}
How to initialise array of ubytes?
I'm trying to do this: ubyte[MAPSIZE][MAPSIZE] map = 1; but it doesn't work and I can't seem to cast the value to a ubyte (which looks rather ugly and out of place in D anyway). Is there a way to do this other than using a couple of loops? Cheers Paul
Re: Can't understand templates
On 11/29/2014 10:19 AM, Sly wrote:
You miss another definition which introduces a conflict:
T getResponse(T)(string question)
{...}
The following works with dmd git head:
import std.stdio;
T getResponse(T)(string question)
{
writef(%s (%s): , question, T.stringof);
T response;
readf( %s, response);
return response;
}
class Pair(A, B) {
A a;
B b;
this(A a, B b) {this.a = a; this.b = b;}
}
Pair!(A, B) getResponse(P : Pair!(A, B), A, B)(string question)
{
writeln(question);
auto a = getResponse!A( a);
auto b = getResponse!B( b);
return new Pair!(A, B)(a, b);
}
struct Point(T)
{
T x;
T y;
}
Point!T getResponse(P : Point!T, T)(string question)
{
writefln(%s (Point!%s), question, T.stringof);
auto x = getResponse!T( x);
auto y = getResponse!T( y);
return Point!T(x, y);
}
void main()
{
auto number = getResponse!int(number?);
writeln(number);
auto pair = getResponse!(Pair!(int, long))(pair?);
writeln(pair);
auto point = getResponse!(Point!int)(point?);
writeln(point);
}
Ali
Re: How to initialise array of ubytes?
Paul:
I'm trying to do this:
ubyte[MAPSIZE][MAPSIZE] map = 1;
but it doesn't work and I can't seem to cast the value to a
ubyte (which looks rather ugly and out of place in D anyway).
Is there a way to do this other than using a couple of loops?
This works:
enum MAPSIZE = 3;
void main() {
ubyte[MAPSIZE][MAPSIZE] map2 = 1;
}
This doesn't work:
enum MAPSIZE = 3;
ubyte[MAPSIZE][MAPSIZE] map1 = ubyte(1);
void main() {}
Why isn't this working?
Bye,
bearophile
Re: How to initialise array of ubytes?
Dne Sat, 29 Nov 2014 21:10:41 +0100 Paul via Digitalmars-d-learn digitalmars-d-learn@puremagic.com napsal(a): I'm trying to do this: ubyte[MAPSIZE][MAPSIZE] map = 1; but it doesn't work and I can't seem to cast the value to a ubyte (which looks rather ugly and out of place in D anyway). Is there a way to do this other than using a couple of loops? Cheers Paul http://stackoverflow.com/questions/24600796/d-set-default-value-for-a-struct-member-which-is-a-multidimensional-static-arr/24754361#24754361 -- Vytvořeno poštovní aplikací Opery: http://www.opera.com/mail/
Re: How to initialise array of ubytes?
On Sat, 29 Nov 2014 21:28:36 +0100 Daniel Kozak via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Dne Sat, 29 Nov 2014 21:10:41 +0100 Paul via Digitalmars-d-learn digitalmars-d-learn@puremagic.com napsal(a): I'm trying to do this: ubyte[MAPSIZE][MAPSIZE] map = 1; but it doesn't work and I can't seem to cast the value to a ubyte (which looks rather ugly and out of place in D anyway). Is there a way to do this other than using a couple of loops? Cheers Paul http://stackoverflow.com/questions/24600796/d-set-default-value-for-a-struct-member-which-is-a-multidimensional-static-arr/24754361#24754361 rgh, make me unsee that! that's... disgusting. signature.asc Description: PGP signature
Re: How to initialise array of ubytes?
Daniel Kozak: http://stackoverflow.com/questions/24600796/d-set-default-value-for-a-struct-member-which-is-a-multidimensional-static-arr/24754361#24754361 Do you also know why the simplest syntax doesn't work? Can't it be implemented and added to the D language? Bye, bearophile
Re: How to initialise array of ubytes?
On Saturday, 29 November 2014 at 20:22:40 UTC, bearophile wrote:
This works:
enum MAPSIZE = 3;
void main() {
ubyte[MAPSIZE][MAPSIZE] map2 = 1;
}
This doesn't work:
enum MAPSIZE = 3;
ubyte[MAPSIZE][MAPSIZE] map1 = ubyte(1);
void main() {}
Why isn't this working?
I'm afraid I don't know. I would guess it's something to do with
trying to initialise the array in the global scope but you've
also changed the expression in the non-working example. I don't
have access to my machine at present so I can't experiment!
Re: Array toHash()
On 11/26/2014 4:40 PM, Ali Çehreli wrote:
[...]
override
size_t toHash() @trusted pure const nothrow
{
auto func = assumePure((typeid(importantStuff).getHash));
return func(importantStuff);
}
Very helpful, thanks! Am I right in assuming that there is some runtime
cost here, as we are calling through a function pointer? Is the lack of
inlining the only cost, or is getting at the typeinfo also costly?
Dave
Re: Can't understand templates
OK. I'm using gdc 4.8.2 and this doesn't compile, so it's
probably an old version. Checked on ideone and it works with
dmd-2.042.
Thanks a lot for your help!
On Saturday, 29 November 2014 at 20:16:24 UTC, Ali Çehreli wrote:
On 11/29/2014 10:19 AM, Sly wrote:
You miss another definition which introduces a conflict:
T getResponse(T)(string question)
{...}
The following works with dmd git head:
import std.stdio;
T getResponse(T)(string question)
{
writef(%s (%s): , question, T.stringof);
T response;
readf( %s, response);
return response;
}
class Pair(A, B) {
A a;
B b;
this(A a, B b) {this.a = a; this.b = b;}
}
Pair!(A, B) getResponse(P : Pair!(A, B), A, B)(string question)
{
writeln(question);
auto a = getResponse!A( a);
auto b = getResponse!B( b);
return new Pair!(A, B)(a, b);
}
struct Point(T)
{
T x;
T y;
}
Point!T getResponse(P : Point!T, T)(string question)
{
writefln(%s (Point!%s), question, T.stringof);
auto x = getResponse!T( x);
auto y = getResponse!T( y);
return Point!T(x, y);
}
void main()
{
auto number = getResponse!int(number?);
writeln(number);
auto pair = getResponse!(Pair!(int, long))(pair?);
writeln(pair);
auto point = getResponse!(Point!int)(point?);
writeln(point);
}
Ali
Re: How to initialise array of ubytes?
On Saturday, 29 November 2014 at 20:45:34 UTC, bearophile wrote:
Daniel Kozak:
http://stackoverflow.com/questions/24600796/d-set-default-value-for-a-struct-member-which-is-a-multidimensional-static-arr/24754361#24754361
Do you also know why the simplest syntax doesn't work? Can't it
be implemented and added to the D language?
Bye,
bearophile
I don't know. But this works too:
module main;
import std.stdio;
int[5][5] p;
static this() {
p = 1;
}
void main() {
writeln(p);
}
Do functions and/or function pointers have scope (or lifetimes)
I'm assuming the answer is yes. If so, that implies that I could execute a function pointer that doesn't point to anything meaningful. Conversely, functionality could exist that I can't get access to because my function pointer is unavailable? If these are dangers, is there a technique or mechanism that I can use to always ensure that both these scenarios never happen. Andrei's book mentions that reference types live forever (or something to that effect) as opposed to value types. So could I put functions and function pointers into Class objects? Thanks.
Re: Do functions and/or function pointers have scope (or lifetimes)
On Sat, Nov 29, 2014 at 10:59:21PM +, WhatMeWorry via Digitalmars-d-learn wrote: I'm assuming the answer is yes. If so, that implies that I could execute a function pointer that doesn't point to anything meaningful. Conversely, functionality could exist that I can't get access to because my function pointer is unavailable? If these are dangers, is there a technique or mechanism that I can use to always ensure that both these scenarios never happen. Andrei's book mentions that reference types live forever (or something to that effect) as opposed to value types. So could I put functions and function pointers into Class objects? [...] Functions always exist throughout the lifetime of your program -- they *are* a part of your executable after all -- so function pointers are always valid. (Well, unless you got them from a manually-loaded dynamic library that gets subsequently unloaded, but I'm assuming that if you're doing *that*, then you already know the answers to your question.) Delegates also live forever, even though technically the GC could collect the context part of the delegate once there are no more references to it. But since delegates are built into the language, and the GC will never collect their contexts as long as you have references to them, you don't have to worry about it either. (Of course, delegates come with other gotchas -- for example, they can close over a reference to a variable that subsequently goes out of scope, but in theory the compiler should warn you about that, or automatically allocate said variable on the heap instead of the stack, so you should still be OK in that case. There *are* some cases where you have to be careful, such as closing over the address of a struct member, because structs are movable, so by the time the delegate runs, the reference may already be invalid. But this is quite rare to run into.) tl;dr, yes you can put function pointers into class objects without getting yourself into trouble. T -- Let X be the set not defined by this sentence...
Re: Array toHash()
On 11/29/2014 12:45 PM, David Held wrote:
On 11/26/2014 4:40 PM, Ali Çehreli wrote:
[...]
override
size_t toHash() @trusted pure const nothrow
{
auto func = assumePure((typeid(importantStuff).getHash));
return func(importantStuff);
}
Am I right in assuming that there is some runtime
cost here, as we are calling through a function pointer?
I think so. However, I think the compiler can eliminate dereferencing
the function pointer if it can prove that it is not necessary.
Is the lack of inlining the only cost, or is getting at the
typeinfo also costly?
typeid() is a runtime function. I think it will be costly every time
toHash is called. The function pointer can be initialized once.
// I've deduced the type from an error message. ;)
static const ulong delegate(const(void*)) const pure nothrow
@trusted func;
// This will be executed once per thread:
static this() {
func = assumePure((typeid(Foo.init.importantStuff).getHash));
}
override
size_t toHash() @trusted pure const nothrow
{
return func(importantStuff);
}
Now there is no TypeInfo lookup after thread initialization time.
Ali
Re: Why the DMD Backend?
On 11/29/14, 3:48 PM, ketmar via Digitalmars-d-learn wrote: On Sat, 29 Nov 2014 15:37:32 + Joakim via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: build time for the whole DMD compiler with standard library, using G++: 100 seconds. yea, no kidding. gdc: i don't even want to think about that, way t long. ldc: not that long as gcc, but still much longer than DMD. I haven't timed it, but compiling ldc feels about 50-100% longer to me, which isn't too bad. Unless you're including the time to compile llvm, which is a different story. at least 80%-100% longer. this is noticable. besides, i don't want to use anything llvm-related. Why not?
Re: Why the DMD Backend?
On Sat, 29 Nov 2014 22:57:52 -0300 Ary Borenszweig via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: besides, i don't want to use anything llvm-related. Why not? let's say that there is some ideological reasons. signature.asc Description: PGP signature
Re: Array toHash()
On 11/29/2014 3:59 PM, Ali Çehreli wrote:
[...]
typeid() is a runtime function. I think it will be costly every time
toHash is called. The function pointer can be initialized once.
// I've deduced the type from an error message. ;)
static const ulong delegate(const(void*)) const pure nothrow
@trusted func;
// This will be executed once per thread:
static this() {
func = assumePure((typeid(Foo.init.importantStuff).getHash));
}
override
size_t toHash() @trusted pure const nothrow
{
return func(importantStuff);
}
Now there is no TypeInfo lookup after thread initialization time.
Nice! This is getting very fancy, but also a bit unfortunate. It would
be appropriate if the type of importantStuff were arbitrary, but it's
not. It's int[]. In fact, the fact that I can get a compiler-generated
hash function for any type (I presume) surprises me. Not entirely,
since the compiler can just treat types as binary blobs, and define a
hash function that operates as if it were byte[].
Although it is nice that we can get at stuff through reflection, this is
not quite the same as the ostensibly static [and inlinable] call to
int[].toHash() which logically occurs when int[] is used directly as a key.
Also, would it be possible to avoid spelling the delegate type by making
func a function static and using an auto return on a named method?
Finally, I find it a little surprising that there's no standard module
which implements a quality hash function builder (using something like
MurmurHash or CityHash). This seems like it would be a fairly common
requirement for a lot of users. Are there any non-standard libraries
which do this?
Dave
