On 27-05-2012 08:50, Era Scarecrow wrote:
Curiously I'm making a huffman compression algo for fun, however I
didn't see anything in std.array or anywhere that was to support bools
specifically (in a packed form anyways). So I'm making one. So far I've
got it saving the data as uint, 0 refers to t
Curiously I'm making a huffman compression algo for fun, however
I didn't see anything in std.array or anywhere that was to
support bools specifically (in a packed form anyways). So I'm
making one. So far I've got it saving the data as uint, 0 refers
to the most significant bit and 7 the least
On Sunday, 27 May 2012 at 03:29:17 UTC, dnewbie wrote:
In C I can write
OPENFILENAME ofn;
ZeroMemory(&ofn, sizeof(ofn));
In D, there is no ZeroMemory. Please help me.
You could use c memset:
import std.c.string;
memset(cast(void*)&ofn, 0, ofn.sizeof);
or this:
(cast(byte*)& a)[0 .. a.sizeo
In C I can write
OPENFILENAME ofn;
ZeroMemory(&ofn, sizeof(ofn));
In D, there is no ZeroMemory. Please help me.
On Saturday, 26 May 2012 at 18:40:53 UTC, maarten van damme wrote:
well, I was thinking about using a sieve but when you were to
request
prime 400_000 you're sieve would blow up in size.
Because you only need primes up to sqrt(n) to check if n is prime,
you can make a sieve based range that on
On 05/26/2012 05:13 PM, Ali Çehreli wrote:
> once you define toHash(), you
> must also define opCmp() and opEquals() that are all consistent with
> each other.
Correction: opEquals() is only for potential optimizations. What is
needed alongside toHash() is just opCmp(), and the reason is to be
On 05/26/2012 12:53 PM, Andrej Mitrovic wrote:
I don't understand this:
import std.stdio;
struct Symbol { string val; }
void main()
{
int[string] hash1;
hash1["1".idup] = 1;
hash1["1".idup] = 2;
writeln(hash1); // writes "["1":2]"
int[Symbol] hash2;
Symbol sym1
On 5/27/12, Era Scarecrow wrote:
> Problem goes
> away when not idup-ing, but likely that is the compiler saving
> space and assigning the same pointer address (which makes sense).
Yes, the .idup was done on purpose here for demonstration.
On Saturday, 26 May 2012 at 22:02:10 UTC, Jonathan M Davis wrote:
Now, that aside, the results with hash2 definitely look like a
bug to me. It's probably just the result of one more of the
many issues with the current AA implementation.
This is what I'm guessing too. I've made toHashes in my
On Sunday, May 27, 2012 00:08:01 Andrej Mitrovic wrote:
> On 5/27/12, Jonathan M Davis wrote:
> > Why can't you have a toHash in your struct?
>
> I mean it doesn't seem to make any difference:
Yeah. I don't know what the deal is. There's definitely at least one bug here,
if not several.
> impo
On 5/27/12, Jonathan M Davis wrote:
> Why can't you have a toHash in your struct?
I mean it doesn't seem to make any difference:
import std.stdio;
struct Foo
{
string x;
size_t toHash() { return 1; }
}
void main()
{
int[Foo] hash;
Foo foo1 = Foo("a".idup);
Foo foo2 = Foo("a
On Saturday, May 26, 2012 21:53:07 Andrej Mitrovic wrote:
> I don't understand this:
>
> import std.stdio;
>
> struct Symbol { string val; }
>
> void main()
> {
> int[string] hash1;
> hash1["1".idup] = 1;
> hash1["1".idup] = 2;
> writeln(hash1); // writes "["1":2]"
>
> int[
I don't understand this:
import std.stdio;
struct Symbol { string val; }
void main()
{
int[string] hash1;
hash1["1".idup] = 1;
hash1["1".idup] = 2;
writeln(hash1); // writes "["1":2]"
int[Symbol] hash2;
Symbol sym1 = Symbol("1".idup);
Symbol sym2 = Symbol("1".idup);
well, I was thinking about using a sieve but when you were to request
prime 400_000 you're sieve would blow up in size. That's why I opted
for something else (and I don't know if it was the right thing to do
though). (Ab)using opIndex like that is indeed a bit wrong but what
would be the alternativ
On Saturday, May 26, 2012 13:05:00 Jacob Carlborg wrote:
> On 2012-05-26 01:17, Jonathan M Davis wrote:
> >> Ok I see, thanks. Is that true for fields in structs and global
> >> variables as well?
> >
> > Anyway, I suppose that that's not terribly conclusive, but the lack of
> > ability to have no
On Saturday, 26 May 2012 at 13:49:53 UTC, maarten van damme wrote:
Is there an easy way to speed up or is this the
ceiling?
I got a 30 percent speedup by replacing this line:
if(&& canFind(quicktestPrimes, possiblePrime))
with this:
if(quicktestPrimes.back >= possiblePrime &&
canFind(qui
On 05/26/2012 03:49 PM, maarten van damme wrote:
I finally made the primerange I wanted to make. I think I'm using a
rather dumb algorithm. The idea is to store the prime we're at in
curPrime and the amount of preceding primes in countPrime. Then
opindex is able to calculate how many primes follo
I finally made the primerange I wanted to make. I think I'm using a
rather dumb algorithm. The idea is to store the prime we're at in
curPrime and the amount of preceding primes in countPrime. Then
opindex is able to calculate how many primes following or preceding
curPrime we have to find to get t
On Sat, May 26, 2012 at 12:39 PM, Tobias Pankrath wrote:
> I am writing a mixin template that uses alias parameters and should me
> instantiated in a class. With only one parameter, it works. But I fail with
> using multiple aliases as a tuple.
>
> This works:
>
> mixin template print(alias x) {
>
On 2012-05-26 01:17, Jonathan M Davis wrote:
Ok I see, thanks. Is that true for fields in structs and global
variables as well?
Anyway, I suppose that that's not terribly conclusive, but the lack of ability
to have non-transitive const declarations is a bit of a problem when dealing
with ex
I am writing a mixin template that uses alias parameters and
should me instantiated in a class. With only one parameter, it
works. But I fail with
using multiple aliases as a tuple.
This works:
mixin template print(alias x) {
void doprint() { writeln(x); }
}
class A { int x; mixin print!x
21 matches
Mail list logo
