div0:
> Just cause you don't like the feature doesn't mean it's unclear, buggy
> or otherwise pointless.
In this discussion I was talking about two different things:
1) In that answer of mine with the word "undecided" I meant that there are D
parts where D specs don't state how a correct D imple
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
bearophile wrote:
>
> are several other undecided things like this,
It's not undecided. It's very clear that a union is exactly equivalent
to it's C/C++ counter for the specific purposes of C/C++ interop and
other low level features like painting str
On 05/04/2010 11:32 AM, Lars T. Kyllingstad wrote:
Shouldn't 'term' and 'signaled' switch names? It looks to me like 'term'
will be nonzero if the process receives any signal, while 'signaled' will
be only be true if it is a terminating signal, and not if it is a stop
signal.
signaled corres
Hello everybody,
I'm trying to create a (very) simple DLL by using D. Now I want export values -
is there any way do this... for example:
Example:
mydll.d:
export int i;
mydll2.d:
export int i = 99;
dll.d:
// Copied from http://www.digitalmars.com/d/2.0/dll.html
test.d:
import std.stdio;
imp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ali Çehreli wrote:
> It is unspecified behavior in C++ to access any member of a union other
> than the one that was used last to store a value in it.
>
> Is that the case with D as well?
>
> Ali
yes, union in D is the same as C/C++
- --
My enormou
Ali Ãehreli:
> It is unspecified behavior in C++ to access any member of a union other
> than the one that was used last to store a value in it.
> Is that the case with D as well?
I have recently asked Walter about this, my purpose was to remove some
undefined situations from D, but after a lon
It is unspecified behavior in C++ to access any member of a union other
than the one that was used last to store a value in it.
Is that the case with D as well?
Ali
On Tue, 04 May 2010 08:55:36 -0500, Ellery Newcomer wrote:
> On 05/04/2010 01:58 AM, Lars T. Kyllingstad wrote:
>> std.process is currently undergoing a complete redesign, so the current
>> situation should improve in the near future. :)
>>
>> -Lars
>
> That's good to hear. And since you're an exp
On 05/04/2010 09:51 AM, Graham Fawcett wrote:
Thanks for posting this. Just curious -- why did you choose to model PID
as a tuple instead of a struct? I'm not clear on what the tradeoffs are.
Best,
Graham
according to core.sys.posix.sys.wait, this is only valid for linux, grrr.
I don't think
On Tue, 04 May 2010 08:55:36 -0500, Ellery Newcomer wrote:
> On 05/04/2010 01:58 AM, Lars T. Kyllingstad wrote:
>
>
>> In your case the segfault would cause SIGSEGV (signal 11) to be sent to
>> the process, and the the above test would print "Process terminated by
>> signal 11".
>>
>> See "man w
On 05/04/2010 09:07 AM, Masahiro Nakagawa wrote:
>
> I once hit the same bug. SHOO has been reported this bug.
> http://d.puremagic.com/issues/show_bug.cgi?id=4003
>
thanks for the link
> I don't know the solution to fix :(
easy, remove the unittest from phobos :)
On 04/23/2010 10:04 PM, Steven Schveighoffer wrote:
> My measurements were 2 minutes 2 seconds on D to 1 minute 20 seconds on
> C++, so not quite a 2x difference, but still significant.
>
> I can only attribute the difference to g++'s more mature
> optimization/inlining techniques. I can see why
On Tue, 04 May 2010 13:21:46 +0900, Ellery Newcomer
wrote:
lately I've been getting a lot of screwy error messages whenever I try
to compile with -unittest:
/home/ellery/Downloads/dmd2044/linux/bin/../../src/phobos/std/typecons.d(425):
Error: static assert (is(Tuple!(string,float) == Tu
On 05/04/2010 01:58 AM, Lars T. Kyllingstad wrote:
In your case the segfault would cause SIGSEGV (signal 11) to be sent to
the process, and the the above test would print "Process terminated by
signal 11".
See "man wait" for more info.
That's where I got my info (or rather /usr/include/bits/
On Mon, 03 May 2010 20:32:03 -0500, Ellery Newcomer wrote:
> On 05/03/2010 06:08 PM, Graham Fawcett wrote:
>>
>> [...]
>>
>> And "(139& 0xff00)>>> 8" evaluates to 0. I am not sure why it's
>> not simply returning the raw status-code, though, and only on Posix
>> systems -- it must be a Posi
15 matches
Mail list logo
