Re: Undefined behaviours in D and C

Don: > (They don't completely overlap in > functionality, but the most important cases are covered by both). I will need to use array ops more to if you are right. > AFAIK 'restrict' hasn't been a terribly successful feature in the C world. I agree. (And I am not sure compilers use it well).

Re: Undefined behaviours in D and C

bearophile wrote: Walter Bright: D doesn't have this problem because D doesn't have the restrict qualifier.< So the D2 specs have to explicitly state that all D pointers can be an alias of each other (and this will make D code slower than Fortran77 code). Array operations address the same

Re: [gdb] Pushing the D patches upstream (again)

On 19/04/10 19:12, Leandro Lucarella wrote: Thanks for picking up this! I was following it but got lost in the paperwork. By the looks of things this isn't a hard thing to do... I think there was never been a formal review of the patch, because the lack of copyright assignment. I thought the

Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver

Eric Poggel wrote: On 4/19/2010 6:43 AM, Lars T. Kyllingstad wrote: IMO, general vectors/matrices should be structs wrapping a pointer to the data: struct Vector(T) { T* ptr; size_t length; size_t stride; } Low-dimensional fixed-size vectors should probably be value

Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver

On 04/19/2010 02:41 PM, Eric Poggel wrote: On 4/16/2010 10:41 PM, Andrei Alexandrescu wrote: Generally I'd strongly suggest making operations free generic functions instead of members. I disagree on this one. It unnecessarily adds more names to an outer namespace and makes code less readable:

Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver

On 4/19/2010 6:43 AM, Lars T. Kyllingstad wrote: IMO, general vectors/matrices should be structs wrapping a pointer to the data: struct Vector(T) { T* ptr; size_t length; size_t stride; } Low-dimensional fixed-size vectors should probably be value types. I think it

Re: Undefined behaviours in D and C

Walter Bright: >D doesn't have this problem because D doesn't have the restrict qualifier.< So the D2 specs have to explicitly state that all D pointers can be an alias of each other (and this will make D code slower than Fortran77 code). >If restrict is used incorrectly, however, undefined be

Re: [gdb] Pushing the D patches upstream (again)

Robert Clipsham, el 9 de abril a las 22:43 me escribiste: > After working on the debug information produced by dmd recently, I > started wondering what happened to the efforts to get the gdb > patches pushed upstream. > > http://d.puremagic.com/issues/show_bug.cgi?id=3207 > http://sourceware.org/

Re: Patches, bottlenecks, OpenSource

bearophile, el 10 de abril a las 08:09 me escribiste: > much slow in patching. A fork will not happen in D soon because there > are not enough people yet that care and work for D enough to make a fork > viable. I think there were some sort of forks in the D history. I see Ares/Tango as a fork of t

Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver

Also, the first syntax will give you intellisense in many IDE's.

Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver

On 4/16/2010 10:41 PM, Andrei Alexandrescu wrote: Generally I'd strongly suggest making operations free generic functions instead of members. I disagree on this one. It unnecessarily adds more names to an outer namespace and makes code less readable: vec1.cross(vec2).project(vec3).length();

Re: Low dimensional matrices, vectors, quaternions and a cubic equation

On 4/19/2010 7:36 AM, #ponce wrote: Maybe merging the good ideas of OMG, Yage, your code, etc... (and sorting out licences "problems")... would lead to a better low-dimensionnal math package class. I'm willing to re-license any of Yage's math library under whatever terms are necessary for inc

Re: value range propagation for _bitwise_ OR

On Sat, 17 Apr 2010 01:55:26 -0400, Andrei Alexandrescu wrote: On 04/16/2010 11:43 PM, Steven Schveighoffer wrote: Andrei Alexandrescu Wrote: Looks great, thanks Jerome! Now, how about that case in which some or all of the ranges involved include negative values? I solved already signed

Re: value range propagation for _bitwise_ OR

Don wrote: > Jérôme M. Berger wrote: >> Andrei Alexandrescu wrote: >>> On 04/16/2010 11:43 PM, Steven Schveighoffer wrote: Andrei Alexandrescu Wrote: > Looks great, thanks Jerome! > > Now, how about that case in which some or all of the ranges > involved include negative v

Re: Undefined behaviours in D and C

On 04/19/2010 11:47 AM, Fawzi Mohamed wrote: no the opposite is safe (pointer -> size_t) but there is no way size_t->pointer can be safe... Michel Fortin wrote: > So you shouldn't be able to *cast a value to a pointer*. The reverse, > casting a pointer to a value, makes sense in my opinion:

Re: (help) automation on windows - COMobjectsSample.zip

Deleaker ( http://deleaker.com/ ) is the best tool for memory leaks detection and localization in C++

Re: Undefined behaviours in D and C

On 19-apr-10, at 12:32, bearophile wrote: In the stdint.h of C99 there is (optionally) uintptr_t that's is an unsigned int that is large enough to contain a pointer (there is a intptr_t too, signed). In C99 you use that to convert a pointer to an integral. I don't know if D specs assert

Re: Low dimensional matrices, vectors, quaternions and a cubic equation

#ponce wrote: I don't know if this help, but here is a subset of my "math" package I've used in real-time applications. http://ponce.paradisia.net/temp/math_package.zip Such code is absolutely not what one would expect to find in a standard library (lots of assembly, almost no std.math, no sa

Re: Low dimensional matrices, vectors, quaternions and a cubic equation

I don't know if this help, but here is a subset of my "math" package I've used in real-time applications. http://ponce.paradisia.net/temp/math_package.zip Such code is absolutely not what one would expect to find in a standard library (lots of assembly, almost no std.math, no safety-checks, no

Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver

On 19-apr-10, at 01:11, Gareth Charnock wrote: Andrei Alexandrescu wrote: On 04/16/2010 04:25 PM, Gareth Charnock wrote: Okay, here goes. I've collected together the basic functionality that Quaternions: opAdd, opSub, opMult(quaternion), opMult(vector), opDiv, Normalise, Normalized, conjuga

Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver

Gareth Charnock wrote: Andrei Alexandrescu wrote: On 04/16/2010 04:25 PM, Gareth Charnock wrote: Okay, here goes. I've collected together the basic functionality that would probably make a good starting point. As I've mentioned my code is very messy and has bits missing (e.g. I never had a use

Re: Low dimensional matrices, vectors, quaternions and a cubic equation solver

Philippe Sigaud wrote: On Mon, Apr 19, 2010 at 01:11, Gareth Charnock > wrote: Couldn't agree more because I'm sure I'll miss tricks and conventions. I would have never thought of that funky swizzling idea. Here is a first try with the new operator synta

Re: Undefined behaviours in D and C

> In the stdint.h of C99 there is (optionally) uintptr_t that's is an unsigned > int that is large enough to contain a pointer (there is a intptr_t too, > signed). In C99 you use that to convert a pointer to an integral. > > I don't know if D specs assert that D size_t is wide enough to represen

Re: Undefined behaviours in D and C

Fawzi Mohamed: > no the opposite is safe (pointer -> size_t) but there is no way size_t- > pointer can be safe... In the stdint.h of C99 there is (optionally) uintptr_t that's is an unsigned int that is large enough to contain a pointer (there is a intptr_t too, signed). In C99 you use that to

Re: Low dimensional matrices, vectors, quaternions and a cubic equation

Gareth Charnock Wrote: > Andrei Alexandrescu wrote: > > On 04/16/2010 04:25 PM, Gareth Charnock wrote: > >> Okay, here goes. I've collected together the basic functionality that > >> would probably make a good starting point. As I've mentioned my code is > >> very messy and has bits missing (e.g.

Re: value range propagation for _bitwise_ OR

Jérôme M. Berger wrote: Andrei Alexandrescu wrote: On 04/16/2010 11:43 PM, Steven Schveighoffer wrote: Andrei Alexandrescu Wrote: Looks great, thanks Jerome! Now, how about that case in which some or all of the ranges involved include negative values? I solved already signed values in terms

Re: Undefined behaviours in D and C

On 19-apr-10, at 08:23, Pelle wrote: On 04/18/2010 02:46 PM, Walter Bright wrote: Michel Fortin wrote: So you shouldn't be able to cast a value to a pointer. The reverse, casting a pointer to a value, makes sense in my opinion: you may want to print the pointer value in a debug output of s

Re: Undefined behaviours in D and C

Lars T. Kyllingstad: > > enum SI { short s; int i; } > > void main() { > > SI e; > > e.i = 1_000_000; > > int foo = e.s; > > } > > Don't you mean 'union' here, not 'enum'? Yes, sorry -.- In Python newsgroups most code snippets shown by people are being run before post. It's an habit that I

Re: Undefined behaviours in D and C

bearophile wrote: Walter Bright: Sorry for the delay, I was away. In this post I try to write in a quite explicit way. I don't see any way to make conversions between pointers and ints implementation defined,< I see. Thank you for the explanation, I'm often ignorant enough. In my origina