Is anybody already working on OpenCL bindings now that Nvidia finally
released a public OpenCL driver?
Adam D. Ruppe wrote:
> I think this makes D's syntax superior. We can say a[0..$] where
> gcc would have to use the more annoying a[0...$-1].
> (pretending the $ worked of course)
Although I generally prefer half-open ranges over closed ranges, both
have their advantages and disadvantages.
Advant
On 29/09/2009 00:31, Nick Sabalausky wrote:
"Yigal Chripun" wrote in message
news:h9r37i$tg...@digitalmars.com...
These aren't just marginal performance gains, they can easily be up to
15-30% improvements, sometimes 50% and more. If this is too complex or
the risk is too high for you then do
On Mon, 28 Sep 2009 19:27:03 -0500, Andrei Alexandrescu wrote:
> language_fan wrote:
>>
>> int min;
>>
>> foreach(int value; list)
>> if (value < min) min = value;
>>
>> Oops, you forgot to define a flag variable or initialize to int.min
>
> You mean int.max :o).
if (list.length ==
On Mon, Sep 28, 2009 at 09:04:27PM -0600, Rainer Deyke wrote:
> > int[101] a;
> > a[0..9] = 1;
> > a[10..99] = 2;
> > a[100] = 3;
>
> This leaves elements 9 and 99 uninitialized. I assume the gcc version
> does not.
That makes sense. I copied it literally without thinking. Easy e
Jesse Phillips wrote:
> Yeah, it was brought to my attention that "type safety" by a friend
> could be another form. bearophile also brings up a good example.
> I think that is what Walter is getting at, you're not dealing with
> memory that is correct, when this happens the program should halt
Adam D. Ruppe wrote:
> Trying it, I see it doesn't actually work in initialization, but you
> can do it after the fact easily enough:
>
> int[101] a;
> a[0..9] = 1;
> a[10..99] = 2;
> a[100] = 3;
This leaves elements 9 and 99 uninitialized. I assume the gcc version
does n
Andrei Alexandrescu wrote:
language_fan wrote:
Mon, 28 Sep 2009 15:35:07 -0400, Jesse Phillips thusly wrote:
language_fan Wrote:
Now if you really want to throw some sticks into the spokes, you
would say that if the program crashes due to a null pointer, it is
still likely that the programme
Andrei Alexandrescu wrote:
Thanks for posting these interesting numbers. I seem to recall that
interface dispach in D does a linear search in the interfaces list, so
you may want to repeat your tests with a variable number of interfaces,
and a variable position of the interface being used.
No
language_fan wrote:
Mon, 28 Sep 2009 15:35:07 -0400, Jesse Phillips thusly wrote:
language_fan Wrote:
Now if you really want to throw some sticks into the spokes, you
would say that if the program crashes due to a null pointer, it is
still likely that the programmer will just initialize/set t
On 2009-09-28 15:36:05 -0400, bearophile said:
Compiled with DMD the running time seems about unchanged. I have no
idea why. Maybe some of you can tell me.
If I recall correctly, implementing an interface adds a variable to an
class which contains a pointer to that interface's vtable
implem
On Mon, 28 Sep 2009 16:01:10 -0400, Steven Schveighoffer wrote:
> On Mon, 28 Sep 2009 15:35:07 -0400, Jesse Phillips
> wrote:
>
>> language_fan Wrote:
>>
>>> Have you ever used functional languages? When you develop in Haskell
>>> or SML, how often you feel there is a good change something will
I don't know if what I am about to rant about has already been discussed and
I haven't noticed, but sometimes I feel like sticking my opinions in and
this seems to be one of them times :-) so bare with me and we'll see if I am
a crazy man blabbing on about crap or not :-).
language_fan wrote:
Mon, 28 Sep 2009 20:17:54 -0400, Nick Sabalausky thusly wrote:
> "language_fan" wrote in message
> news:h9relp$1eb...@digitalmars.com...
>> Mon, 28 Sep 2009 22:33:26 +, language_fan thusly wrote:
>>
>>> Value types can be incorrectly initialized and nobody notices. E.g.
>>>
>>> int min;
>>>
On Tue, 29 Sep 2009 02:58:01 +0400, gzp wrote:
Hello,
Iám new to D so i might be all wrong. Given the code:
Hello and welcome to the D world!
class Foo {
int opApply( int delegate(ref real) dg ) {...} //A.
int opApply( int delegate(real) dg ) {...} // B,
}
...
Foo
"language_fan" wrote in message
news:h9relp$1eb...@digitalmars.com...
> Mon, 28 Sep 2009 22:33:26 +, language_fan thusly wrote:
>
>> Value types can be incorrectly initialized and nobody notices. E.g.
>>
>> int min;
>>
>> foreach(int value; list)
>> if (value < min) min = value;
>
>>
On Mon, Sep 28, 2009 at 6:58 PM, gzp wrote:
> Hello,
>
> Iám new to D so i might be all wrong. Given the code:
>
> class Foo {
> int opApply( int delegate(ref real) dg ) {...} //A.
> int opApply( int delegate(real) dg ) {...} // B,
> }
>
> ...
> Foo foo = new Foo;
> for
Hello,
Iám new to D so i might be all wrong. Given the code:
class Foo {
int opApply( int delegate(ref real) dg ) {...} //A.
int opApply( int delegate(real) dg ) {...} // B,
}
...
Foo foo = new Foo;
foreach( a; foo ) {...} // 1.
foreach( ref a; foo ) {..
Mon, 28 Sep 2009 22:33:26 +, language_fan thusly wrote:
> Value types can be incorrectly initialized and nobody notices. E.g.
>
> int min;
>
> foreach(int value; list)
> if (value < min) min = value;
> Now I can tell you, in functional languages there is no other way. All
> initiali
Mon, 28 Sep 2009 15:35:07 -0400, Jesse Phillips thusly wrote:
> language_fan Wrote:
>
>> > Now if you really want to throw some sticks into the spokes, you
>> > would say that if the program crashes due to a null pointer, it is
>> > still likely that the programmer will just initialize/set the va
Yigal Chripun:
>Have you ever heard of Stalin (i'm not talking about the dictator)?<
Stalin accepts only a certain subset of Scheme, you can't use some of the
nicest things.
And while ShedSkin is slow, Stalin is really slow, so slow that compiling
largish programs becomes not handy (I think tim
Lutger wrote:
> bearophile wrote:
>
>> Lutger:
>>
>>> We don't need an extension for this! Look:
>>>
>>> template Eval(string exp)
>>> {
>>> enum Eval = mixin(exp);
>>> }
>>>
>>> template IsConstant(string exp)
>>> {
>>> enum IsConstant = __traits(compiles, Eval!exp);
>>> }
>>
>>
>>
"Yigal Chripun" wrote in message
news:h9r37i$tg...@digitalmars.com...
>
>>
>> These aren't just marginal performance gains, they can easily be up to
>> 15-30% improvements, sometimes 50% and more. If this is too complex or
>> the risk is too high for you then don't use a systems language :)
>
> y
bearophile wrote:
> Lutger:
>
>> We don't need an extension for this! Look:
>>
>> template Eval(string exp)
>> {
>> enum Eval = mixin(exp);
>> }
>>
>> template IsConstant(string exp)
>> {
>> enum IsConstant = __traits(compiles, Eval!exp);
>> }
>
>
> From what I see I think your code i
Mon, 28 Sep 2009 20:34:44 +, BCS thusly wrote:
> Hello Manfred_Nowak,
>
>> BCS wrote:
>>
>> [...]
>>
>>> I wouldn't want to hire a programer that *habitually* (and
>>> unnecessarily) hacks past a feature designed to prevent bugs.
>>>
>> In the short time of an interview its not possible to
"bearophile" wrote in message
news:h9qo0l$75...@digitalmars.com...
>
> But beside normal C unions that I don't want to remove from C, it can be
> also useful to have safe automatic tagged unions of Cyclone. They are
> safer and give just a little less performance compared to C unions. In D
> t
Mon, 28 Sep 2009 13:27:13 -0400, Steven Schveighoffer thusly wrote:
> On Mon, 28 Sep 2009 12:58:57 -0400, bearophile
> wrote:
>
>> Jarrett Billingsley:
>>
>>> Which do you want? Do you want new features, or do you want things to
>>> be fixed?<
>>
>> The ideas shown in that post are low priority,
"Jeremie Pelletier" wrote in message
news:h9q1pn$1po...@digitalmars.com...
> Nick Sabalausky wrote:
>>
>> Unions are nothing more than an alternate syntax for a reinterpret cast.
>> And it's an arguably worse syntax because unlike casts, uses of it are
>> indistinguishable from normal safe code
Justin Johansson wrote:
Andrei Alexandrescu Wrote:
It turns out this is a great example for NVI. In D, we could and should
do the following:
class Object {
// Implement this
private bool opEqualsImpl(Object rhs) {
return false;
}
// Use this
final bool opEqual
On Mon, Sep 28, 2009 at 03:45:16PM -0400, bearophile wrote:
> Adam D. Ruppe:
> > > Triple points can be used for initializations too:
> > > int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
> >
> > D's slicing can already do this I believe.
>
> How?
Trying it, I see it doesn't actual
Hello Manfred_Nowak,
BCS wrote:
[...]
I wouldn't want to hire a programer that *habitually* (and
unnecessarily) hacks past a feature designed to prevent bugs.
In the short time of an interview its not possible to test for habits
(or necessarity) to hack past a feature designed to provent bu
Lutger:
> We don't need an extension for this! Look:
>
> template Eval(string exp)
> {
> enum Eval = mixin(exp);
> }
>
> template IsConstant(string exp)
> {
> enum IsConstant = __traits(compiles, Eval!exp);
> }
>From what I see I think your code is useless for my purposes:
// D2 code
On Mon, 28 Sep 2009 15:35:07 -0400, Jesse Phillips
wrote:
language_fan Wrote:
Have you ever used functional languages? When you develop in Haskell or
SML, how often you feel there is a good change something will be
initialized to the wrong value? Can you show some statistics that show
how u
Adam D. Ruppe:
> > Triple points can be used for initializations too:
> > int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
>
> D's slicing can already do this I believe.
How?
Bye,
bearophile
On 28/09/2009 15:28, Jeremie Pelletier wrote:
here's a type-safe alternative
note: untested
struct Vec3F {
float[3] v;
alias v[0] x;
alias v[1] y;
alias v[2] z;
}
D provides alignment control for structs, why do we need to have a
separate union construct if it is just a special case of struct
Christopher Wright:
> > Certainly agreed on virtual calls: on my machine, I timed a simple
> > example as executing 65 interface calls per microsecond, 85 virtual
> > calls per microsecond, and 210 non-member function calls per
> > microsecond. So you should almost never worry about the cost of
language_fan Wrote:
> > Now if you really want to throw some sticks into the spokes, you would
> > say that if the program crashes due to a null pointer, it is still
> > likely that the programmer will just initialize/set the value to a
> > "default" that still isn't valid just to get the program
Andrei Alexandrescu Wrote:
> It turns out this is a great example for NVI. In D, we could and should
> do the following:
>
> class Object {
> // Implement this
> private bool opEqualsImpl(Object rhs) {
> return false;
> }
> // Use this
> final bool opEquals(Objec
Rainer Deyke Wrote:
> You could argue that assigned a 'B' to a variable that is declared to
> hold an 'A' is already a memory safety violation.
Yeah, it was brought to my attention that "type safety" by a friend could be
another form. bearophile also brings up a good example.
>If so, then the
On Mon, Sep 28, 2009 at 12:35:05PM -0400, bearophile wrote:
> Beside the known ones, like computed gotos and __builtin_expect(), GCC has
> other less known extensions, you can find some of them here:
> http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
I remember this page... did you po
Christopher Wright wrote:
bearophile wrote:
Jeremie Pelletier:
Again, that's a lazy view on programming. High level constructs are
useful to isolate small and simple algorithms which are implemented
at low level.
Software is inherently multi-scale. Probably in 90-95% of the code of
a progra
On Mon, Sep 28, 2009 at 1:27 PM, Steven Schveighoffer
wrote:
> On Mon, 28 Sep 2009 12:58:57 -0400, bearophile
> wrote:
>
>> Jarrett Billingsley:
>>
>>> Which do you want? Do you want new features, or do you want things to be
>>> fixed?<
>>
>> The ideas shown in that post are low priority, so they
On Mon, 28 Sep 2009 12:58:57 -0400, bearophile
wrote:
Jarrett Billingsley:
Which do you want? Do you want new features, or do you want things to
be fixed?<
The ideas shown in that post are low priority, so they can wait. But
things can be planned for the future too, you can start
thi
bearophile wrote:
> Beside the known ones, like computed gotos and __builtin_expect(), GCC has
> other less known extensions, you can find some of them here:
> http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
>
> They are used by Linux. If D wants to be a system language, such small
>
bearophile wrote:
Jeremie Pelletier:
Again, that's a lazy view on programming. High level constructs are
useful to isolate small and simple algorithms which are implemented at
low level.
Software is inherently multi-scale. Probably in 90-95% of the code of a program
micro-optimizations aren'
Jarrett Billingsley:
>Which do you want? Do you want new features, or do you want things to be
>fixed?<
The ideas shown in that post are low priority, so they can wait. But things can
be planned for the future too, you can start thinking/planning about them even
years before they are implement
On Mon, Sep 28, 2009 at 12:35 PM, bearophile wrote:
> Beside the known ones, like computed gotos and __builtin_expect(), GCC has
> other less known extensions, you can find some of them here:
> http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
>
> They are used by Linux. If D wants to
Jari-Matti M.:
> It depends on the boolean representation. I see no reason why a built-in
> feature should be slower than some bitwise logic operation in user code.
> After all, the set of operations the language provides for the user is a
> subset of all possible operations the language implem
Beside the known ones, like computed gotos and __builtin_expect(), GCC has
other less known extensions, you can find some of them here:
http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/
They are used by Linux. If D wants to be a system language, such small things
may be useful if you
Jeremie Pelletier:
> Not always true.
I agree, I'm using D also because it offers unions. Sometimes they are useful.
But beside normal C unions that I don't want to remove from C, it can be also
useful to have safe automatic tagged unions of Cyclone. They are safer and give
just a little less
On 28-9-2009 18:09, Jeremie Pelletier wrote:
Max Samukha wrote:
Lionello Lunesu wrote:
On 27-9-2009 9:20, Walter Bright wrote:
language_fan wrote:
The idea behind non-nullable types and other contracts is to catch
these errors on compile time. Sure, the code is a bit harder to write,
but it
Yigal Chripun wrote:
On 28/09/2009 12:05, Jeremie Pelletier wrote:
Nick Sabalausky wrote:
"Jeremie Pelletier" wrote in message
news:h9mmre$1i8...@digitalmars.com...
Ary Borenszweig wrote:
Object is not-nullable, Object? (or whatever syntax you like) is
nullable. So that line is a compile-tim
On 28/09/2009 12:05, Jeremie Pelletier wrote:
Nick Sabalausky wrote:
"Jeremie Pelletier" wrote in message
news:h9mmre$1i8...@digitalmars.com...
Ary Borenszweig wrote:
Object is not-nullable, Object? (or whatever syntax you like) is
nullable. So that line is a compile-time error: you can't cas
BCS wrote:
[...]
> I wouldn't want to hire a programer that *habitually* (and
> unnecessarily) hacks past a feature designed to prevent bugs.
In the short time of an interview its not possible to test for habits (or
necessarity) to hack past a feature designed to provent bugs.
Therefore the onl
Jeremie Pelletier wrote:
> Jari-Matti Mäkelä wrote:
>> Jeremie Pelletier wrote:
>>
>>> Nick Sabalausky wrote:
union A {
int foo;
float bar;
}
>>> Yet it's the only way I know of to do bitwise logic on floating points
>>> in D to extract the exponent, sign and mantissa for
Jari-Matti Mäkelä wrote:
Jeremie Pelletier wrote:
Nick Sabalausky wrote:
union A {
int foo;
float bar;
}
Yet it's the only way I know of to do bitwise logic on floating points
in D to extract the exponent, sign and mantissa for example.
You could add built-in methods for those operations t
Jeremie Pelletier wrote:
> Nick Sabalausky wrote:
>> union A {
>> int foo;
>> float bar;
>> }
>>
>
> Yet it's the only way I know of to do bitwise logic on floating points
> in D to extract the exponent, sign and mantissa for example.
You could add built-in methods for those operations to the f
Max Samukha wrote:
Lionello Lunesu wrote:
On 27-9-2009 9:20, Walter Bright wrote:
language_fan wrote:
The idea behind non-nullable types and other contracts is to catch
these errors on compile time. Sure, the code is a bit harder to write,
but it is safe and never segfaults. The idea is to mi
Nick Sabalausky wrote:
"Jeremie Pelletier" wrote in message
news:h9mmre$1i8...@digitalmars.com...
Ary Borenszweig wrote:
Object is not-nullable, Object? (or whatever syntax you like) is
nullable. So that line is a compile-time error: you can't cast a null to
an Object (because Object *can't*
Lionello Lunesu wrote:
> On 27-9-2009 9:20, Walter Bright wrote:
>> language_fan wrote:
>>> The idea behind non-nullable types and other contracts is to catch
>>> these errors on compile time. Sure, the code is a bit harder to write,
>>> but it is safe and never segfaults. The idea is to minimize
On Mon, 28 Sep 2009 01:31:44 +0400, Jeremie Pelletier
wrote:
Andrei Alexandrescu wrote:
Jeremie Pelletier wrote:
Is this Linux specific? what about other *nix systems, like BSD and
solaris?
Signal handler are standard to most *nix platforms since they're part
of the posix C standard li
"Jeremie Pelletier" wrote in message
news:h9mmre$1i8...@digitalmars.com...
> Ary Borenszweig wrote:
>>
>> Object is not-nullable, Object? (or whatever syntax you like) is
>> nullable. So that line is a compile-time error: you can't cast a null to
>> an Object (because Object *can't* be null).
>
62 matches
Mail list logo
