On Monday, 3 September 2012 at 07:19:06 UTC, Russel Winder wrote:
Hi,
Is there anyone out there using SCons to build D code? If so it
would be
good to get some alpha and beta testers for the evolution of D
support
in SCons.
I appreciate that other build frameworks may be the preferred
ones
On Saturday, 15 September 2012 at 21:30:03 UTC, Walter Bright
wrote:
On 9/15/2012 5:39 AM, Henning Pohl wrote:
The way D is dealing with classes reminds me of pointers
because you can null
them. C++'s references cannot (of course you can do some nasty
casting).
Doing null references in C++ is
On Thursday, 4 October 2012 at 17:55:45 UTC, Jonathan M Davis
wrote:
On Thursday, October 04, 2012 13:14:00 Alex Burton, @gmail.com
wrote:
On Saturday, 15 September 2012 at 21:30:03 UTC, Walter Bright
wrote:
> On 9/15/2012 5:39 AM, Henning Pohl wrote:
>> The way D is dealing wit
On Wednesday, 3 October 2012 at 17:37:14 UTC, Franciszek Czekała
wrote:
On Wednesday, 3 October 2012 at 16:33:15 UTC, Simen Kjaeraas
wrote:
On 2012-10-03, 18:12, wrote:
They make sure you never pass null to a function that doesn't
expect null - I'd say that's a nice advantage.
However w
On Saturday, 15 September 2012 at 17:51:39 UTC, Jonathan M Davis
wrote:
On Saturday, September 15, 2012 19:35:44 Alex Rønne Petersen
wrote:
Out of curiosity: Why? How often does your code actually
accept null as
a valid state of a class reference?
I have no idea. I know that it's a non-neglig
On Friday, 5 October 2012 at 04:50:18 UTC, Jonathan M Davis wrote:
On Friday, October 05, 2012 05:42:03 Alex Burton wrote:
I realise what is currently the case I am making an argument as
to why I this should be changed (at least for class references
in
D).
This was talking about C
struct Init
{
Factory * factory;
Other arg1;
Another arg2;
};
void foo(const Init& init);
void bar(const Init& init)
{
foo(init);
other stuff;
};
bar(Init(factory,other args));
In C++ I often wrap some arguments that are common to multiple
functions in a struct.
This idiom can red
On Wednesday, 1 January 2014 at 23:11:49 UTC, Adam D. Ruppe wrote:
On Wednesday, 1 January 2014 at 23:00:33 UTC, alex burton wrote:
In D this would be void bar(in Init init) which makes init
const
You should just take Init, without the in.
"in" means that you won't modify AND
Also: I couldn't find how to download old versions to make a
better report on the version it was introduced in.
Links to old versions in the changelog point to the current
version download.
struct Foo
{
};
void bar(ref Foo f)
{
}
void main()
{
bar(Foo()); //Error: function test.bar (ref Foo f) is not
callable using argument types (Foo)
}
I get the above error with 2.064 not with 2.060.
Is it a bug ?
Is it a feature ?
If so :
Why can't I take a non const ref to a temp struct -
On Friday, 3 January 2014 at 03:59:50 UTC, Jonathan M Davis wrote:
On Friday, January 03, 2014 03:13:12 alex burton wrote:
struct Foo
{
};
void bar(ref Foo f)
{
}
void main()
{
bar(Foo()); //Error: function test.bar (ref Foo f) is not
callable using argument types (Foo)
}
I get the above
On Sunday, 5 January 2014 at 00:05:46 UTC, Walter Bright wrote:
On 1/4/2014 3:04 PM, deadalnix wrote:
On Saturday, 4 January 2014 at 22:06:13 UTC, Walter Bright
wrote:
I don't really understand your point. Null is not that
special.
For example, you may want a constrained type:
1. a float gua
On Monday, 6 January 2014 at 23:13:14 UTC, Walter Bright wrote:
On 1/6/2014 3:02 PM, Alex Burton wrote:
All the others should result in an exception at some point.
Exceptions allow stack unwinding, which allows people to write
code that doesn't
leave things in undefined states in the eve
On Tuesday, 7 January 2014 at 11:36:50 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 7 January 2014 at 11:29:18 UTC, alex burton wrote:
Hardware exceptions allow for the same thing.
I am not sure what you mean by the above.
You can trap the segfault and access a OS-specific data
structure
Hi,
I just found a bug that comes out of the property syntax.
The property syntax is great in that it allows a smooth transition from simple
code dealing with public member variables to the use of interfaces without
needing to update the client code.
i.e. A.bob = 1 can stay as A.bob = 1 when bo
Robert Jacques Wrote:
> On Thu, 05 Feb 2009 06:55:46 -0500, Alex Burton wrote:
>
> > Hi,
> >
> > I just found a bug that comes out of the property syntax.
> >
> > The property syntax is great in that it allows a smooth transition from
> > simple co
Robert Jacques Wrote:
> On Thu, 05 Feb 2009 14:27:27 -0500, Bill Baxter wrote:
>
> > On Fri, Feb 6, 2009 at 2:34 AM, Robert Jacques wrote:
> >> On Thu, 05 Feb 2009 06:55:46 -0500, Alex Burton wrote:
> >>> int main()
> >>> {
> >>> B
I vote yes.
I was pretty sure the topic was refering to the ability to specify a pointer
that could not be set to 0.
I totally agree with this rule, and enforce it in all my C++ code with smart
pointers.
class X
{
};
X x; //in D
or X * x; //in C++
Setting x to zero or any other value that i
I think it makes no sense to have nullable pointers in a high level language
like D.
In D :
X x = new X;
This is a bit redundant, if we take away the ability to write X x; to mean X x
= 0; then we can have X x; mean X x = new X;
If the class has a ctor then we can write X x(32); instead of X x
Ary Borenszweig Wrote:
> Alex Burton wrote:
> > I think it makes no sense to have nullable pointers in a high level
> > language like D.
> >
> > In D :
> >
> > X x = new X;
> > This is a bit redundant, if we take away the ability to write X x; to me
Daniel Keep Wrote:
>
>
> Alex Burton wrote:
> > I think it makes no sense to have nullable pointers in a high level
> > language like D.
>
> Oh, and how do you intend to make linked lists? Or trees? Or any
> non-trivial data structure?
I am not saying than
Daniel Keep Wrote:
>
>
> Alex Burton wrote:
> > I think it makes no sense to have nullable pointers in a high level
> > language like D.
>
> Oh, and how do you intend to make linked lists? Or trees? Or any
> non-trivial data structure?
I am not saying than
Daniel Keep Wrote:
>
>
> Alex Burton wrote:
> > Daniel Keep Wrote:
> >
> >>
> >> Alex Burton wrote:
> >>> I think it makes no sense to have nullable pointers in a high level
> >>> language like D.
> >> Oh, and how do y
bearophile Wrote:
> Andrei Alexandrescu:
> > I did some more research and found a study:
> > http://users.encs.concordia.ca/~chalin/papers/TR-2006-003.v3s-pub.pdf
> > ...
> > Turns out in 2/3 of cases, references are really meant to be non-null...
> > not really a landslide but a comfortable majo
Walter Bright Wrote:
> Daniel Keep wrote:
> >> * Accessing arrays out-of-bounds
> >> * Dereferencing null pointers
> >> * Integer overflow
> >> * Accessing uninitialized variables
> >>
> >> 50% of the bugs in Unreal can be traced to these problems!
> >
> > Tim Sweeny isn't an amateur; he's respon
Walter Bright Wrote:
When I see code like this I see bugs.
>
> Foo f;
> if (x < 1) f = new Foo(1);
> else if (x >= 1) f = new Foo(2);
> f.member();
>
This should not compile IMHO default non nullable is necessary.
If using a language with default nullable, I would write this as
Foo generateFo
Alex Burton Wrote:
> bearophile Wrote:
>
> > Andrei Alexandrescu:
> > > I did some more research and found a study:
> > > http://users.encs.concordia.ca/~chalin/papers/TR-2006-003.v3s-pub.pdf
> > > ...
> > > Turns out in 2/3 of cases, referenc
Alex Burton Wrote:
>
> Oops I'm wrong the 2/3 is NON nullable. My brain seems to have trouble
> reading all this 'non null' stuff.
>
Actually non nullable is a double negative.
What we really want in the D language and the language of the discussions about
On Thursday, 14 April 2016 at 09:46:34 UTC, Marc Schütz wrote:
On Thursday, 14 April 2016 at 00:31:34 UTC, Simen Kjaeraas
wrote:
@constanttime functions can only call other functions marked
@constanttime, and may not contain conditionals, gotos or
while-loops.
@constanttime functions may contai
29 matches
Mail list logo
