Re: various questions
== Quote from Rory Mcguire (rjmcgu...@gm_no_ail.com)'s article > Jason Spencer wrote: > > I nievely went and replaced "foreach (t; Iota!(str_types.length))" > > with "foreach (t; str_types.length)", since the length of that > > array is known at compile-time. > your replacement tries to loop over an uint called str_types.length. > Never gonna happen. > Iota!(str_types.length) seems to generate str_types.length(a number > of)integer indexes. Can't use 0 .. str_types.length in the foreach > because compiler is expecting Integer constants so it can make the > template "foo" into actual code. Not quite sure I follow. I think you're saying the range in foreach has to be actual literals, and not just an expression that can be evaluated at compile time to generate the same range...close? If that's the case, then why does it work to instantiate Iota! with str_types.length? It can obviously get the value behind it at compile time. I'm still missing something. Jason
Re: various questions
Jason Spencer wrote:
> == Quote from Rory Mcguire (rjmcgu...@gm_no_ail.com)'s article
>> Jason Spencer wrote:
>
>> > I nievely went and replaced "foreach (t; Iota!(str_types.length))"
>> > with "foreach (t; str_types.length)", since the length of that
>> > array is known at compile-time.
>
>> your replacement tries to loop over an uint called str_types.length.
>> Never gonna happen.
>> Iota!(str_types.length) seems to generate str_types.length(a number
>> of)integer indexes. Can't use 0 .. str_types.length in the foreach
>> because compiler is expecting Integer constants so it can make the
>> template "foo" into actual code.
>
> Not quite sure I follow. I think you're saying the range in foreach
> has to be actual literals, and not just an expression that can be
> evaluated at compile time to generate the same range...close?
>
> If that's the case, then why does it work to instantiate Iota! with
> str_types.length? It can obviously get the value behind it at compile
> time. I'm still missing something.
>
> Jason
I convert str_types.length to its actual value below:
foreach (t; 3) {
...
}
You can't do that (dmd : t.d(6): Error: int is not an aggregate type)
Re: Wanting an immutable associative array in a class
On Thu, 29 Jul 2010 22:55:35 -0400, bearophile wrote:
> RedZone:
>> But it would be nice if I could have the array reference itself be
>> immutable and not just the array's contents. Is there any way I could
>> do this?
>
> Let's say your code is as your second example:
>
> class Foo {
> private:
> immutable int[string] bar;
>
> public:
> this() {
> bar = ["AB":1, "CD":2, "EF":3];
> }
> }
>
> void main() {
> auto f = new Foo;
> }
>
>
> How can you change the array reference outside the class constructor?
But that was not his second example. :) His second example used the type
immutable(int)[char[]]
while you used the "correct" one,
immutable(int[char[]])
RedZone: Even though the overall type is immutable, you can still set it
in a constructor, like bearophile showed.
May I also suggest a small improvement? Doing it like this means that
the array will be constructed anew every time you create an instance of
the class. If it's meant to be immutable, and you know all the elements
of the array at compile time, that's just wasteful. In that case, it's
probably better to make it a static member variable, and set its value in
a static constructor. That way it will only get constructed once, at
program startup.
class Foo
{
private:
static immutable int[string] bar;
static this() // Only run when program loads
{
bar = ["AB": 1, "CD": 2, "EF": 3];
}
public:
...
}
-Lars
Re: various questions
Jason Spencer:
> I nievely went and replaced "foreach (t; Iota!(str_types.length))"
> with "foreach (t; str_types.length)", since the length of that array
> is known at compile-time. That of course bombed, but I don't quite
> get why. Is the compiler actually evaluating the foreach loop at
> compile time? How could it, when the body makes run-time checks? If
> it's not, why doesn't my change work?
foreach (t; str_types.length) doesn't work because integral values are not
iterable. You need a range, collection or tuple.
foreach (t; 0 .. str_types.length) doesn't work in that code because it's a
run-time foreach.
The Iota!(n) creates a tuple of the values 0, 1, 2 ... n-1.
The foreach done on a tuple is a static foreach, it's done at compile-time, so
my code is a way to perform a compile-time unrolling of the if-goto body. You
can see it with this example (normally DMD is not able to perform loop
unrolling):
import std.typetuple: TypeTuple;
import std.c.stdio: printf;
template Iota(int stop) {
static if (stop <= 0)
alias TypeTuple!() Iota;
else
alias TypeTuple!(Iota!(stop-1), stop-1) Iota;
}
void main() {
foreach (i; Iota!(5)) {
enum int n = i;
printf("%d\n", n);
}
}
The resulting asm:
__Dmain comdat
pushEBX
push0
mov EAX,offset FLAT:_DATA
pushEAX
callnear ptr _printf
add ESP,8
push1
mov ECX,offset FLAT:_DATA
pushECX
callnear ptr _printf
add ESP,8
push2
mov EDX,offset FLAT:_DATA
pushEDX
callnear ptr _printf
add ESP,8
push3
mov EBX,offset FLAT:_DATA
pushEBX
callnear ptr _printf
add ESP,8
push4
pushEBX
callnear ptr _printf
add ESP,8
xor EAX,EAX
pop EBX
ret
I suggest you to use a variant of my last version of the code because it
contains some asserts and static asserts that improve code safety a bit.
See also this enhancement request of mine:
http://d.puremagic.com/issues/show_bug.cgi?id=4085
Bye,
bearophile
Re: alias = compile-time variants?
On Thu, Jul 29, 2010 at 22:40, Jason Spencer wrote:
> In writing templates that make heavy use of alias parameters, does
> anyone else feel uneasy about whether the caller will pass a type, a
> value, or a schmoo?
I thought they could only be symbols. That is, an alias is a 'link', a sort
of pointer to a symbol: a template name, a module name, a function name,
etc.
It does not seem to accept types:
template TestAlias(alias a)
{
enum string TestAlias = __traits(identifier, a);
}
void main()
{
T foo(T)(T t) { return t;}
writeln(TestAlias!foo); // works
writeln(TestAlias!int); // do not compile
}
Though '3' is accepted by alias... Hmm.
> I'm having a hard time getting my head around
> how wide-open aliases are and trying to resist the urge to put in
> thousands of static asserts to check what should be invariants on
> the kind of thing that can be passed in that position. This all
> feels very strange when I typically look for templates to provide
> that nice, static, compile-time safety that keeps me from having to
> check everything that gets passed. Any words of wisdom on adjusting
> to this feature?
Wisdom, I don't know, as I still feel like I'm exploring things. But
template constraints are there to limit what you can instantiate. The C++
syntax is still there (T : U, etc), but it's quite limited and not so easy
to parse, compared to D template constraints.
Feel free to ignore what follows if that's well-treaded ground to you.
Say I have a template that takes an alias, fun, and a type, T.
fun is supposed to be a function, but in fact why limit it to that? What I
need is for foo to be callable with a T. So let's test for that:
auto doSomething(alias fun, T)(T t)
if (is(typeof( fun(T.init) )))
{
// now that I'm here, I can freely use fun as a callable on any T
auto result = fun(t);
// ...
}
So, T is a type. T.init is a value of type T, the default value for any T.
.init is a easy way to generate a value from a type. Any type in D has a
.init field (not typetuples, though). Note that 't' is not really accessible
inside the constraint template, because t will have a runtime value, whereas
here we are at compile-time. I think t can be used, but is still T.init at
this stage.
I call fun with T.init. If that compiles, then the resulting expression has
a type: I use typeof() to get it, and then the is() expression to get a bool
telling me if that's a valid type. If foo(T.init) doesn't compile, for
whatever reason (fun as no opCall defined, or foo is callable, but not with
a T...) then foo(T.init) has no type, so is(typeof( ... )) returns false and
the template constraint forbids the template to be instantiated.
inside doSomething(), I can freely use fun as something callable with one T.
Note that my constraint is not complete: I did not test for fun(T.init) to
return a value: it could be a void function(T) and the assignement would
fail. I could also test for that, I guess.
Philippe
string initialization question.
Hello. Is there anyway in D to convenient fill a string variable with a char say X times? So, I'd like to do something like: string divider( size, '-');// C++ notation. $divider = '-' x $size;// perl notation. I thought I could do the following: const char divider[rowstr.length] = '-'; but the compiler complains about not having a constant integer expression. thanks.
Re: string initialization question.
On Fri, 30 Jul 2010 11:24:41 -0400, dcoder wrote: Hello. Is there anyway in D to convenient fill a string variable with a char say X times? So, I'd like to do something like: string divider( size, '-');// C++ notation. $divider = '-' x $size;// perl notation. I thought I could do the following: const char divider[rowstr.length] = '-'; but the compiler complains about not having a constant integer expression. thanks. It's most likely complaining about rowstr.length not being a constant, not the '-'. This works: const char divider[5] = '-'; If you want to allocate a new array on the heap with '-' in it, I think there is a way, but I'm not sure how to do it. I'm pretty sure there's a runtime function to do it. -Steve
Re: string initialization question.
On Fri, 30 Jul 2010 11:35:15 -0400, Steven Schveighoffer wrote: > > On Fri, 30 Jul 2010 11:24:41 -0400, dcoder wrote: > > > Hello. > > > > Is there anyway in D to convenient fill a string variable with a char > > say X times? > > > > So, I'd like to do something like: > > > > string divider( size, '-');// C++ notation. > > $divider = '-' x $size;// perl notation. > > > > > > I thought I could do the following: > > > > const char divider[rowstr.length] = '-'; > > > > but the compiler complains about not having a constant integer > > expression. > > > > thanks. > > It's most likely complaining about rowstr.length not being a constant, not > the '-'. This works: > > const char divider[5] = '-'; > > If you want to allocate a new array on the heap with '-' in it, I think > there is a way, but I'm not sure how to do it. I'm pretty sure there's a > runtime function to do it. > > -Steve Something like this will work on the heap: char[] divider = new char[5]; divider[] = '-';
Re: string initialization question.
On Fri, 30 Jul 2010 11:46:32 -0400, Justin Spahr-Summers wrote: On Fri, 30 Jul 2010 11:35:15 -0400, Steven Schveighoffer wrote: If you want to allocate a new array on the heap with '-' in it, I think there is a way, but I'm not sure how to do it. I'm pretty sure there's a runtime function to do it. Something like this will work on the heap: char[] divider = new char[5]; divider[] = '-'; That assigns 0xff to all divider chars, and then assigns '-'. I think there's a way to do it without the initial assignment. -Steve
Re: string initialization question.
Steven Schveighoffer: > > char[] divider = new char[5]; > > divider[] = '-'; > > That assigns 0xff to all divider chars, and then assigns '-'. I think > there's a way to do it without the initial assignment. In past there was some way to do that: typedef char mchar = '-'; mchar[] divider = new mchar[5]; Now you have to initialize the dynamic array two times (using a char struct with alias this is probably not a good idea). I have shown this problem, but I think Walter was not interested. Maybe LDC will able to optimize away the first initialization, I have an enhancement request for LLVM. Bye, bearophile
Re: string initialization question.
On Fri, 30 Jul 2010 12:46:20 -0400, bearophile
wrote:
Steven Schveighoffer:
> char[] divider = new char[5];
> divider[] = '-';
That assigns 0xff to all divider chars, and then assigns '-'. I think
there's a way to do it without the initial assignment.
I was wrong, I looked through the runtime and did not find such a function.
I think I may have read it in my copy of TDPL that I reviewed.
In any case, I think D deserves a way to do that.
In past there was some way to do that:
typedef char mchar = '-';
mchar[] divider = new mchar[5];
As a way to initialize an array, this is horrible :)
Now you have to initialize the dynamic array two times (using a char
struct with alias this is probably not a good idea).
I have shown this problem, but I think Walter was not interested. Maybe
LDC will able to optimize away the first initialization, I have an
enhancement request for LLVM.
I think a function to do it is fine, like makeArray('-', 5);
-Steve
xfbuild, optlink and pragma(lib)
Hi,
I wanted to create an simple wrapper around SDL. After my simple first
steps, I wanted to create a simple application using my wrapper. That's it:
///
module test;
import std.stdio;
import mysdl.system;
//pragma(lib,r"Path\to\SDL\lib\libSDLmain.a");
pragma(lib,r"Path\to\SDL\lib\libSDL.dll.a");
void main() {
initAll(); //Init all SDL-subsystems
}
I tried to compile it using
xfbuild test.d +full +xstd +xcore -debug -I.. +v +o=test
(-I.. -> there is mysdl)
That doesn't work! It doesn't create any executable but there's no
error. Because xfbuild -v doesn't show the linker-command either I tried
to reproduce it myself. It seems that optlink is the problem because it
does nothing but shows no errormessages.
When I comment out the pragma(lib) optlink fails (correctly) and xfbuild
crashes (:-(). Then I call optlink myself with libsdl.dll.a and it
creates a corrupt exe without errormessages.
Please help me. It seems that there are bugs over bugs. I don't konw
what to do.
I use Windows 7, dmd (2.047), xfbuild with cmd/powershell.
PS: I know there's Derelict but wanted to create this myself as a task
for learning D.
Re: string initialization question.
On Friday, July 30, 2010 10:14:45 Steven Schveighoffer wrote:
> I think a function to do it is fine, like makeArray('-', 5);
Well, creating a function for producing an array literal and returning it using
templates and string mixins wouldn't be all that hard, but if you want to
create
a dynamic array of arbitrary size at runtime, that's not going to work, and a
makeArray() function would have exactly the same tools that you have to create
an array of all the same value. So, it's not going to be any more efficient
that
what you can do.
int[] a = new int[](x);
a[] = val;
_should_ be fairly easily optimized by the compiler and thus really should be
optimized down to an initialization rather than an initialization and an
assignment.
A makeArray() function wouldn't hurt any, but I don't think that it would
really
buy us much. Of course, truth be told, I've always thought that the ability to
construct a string or vector in C++ all of a single value was pretty useless.
Obviously, some people find it useful at least once in a while, but I've never
had much use for it. A makeArray() function would probably still be a good
thing
to have, but what we really need here is either a syntactic way to do it or for
the compiler to optimize out the useless initialization (as well as inline
makeArray()) so that you don't have to deal with the extra cost of setting
everything twice.
- Jonathan M Davis
Re: string initialization question.
On Fri, 30 Jul 2010 15:56:36 -0400, Jonathan M Davis
wrote:
On Friday, July 30, 2010 10:14:45 Steven Schveighoffer wrote:
I think a function to do it is fine, like makeArray('-', 5);
Well, creating a function for producing an array literal and returning
it using
templates and string mixins wouldn't be all that hard, but if you want
to create
a dynamic array of arbitrary size at runtime, that's not going to work,
and a
makeArray() function would have exactly the same tools that you have to
create
an array of all the same value.
The function would call gc_malloc directly, which does not initialize the
requested memory. Actually, it would call a new run time function that I
will write, which would initialize the array length also.
So, it's not going to be any more efficient that
what you can do.
int[] a = new int[](x);
a[] = val;
_should_ be fairly easily optimized by the compiler and thus really
should be
optimized down to an initialization rather than an initialization and an
assignment.
It's not. The only runtime functions available to the compiler look like
this:
_d_newarrayT(TypeInfo ti, size_t length);
-Steve
Re: string initialization question.
Jonathan M Davis: > a makeArray() function would have exactly the same tools that you have to > create > an array of all the same value. So, it's not going to be any more efficient > that > what you can do. Doesn't the D2 GC give you a lower level function to GC-allocate uninitialized memory? The GC in D1 has such function, so in D1 it's easy to create a makeArray(). Bye, bearophile
Re: string initialization question.
Dnia 30-07-2010 o 17:24:41 dcoder napisał(a):
Is there anyway in D to convenient fill a string variable with a char
say X times?
If you need to only print, you can:
import std.stdio;
import std.range;
void main() {
foreach (c; take(repeat('-'), 5))
write(c);
}
I know, I know, you said *convenient* ;) I heard write(ln) is to print
arbitrary ranges, so this'd come down to:
writeln(take(repeat('-'), 5));
and if universal call syntax worked correctly then even this would be
possible:
writeln('-'.repeat.take(5));
much easier to type.
BTW, I stumbled on this when crafting the example:
http://d.puremagic.com/issues/show_bug.cgi?id=4537
Tomek
Re: string initialization question.
Dnia 30-07-2010 o 22:15:50 Tomek Sowiński napisał(a):
writeln('-'.repeat.take(5));
Oh, and if repeat had slicing (as it should)... '-'.repeat[0..5]
Still, it's far cry from Python's '-' * 5
Tomek
Re: string initialization question.
On Friday, July 30, 2010 13:10:46 Steven Schveighoffer wrote:
> On Fri, 30 Jul 2010 15:56:36 -0400, Jonathan M Davis
>
> wrote:
> > On Friday, July 30, 2010 10:14:45 Steven Schveighoffer wrote:
> >> I think a function to do it is fine, like makeArray('-', 5);
> >
> > Well, creating a function for producing an array literal and returning
> > it using
> > templates and string mixins wouldn't be all that hard, but if you want
> > to create
> > a dynamic array of arbitrary size at runtime, that's not going to work,
> > and a
> > makeArray() function would have exactly the same tools that you have to
> > create
> > an array of all the same value.
>
> The function would call gc_malloc directly, which does not initialize the
> requested memory. Actually, it would call a new run time function that I
> will write, which would initialize the array length also.
Well, if there's a function other than new to allocate GC memory, then
makeArray() is quite doable. I've never dealt with anything but new. As far as
I've been aware, you either use new for GC memory or malloc for non-GC memory.
If there's a gc_malloc, then that would solve the problem and it would make
good
sense to do that with makeArray().
>
> > So, it's not going to be any more efficient that
> > what you can do.
> >
> > int[] a = new int[](x);
> > a[] = val;
> >
> > _should_ be fairly easily optimized by the compiler and thus really
> > should be
> > optimized down to an initialization rather than an initialization and an
> > assignment.
>
> It's not. The only runtime functions available to the compiler look like
> this:
>
> _d_newarrayT(TypeInfo ti, size_t length);
I guess that's one thing that comes of not really implementing it as a
primitive. If there are enough such functions that would be properly
optimizable
had they actually been implemented as primitives, I would think that there
would
be some merit in finding a way to get the compiler to understand that it can do
such optimizations. But I really don't know how all that works in dmd, so I
have
no idea how feasible that is.
- Jonathan M Davis
Re: string initialization question.
On Fri, 30 Jul 2010 16:31:49 -0400, Jonathan M Davis wrote: On Friday, July 30, 2010 13:10:46 Steven Schveighoffer wrote: It's not. The only runtime functions available to the compiler look like this: _d_newarrayT(TypeInfo ti, size_t length); I guess that's one thing that comes of not really implementing it as a primitive. If there are enough such functions that would be properly optimizable had they actually been implemented as primitives, I would think that there would be some merit in finding a way to get the compiler to understand that it can do such optimizations. But I really don't know how all that works in dmd, so I have no idea how feasible that is. To be clear, the compiler could do the optimization if it had another runtime function to call. But since there is *no* runtime function that allocates a new array and initializes it with a custom initial element, how do you make a primitive? So if the function exists, the compiler can be fixed to make the sequence of "create then assign" a primitive, but I think just a runtime function is good enough, and will work without compiler changes. -Steve
Re: string initialization question.
== Quote from Jonathan M Davis (jmdavisp...@gmail.com)'s article > A makeArray() function wouldn't hurt any, but I don't think that it would > really > buy us much. Of course, truth be told, I've always thought that the ability to > construct a string or vector in C++ all of a single value was pretty useless. > Obviously, some people find it useful at least once in a while, but I've never > had much use for it. A makeArray() function would probably still be a good > thing > to have, but what we really need here is either a syntactic way to do it or > for > the compiler to optimize out the useless initialization (as well as inline > makeArray()) so that you don't have to deal with the extra cost of setting > everything twice. > - Jonathan M Davis If I'm writing a program that pretty prints tree data, or output of sql, like Oracle's sqlplus, or postgres equivalent, I find having such a utility function/constructor a pretty handy feature. I don't know where such a tool should finally be placed in D, but I having it available as a library or as part of the language would be great. It seems like a lot of other languages have it like python, perl, C++, and Java. So it can't be that useless.
Re: string initialization question.
> > > I don't know where such a tool should finally be placed in D, but I having > it > available as a library or as part of the language would be great. It seems > like a > lot of other languages have it like python, perl, C++, and Java. So it > can't be > that useless. > There is fill() in std.algorithm, but it needs an already present range... auto s = new int[5]; fill(s, 10); s is now [10,10,10,10,10]
Re: string initialization question.
On Friday, July 30, 2010 14:13:15 dcoder wrote: > If I'm writing a program that pretty prints tree data, or output of sql, > like Oracle's sqlplus, or postgres equivalent, I find having such a > utility function/constructor a pretty handy feature. > > I don't know where such a tool should finally be placed in D, but I having > it available as a library or as part of the language would be great. It > seems like a lot of other languages have it like python, perl, C++, and > Java. So it can't be that useless. Well, I certainly have no problem with a function like makeArray() existing. It's just that it's one of those functions that I've never found useful, and I don't think that I've ever seen anyone use it in code. Now, for strings, I find such a function to be a bit dangerous since it's ignoring the fact that char is a UTF-8 code unit rather than an ASCII value, but for other types of arrays, that wouldn't be a problem. And for strings, you could either use dstrings or just be certain that all of your characters are actually a single code unit. But I certainly wouldn't want the equivalent of having a string constructor that takes a char and a count like C++'s string does. It would be fine in many cases, but string functions that take chars are generally asking for trouble due to unicode issues. But since, string in D is an array rather than a class, that's not really a problem in the same way. makeArray() being for arrays in general rather than specifically strings would not promote bad string code in the same way that C++'s string constructor does. - Jonathan M Davis
Re: string initialization question.
On Fri, 30 Jul 2010 16:30:17 -0700, Jonathan M Davis wrote: > On Friday, July 30, 2010 14:13:15 dcoder wrote: > > If I'm writing a program that pretty prints tree data, or output of sql, > > like Oracle's sqlplus, or postgres equivalent, I find having such a > > utility function/constructor a pretty handy feature. > > > > I don't know where such a tool should finally be placed in D, but I having > > it available as a library or as part of the language would be great. It > > seems like a lot of other languages have it like python, perl, C++, and > > Java. So it can't be that useless. > > Well, I certainly have no problem with a function like makeArray() existing. > It's just that it's one of those functions that I've never found useful, and > I > don't think that I've ever seen anyone use it in code. I agree with this sentiment. I think the feature is pretty niche to begin with, and the compiler should be able to optimize out the initialization in the sample I gave previously. D is indeed a systems language, but I (and I'm sure others) would like to use it in a high- level way, where I can write natural, straightforward code and expect the compiler to do the Right Thing. Besides, performance is not an applicable argument for this use case. Even if the array initialization is compiled into the binary, the amount of time it would take is infinitesimal. If someone's trying to initialize a 100,000 element array to some specific value, they're likely going to write their own makeArray() anyways.
