Time ago I have heard that "enum" is useless and const/immutable
suffice.
AFAIK it wasn't clear, it was said that we adopted this usage of "enum"
just because of some bugs in "const/immutable" but we also know "enum" and
"immutable" have difference(s), especially related to this issue. We c
Andrei Alexandrescu wrote:
> Hello,
>
>
> It is my great pleasure to announce that the GSoC 2011 selection
> process has turned favorably for us. Cristi Cobzarenco, David
> Nadlinger, and Dmitry Olshansky have been selected to occupy the
> three slots that Google assigned to Digital Mars.
>
> Pl
On Apr 26, 11 07:25, bearophile wrote:
KennyTM~:
Also, if the precondition were complaining, and you change some bit of
the code and find it can be compiled -- that won't mean anything, as it
is likely the change just make the precondition non-CTFE-able.
You are right, this is bad. But the co
On Tue, 26 Apr 2011 00:03:31 +0200, Andrei Alexandrescu
wrote:
Hello,
It is my great pleasure to announce that the GSoC 2011 selection process
has turned favorably for us. Cristi Cobzarenco, David Nadlinger, and
Dmitry Olshansky have been selected to occupy the three slots that
Google
bearophile wrote:
Given that pre-conditions are meant to run fast and to be (nearly)
pure, this is my idea: when you call a function with all arguments
known at compile time (as at the r3 variable) the compiler runs just
the pre-condition of that function at compile-time (and not its body
and pos
Daniel Gibson:
> Does it support exceptions on Windows?
> AFAIK that wasn't supported in older LLVM versions (and thus in LDC).
I have just tried it with this (fixing the output):
https://alioth.debian.org/scm/viewvc.php/*checkout*/shootout/bench/except/except.gcc?revision=1.1.1.1&root=shootout
Am 26.04.2011 03:59, schrieb bearophile:
> LLVM 2.9 is out (since some days), and for the first time Clang is available
> for Windows.
>
> It compiles C++ code too, with Clang++.
Does it support exceptions on Windows?
AFAIK that wasn't supported in older LLVM versions (and thus in LDC).
LLVM 2.9 is out (since some days), and for the first time Clang is available
for Windows. Beside normal warnings has a "--analyze" option that performs more
static tests on the code. Being a young feature it's surely not as powerful as
a lint (as split, that's free, splint.org ), but it's better
KennyTM~:
> Also, if the precondition were complaining, and you change some bit of
> the code and find it can be compiled -- that won't mean anything, as it
> is likely the change just make the precondition non-CTFE-able.
You are right, this is bad. But the compile-time interpreter is getting a
On 4/25/11 4:20 PM, Kim D wrote:
On 04/25/2011 10:06 AM, Iain Buclaw wrote:
I was thinking of where one implements an alternative runtime that may
not
necessarily interface with a GC, or has different semantics on the use of
the
keyword (the compiler, after all, doesn't know/care what exactly 'd
Hello,
It is my great pleasure to announce that the GSoC 2011 selection process
has turned favorably for us. Cristi Cobzarenco, David Nadlinger, and
Dmitry Olshansky have been selected to occupy the three slots that
Google assigned to Digital Mars.
Please join me in congratulating the three
On Apr 26, 11 03:44, bearophile wrote:
Given that pre-conditions are meant to run fast and to be (nearly) pure, this
is my idea: when you call a function with all arguments known at compile time
(as at the r3 variable) the compiler runs just the pre-condition of that
function at compile-time (
> On 04/25/2011 10:06 AM, Iain Buclaw wrote:
>> I was thinking of where one implements an alternative runtime that may
>> not
>> necessarily interface with a GC, or has different semantics on the use of
>> the
>> keyword (the compiler, after all, doesn't know/care what exactly 'delete'
>> does,
On Apr 26, 11 03:44, bearophile wrote:
[-
Little box:
Time ago I have heard that "enum" is useless and const/immutable suffice. So if
"enum" gets removed from D how do you tell apart the desire to run a function (not a
global call) at compile time from the desire to run it at
Only reason using "enum, static, immutable" over "auto" should be
"making sure" it runs at compile-time (again, if it can).
Besides the obvious reason, making it immutable :)
On Mon, 25 Apr 2011 22:44:07 +0300, bearophile
wrote:
This is a possible enhancement request for DMD. I am not sure about the
consequences of this, so this is currently not in Bugzilla, I look for
opinions.
DMD currently runs functions at compile time only if their call is in a
context
This is a possible enhancement request for DMD. I am not sure about the
consequences of this, so this is currently not in Bugzilla, I look for opinions.
DMD currently runs functions at compile time only if their call is in a context
where a compile-time value is expected, to avoid troubles. C++0
Don:
> Top bug reporters:
> bearophile: 482
Some of them are enhancement requests and not true bugs... and recently some of
them are just Phobos bugs.
Bye,
bearophile
bearophile wrote:
dsimcha:
How a statistics library could possibly be so good for
finding compiler bugs that the test suites miss, I'll never know.
I have found several bugs even writing 20-lines long programs.
Bye,
bearophile
"Several", huh?
Top bug reporters:
bearophile: 482
David Simch
Here's another implementation:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=56018
On Apr 24, 2011, at 1:17 PM, Andrei Alexandrescu wrote:
>
> It is much better in very many ways, in particular in D. For one simple
> argument, consider:
>
> auto obj = new Widget;
>
> Simple modularity considerations would require this operator to have
> semantics independent of Widget, such
On Apr 24, 2011, at 7:25 PM, Robert Jacques wrote:
>
> To the best of my knowledge, for 'small' allocations, the current GC uses
> free-lists of power-of-2 sized blocks. (I think small is defined as anything
> under 4k)
That's correct.
bearophile:
> I don't need a perfect language, but I fail to understand why
> similar little pieces of trash are wanted in any language.
It's probably meant to make interaction with C a little easier. In
C, arrays and pointers are interchangeable in a lot of places. It'd
make D code look more like
Steven Schveighoffer:
> simpler language spec/compiler :)
Here there are several people that use D that find surprising things in a tiny
piece of code, and discuss about it with many posts. This is the best
demonstration that this is a special case that adds complexity to the language,
that ne
Daniel Gibson:
> No. Casting other structs (*not* pointer to struct) is in fact illegal.
> (This just occured to me, I didn't think of this when writing the other
> post)
Right, sorry.
> So my only remaining objection is: Allowing it doesn't hurt (IMHO) and
> disallowing may break existing code
On 4/24/11 10:53 AM, Adam D. Ruppe wrote:
KennyTM~ wrote:
I think these should be static functions?
At first my idea was free functions, but getOverloads only works with
classes, so I pasted them in without really thinking about it.
But yes, I think you're right.
BTW, you toy example is way
On Mon, 25 Apr 2011 13:40:30 -0400, Daniel Gibson
wrote:
Am 25.04.2011 19:30, schrieb bearophile:
Daniel Gibson:
So why not just leave it the way it is?
It muds the semantic of the language, adding another special case. I
think the right (right = shared with other structs) semantics he
Am 25.04.2011 19:30, schrieb bearophile:
> Daniel Gibson:
>
>> So why not just leave it the way it is?
>
> It muds the semantic of the language, adding another special case. I think
> the right (right = shared with other structs) semantics here is to return the
> address of the length field.
>
On Mon, 25 Apr 2011 12:55:38 -0400, Andrej Mitrovic
wrote:
Isn't it dangerous to pass a D string and let the C code overwrite the
string, regardless of char* vs .ptr field?
Yes. Using sprintf is dangerous regardless of what language you are
using. It is advised to use D equivalents.
-
On Mon, 25 Apr 2011 12:47:20 -0400, Daniel Gibson
wrote:
Am 25.04.2011 17:36, schrieb Steven Schveighoffer:
On Mon, 25 Apr 2011 11:26:57 -0400, Vladimir Panteleev
wrote:
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 2
Daniel Gibson:
> So why not just leave it the way it is?
It muds the semantic of the language, adding another special case. I think the
right (right = shared with other structs) semantics here is to return the
address of the length field.
My experience based seeing it happen again and again te
Isn't it dangerous to pass a D string and let the C code overwrite the
string, regardless of char* vs .ptr field?
Am 25.04.2011 17:36, schrieb Steven Schveighoffer:
> On Mon, 25 Apr 2011 11:26:57 -0400, Vladimir Panteleev
> wrote:
>
>> On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
>> wrote:
>>
>>> On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighof
On Mon, 25 Apr 2011 18:42:32 +0300, Steven Schveighoffer
wrote:
Regardless of all this, cast(char *)buffer is *not* recommended D code,
and will likely fail in some future 2.x version of the compiler.
I'm pretty sure I learned of this trick from reading some Phobos code.
Perhaps this beh
On Mon, 25 Apr 2011 15:26:44 +0300, Piotr Szturmaj
wrote:
In my Postgres implementation SELECT result is an Input Range, since
Forward Range implies position saving and that's possible only with
cursors.
I think we could loosely follow .NET approach where each client has
separate class
On 04/25/2011 10:06 AM, Iain Buclaw wrote:
I was thinking of where one implements an alternative runtime that may not
necessarily interface with a GC, or has different semantics on the use of the
keyword (the compiler, after all, doesn't know/care what exactly 'delete' does,
it
just does it's jo
On Mon, 25 Apr 2011 11:39:28 -0400, Steven Schveighoffer
wrote:
On Mon, 25 Apr 2011 11:26:57 -0400, Vladimir Panteleev
wrote:
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveig
On 25/04/2011 16:26, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a char *. He should
jus
On 25/04/2011 16:36, Steven Schveighoffer wrote:
Try it.
I thought that "feature" was removed from D2? Just tested it, and it's
definitely not removed yet. But it will be :)
-Steve
Thanks for putting my mind at ease, I just spent ten minutes writing
various variations and disassembling them
On Mon, 25 Apr 2011 11:26:57 -0400, Vladimir Panteleev
wrote:
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a
On Mon, 25 Apr 2011 11:26:57 -0400, Vladimir Panteleev
wrote:
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a
On Mon, 25 Apr 2011 18:21:16 +0300, Robert Clipsham
wrote:
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a char *. He should
just use buffer.ptr.
Casting a string to char*
On 25/04/2011 15:56, Vladimir Panteleev wrote:
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a char *. He should
just use buffer.ptr.
Casting a string to char* is exactly the same as using the .ptr
property, as far as genera
== Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article
> On 04/24/2011 08:08 PM, Iain Buclaw wrote:
> > == Quote from Timon Gehr (timon.g...@gmx.ch)'s article
> >> Andrei Alexandrescu wrote:
> >>> I am sorry, you simply have no case - each and every argument you put
> >>> forth
On Mon, 25 Apr 2011 17:19:12 +0300, Steven Schveighoffer
wrote:
The problem the OP has is he is casting buffer to a char *. He should
just use buffer.ptr.
Casting a string to char* is exactly the same as using the .ptr property,
as far as generated code is concerned.
--
Best regards,
On Sun, 24 Apr 2011 17:22:39 -0400, dsimcha wrote:
On 4/24/2011 5:22 PM, Justin Hanekom wrote:
Hi all,
I have what should be an *extremely* simple question that Im banging my
head against: how to use
sprintf to format something to a string.
I have tried:
import std.stdio;
...
aut
On Tue, 19 Apr 2011 07:25:06 +, Lars T. Kyllingstad wrote:
> As announced a week ago, the formal review process for David Simcha's
> std.parallelism module is now over, and it is time to vote over whether
> the module should be included in Phobos. See below for more information
> on the modul
Alex Khmara wrote:
On Mon, 25 Apr 2011 12:16:19 +0300, Piotr Szturmaj
wrote:
Alex Khmara wrote:
Second variant is a kind of ORM, and I think it will be too highlevel
for
many cases. But I understand that for web framework it's interesting
direction. As for standard D library, I would like to
On Mon, 25 Apr 2011 12:16:19 +0300, Piotr Szturmaj
wrote:
Alex Khmara wrote:
Second variant is a kind of ORM, and I think it will be too highlevel
for
many cases. But I understand that for web framework it's interesting
direction. As for standard D library, I would like to have something
Alex Khmara wrote:
Second variant is a kind of ORM, and I think it will be too highlevel for
many cases. But I understand that for web framework it's interesting
direction. As for standard D library, I would like to have something more
generic and traditional. Probably, something modeled from Per
"YES"
--
Simen
51 matches
Mail list logo
