On 2012-08-28 23:29, Walter Bright wrote:
I think there need to be explicit types in the doc so people can click
on a link to them and see what they are.
I should work with "auto" as well.
--
/Jacob Carlborg
On 2012-08-26 12:19, Manu wrote:
Looks good, though one thing annoys me as always throughout the D docs,
liberal use of auto can make them very difficult to understand.
auto result = hash.finish();
From the examples where this appears, I have absolutely no idea what
'result' could possibly be
Am Mon, 27 Aug 2012 19:46:57 +0200
schrieb "foobar" :
> The point was that there are _other_ motivating examples for
> annotations hence there's already popular demand for it. Which is
> why it's worth the added complexity to the language. In fact part
> of that complexity *already* exists in D
On 2012-08-28 21:27, Robert Clipsham wrote:
The body of the function has nothing to do with its type.
If I change the body of one of the functions the problem doesn't appear.
--
/Jacob Carlborg
Am Tue, 28 Aug 2012 22:08:11 -0700
schrieb Jonathan M Davis :
> On Wednesday, August 29, 2012 06:46:25 Tommi wrote:
> > The weird thing is that you can use a member access operator with
> > a pointer (without explicitly dereferencing the pointer first).
>
> Well, you clearly haven't done much poi
On Tuesday, 28 August 2012 at 23:34:54 UTC, Carl Sturtivant wrote:
On Tuesday, 28 August 2012 at 21:40:01 UTC, Timon Gehr wrote:
On 08/28/2012 10:33 PM, Carl Sturtivant wrote:
On Monday, 27 August 2012 at 00:44:54 UTC, Walter Bright
wrote:
On 8/26/2012 4:50 PM, Timon Gehr wrote:
On 08/27/2012
On 29 August 2012 04:31, Jonathan M Davis wrote:
> On Wednesday, August 29, 2012 01:13:15 Manu wrote:
> > On 28 August 2012 21:52, Andrei Alexandrescu
> >
> > wrote:
> > > On 8/28/12 8:23 AM, Manu wrote:
> > >> Well that's painful for a number of reasons..
> > >>
> > >> Other than the fact that I
On Tuesday, 28 August 2012 at 20:33:50 UTC, Carl Sturtivant wrote:
On Monday, 27 August 2012 at 00:44:54 UTC, Walter Bright wrote:
On 8/26/2012 4:50 PM, Timon Gehr wrote:
On 08/27/2012 12:41 AM, Walter Bright wrote:
The trouble for function pointers, is that any default args
would need
to b
On Wednesday, August 29, 2012 12:40:45 Manu wrote:
> I've conceded that I don't mind changing my code, if a satisfactory
> alternative exists (it doesn't currently). Also, I'd like to have some
> notice that I need to make some time to change the code, and the
> opportunity to work it into my sched
Caligo:
Did you time the runs?
I didn't time them. My timings (compiling with GHC -O3) are
similar to your ones.
If you want a better comparison, this Haskell code is closer to
the D/Python versions (the run-time is similar, maybe it's a bit
faster):
pick :: Int -> Int -> [String]
pick
On Wednesday, 29 August 2012 at 04:54:31 UTC, Tommi wrote:
On Wednesday, 29 August 2012 at 03:17:39 UTC, Era Scarecrow
I think that's right; Otherwise ref wouldn't be allowed in
@safe code (at all).
But couldn't the compiler disallow all unsafe ref use in @safe
code, and allow all use of ref
On Wednesday, 29 August 2012 at 02:57:27 UTC, Era Scarecrow wrote:
Assuming 'ref' works:
struct S {
ref int r;
}
//ref local variable/stack, Ticking timebomb
//compiler may refuse
void useRef(ref S input, int r) {
input.r = r;
}
I think we might be talking about somewhat differen
On Wednesday, 29 August 2012 at 07:00:06 UTC, Marco Leise wrote:
Am Mon, 27 Aug 2012 19:46:57 +0200
schrieb "foobar" :
The point was that there are _other_ motivating examples for
annotations hence there's already popular demand for it. Which
is why it's worth the added complexity to the langu
On Wednesday, 29 August 2012 at 12:41:26 UTC, Tommi wrote:
I think we might be talking about somewhat different things.
What I mean by reference variable is what the term means in
C++. From wikipedia:
http://en.wikipedia.org/wiki/Reference_%28C%2B%2B%29
C++ references differ from pointers in
Era Scarecrow wrote:
suggested new was the constructor & allocator, meaning you'd
have to have in depth detail of both steps in order to override
it later. Abstraction then is thrown away and the black box
method becomes a white/clear box method, encapsulation goes out
the window.
You raise
On Tue, 28 Aug 2012 04:57:53 -0400, Don Clugston wrote:
On 27/08/12 16:16, Steven Schveighoffer wrote:
On Sun, 26 Aug 2012 18:26:40 -0400, Manu wrote:
I just updated to 2.60 and found errors throughout my code where
function
pointers default args no longer work.
*Every single project* I'v
Actually, now that I think about it, there's an potentially
better way. Simply have static analysis do the work for us:
class A
{
int a;
this new() {
// if 'this = ...' is found before 'this.whatever' then
// the automatic allocation is overriden. So we have no need
// for any ki
On Wednesday, 29 August 2012 at 15:07:42 UTC, F i L wrote:
Actually, now that I think about it, there's an potentially
better way. Simply have static analysis do the work for us:
class A
{
int a;
this new() {
// if 'this = ...' is found before 'this.whatever' then
// the automatic a
*References cannot be null, whereas pointers can; every
reference refers to some object, although it may or may not be
valid. Note that for this reason, containers of references are
not allowed.
* References cannot be uninitialized. Because it is impossible
to reinitialize a reference, they m
On Wednesday, 29 August 2012 at 15:49:26 UTC, Namespace wrote:
*References cannot be null, whereas pointers can; every
reference refers to some object, although it may or may not be
valid. Note that for this reason, containers of references are
not allowed.
* References cannot be uninitialize
On Wednesday, 29 August 2012 at 14:17:21 UTC, Era Scarecrow wrote:
Then most of my examples change to going into the constructor
rather than out, and the global one goes away. But it still
doesn't help with the problem of anything stack allocated.
struct S {
//default construtor otherwise
The current possibility of UFCS is:
struct S { }
void func(S s) { }
S s;
s.func(); // equivalent of func(s);
why not add:
template sizeInInts(T)
{
enum sizeInInts = T.sizeof / 4;
}
S.sizeInInts // equivalent of sizeInInts!S
Is it worth it? I mean adding static members to aggregate types.
Piotr Szturmaj wrote:
and instead of writing hash!SHA1("abc"), write SHA1.hash("abc");
Another example:
template MutablePointer(T)
{
alias PointerTarget!(Unqual!T) MutablePointer;
}
alias const(int) CInt;
static assert(is(MutablePointer!CInt == int*));
Alternativ
Am Tue, 28 Aug 2012 11:37:48 +0200
schrieb "sidhu gaikwad" :
> On Tuesday, 28 August 2012 at 09:21:55 UTC, Chris wrote:
> > Probably this question has been asked and answered before, but
> > I wonder if there is a way to cross-compile D code so that you
> > can work on one platform and simultane
You may want to try/read this:
http://ddili.org/ders/d.en/
Thanks to Ali for this fantastic book!!! Looking forward for the next
translations.
On 25.08.2012 22:37, timotheecour wrote:
Is there a "best practices" page on this site to use as reference for
those FAQ, that AFAIK are not in the d
The voting ends today, time to count the votes.
With the result of 6 YES votes vs 1 NO std.digest package is accepted
for inclusion into Phobos.
Congratulations, Johannes.
---
Still, there is one thing that bothers me.
Of few issues that were found (and addressed) during voting there is o
On 08/29/2012 01:53 PM, notna wrote:
> You may want to try/read this:
>
> http://ddili.org/ders/d.en/
>
> Thanks to Ali for this fantastic book!!! Looking forward for the next
> translations.
Thank you notna. :) Although, I don't have the exact answers that
timotheecour is looking for.
I have
Am Wed, 29 Aug 2012 13:56:12 +0200
schrieb "bearophile" :
> It runs the (8, 13) case (40_489 solutions) in less than half
> second, about eleven times faster than the Haskell version.
>
> I think the Haskell run-time is re-using some thunks of precedent
> lazy computations, so I think Haskell i
On Wednesday, 29 August 2012 at 15:07:42 UTC, F i L wrote:
Actually, now that I think about it, there's an potentially
better way. Simply have static analysis do the work for us:
class A
{
int a;
this new() {
// if 'this = ...' is found before 'this.whatever' then
// the automatic a
Marco Leise:
Haskell isn't half
bad with the optimizing compiler. The native efficiency is
comparable to D until you really start to optimize.
Lot of people say similar things, but saying it again and again
doesn't make them true. So far I have seen no evidence of this.
The few times where
On Wednesday, 29 August 2012 at 19:55:08 UTC, Tommi wrote:
I honestly don't know anything about memory safety and what it
entails. So, I can't comment about any of that stuff. But if
you say general ref variables can't be implemented in @safe
mode, then I can just take your word for it. But wha
On Tuesday, 28 August 2012 at 22:53:46 UTC, bearophile wrote:
The purpose of this post of mine is to compare a nice looking
Haskell solution of this problem to its Python/D translation.
This means this post is about language design matters and it's
not about problem solving :-)
...
There is
Peter Alexander:
In general, it is not possible to have both full expressiveness
and full performance.
The ShedSkin compiler has shown me that in some important cases
this is not true. But even if in this case you are right, I am OK
with that, because I write both performance-critical D code
On Wednesday, 29 August 2012 at 21:37:33 UTC, Era Scarecrow wrote:
struct R {
ref int r;
this(ref int i) {r = i;}
}
I had totally forgotten what it says in "The book" about struct
and class construction. It's basically that all fields are first
initialized to either T.init or by using
...but I guess you could do this:
int globalVal1;
int globalVal2;
struct MyStruct(alias valToRef)
{
ref int refVal = valToRef;
}
void main()
{
MyStruct!globalVal1 ms1;
MyStruct!globalVal2 ms2;
}
...although, now I'm thinking that having reference variables as
members of struct or class won't ever work. And that's because
T.init is a compile-time variable, and references can't be known
at compile-time (unlike pointers, which can be null). Perhaps the
easiest way to implement reference v
I think references should either take the C# approach (which is
rock-solid), or the C++ approach (which is also pretty
rock-solid), but not an in-between.
On Saturday, 25 August 2012 at 20:37:27 UTC, timotheecour wrote:
Is there a "best practices" page on this site to use as
reference for those FAQ, that AFAIK are not in the docs:
* when to use class vs struct
(eg
http://stackoverflow.com/questions/11058906/struct-vs-class-for-writing-d-wrappers
On 2012-08-29 22:20, Piotr Szturmaj wrote:
The current possibility of UFCS is:
struct S { }
void func(S s) { }
S s;
s.func(); // equivalent of func(s);
why not add:
template sizeInInts(T)
{
enum sizeInInts = T.sizeof / 4;
}
S.sizeInInts // equivalent of sizeInInts!S
Is it worth it? I m
On Wednesday, 29 August 2012 at 20:20:04 UTC, Piotr Szturmaj
wrote:
The current possibility of UFCS is:
struct S { }
void func(S s) { }
S s;
s.func(); // equivalent of func(s);
why not add:
template sizeInInts(T)
{
enum sizeInInts = T.sizeof / 4;
}
S.sizeInInts // equivalent of sizeInInt
40 matches
Mail list logo
