The Anh Tran:
> This is just a small D exercise. I port c++ knucleotide from
> shootout.alioth.debian.org
This was my version, maybe it solves some of your problems:
http://shootout.alioth.debian.org/debian/benchmark.php?test=knucleotide&lang=gdc&id=2
I haven't used my dlibs here, so for example
This is just a small D exercise. I port c++ knucleotide from
shootout.alioth.debian.org
Issue 1:
If i manually listing hashtable contents, the key does exist in that ht.
But (key in hash_table) always yield null.
Worse, if i use: "auto val = ht[key]", an exception is thrown.
Problem code is fr
Don wrote:
BCS wrote:
Hello Ary,
Don wrote:
Phil Deets wrote:
On Mon, 28 Dec 2009 16:18:46 -0500, Simen kjaeraas
wrote:
Apart from C legacy, is there a reason to assume anything we don't
know what
is, is an int? Shouldn't the compiler instead say 'unknown type' or
something
else that ma
Today PCs have lot of RAM, so reducing the memory used by a program may seem
not so important, but practice shows that reducing the memory used by a program
reduces the cache traffic and increases cache coherence, so the code runs
faster (I have recently seen a 13X speedup in a not synthetic pro
Michael P.:
>Also, would short unsigned int be a 'ushort' then?<
In D ushort is an unsigned integer 16 bits long. While I think in C short
unsigned int is not guaranteed to be 16 bit wide. The same is true for unsigned
short / uint.
Bye,
bearophile
BCS Wrote:
> Hello Michael P.,
>
> > I'm converting some C headers into D, and had some questions.
> > 1. What is the equivalent of a 'short int' in D?
> > e.g:
> > struct ScePspSRect {
> > short int x;
> > short int y;
> > short int w;
> > short int h;
> > }
>
> short
>
> > 3.
> > type
Hello Michael P.,
I'm converting some C headers into D, and had some questions.
1. What is the equivalent of a 'short int' in D?
e.g:
struct ScePspSRect {
short int x;
short int y;
short int w;
short int h;
}
short
3.
typedef uint8_t u8;
typede
I'm converting some C headers into D, and had some questions.
1. What is the equivalent of a 'short int' in D?
e.g:
struct ScePspSRect {
short int x;
short int y;
short int w;
short int h;
}
2. If I have this union in C:
typedef union ScePsp
Stewart Gordon wrote:
Don wrote:
I think we could get the behaviour you want by changing the definition
of T.init. I think it should ALWAYS be a bug to read an uninitialized
variable;
All variables in D are initialized, unless overridden with a void
initializer. But what would "ALWAYS be
Don wrote:
I think we could get the behaviour you want by changing the definition
of T.init. I think it should ALWAYS be a bug to read an uninitialized
variable;
All variables in D are initialized, unless overridden with a void
initializer. But what would "ALWAYS be a bug" mean?
(a) Trig
Steven Schveighoffer schrieb:
You are right, I asked the question on that thread of whether it was
worth keeping struct literals for this purpose.
And the answer (created by bearophile): http://codepad.org/8HnF62s2
Yeah, I know but if you got that data out of some file like the resource
sec
grauzone schrieb:
First the anti-feature: [0xAB, ...] will yield an int[], not a ubyte[]
(I guess ubyte[] is what you're expecting). If you cast two arrays, the
compiler will reinterpret cast all data. The result won't be what you
intended.
Yeah I already encountered that problem. That's why
BCS wrote:
Hello Ary,
Don wrote:
Phil Deets wrote:
On Mon, 28 Dec 2009 16:18:46 -0500, Simen kjaeraas
wrote:
Apart from C legacy, is there a reason to assume anything we don't
know what
is, is an int? Shouldn't the compiler instead say 'unknown type' or
something
else that makes sense?
Steven Schveighoffer wrote:
On Mon, 28 Dec 2009 21:52:24 -0500, Don wrote:
Steven Schveighoffer wrote:
Whether you like it or not, the runtime must initialize it to
something, even if the value means "uninitialized".
The key question is: is it valid to read an uninitialized variable? I
wou
Hello Ary,
Don wrote:
Phil Deets wrote:
On Mon, 28 Dec 2009 16:18:46 -0500, Simen kjaeraas
wrote:
Apart from C legacy, is there a reason to assume anything we don't
know what
is, is an int? Shouldn't the compiler instead say 'unknown type' or
something
else that makes sense?
C++ abandone
Hello Don,
Simen kjaeraas wrote:
Apart from C legacy, is there a reason to assume anything we don't
know
what
is, is an int? Shouldn't the compiler instead say 'unknown type' or
something
else that makes sense?
There's now an Error type in the compiler. It's gradually filtering
its way throug
Hello teo,
There was a way to define new types within templates and I think that
I have seen that demonstrated here in the newsgroups, but cannot find
it now. Can someone help me please?
I would like to do something like this:
template MyTemplate(T)
{
struct T ~ "Struct" // define FooStruct s
teo wrote:
There was a way to define new types within templates and I think that I
have seen that demonstrated here in the newsgroups, but cannot find it
now. Can someone help me please?
I would like to do something like this:
template MyTemplate(T)
{
struct T ~ "Struct" // define FooStruc
Trass3r wrote:
I got some RGB palette in a byte array which I'd like to convert or
"map" to an RGB struct array, isn't this easily possible without using
dozens of struct constructors?
RGB[256] PALETTE = cast(RGB[256]) [
0x00, 0x00, 0x00, 0xE3, 0x53, 0x00,
0xCF, 0x4B, 0x07, 0xBF, 0x43
There was a way to define new types within templates and I think that I
have seen that demonstrated here in the newsgroups, but cannot find it
now. Can someone help me please?
I would like to do something like this:
template MyTemplate(T)
{
struct T ~ "Struct" // define FooStruct structure
On Tue, 29 Dec 2009 17:44:18 -0500, teo
wrote:
There was a way to define new types within templates and I think that I
have seen that demonstrated here in the newsgroups, but cannot find it
now. Can someone help me please?
I would like to do something like this:
template MyTemplate(T)
{
s
On Tue, 29 Dec 2009 10:37:43 -0500, Steven Schveighoffer
wrote:
On Tue, 29 Dec 2009 10:03:50 -0500, Trass3r wrote:
Steven Schveighoffer schrieb:
What is RGB's structure?
I would expect something like this to work:
RGB[256] PALETTE = [
{0x00, 0x00, 0x00},
{0xE3, 0x53, 0x00},
...
];
Assu
On Tue, 29 Dec 2009 13:44:18 -0500, teo
wrote:
On Tue, 29 Dec 2009 09:12:15 -0500, Steven Schveighoffer wrote:
Eventually, marking Prop as a @property should also work (haven't tested
it, it may work now):
@property A Prop() { return a; }
...
b.Prop += 3; // compiles
-Steve
Unfortunat
On Tue, 29 Dec 2009 09:12:15 -0500, Steven Schveighoffer wrote:
> On Tue, 29 Dec 2009 09:10:14 -0500, Steven Schveighoffer
> wrote:
>
>> On Tue, 29 Dec 2009 09:01:38 -0500, teo
>> wrote:
>>
>>> Consider following:
>>>
>>> class A
>>> {
>>> int m;
>>> void opAddAssign(int n) { m += n; }
>>>
Don wrote:
Phil Deets wrote:
On Mon, 28 Dec 2009 16:18:46 -0500, Simen kjaeraas
wrote:
Apart from C legacy, is there a reason to assume anything we don't
know what
is, is an int? Shouldn't the compiler instead say 'unknown type' or
something
else that makes sense?
C++ abandoned default
On Tue, 29 Dec 2009 07:37:42 +0100, Don wrote:
Simen kjaeraas wrote:
Apart from C legacy, is there a reason to assume anything we don't know
what
is, is an int? Shouldn't the compiler instead say 'unknown type' or
something
else that makes sense?
There's now an Error type in the compile
On Tue, 29 Dec 2009 10:03:50 -0500, Trass3r wrote:
Steven Schveighoffer schrieb:
What is RGB's structure?
I would expect something like this to work:
RGB[256] PALETTE = [
{0x00, 0x00, 0x00},
{0xE3, 0x53, 0x00},
...
];
Assuming RGB is a struct of 3 ubyte members...
Yeah, simply 3 ubytes.
Steven Schveighoffer schrieb:
What is RGB's structure?
I would expect something like this to work:
RGB[256] PALETTE = [
{0x00, 0x00, 0x00},
{0xE3, 0x53, 0x00},
...
];
Assuming RGB is a struct of 3 ubyte members...
Yeah, simply 3 ubytes.
But IIRC I read that struct literals will be removed i
On Tue, 29 Dec 2009 09:10:14 -0500, Steven Schveighoffer
wrote:
On Tue, 29 Dec 2009 09:01:38 -0500, teo
wrote:
Consider following:
class A
{
int m;
void opAddAssign(int n) { m += n; }
}
class B
{
A a;
this() { a = new A; }
A Prop() { return a; }
}
void main()
{
B b = new B
On Tue, 29 Dec 2009 07:56:04 -0500, Trass3r wrote:
I got some RGB palette in a byte array which I'd like to convert or
"map" to an RGB struct array, isn't this easily possible without using
dozens of struct constructors?
RGB[256] PALETTE = cast(RGB[256]) [
0x00, 0x00, 0x00, 0xE3, 0x5
On Tue, 29 Dec 2009 09:01:38 -0500, teo
wrote:
Consider following:
class A
{
int m;
void opAddAssign(int n) { m += n; }
}
class B
{
A a;
this() { a = new A; }
A Prop() { return a; }
}
void main()
{
B b = new B;
b.Prop += 3;
}
I get a compilation error (dmd v2.037):
test.d(1
Just remembered the old casting hack:
RGB[] PALETTE = (cast(RGB*) cast(ubyte[]) [...])[0..256];
It works but is there perhaps another nicer possibility?
Consider following:
class A
{
int m;
void opAddAssign(int n) { m += n; }
}
class B
{
A a;
this() { a = new A; }
A Prop() { return a; }
}
void main()
{
B b = new B;
b.Prop += 3;
}
I get a compilation error (dmd v2.037):
test.d(17): Error: 'b.Prop' is not a scalar, it is a A()
test
I got some RGB palette in a byte array which I'd like to convert or
"map" to an RGB struct array, isn't this easily possible without using
dozens of struct constructors?
RGB[256] PALETTE = cast(RGB[256]) [
0x00, 0x00, 0x00, 0xE3, 0x53, 0x00,
0xCF, 0x4B, 0x07, 0xBF, 0x43, 0x0F, ...
doe
Don wrote:
Steven Schveighoffer wrote:
That value should always be consistent. There has to be a way to
verify that the value was set properly. Otherwise, how do you verify
things
like communication protocols or expectations for runtime functions?
I think that sending an uninitialized vari
On Mon, 28 Dec 2009 21:52:24 -0500, Don wrote:
Steven Schveighoffer wrote:
Whether you like it or not, the runtime must initialize it to
something, even if the value means "uninitialized".
The key question is: is it valid to read an uninitialized variable? I
would hope the compiler would
Phil Deets wrote:
On Mon, 28 Dec 2009 16:18:46 -0500, Simen kjaeraas
wrote:
Apart from C legacy, is there a reason to assume anything we don't
know what
is, is an int? Shouldn't the compiler instead say 'unknown type' or
something
else that makes sense?
C++ abandoned default int. I think
Simen kjaeraas wrote:
Apart from C legacy, is there a reason to assume anything we don't know
what
is, is an int? Shouldn't the compiler instead say 'unknown type' or
something
else that makes sense?
There's now an Error type in the compiler. It's gradually filtering its
way through the com
Ali Çehreli wrote:
bearophile wrote:
> Ali Çehreli:
>> auto s = S(1, 2);
Doesn't work for structs that have opCall (or maybe an opCall with
matching parameters to that use).
> And by the way, that's the idiomatic way to initialize a struct in D.
Excellent! That's the way I have chosen and
On Mon, 28 Dec 2009 16:18:46 -0500, Simen kjaeraas
wrote:
Apart from C legacy, is there a reason to assume anything we don't know
what
is, is an int? Shouldn't the compiler instead say 'unknown type' or
something
else that makes sense?
C++ abandoned default int. I think it would be bes
Steven Schveighoffer wrote:
On Mon, 28 Dec 2009 06:51:30 -0500, Don wrote:
Stewart Gordon wrote:
Steven Schveighoffer wrote:
Are you still working on this? :) I think this proves my point.
The compiler does not provide an easy way to compare floats bitwise,
so this means convoluted hard
Ali Ãehreli:
> As 'this' is not available in static member functions; you mean
Yes, of course, I am sorry. You know about D as much as me or more, so it's
time for me to shut up :-)
Bye,
bearophile
bearophile wrote:
> Ali Çehreli:
>
>> >> auto s = S(1, 2);
>>
>> Doesn't work for structs that have opCall (or maybe an opCall with
>> matching parameters to that use).
>
> Try:
> static S opCall(int x, int y) { this.x = x; this.y = y; }
As 'this' is not available in static member functions; you
bearophile wrote:
> This prints 42 0.00 with the latest dmd2 and 42 nan with an older
dmd1.
You are unlucky then... ;) The following program leaves random values in
s.d with dmd 2.037. Here is one output:
42 -0.008821
> It can be a bug:
Yes it is! :)
http://d.puremagic.com/issues/sh
Apart from C legacy, is there a reason to assume anything we don't know
what
is, is an int? Shouldn't the compiler instead say 'unknown type' or
something
else that makes sense?
--
Simen
On Mon, 28 Dec 2009 10:40:58 -0500, Ali Çehreli wrote:
One issue remains, which prompted me to open this thread in the first
place:
I wanted to experiment with defining opCall for that struct:
struct S
{
int x;
int y;
const int opCall(int p0, int p1)
{
return p
Ali Ãehreli:
> >> auto s = S(1, 2);
>
> Doesn't work for structs that have opCall (or maybe an opCall with
> matching parameters to that use).
Try:
static S opCall(int x, int y) { this.x = x; this.y = y; }
> I think the {} should still default initialize the
> remaining members (like C and
Steven Schveighoffer wrote:
[irrelevant text cut out]
...I'm having some difficulties. Consider this code:
---
struct Templ(int N,T){}
template Templ1(T)
{
alias Templ!(1,T) Templ1;
}
void foo2(T)(Templ1!T t){}
void main()
{
Templ1!(float) t1f1;
foo2(t1f1); // this doesn't com
bearophile wrote:
> Ali Çehreli:
>> auto s = S(1, 2);
Doesn't work for structs that have opCall (or maybe an opCall with
matching parameters to that use).
> And by the way, that's the idiomatic way to initialize a struct in D.
Excellent! That's the way I have chosen and have been using in my
On Thu, 24 Dec 2009 12:45:41 -0500, Stanislav Blinov
wrote:
Hello,
I'm trying to make a template that would be an alias to another template
instance (sort of a shortcut), but I'm having some difficulties.
Consider this code:
---
import std.stdio;
struct Templ(int N,T){}
alias Templ!
On Mon, 28 Dec 2009 06:51:30 -0500, Don wrote:
Stewart Gordon wrote:
Steven Schveighoffer wrote:
Are you still working on this? :) I think this proves my point. The
compiler does not provide an easy way to compare floats bitwise, so
this means convoluted hard-to-write code. When we ha
Stewart Gordon wrote:
Steven Schveighoffer wrote:
Are you still working on this? :) I think this proves my point. The
compiler does not provide an easy way to compare floats bitwise, so
this means convoluted hard-to-write code. When we have two operators
that do equality -- and one of tho
Ali Ãehreli:
> auto s = S(1, 2);
And by the way, that's the idiomatic way to initialize a struct in D.
If you want to statically initialize it, there are other ways I've shown you.
Bye,
bearophile
Phil Deets wrote:
On Thu, 24 Dec 2009 13:10:14 -0500, Phil Deets wrote:
On Thu, 24 Dec 2009 12:49:42 -0500, Richard Webb
wrote:
Sounds like you might be running into this:
http://d.puremagic.com/issues/show_bug.cgi?id=3342
Thanks for the link. That is probably my problem since I'm runnin
Ali Ãehreli:
> S s = { 1 };
>
> Not good; because we may forget to provide initializers and the
> remaining members are not even default initialized.
All fields get initialized, unless explicitly told to not be initialized (and
sometimes they get initialized even if you explicitly tell them t
Steven Schveighoffer wrote:
Are you still working on this? :) I think this proves my point. The
compiler does not provide an easy way to compare floats bitwise, so this
means convoluted hard-to-write code. When we have two operators that do
equality -- and one of those means bitwise compar
Coming from C++ and reading the D2 spec, I realized that I don't
understand struct construction yet. :) I am playing with dmd 2.037.
Considering
struct S
{
int x;
int y;
}
which may have a
this(int x, int y)
defined:
1)
S s = { 1 };
Not good; because we may forget to provide i
57 matches
Mail list logo
