This sounds excellent.
Daniel Keep wrote:
Andrei Alexandrescu wrote:
Michel Fortin wrote:
On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
said:
It's also arguable that all functions in std.string should take
const(char)[]. Or, you know, const(T)[], since D supports encodings
other than UTF-8, despite what std.s
Daniel Keep wrote:
> How do you define 'tolower' on non-characters?
How do you define it for characters? I -> ı or I -> i?
'tolower' is a complicated, locale-dependent operation, not at all
analogous to finding a substring. It belongs in a different part of the
library or in a different library
Daniel Keep Wrote:
>
>
> Andrei Alexandrescu wrote:
> > Michel Fortin wrote:
> >> On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
> >> said:
> >>
> It's also arguable that all functions in std.string should take
> const(char)[]. Or, you know, const(T)[], since D supports encodings
>
bearophile Wrote:
> grauzone:
>
> > I see two things a dotnet implementation of D could have over native D:
> > - better garbage collector (the D one barely does its job...)
>
> The dotnet GC is probably better than the current D GC, but I think it's
> designed for mostly movable objects. Curre
Andrei Alexandrescu wrote:
> Michel Fortin wrote:
>> On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
>> said:
>>
It's also arguable that all functions in std.string should take
const(char)[]. Or, you know, const(T)[], since D supports encodings
other than UTF-8, despite what std
Lionello Lunesu wrote:
"Andrei Alexandrescu" wrote in message
news:h5ndt0$1bl...@digitalmars.com...
bearophile wrote:
Walter Bright:
Under the hood, a T[new] will be a single pointer to a library
defined type. This library defined type will likely contain three
properties:
I have another
== Quote from bearophile (bearophileh...@lycos.com)'s article
> Walter Bright:
> > Under the hood, a T[new] will be a single pointer to a library defined
> > type. This library defined type will likely contain three properties:
> I have another question: are there some performance penalities in usi
"Andrei Alexandrescu" wrote in message
news:h5ndt0$1bl...@digitalmars.com...
bearophile wrote:
Walter Bright:
Under the hood, a T[new] will be a single pointer to a library defined
type. This library defined type will likely contain three properties:
I have another question: are there some
Mon, 10 Aug 2009 01:56:35 +0200, Michiel Helvensteijn wrote:
> Walter Bright wrote:
>
>>> But I know, unique isn't easy to implement to fit all the use cases we'd
>>> like to solve. I'm just sharing a dream.
>>
>> We explored unique at length, and trying to make it work would render
>> the rest
On Sun, 09 Aug 2009 14:21:31 -0700, Walter Bright
wrote:
bearophile wrote:
2. make arrays implementable on .net
I don't care of such thing. dotnet already has C# and C# is probably
better than D, and it's similar anyway. So I don't think people will
use D on dotnet. So even if creating a D
Walter Bright wrote:
>> But I know, unique isn't easy to implement to fit all the use cases we'd
>> like to solve. I'm just sharing a dream.
>
> We explored unique at length, and trying to make it work would render
> the rest of the language nearly unusably complex.
I've heard 'unique' mentioned
Michel Fortin wrote:
But I know, unique isn't easy to implement to fit all the use cases we'd
like to solve. I'm just sharing a dream.
We explored unique at length, and trying to make it work would render
the rest of the language nearly unusably complex.
Michel Fortin wrote:
On 2009-08-09 14:10:10 -0400, Andrei Alexandrescu
said:
But shouldn't they work with *ranges* in general, a string being only
a specific case?
That's true as well! In my dreams, me and the famous actress... oh
wait, wrong dream. In my dreams, I eliminate std.string and
On 2009-08-09 16:29:21 -0400, Walter Bright said:
D has a number of subtle problems (performance and semantic) that arise
when arrays are resized. The solution is to separate resizeable array
types from slices. Slices will retain the old:
T[] slice;
syntax. Resizeable arrays will be dec
Walter Bright, el 9 de agosto a las 13:29 me escribiste:
> D has a number of subtle problems (performance and semantic) that arise
> when arrays are resized. The solution is to separate resizeable array
> types from slices. Slices will retain the old:
>
>T[] slice;
>
> syntax. Resizeable arr
Stewart Gordon wrote:
Moreover, would whatever happens solve such const/invariant holes as bug
2093?
Just what happens to the ~= operator anyway? Right now, it appends data
inline.
My vote would be to make "a~=b" do the same as "a=a~b" (with types "T[]
a" and "T[] b" or "T b"). T[new]'s ~=
Stewart Gordon wrote:
Walter Bright wrote:
Under the hood, a T[new] will be a single pointer to a library defined
type. This library defined type will likely contain three properties:
size_t length;
T* ptr;
size_t capacity;
The usual array operations will work on T[new] as well a
Walter Bright wrote:
Under the hood, a T[new] will be a single pointer to a library defined
type. This library defined type will likely contain three properties:
size_t length;
T* ptr;
size_t capacity;
The usual array operations will work on T[new] as well as T[].
Would new T[1
Daniel Keep wrote:
It's not ambiguous. Tokens are matched with maximal munch meaning that
/* is ALWAYS the opening of a multi-line comment.
Actually, it isn't always maximal munch - for example, 2..3 tokenises as
2 .. 3 rather than 2. .3. But you're right about comment syntax.
Stewart.
grauzone:
> I see two things a dotnet implementation of D could have over native D:
> - better garbage collector (the D one barely does its job...)
The dotnet GC is probably better than the current D GC, but I think it's
designed for mostly movable objects. Currently most (or all) D objects are
bearophile wrote:
2. make arrays implementable on .net
I don't care of such thing. dotnet already has C# and C# is probably
better than D, and it's similar anyway. So I don't think people will
use D on dotnet. So even if creating a D for dotnet can be positive,
I don't want D2 to change its des
bearophile wrote:
2. make arrays implementable on .net
I don't care of such thing. dotnet already has C# and C# is probably better
than D, and it's similar anyway. So I don't think people will use D on dotnet.
So even if creating a D for dotnet can be positive, I don't want D2 to change
its
Now there are four ways to create/use "arrays" in D2:
- the * syntax on a raw memory block, like in C.
- fixed sized arrays, that are just a pointer somewhere. they may even become
fully value types
- the slice struct, about 2 * size_t.sizeof
- the new reference arrays, a pointer on the st
Reply to bearophile,
Walter Bright:
2. make arrays implementable on .net
I don't care of such thing. dotnet already has C# and C# is probably
better than D,
I beg to differ. D is much better than c# in many ways (D's abstraction tools
are WAY better; C#'s end at reflection and generics, b
bearophile wrote:
Walter Bright:
I like this general proposal, it sounds like something that can improve D a
little. There are many other things that have to be improved in D, but baby
steps are enough to go somewhere :-)
Slices will retain the old:
T[] slice;
syntax. Resizeable arrays w
Brad Roberts wrote:
Walter Bright wrote:
Brad Roberts wrote:
Yay. What will happen with slices over a T[new] when the underlying
T[new] must
be moved due to resizing? The behavior needs to be at least well
specified, if
not well defined.
Great question! It's no different from what happens wi
bearophile wrote:
Walter Bright:
Under the hood, a T[new] will be a single pointer to a library defined
type. This library defined type will likely contain three properties:
I have another question: are there some performance penalities in using such
arrays for normal random access operations
Walter Bright wrote:
> Brad Roberts wrote:
>> Yay. What will happen with slices over a T[new] when the underlying
>> T[new] must
>> be moved due to resizing? The behavior needs to be at least well
>> specified, if
>> not well defined.
>
> Great question! It's no different from what happens with
Walter Bright:
I like this general proposal, it sounds like something that can improve D a
little. There are many other things that have to be improved in D, but baby
steps are enough to go somewhere :-)
>Slices will retain the old:
> T[] slice;
> syntax. Resizeable arrays will be declared
Walter Bright:
> Under the hood, a T[new] will be a single pointer to a library defined
> type. This library defined type will likely contain three properties:
I have another question: are there some performance penalities in using such
arrays for normal random access operations?
Bye,
bearophil
grauzone wrote:
will
T[new] a;
allocate something?
Nope.
Or will the allocation of the hidden library array
object delayed until the length is set to non null?
Yes.
If the library array
object is not allocated, will a.ptr, a.capacity and a.length simply
return null?
Yes. Clearly, tho
By the way, T[new] is Andrei's idea, as well as it being his idea to
make it a reference type.
That's great. I think this would finally fix some of the more pressing
issues of D.
I have a question:
will
T[new] a;
allocate something? Or will the allocation of the hidden library array
object delayed until the length is set to non null? If the library array
object is not allocated, will
Brad Roberts wrote:
Yay. What will happen with slices over a T[new] when the underlying T[new] must
be moved due to resizing? The behavior needs to be at least well specified, if
not well defined.
Great question! It's no different from what happens with any container
when its contents change
On 2009-08-09 14:10:10 -0400, Andrei Alexandrescu
said:
But shouldn't they work with *ranges* in general, a string being only a
specific case?
That's true as well! In my dreams, me and the famous actress... oh
wait, wrong dream. In my dreams, I eliminate std.string and put all of
its algor
Yay. What will happen with slices over a T[new] when the underlying T[new] must
be moved due to resizing? The behavior needs to be at least well specified, if
not well defined.
Walter Bright wrote:
> D has a number of subtle problems (performance and semantic) that arise
> when arrays are resize
D has a number of subtle problems (performance and semantic) that arise
when arrays are resized. The solution is to separate resizeable array
types from slices. Slices will retain the old:
T[] slice;
syntax. Resizeable arrays will be declared as:
T[new] array;
The new expression:
n
grauzone:
>Then what is there to complain?<
I have paid for 2 GB RAM, so I am allowed to desire a 1800 MB array :-)
>You know you must check return values.<
In real programs I check the return value of malloc, of course.
>The D allocation probably fails due to memory fragmentation (just a gue
On Sun, Aug 9, 2009 at 11:25 AM, grauzone wrote:
> Bill Baxter wrote:
>>
>> Interesting thing I found out about C# properties.
>> The syntax
>>
>> int Thing {
>> get { return _thing; }
>> set { _thing = value; }
>> }
>>
>> is rewritten by the C# compiler into
>>
>> int prop_Thing() { return _th
bearophile wrote:
Frank Benoit:
Is it the malloc that fails (returning null) or the handling of the block?<
It's the filling of the memory block. malloc by itself doesn't crash.
Then what is there to complain? You know you must check return values.
The D allocation probably fails due to mem
Bill Baxter wrote:
Interesting thing I found out about C# properties.
The syntax
int Thing {
get { return _thing; }
set { _thing = value; }
}
is rewritten by the C# compiler into
int prop_Thing() { return _thing; }
void prop_Thing(int value) { _thing = value; }
Just thought it was inter
Johan Granberg wrote:
Michel Fortin wrote:
On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
said:
It's also arguable that all functions in std.string should take
const(char)[]. Or, you know, const(T)[], since D supports encodings
other than UTF-8, despite what std.string leads you to believ
Michel Fortin wrote:
On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
said:
It's also arguable that all functions in std.string should take
const(char)[]. Or, you know, const(T)[], since D supports encodings
other than UTF-8, despite what std.string leads you to believe.
Yah, I think they
Michel Fortin wrote:
> On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
> said:
>
>>> It's also arguable that all functions in std.string should take
>>> const(char)[]. Or, you know, const(T)[], since D supports encodings
>>> other than UTF-8, despite what std.string leads you to believe.
>>
>
On 2009-08-09 11:10:48 -0400, Andrei Alexandrescu
said:
It's also arguable that all functions in std.string should take
const(char)[]. Or, you know, const(T)[], since D supports encodings
other than UTF-8, despite what std.string leads you to believe.
Yah, I think they should all be paramete
Eljay:
>Should larger sizes have reserved keywords? Or are those larger sizes just
>too ludicrously large to worry about?<
Today a CPU can perform an operation like ucent & ucent using the single SSE2
instruction PAND (_mm_and_si128 on GCC).
A 128 bit unsigned number may look of little use if
As cent/ucent, should a keyword be reserved for 256? 512? 1024?
- - - - - - - - - - - - - - -
Most programming languages are loathe to add new keywords, because that has the
chance to impact existing code.
So the time to add keywords for D 2.0(alpha) is now, since the language is in
alpha.
Jarrett Billingsley wrote:
On Sun, Aug 9, 2009 at 9:34 AM, Andrei
Alexandrescu wrote:
Jos van Uden wrote:
Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
(Don't tell anyone, but I plan to rewrite it.)
Andrei
This do
On Sun, Aug 9, 2009 at 9:34 AM, Andrei
Alexandrescu wrote:
> Jos van Uden wrote:
>>
>> Andrei Alexandrescu wrote:
>>>
>>>
>>> http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
>>>
>>> (Don't tell anyone, but I plan to rewrite it.)
>>>
>>> Andrei
>>
>> T
Jos van Uden wrote:
Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
(Don't tell anyone, but I plan to rewrite it.)
Andrei
This doesn't compile:
string[] words = split(strip(line));
it has to be
string[] words = s
Frank Benoit:
>Is it the malloc that fails (returning null) or the handling of the block?<
It's the filling of the memory block. malloc by itself doesn't crash.
-
Robert Fraser:
> Have you tried with DMC?<
I have done a test with MDC too now.
// D code
import std.c.stdlib:
Jos van Uden wrote:
Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
(Don't tell anyone, but I plan to rewrite it.)
Andrei
This doesn't compile:
string[] words = split(strip(line));
it has to be
string[] words = s
On 2009-08-09 00:23:06 -0400, Bill Baxter said:
Dang I remembered wrong from what I read yesterday. C# turns it into
int get_Thing() { return _thing; }
void set_Thing(int value) { _thing = value; }
I don't recall anyone proposing exactly that for D. There was
prop_Thing, and there was getTh
bearophile wrote:
I don't think so, I am running a 32 bit GCC on a 32 bit XP operating system.
I think the bug is elsewhere (in DMD).
Have you tried with DMC?
Frank Benoit:
>Is it the malloc that fails (returning null) or the handling of the block?<
The malloc, as I have written. But only when used by DMD.
Jeremie Pelletier:
> Your C program probably compiled in 64bit, which has MUCH more room for
> virtual memory.
I don't thi
bearophile schrieb:
> In a small program on Windows XP I have to allocate a large chunk of
> RAM, about 1847 MB of RAM. This PC has 2 GB RAM. So I use
> std.c.stdio.malloc(), with DMD v1.042 (or v2.031). But it's not able
> to allocate it, and produces at runtime: Error: Access Violation
>
> An eq
Andrei Alexandrescu wrote:
http://www.reddit.com/r/programming/comments/975ng/diving_into_the_d_programming_language_tdpl/
(Don't tell anyone, but I plan to rewrite it.)
Andrei
This doesn't compile:
string[] words = split(strip(line));
it has to be
string[] words = split(strip(line.idup)
58 matches
Mail list logo
