Is there anyway to work around this compiler problem temporarily? Thanks.
/dmd/linux/bin/../bin/../../src/phobos/std/traits.d(1011): Error: static
assert "Type const(int) does not have an Unsigned counterpart"
/dmd/linux/bin/../bin/../../src/phobos/std/traits.d(2454): Error: template
instance st
dennis luehring wrote:
> On 24.04.2009 08:24, dennis luehring wrote:
>> dennis luehring schrieb:
>>> Andrei Alexandrescu schrieb:
dennis luehring wrote:
> Andrei Alexandrescu schrieb:
>> does that also mean that strings are getting template based?
>>
>> what amount of debug-code will pro
On Thu, 23 Apr 2009 13:58:38 +0300, Andrei Alexandrescu
wrote:
[snip]
Yes please. D's GC sometimes just gets in the way, and you end up managing
most memory manually.
Just don't forget to have a version(nogc) !
--
Best regards,
Vladimir mailto:thecybersha...@g
Thanks for reading through it!
bearophile wrote:
Robert Fraser:
Attached, if you don't mind NO comments.
This is your code, I can see you have not used the union trick to reduce the
memory used by each node that I suggested you:
private static struct TreeNode
{
On Fri, 24 Apr 2009 11:57:45 -0400, Andrei Alexandrescu
wrote:
Christian Kamm wrote:
Andrei Alexandrescu Wrote:
1. Put array definitions in object.d. Have the compiler rewrite "T[]"
->
".Array!(T)" and "[ a, b, c ]" -> ".Array!(typeof(a))(a, b, c)". I
think
superdan suggested that when
Robert Fraser:
> Attached, if you don't mind NO comments.
This is your code, I can see you have not used the union trick to reduce the
memory used by each node that I suggested you:
private static struct TreeNode
{
TreeNode* left;
TreeNode* right;
bearophile wrote:
Robert Fraser:
I implemented a version of the TST you posted using Tango + D1... Here
are my results:
Nice.
Is your TST a map? (not a set).
Yes, it's a map (for my use case).
Are you willing to show me your TST code? Your code is surely better than mine,
and there can be
On 24.04.2009 08:24, dennis luehring wrote:
dennis luehring schrieb:
Andrei Alexandrescu schrieb:
dennis luehring wrote:
Andrei Alexandrescu schrieb:
does that also mean that strings are getting template based?
what amount of debug-code will produce this? like with the stl (or
boost) - zilli
Christian Kamm wrote:
Andrei Alexandrescu Wrote:
1. Put array definitions in object.d. Have the compiler rewrite "T[]" ->
".Array!(T)" and "[ a, b, c ]" -> ".Array!(typeof(a))(a, b, c)". I think
superdan suggested that when he wasn't busy cursing :o).
While I'd support such a rewriting of buil
Robert Fraser:
> I implemented a version of the TST you posted using Tango + D1... Here
> are my results:
Nice.
Is your TST a map? (not a set).
Are you willing to show me your TST code? Your code is surely better than mine,
and there can be few little things that can be tuned.
And are you also w
Andrei Alexandrescu wrote:
There shouldn't be any harm in using Array or AssocArray directly.
How about __Array or something? I already have a struct Array!()
Andrei Alexandrescu Wrote:
> 1. Put array definitions in object.d. Have the compiler rewrite "T[]" ->
> ".Array!(T)" and "[ a, b, c ]" -> ".Array!(typeof(a))(a, b, c)". I think
> superdan suggested that when he wasn't busy cursing :o).
While I'd support such a rewriting of builtin arrays and assoc
Robert Fraser wrote:
bearophile wrote:
Does someone has some need for Ternary Search Trees into Phobos (for
D1. And eventually later for D2 too)?
TSTs allow to find keys, key prefixes, or even keys with holes. Keys
are arrays of T, where T is the template type.
They can be designed to store the
bearophile wrote:
Does someone has some need for Ternary Search Trees into Phobos (for D1. And
eventually later for D2 too)?
TSTs allow to find keys, key prefixes, or even keys with holes. Keys are arrays
of T, where T is the template type.
They can be designed to store the keys alone, or as an
Denis Koroskin Wrote:
> First, I can't import Foo, because it will lead to name collision. It means
> that I have no access to enum Bar and its elements.
For me no name collision happens when I import Foo, only enum is forward
referenced, here you are safe to declare function with int parameter
Thanks.
I had not really thought about efficiency of the scanner with regards to
realtime usage, and you are proberbly right about scanning/lexing on a
line by line basis. Maybe the right thing to do, is to write a custom
scanner that accomodates that. I was trying to avoid this however,
beca
On Fri, 24 Apr 2009 08:47:49 +0400, Daniel Keep
wrote:
Andrei Alexandrescu wrote:
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Joel C. Salomon wrote:
Just as (1) & (2) point to a way to remove the “magic” of built-in
arrays & hash-tables, so too might (5) & (6) point to a way of
replac
Andrei Alexandrescu Wrote:
> 1. Create one heap object of type T with creation arguments args.
> Currently: new T(args), except when T is a variable-sized array in which
> case syntax is new T[arg] (only one arg allowed). It is next to
> impossible to create one heap object of fixed-size array
Sean Kelly Wrote:
> I've always been careful to say that array and
> AA operations will leak if linked against this lib.
You can remove leaking operations from druntime and leaking application won't
link.
Vincenzo Romano wrote:
...
> It's 2009Q2 now.
> The comparison is still not a comparison at all by just showing the D
features.
> If you want to attract more programmers to D you need to show HIGH QUALITY
code (snippets) in, say,
> D, C++, Java ... you choose.
> You need to show the value.
Did y
20 matches
Mail list logo
