I would much rather show a stacktrace to the user than "Unknown
error" or some other little usable message.
These two approaches do not conflict and Windows solves the
problem by combining them since... Windows 2000, I guess.
// Checks if two files have equal content using memory mapped
files
import std.file;
import std.mmfile;
import std.stdio;
// Compares the content of two files
private bool equals(in string f1, in string f2)
{
if (getSize(f1) != getSize(f2))
return false; // different fi
On Thursday, 31 January 2013 at 07:34:52 UTC, d coder wrote:
To be honest deque can be implemented far better if random
access as in
indexing, removal and such is dropped.
As other people too pointed out, Deque is indeed a random access
range, so indexing operator is a must. Insert/Remove too
On 01/31/2013 02:48 AM, bearophile wrote:
Steven Schveighoffer:
Hm... I thought deque's major draw was that it had O(1)
insertion/removal from the front and back, and ALSO had O(1) indexing.
Amortized O(1) insert/removal, and hard O(1) for indexing. And the
multiplicative constants must be l
On 01/31/2013 08:33 AM, d coder wrote:
To be honest deque can be implemented far better if random access as in
indexing, removal and such is dropped.
As other people too pointed out, Deque is indeed a random access
range, so indexing operator is a must. Insert/Remove too are good to
have. Array
On 01/31/2013 09:46 AM, monarch_dodra wrote:
On Thursday, 31 January 2013 at 07:34:52 UTC, d coder wrote:
To be honest deque can be implemented far better if random access as in
indexing, removal and such is dropped.
As other people too pointed out, Deque is indeed a random access
range, so in
On 01/31/2013 03:10 AM, TommiT wrote:
I think my former unholy union of namespace and variable is just too
confusing to reason about, so here's my new way of seeing effectively
the same thing, but with simpler semantics:
Keyword property is like the keyword struct, except:
1) properties can't h
On Wednesday, 30 January 2013 at 12:51:18 UTC, Simen Kjaeraas
wrote:
On 2013-01-30, 09:26, Don wrote:
The discussion we had on github agreed that std.halffloat
isn't a good place.
But OTOH std.numeric needs a complete overhaul, it's a mess.
It would be a mistake to throw it in there.
So put
Roumen Roupski:
private bool equals(in string f1, in string f2)
{
if (getSize(f1) != getSize(f2))
return false; // different file sizes
if (getSize(f1) == 0)
return true;// zero-length files are equal
Making equals() private is not useful,
On 2013-18-31 11:01, Don wrote:
std.numeric is not superficially flawed, it's fundamentally flawed. What
is it for? What is its theme? The problem is, std.numeric is one of the
few good names which are left as a possible package name, after C
insulted the mathematical community by creating
Don wrote:
> On Wednesday, 30 January 2013 at 12:51:18 UTC, Simen Kjaeraas wrote:
> >On 2013-01-30, 09:26, Don wrote:
> >
> >>The discussion we had on github agreed that std.halffloat isn't
> >>a good place.
> >>But OTOH std.numeric needs a complete overhaul, it's a mess.
> >>It would be a mistake
On Thursday, 31 January 2013 at 08:42:48 UTC, Roumen Roupski
wrote:
finally
{
delete m1;
delete m2;
}
D has a GC. No need for manual deletion.
(In fact, I think this is deprecated? Or scheduled for removal?
Or maybe neither. Who knows).
On Thu, Jan 31, 2013 at 2:43 PM, Robert burner Schadek
wrote:
> Thats not totally correct. The Rb tree is a class. But the real reason for
> the Deque being a class
> is that it holds two value members. And if you pass the Deque around you
> need to do this as ref.
> Otherwise you shall not call a
On Thursday, 31 January 2013 at 10:58:48 UTC, Peter Alexander
wrote:
On Thursday, 31 January 2013 at 08:42:48 UTC, Roumen Roupski
wrote:
finally
{
delete m1;
delete m2;
}
D has a GC. No need for manual deletion.
(In fact, I think this is
On Thursday, 31 January 2013 at 11:35:31 UTC, d coder wrote:
On Thu, Jan 31, 2013 at 2:43 PM, Robert burner Schadek
wrote:
Thats not totally correct. The Rb tree is a class. But the
real reason for
the Deque being a class
is that it holds two value members. And if you pass the Deque
around yo
On 2013-01-27 10:51, Brian Schott wrote:
I'm writing a D lexer for possible inclusion in Phobos.
DDOC:
http://hackerpilot.github.com/experimental/std_lexer/phobos/lexer.html
Code:
https://github.com/Hackerpilot/Dscanner/blob/range-based-lexer/std/d/lexer.d
It's currently able to correctly synt
On 01/31/2013 11:18 AM, Don wrote:
std.numeric is not superficially flawed, it's fundamentally flawed. What is it
for? What is its theme? The problem is, std.numeric is one of the few good names
which are left as a possible package name
std.numerical ... ?
On 2013-01-30 10:49, Brian Schott wrote:
Results:
$ avgtime -q -r 200 ./dscanner --tokenCount ../phobos/std/datetime.d
Total time (ms): 13861.8
Repetitions: 200
Sample mode: 69 (90 ocurrences)
Median time: 69.0745
Avg time : 69.3088
Std dev. : 0
On 2013-01-31 12:38, Namespace wrote:
If you want to do something, then take destroy.
AFAIK delete destroy _and_ release the memory immediately. 'destroy' doesn't.
And that's why delete is valuable (at least on 32-bit windows).
Especially when you are comparing 500 MB files in a loop. :)
On Thu, Jan 31, 2013 at 5:30 PM, monarch_dodra wrote:
> The pull is kind of stuck in limbo, specifically because of the problems
> associated with implementing reference semantics with structs :/
Thanks for the enlightening email.
I am of the considered view that reference semantics with struct
On 2013-01-31 13:14, Jacob Carlborg wrote:
Just thinking out loud here. Would it be possible to lex a file in parallel?
Cutting it in half (or similar) and lex both pieces simultaneously in parallel.
Do you know where you can safely cut it without having it lexed beforehand? :)
On Thursday, 31 January 2013 at 12:28:00 UTC, d coder wrote:
On Thu, Jan 31, 2013 at 5:30 PM, monarch_dodra
wrote:
The pull is kind of stuck in limbo, specifically because of
the problems
associated with implementing reference semantics with structs
:/
Thanks for the enlightening email.
I
On Thursday, 31 January 2013 at 12:28:43 UTC, FG wrote:
On 2013-01-31 12:38, Namespace wrote:
If you want to do something, then take destroy.
AFAIK delete destroy _and_ release the memory immediately.
'destroy' doesn't.
And that's why delete is valuable (at least on 32-bit windows).
Especiall
Am 31.01.2013 13:14, schrieb Jacob Carlborg:
On 2013-01-27 10:51, Brian Schott wrote:
I'm writing a D lexer for possible inclusion in Phobos.
DDOC:
http://hackerpilot.github.com/experimental/std_lexer/phobos/lexer.html
Code:
https://github.com/Hackerpilot/Dscanner/blob/range-based-lexer/std/d/l
On 01/31/2013 01:00 PM, monarch_dodra wrote:
On Thursday, 31 January 2013 at 11:35:31 UTC, d coder wrote:
On Thu, Jan 31, 2013 at 2:43 PM, Robert burner Schadek
wrote:
Thats not totally correct. The Rb tree is a class. But the real
reason for
the Deque being a class
is that it holds two value
On Thursday, 31 January 2013 at 12:28:43 UTC, FG wrote:
On 2013-01-31 12:38, Namespace wrote:
If you want to do something, then take destroy.
AFAIK delete destroy _and_ release the memory immediately.
'destroy' doesn't.
And that's why delete is valuable (at least on 32-bit windows).
Especiall
On Thursday, 31 January 2013 at 03:35:32 UTC, Zach the Mystic
wrote:
Now classes are a different kettle of fish.
Sorry for not being more explicit. Bjarne Stroustrup is the
creator of C++, so the Q&A I posted refers to C++, not D. But,
long story short, all of the Q&A is applicaple to D, as l
On 2013-01-31 13:35, dennis luehring wrote:
why not only the symbols at the border needs to be "connected" then
the question is: how many blocks(threads) are ok for 1,2,3,8 cores - can
also depend on the speed of the filesystem
That would require some profiling to figure out.
--
/Jacob Carlb
On 2013-01-31 13:34, FG wrote:
Do you know where you can safely cut it without having it lexed
beforehand? :)
I was thinking that myself. It would probably be possible to just cut it
in the middle and then lex a few characters forward and backwards until
you get a valid token. Try and calcul
On Thursday, 31 January 2013 at 09:39:06 UTC, Timon Gehr wrote:
auto v = t.myProp; // ?
I think it might be fine to allow copy-constructing 'properties',
passing them to functions by value or by reference, and such. So,
you could do:
void func(ref T.PropType v);
PropType v = t.myProp;
func
Am 31.01.2013 13:48, schrieb Jacob Carlborg:
On 2013-01-31 13:35, dennis luehring wrote:
why not only the symbols at the border needs to be "connected" then
the question is: how many blocks(threads) are ok for 1,2,3,8 cores - can
also depend on the speed of the filesystem
That would require
On Thursday, 31 January 2013 at 00:54:54 UTC, Steven
Schveighoffer wrote:
On Wed, 30 Jan 2013 03:05:37 -0500, q66
wrote:
On Wednesday, 30 January 2013 at 03:02:38 UTC, deadalnix wrote:
On Wednesday, 30 January 2013 at 00:26:11 UTC, q66 wrote:
It deeply disturbs me that people even take the o
On Thursday, 31 January 2013 at 12:28:43 UTC, FG wrote:
On 2013-01-31 12:38, Namespace wrote:
If you want to do something, then take destroy.
AFAIK delete destroy _and_ release the memory immediately.
'destroy' doesn't.
And that's why delete is valuable (at least on 32-bit windows).
Especiall
FG:
Especially when you are comparing 500 MB files in a loop. :)
I have had problems comparing with this program a single pair of
files that large...
Bye,
bearophile
On 1/31/13 5:18 AM, Don wrote:
std.numeric is not superficially flawed, it's fundamentally flawed. What
is it for? What is its theme? The problem is, std.numeric is one of the
few good names which are left as a possible package name, after C
insulted the mathematical community by creating a modul
On Wednesday, 30 January 2013 at 18:53:02 UTC, Paulo Pinto wrote:
Have you unblocked the file?
chm files can contain ActiveXs, so as security measure since
the XP security overall you need to explicitly allow chm files
that you downloaded to be secure.
Check the file properties.
Thanks for
On Thursday, 31 January 2013 at 12:44:18 UTC, TommiT wrote:
On Thursday, 31 January 2013 at 03:35:32 UTC, Zach the Mystic
wrote:
Now classes are a different kettle of fish.
Sorry for not being more explicit. Bjarne Stroustrup is the
creator of C++, so the Q&A I posted refers to C++, not D. Bu
On 2013-01-31 14:21, bearophile wrote:
Especially when you are comparing 500 MB files in a loop. :)
I have had problems comparing with this program a single pair of files that
large...
Strange. No problems here. Only had to switch from dmd32 to gdc64 with 1GB or
bigger files. Tested on win7-
On Thursday, 31 January 2013 at 13:58:44 UTC, Zach the Mystic
wrote:
I hope this isn't the final word on the topic.
I found this article which I think explains the reasoning behind
non-zero sized structs even better:
http://bytes.com/topic/c/insights/660463-sizeof-empty-class-structure-1-a
FG:
Strange. No problems here. Only had to switch from dmd32 to
gdc64 with 1GB or bigger files. Tested on win7-64.
How much memory is it using? What's the performance compared to
the diff tool?
Bye,
bearophile
On Thu, 31 Jan 2013 08:14:15 -0500, q66 wrote:
On Thursday, 31 January 2013 at 00:54:54 UTC, Steven Schveighoffer wrote:
On Wed, 30 Jan 2013 03:05:37 -0500, q66 wrote:
On Wednesday, 30 January 2013 at 03:02:38 UTC, deadalnix wrote:
On Wednesday, 30 January 2013 at 00:26:11 UTC, q66 wrote:
Now we're just name calling ;) I tend to think that for the
most successful company in the business to standardize on it is
a pretty good testimony to it being well designed.
This is a really bad argument. The facts that language is being
used by a large companies does not make it well design
On Thursday, 31 January 2013 at 12:58:13 UTC, TommiT wrote:
[..] So, it might be just as well to just disallow copying of
'properties' except when it happens as a part of copying the
enclosing object.
Or... maybe not, because disallowing making a copy of a property
variable makes it illegal t
On Thu, 31 Jan 2013 14:39:56 -, jerro wrote:
Now we're just name calling ;) I tend to think that for the most
successful company in the business to standardize on it is a pretty
good testimony to it being well designed.
This is a really bad argument. The facts that language is being u
On Wed, 30 Jan 2013 21:49:35 -0500, Zach the Mystic
wrote:
On Thursday, 31 January 2013 at 01:26:19 UTC, Steven Schveighoffer wrote:
The compromise is: OK, you want to ditch @property? I can live with
that as long as we have some way to designate properties. How about
this?
It's only
On Thu, 31 Jan 2013 09:39:56 -0500, jerro wrote:
Now we're just name calling ;) I tend to think that for the most
successful company in the business to standardize on it is a pretty
good testimony to it being well designed.
This is a really bad argument. The facts that language is being u
On Thursday, 31 January 2013 at 14:28:39 UTC, Steven
Schveighoffer wrote:
On Thu, 31 Jan 2013 08:14:15 -0500, q66
wrote:
On Thursday, 31 January 2013 at 00:54:54 UTC, Steven
Schveighoffer wrote:
On Wed, 30 Jan 2013 03:05:37 -0500, q66
wrote:
On Wednesday, 30 January 2013 at 03:02:38 UTC,
On Thu, 31 Jan 2013 07:27:08 -0500, d coder wrote:
On Thu, Jan 31, 2013 at 5:30 PM, monarch_dodra
wrote:
The pull is kind of stuck in limbo, specifically because of the problems
associated with implementing reference semantics with structs :/
Thanks for the enlightening email.
I am of th
On Thu, 31 Jan 2013 09:57:12 -0500, q66 wrote:
On Thursday, 31 January 2013 at 14:28:39 UTC, Steven Schveighoffer wrote:
As another option, what about changing my proposal so instead of setX,
it's set_x, and then casing concerns are eliminated? I think C++.net
does that.
-Steve
No, tha
On 1/31/13 3:46 AM, monarch_dodra wrote:
Quite frankly, I'm bringing more and more into question the fact that
everything in phobos are structs, especially considering the "no default
constructor" problem.
The containers in std.container pretty much emulate final classes via
pointers to payloads
On 1/31/13 10:03 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 07:27:08 -0500, d coder wrote:
On Thu, Jan 31, 2013 at 5:30 PM, monarch_dodra
wrote:
The pull is kind of stuck in limbo, specifically because of the problems
associated with implementing reference semantics with structs :/
On Thursday, 31 January 2013 at 14:47:17 UTC, TommiT wrote:
[..]
Although, it's just not very healthy to be passing those property
variables around, because it enables writing all kinds of bugs:
struct S
{
int n;
property Prop
{
@property int get() { return outer.n; }
On Thu, 31 Jan 2013 10:12:53 -0500, Andrei Alexandrescu
wrote:
On 1/31/13 10:03 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 07:27:08 -0500, d coder
wrote:
On Thu, Jan 31, 2013 at 5:30 PM, monarch_dodra
wrote:
The pull is kind of stuck in limbo, specifically because of the
pro
On 1/31/13 10:18 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 10:12:53 -0500, Andrei Alexandrescu
As far as I can tell classes have the same problem.
Nope.
void foo(someclass aa, int x, int y)
{
aa[x] = y;
}
void main()
{
someclass aa;
foo(aa, 1, 2); // segfault
...
}
We could easil
On 01/29/2013 10:26 PM, Walter Bright wrote:
valgrind is immensely useful for C, but a lot less so for D as D guarantees
initialization and a GC takes care of much of the rest.
On the subject of valgrind and D's garbage collection -- when I've run any D
program through valgrind's memory check,
On Thursday, 31 January 2013 at 15:21:02 UTC, Andrei Alexandrescu
wrote:
We could easily arrange things to segfault just the same with a
struct-based implementation.
Andrei
Not if you have a "lazy initialization scheme", which is the
current scheme we are using...
...and will probably co
On Thu, 31 Jan 2013 10:21:04 -0500, Andrei Alexandrescu
wrote:
On 1/31/13 10:18 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 10:12:53 -0500, Andrei Alexandrescu
As far as I can tell classes have the same problem.
Nope.
void foo(someclass aa, int x, int y)
{
aa[x] = y;
}
void main
On Thursday, 31 January 2013 at 15:12:52 UTC, Andrei Alexandrescu
wrote:
As far as I can tell classes have the same problem.
Andrei
Regarding classes, would there be any chance of being to create a
class instance that isn't a child of "object"?
I'm not entirely sure what the implications
On Thursday, 31 January 2013 at 13:41:13 UTC, Andrei Alexandrescu
wrote:
On 1/31/13 5:18 AM, Don wrote:
std.numeric is not superficially flawed, it's fundamentally
flawed. What
is it for? What is its theme? The problem is, std.numeric is
one of the
few good names which are left as a possible pa
On 1/31/13 10:27 AM, monarch_dodra wrote:
On Thursday, 31 January 2013 at 15:12:52 UTC, Andrei Alexandrescu wrote:
As far as I can tell classes have the same problem.
Andrei
Regarding classes, would there be any chance of being to create a class
instance that isn't a child of "object"?
Us
On 1/31/13 10:29 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 10:21:04 -0500, Andrei Alexandrescu
wrote:
On 1/31/13 10:18 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 10:12:53 -0500, Andrei Alexandrescu
As far as I can tell classes have the same problem.
Nope.
void foo(somec
On 2013-01-31 14:50:40 +, "Steven Schveighoffer"
said:
It actually is a bit depressing, we have to reset the clock back to
late 2009 to start over with properties...
I haven't participated in the discussions about properties this time
around because it's pretty obvious to me it's getti
On Thu, Jan 31, 2013 at 01:48:02PM +0100, Jacob Carlborg wrote:
> On 2013-01-31 13:34, FG wrote:
>
> >Do you know where you can safely cut it without having it lexed
> >beforehand? :)
>
> I was thinking that myself. It would probably be possible to just
> cut it in the middle and then lex a few c
On Thu, 31 Jan 2013 10:40:15 -0500, Andrei Alexandrescu
wrote:
On 1/31/13 10:29 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 10:21:04 -0500, Andrei Alexandrescu
wrote:
On 1/31/13 10:18 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 10:12:53 -0500, Andrei Alexandrescu
As far
On Thu, 31 Jan 2013 10:40:18 -0500, Michel Fortin
wrote:
On 2013-01-31 14:50:40 +, "Steven Schveighoffer"
said:
It actually is a bit depressing, we have to reset the clock back to
late 2009 to start over with properties...
By the way I was a big proponent of properties with no se
On 01/31/2013 04:11 PM, Andrei Alexandrescu wrote:
On 1/31/13 3:46 AM, monarch_dodra wrote:
Quite frankly, I'm bringing more and more into question the fact that
everything in phobos are structs, especially considering the "no default
constructor" problem.
The containers in std.container pretty
On Thursday, January 31, 2013 10:39:46 Andrei Alexandrescu wrote:
> On 1/31/13 10:27 AM, monarch_dodra wrote:
> > On Thursday, 31 January 2013 at 15:12:52 UTC, Andrei Alexandrescu wrote:
> >> As far as I can tell classes have the same problem.
> >>
> >>
> >> Andrei
> >
> > Regarding classes, wou
On 1/31/13 11:12 AM, Robert burner Schadek wrote:
struct Deque(T) {
struct Payload {
T* array;
size_t head, size;
size_t ref;
}
Payload* load;
~this() {
if(load !is null && (load.ref-=1) == 0) {
free(load);
}
}
Yes, that's the general pattern. I agree it's a pain but I also
understand that l
On 1/31/13 11:00 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 10:40:15 -0500, Andrei Alexandrescu
wrote:
It has a destructor.
One which is not called if allocated on the heap.
That is correct. My point was that with structs we get to implement
full-fledged reference counting for con
On 01/31/2013 05:16 PM, Andrei Alexandrescu wrote:
On 1/31/13 11:12 AM, Robert burner Schadek wrote:
struct Deque(T) {
struct Payload {
T* array;
size_t head, size;
size_t ref;
}
Payload* load;
~this() {
if(load !is null && (load.ref-=1) == 0) {
free(load);
}
}
Yes, that's the general patter
On 2013-01-31 16:54, H. S. Teoh wrote:
Doesn't work if the middle happens to be inside a string literal
containing code. Esp. a q{} literal (you wouldn't be able to tell where
it starts/ends without scanning the entire file, because the {}'s nest).
That would be a problem.
--
/Jacob Carlborg
On 2013-01-31 13:57, dennis luehring wrote:
i would say it "can" help alot so the design should be able to use
split-parts and combine symboles at the border
and also file-based lexing should be threadable so that 16 files can be
handled by my 16 cores system full in parallel :)
This is kind
On 2013-01-31 15:28, Steven Schveighoffer wrote:
Now we're just name calling ;) I tend to think that for the most
successful company in the business to standardize on it is a pretty good
testimony to it being well designed. I certainly have grown fond of it,
there are some really nice features
On 2013-01-31 15:56, Steven Schveighoffer wrote:
From what I remember Andrei saying, they write their code in C++ and
compile it to php, or something like that.
I'm pretty sure it's the opposite. PHP code compiles to C++.
"HipHop programmatically transforms your PHP source code into highly
o
On Thursday, 31 January 2013 at 16:17:09 UTC, Jonathan M Davis
wrote:
On Thursday, January 31, 2013 10:39:46 Andrei Alexandrescu
wrote:
On 1/31/13 10:27 AM, monarch_dodra wrote:
> On Thursday, 31 January 2013 at 15:12:52 UTC, Andrei
> Alexandrescu wrote:
>> As far as I can tell classes have th
On Jan 31, 2013, at 7:38 AM, "Don" wrote:
> But if it doesn't get to be at least ten times larger, some of this niche
> stuff shouldn't be in there, they are functions from LargePhobos. If we go
> with SmallPhobos then we need to move the niche stuff somewhere else.
If D had a package distribu
On Thursday, 31 January 2013 at 15:18:36 UTC, TommiT wrote:
[..] So, I guess properties need to be magic, [..]
So, going back to the concept of property as a crossbreed between
a namespace and a variable. Here's my new take on it:
* Property looks like a namespace when it is defined, and a
On 01/31/2013 03:56 PM, Steven Schveighoffer wrote:
...See PHP, for
example - a *horrible* mess of a language, but it is being used at
Facebook.
From what I remember Andrei saying, they write their code in C++ and
compile it to php, or something like that.
...
Other way round!
On Thursday, 31 January 2013 at 16:44:03 UTC, TommiT wrote:
T t;
foo(t.myProp); // foo(t.myProp.opGet());
auto v = t.myProp; // int v = t.myProp.opGet();
t.myProp = 41; // t.myProp.opAssign(41);
t.myProp += 1; // t.myProp.opAssign!"+"(41);
assert(t.myProp.isCorrect());
immutable T t2
On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
On Thursday, 31 January 2013 at 13:41:13 UTC, Andrei
Alexandrescu wrote:
On 1/31/13 5:18 AM, Don wrote:
std.numeric is not superficially flawed, it's fundamentally
flawed. What
is it for? What is its theme? The problem is, std.numeric is
On 1/31/13 10:38 AM, Don wrote:
The basic problem is that there are hundreds of potential numeric
algorithms and data structures of equal importance to these ones. In
fact, the total number of mathematical algorithms is probably a
substantial fraction of the total algorithms in computer science!
On 1/31/13 11:36 AM, Jacob Carlborg wrote:
On 2013-01-31 15:56, Steven Schveighoffer wrote:
From what I remember Andrei saying, they write their code in C++ and
compile it to php, or something like that.
I'm pretty sure it's the opposite. PHP code compiles to C++.
"HipHop programmatically tr
On 1/31/13 12:08 PM, Andrei Alexandrescu wrote:
I'm that team!
s/that/on that/
31-Jan-2013 19:11, Andrei Alexandrescu пишет:
On 1/31/13 3:46 AM, monarch_dodra wrote:
Quite frankly, I'm bringing more and more into question the fact that
everything in phobos are structs, especially considering the "no default
constructor" problem.
The containers in std.container pretty much
31-Jan-2013 05:34, Steven Schveighoffer пишет:
On Tue, 29 Jan 2013 15:08:36 -0500, Dmitry Olshansky
wrote
I skimmed through it what caught my eye instantly: this deque exposes
too much of operations that are not required of any deque. The end
result is that it's pretty much always have to be
On 1/31/13 12:16 PM, Dmitry Olshansky wrote:
Then the only layout left to propose is an array of blocks. Then
indexing is done like:
blocks[idx>>N][idx&mask]
if block size is power of 2. Not half-bad and still O(1).
Yah that's how C++'s deque is implemented. Blocks are of
statically-fixed size
On 1/31/13 12:12 PM, Dmitry Olshansky wrote:
IMHO we need both kinds of containers: small value semantics a-la STL
(with the usual samll string optimization and whatnot) and the large
bulky ones with clean reference semantics.
I don't see much use case for the small value semantics containers.
Andrei Alexandrescu:
Yah that's how C++'s deque is implemented. Blocks are of
statically-fixed size.
I think I have suggested a better solution.
Bye,
bearophile
On 2013-01-31 15:17, bearophile wrote:
FG:
Strange. No problems here. Only had to switch from dmd32 to gdc64 with 1GB or
bigger files. Tested on win7-64.
How much memory is it using? What's the performance compared to the diff tool?
Two identical files, 1069 MB each. Program compiled with G
On 01/31/2013 12:42 AM, Roumen Roupski wrote:
> catch (Throwable ex)
> {
> writefln("File read error: %s", ex.msg);
> return false; // cannot compare the files
Throwable is a little too high in the exception hierarchy:
Throwable
/ \
ErrorException
/ \ / \
A program sh
On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
I'm not sure that we can solve this without addressing the
high-level question: What is the scope of Phobos?
How big will it eventually get? Twice its current size? Ten
times? A hundred times?
Purely by chance I read an article on the
On Thu, 31 Jan 2013 11:17:14 -0500, Andrei Alexandrescu
wrote:
On 1/31/13 11:00 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 10:40:15 -0500, Andrei Alexandrescu
wrote:
It has a destructor.
One which is not called if allocated on the heap.
That is correct. My point was that with
On Thu, Jan 31, 2013 at 07:53:58PM +0100, Zach the Mystic wrote:
> On Thursday, 31 January 2013 at 15:38:04 UTC, Don wrote:
> >I'm not sure that we can solve this without addressing the
> >high-level question: What is the scope of Phobos?
> >
> >How big will it eventually get? Twice its current siz
31-Jan-2013 21:47, Andrei Alexandrescu пишет:
On 1/31/13 12:12 PM, Dmitry Olshansky wrote:
IMHO we need both kinds of containers: small value semantics a-la STL
(with the usual samll string optimization and whatnot) and the large
bulky ones with clean reference semantics.
I don't see much use
On Thursday, 31 January 2013 at 15:40:19 UTC, Michel Fortin wrote:
And you have to admit that the way D does properties today is
both simple, clever, and appealing. It does have some
error-prone liabilities when it comes to callable types and
generic programming especially, but beside that I do
On 1/31/2013 7:27 AM, Joseph Rushton Wakeling wrote:
On 01/29/2013 10:26 PM, Walter Bright wrote:
valgrind is immensely useful for C, but a lot less so for D as D guarantees
initialization and a GC takes care of much of the rest.
On the subject of valgrind and D's garbage collection -- when I'
31-Jan-2013 19:21, Andrei Alexandrescu пишет:
On 1/31/13 10:18 AM, Steven Schveighoffer wrote:
On Thu, 31 Jan 2013 10:12:53 -0500, Andrei Alexandrescu
As far as I can tell classes have the same problem.
Nope.
void foo(someclass aa, int x, int y)
{
aa[x] = y;
}
void main()
{
someclass aa;
fo
On Thursday, 31 January 2013 at 18:59:20 UTC, Steven
Schveighoffer wrote:
Structs by default are easily destroyed from the stack, but
lack the fundamental cogs to get GC-based destruction.
-Steve
Perhaps _d_newitemT() and buddies can check whether it creates
structs, store a collection of po
On Thursday, 31 January 2013 at 19:13:03 UTC, Zach the Mystic
wrote:
Here's the most concise quote which gives you the gist of the
thing:
"Now classes are a different kettle of fish. I haven't thought
them out and I don't think I need to. They may work seamlessly
with my idea or be fraught wi
30-Jan-2013 01:52, Dmitry Olshansky пишет:
Recap:
During a couple of rounds of the informal review new std.uni had its
docs happily destroyed, and later re-written based on the feedback.
[snip]
- Squeezed extra 31Kb slack from object-file size (32 bits, more on 64).
Now all of the packed tab
1 - 100 of 191 matches
Mail list logo
