On Sunday 19 September 2010 18:19:25 Juanjo Alvarez wrote:
> On Sun, 19 Sep 2010 20:07:38 -0400, bearophile
>
> wrote:
> > C standard say that's not safe. You can force that to be safe in
>
> C-GCC if you explicitly disable a compiler optimization. I think D
> docs don't say anything about this.
On Sun, 19 Sep 2010 20:07:38 -0400, bearophile
wrote:
C standard say that's not safe. You can force that to be safe in
C-GCC if you explicitly disable a compiler optimization. I think D
docs don't say anything about this. And Walter has said that
regarding such things D acts as C. So I am not
Jonathan M Davis wrote:
> On Sunday 19 September 2010 17:07:38 bearophile wrote:
>> orgoton baberek:
>>> Use a union, which is the correct and safe way.
>> C standard say that's not safe. You can force that to be safe in
C-GCC if
>> you explicitly disable a compiler optimization. I think D docs
On Sunday 19 September 2010 17:07:38 bearophile wrote:
> orgoton baberek:
> > Use a union, which is the correct and safe way.
>
> C standard say that's not safe. You can force that to be safe in C-GCC if
> you explicitly disable a compiler optimization. I think D docs don't say
> anything about th
On Sunday 19 September 2010 17:13:14 Stewart Gordon wrote:
> On 19/09/2010 04:35, Jonathan M Davis wrote:
>
>
> > That doesn't work because you're just copying the pointer. Is there a way
> > to actually do a deep copy of the delegate? I can see why this would be
> > problematic if the delegate h
> This program doesn't work:
>
> import std.typecons;
> void main() {
> auto t = tuple(42, 3.14);
> double d = t[1];
> }
>
>
> And I think bug 2800 is unrelated:
> http://d.puremagic.com/issues/show_bug.cgi?id=2800
But now I have seen this:
http://www.dsource.org/projects/phobos/changes
Jonathan M Davis:
> I assume that if you declare a member function as pure, then all of its
> parameters - including the invisible this - are included in that. That is, if
> all of them - including the invisible this - have the same value, then the
> result will be the same.
This D2 program ru
On 19/09/2010 04:35, Jonathan M Davis wrote:
That doesn't work because you're just copying the pointer. Is there a way to
actually do a deep copy of the delegate? I can see why this would be problematic
if the delegate had reference types in its scope (since presumably, they'd have
to be shallow
Juanjo Alvarez:
> But if I move the tuple
> definition to another file (urls.d) the compiler gives me the error:
It seems a compiler bug. If not already present it probably needs to be added.
> Is there any other way to iterate over a tuple with values of different
> tuples?
You may use a ty
Philippe Sigaud:
> Recently, bug 2800 was corrected and you can also directly access a tuple's
> fields by indexing:
> double d = tup[1]; // or simply: auto d = tup[1];
This program doesn't work:
import std.typecons;
void main() {
auto t = tuple(42, 3.14);
double d = t[1];
}
And I
orgoton baberek:
> Use a union, which is the correct and safe way.
C standard say that's not safe. You can force that to be safe in C-GCC if you
explicitly disable a compiler optimization. I think D docs don't say anything
about this. And Walter has said that regarding such things D acts as C. S
Yes, that did it exactly!
Thank you, Simen, and Orgoton.
Bradley Mitchell wrote:
int xi = cast(int)cast(void*)x;
[...]
x = cast(float)cast(void*)xi;
The simple solution (seeing as how x is an lvalue) is
int xi = *cast(int*)&x;
[...]
x = *cast(float*)ξ
Function version:
T reinterpret( T, U )( U value ) {
return *cast( T* )&
On 19/09/2010 18:39, Bradley Mitchell wrote:
Hello,
I'm trying to implement the Quake 3 fast inverse square root algorithm which
requires casting from int to float without modifying the stored bits. A C++
reinterpret cast seems to accomplish this just fine but so far I have had no
success in D a
Hello,
I'm trying to implement the Quake 3 fast inverse square root algorithm which
requires casting from int to float without modifying the stored bits. A C++
reinterpret cast seems to accomplish this just fine but so far I have had no
success in D after trying quite a few different things. Here
Philippe Sigaud wrote:
> What languages are you used to? You seem to do quite well with genericity
> :)
What I've done profesionally and personally in the last year would be 90%
Python, 5% Java and 5% C++. So yes, since Python is like a D with an
uberauto and everything being runtime templates
Ivo Kasiuk Wrote:
>
> - Is there any way the regular finalization sequence (i.e. including
> automatic invoking of the destructors) can be run for an object that
> uses non-GC memory?
It should happen when delete is called. Here's the code executed for delete:
http://dsource.org/projects/drunti
> instead of a virtual function, but I'll keep the current design because is
> simpler for me (I'm still adapting my brain to all this genericity).
>
What languages are you used to? You seem to do quite well with genericity :)
>
> On my current implementation with functions I still have a doubt:
Philippe Sigaud wrote:
> String mixins are quite powerful, if a bit clunky at times.
Both true, for what I'm seeing of them.
> See also __traits(getMember, ...)
> http://digitalmars.com/d/2.0/traits.html (look for getMember)
Nice, with getMembers I could redesign again my test code for using
> > Ok, that makes sense. So the deallocators really should not get called
> > in this case. But why are the destructors not invoked when the GC
> > finalizes the objects?
>
> For S1 and S2, this is a known bug - destructors of structs on the heap
> don't get called.
Ah, I see. You mean #2834. Th
> >> > Exploring the example a bit further:
> >> > If C's malloc is used instead of GC.malloc then the deallocators also
> >> > are not called and the program runs out of memory. How are the objects
> >> > supposed to get finalized in this case - do I have to use the delete
> >> > keyword explicit
21 matches
Mail list logo
