The code below compiles to a single machine instruction, yet the results
are CPU manufacturer-dependent.
import std.math;
void main()
{
assert( yl2x(0x1.0076fc5cc7933866p+40L, LN2)
== 0x1.bba4a9f774f49d0ap+4L); // Pass on Intel, fails on AMD
}
The results for
== Quote from Don (nos...@nospam.com)'s article
The code below compiles to a single machine instruction, yet the results
are CPU manufacturer-dependent.
import std.math;
void main()
{
assert( yl2x(0x1.0076fc5cc7933866p+40L, LN2)
== 0x1.bba4a9f774f49d0ap+4L); // Pass on
El 26/11/2010 08:43, Bruno Medeiros escribió:
On 24/11/2010 21:44, Tom wrote:
El 17/11/2010 15:52, Bruno Medeiros escribió:
I'm announcing the release of DDT (D Development Tools) version 0.4.0:
http://code.google.com/a/eclipselabs.org/p/ddt/
(There was previously an older inactive project
Don wrote:
The code below compiles to a single machine instruction, yet the results
are CPU manufacturer-dependent.
This is awesome work, Don. Kudos to you, David and Dmitry.
BTW, I've read that fine-grained CPU detection can be done, beyond what CPUID
gives, by examining slight differences
%u wrote:
Slightly related, do you have some code to convert a hex float string to float?
Hex float literals are supported by D.
Walter:
%u wrote:
Slightly related, do you have some code to convert a hex float string to
float?
Hex float literals are supported by D.
hex float string != Hex float literal.
Bye,
bearophile
bearophile wrote:
Lutger Blijdestijn:
Actually the unix convention is to give exit code 0 as an indicator of
success, so there is feedback. It is very usable for scripting.
But currently something like that is not present in the D unittest system.
Yes, it is. Unit test failures return a
Walter:
Yes, it is. Unit test failures return a non-zero exit code.
I see, good. But real unit test systems don't just return that value, they give
a more visible feedback, like the number of failed/passed tests. One line of
text that shows those numbers is a good start.
Bye,
bearophile
But real unit test systems don't just return that value, they give a more
visible feedback, like the number of failed/passed tests. One line of text
that shows those numbers is a good start.
Or maybe that's not the job of a compiler...
Bye,
bearophile
On Friday 26 November 2010 17:17:56 bearophile wrote:
Walter:
Yes, it is. Unit test failures return a non-zero exit code.
I see, good. But real unit test systems don't just return that value, they
give a more visible feedback, like the number of failed/passed tests. One
line of text that
bearophile wrote:
Walter:
Yes, it is. Unit test failures return a non-zero exit code.
I see, good.
I wish you'd check these things before confidently posting incorrect assertions
about how D behaves.
Jonathan M Davis wrote:
I'm a firm believer that D unit tests should not change how they fundamentally
work at this point. I don't _want_ it to report the number of tests that passed.
That's right. The number that fail is completely useless window dressing.
That information is not at all
On Friday 26 November 2010 18:52:59 Walter Bright wrote:
Jonathan M Davis wrote:
I'm a firm believer that D unit tests should not change how they
fundamentally work at this point. I don't _want_ it to report the number
of tests that passed.
That's right. The number that fail is
Walter Bright wrote:
Don wrote:
The code below compiles to a single machine instruction, yet the
results are CPU manufacturer-dependent.
This is awesome work, Don. Kudos to you, David and Dmitry.
BTW, I've read that fine-grained CPU detection can be done, beyond what
CPUID gives, by
Most recent code: http://is.gd/hO85C
I added code for Mac OS X which should use its monotonic clock functions.
Unfortunately, as I don't own a Mac, it's completed untested, but in theory,
what's there should work, and someone with a Mac can fix it later if need be.
I also updated my unit
Most recent code: http://is.gd/hO8HP
Per the suggestions in this thread, I changed the string mixin templates to
functions using lazy. I also added assertOpBinary and made assertOpOpAssign()
call opOpAssign() directly. Finally, I made assertEqual() and assertNotEqual()
templatized on a
Jonathan M Davis jmdavisp...@gmx.com wrote:
You can, create .di files which have function declarations
leaving the definitions in a .d file (
http://www.digitalmars.com/d/2.0/dmd-
linux.html#interface_files ), but those are specific to dmd (as opposed
to the D
language)
This is false. .di
On Friday 26 November 2010 00:44:03 Simen kjaeraas wrote:
Jonathan M Davis jmdavisp...@gmx.com wrote:
You can, create .di files which have function declarations
leaving the definitions in a .d file (
http://www.digitalmars.com/d/2.0/dmd-
linux.html#interface_files ), but those are
Jonathan M Davis jmdavisp...@gmx.com wrote:
On Friday 26 November 2010 00:44:03 Simen kjaeraas wrote:
Jonathan M Davis jmdavisp...@gmx.com wrote:
You can, create .di files which have function declarations
leaving the definitions in a .d file (
http://www.digitalmars.com/d/2.0/dmd-
Walter Bright wrote:
Jens Mueller wrote:
I'm converting a .h to a d module. I'm following the guide on
http://www.digitalmars.com/d/2.0/htomodule.html
It says
D has const as a storage class, not a type modifier. Hence, just drop
any const used as a type modifier
I do not understand the
In TDPL const/immutable are type qualifiers. Type qualifier is a
synonym for type modifier, isn't it? And I know storage classes like
static/ref. In C you have the type qualifiers const, volatile, and
restrict and the storage classes auto, register, static, extern. Now
const in D is a storage
Jens Mueller wrote:
Walter Bright wrote:
Jens Mueller wrote:
I'm converting a .h to a d module. I'm following the guide on
http://www.digitalmars.com/d/2.0/htomodule.html
It says
D has const as a storage class, not a type modifier. Hence, just drop
any const used as a type modifier
I do not
Am 26.11.2010 02:38, schrieb Jonathan M Davis:
On Thursday 25 November 2010 16:05:42 rickned wrote:
Modules, files, packages, compilation units...
I have a class that is designed to be derived from. Can I put it in
a module (file) so other people can import the module (file) like a
C-c++
On 2010-11-26 03:03:15 -0500, Jonathan M Davis jmdavisp...@gmx.com said:
Most recent code: http://is.gd/hO85C
I added code for Mac OS X which should use its monotonic clock functions.
Unfortunately, as I don't own a Mac, it's completed untested, but in theory,
what's there should work, and
Trass3r wrote:
In TDPL const/immutable are type qualifiers. Type qualifier is a
synonym for type modifier, isn't it? And I know storage classes like
static/ref. In C you have the type qualifiers const, volatile, and
restrict and the storage classes auto, register, static, extern. Now
const in
Let's check all the possible cases:
void foo(const int *non_const_ptr_to_const,
char *const const_ptr_to_non_const,
const float *const const_ptr_to_const);
In D2 you cannot express char *const. That's due to the transitivity of
const. You can only do a const char* which is a
On 2010-11-26 07:51:20 -0500, Jens Mueller jens.k.muel...@gmx.de said:
Trass3r wrote:
In TDPL const/immutable are type qualifiers. Type qualifier is a
synonym for type modifier, isn't it? And I know storage classes like
static/ref. In C you have the type qualifiers const, volatile, and
Trass3r wrote:
Let's check all the possible cases:
void foo(const int *non_const_ptr_to_const,
char *const const_ptr_to_non_const,
const float *const const_ptr_to_const);
In D2 you cannot express char *const. That's due to the transitivity of
const. You can only do a
On Friday 26 November 2010 04:38:47 Michel Fortin wrote:
On 2010-11-26 03:03:15 -0500, Jonathan M Davis jmdavisp...@gmx.com said:
Most recent code: http://is.gd/hO85C
I added code for Mac OS X which should use its monotonic clock functions.
Unfortunately, as I don't own a Mac, it's
On Friday 26 November 2010 05:59:58 Jonathan M Davis wrote:
On Friday 26 November 2010 04:38:47 Michel Fortin wrote:
On 2010-11-26 03:03:15 -0500, Jonathan M Davis jmdavisp...@gmx.com said:
Most recent code: http://is.gd/hO85C
I added code for Mac OS X which should use its monotonic
Michel Fortin wrote:
On 2010-11-26 07:51:20 -0500, Jens Mueller jens.k.muel...@gmx.de said:
Trass3r wrote:
In TDPL const/immutable are type qualifiers. Type qualifier is a
synonym for type modifier, isn't it? And I know storage classes like
static/ref. In C you have the type qualifiers
Jonathan M Davis Wrote:
On Friday 26 November 2010 04:38:47 Michel Fortin wrote:
One thing I wonder about... what is the expected behaviour if you put
the computer to sleep in the middle of the above program? With
mach_absolute_time, the clock stops counting while the computer is put
to
On 2010-11-26 08:59:58 -0500, Jonathan M Davis jmdavisp...@gmx.com said:
On Friday 26 November 2010 04:38:47 Michel Fortin wrote:
One thing I wonder about... what is the expected behaviour if you put
the computer to sleep in the middle of the above program? With
mach_absolute_time, the clock
On 2010-11-26 09:12:53 -0500, Jens Mueller jens.k.muel...@gmx.de said:
So how do you like it to be?
void foo(const(int)*, char *, const(float)*);
or
void foo(const int*, char *, const float*);
I still like the fixed original one namely
void foo(const(int)*, char *, const float*);
I don't
On Friday 26 November 2010 06:14:29 Michel Fortin wrote:
On 2010-11-26 08:59:58 -0500, Jonathan M Davis jmdavisp...@gmx.com said:
On Friday 26 November 2010 04:38:47 Michel Fortin wrote:
One thing I wonder about... what is the expected behaviour if you put
the computer to sleep in the
On 06/11/2010 19:57, Walter Bright wrote:
Adam Burton wrote:
I wouldn't consider that as the same thing. null represents the lack
of a value where as 25 is the wrong value. Based on that argument the
application should fail immediately on accessing the item with 25 (not
many moons later) in the
On 03/11/2010 20:33, Andrei Alexandrescu wrote:
On 11/3/10 7:07 AM, zhang wrote:
This code belown can be compiled with DMD 2.050. However, it throws an
error message:
core.exception.HiddenFuncError: Hidden method called for main.AClass
I'm not sure about whether it is a bug. Thanks for any
Michel Fortin wrote:
On 2010-11-26 09:12:53 -0500, Jens Mueller jens.k.muel...@gmx.de said:
So how do you like it to be?
void foo(const(int)*, char *, const(float)*);
or
void foo(const int*, char *, const float*);
I still like the fixed original one namely
void foo(const(int)*, char *,
On 24/11/2010 21:12, Daniel Gibson wrote:
bearophile schrieb:
Bruno Medeiros:
On the other hand, I would be surprised if a person of the female
variety
would be that interested in D, to the point of contributing in such way.
In Python newsgroups I have seen few women, now and then, but in
On 07/11/2010 21:29, Tomek Sowiński wrote:
This wraps up a thread from a few days ago. Pascal featured my D
examples on his Scriptometer site.
http://rigaux.org/language-study/scripting-language/
D comes 17th out of 28, so it's so-so for scripting.
Hum, nice, I think this is a very
On 11/11/2010 13:50, Alexander Malakhov wrote:
Perhaps a module std.scripting could help quite a lot, too.
module std.script;
public import std.stdio, std.file, std.process, std.algorithm, ... etc
I use at least some of these for most of my programs/scripts. And
std.all is probably a
On 11/26/10 9:30 AM, Bruno Medeiros wrote:
On 03/11/2010 20:33, Andrei Alexandrescu wrote:
On 11/3/10 7:07 AM, zhang wrote:
This code belown can be compiled with DMD 2.050. However, it throws an
error message:
core.exception.HiddenFuncError: Hidden method called for main.AClass
I'm not sure
On 25/11/2010 16:55, Daniel Gibson wrote:
On Thu, Nov 25, 2010 at 5:28 PM, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
On 05/11/2010 18:52, Daniel Gibson wrote:
Walter Bright schrieb:
It's infinitely worse. Null pointers do not result in memory
corruption, buffer overflows, and
On 06/11/2010 20:02, Walter Bright wrote:
Jérôme M. Berger wrote:
I thought D was supposed to be a pragmatic language? All this means
is that we need a compromise between what would be ideal (being able
to represent arbitrary conditions and have them statically enforced
at compile time) and
On 26/11/2010 17:28, Bruno Medeiros wrote:
And I agree with that, and because of that I'm suprised and curious to
understand why Hoare mentioned (in the abstract on the link posted
originally), that null pointers have caused innumerable vulnerabilities.
Hum, cool, I just found out that this
On 09/11/2010 01:43, Jonathan M Davis wrote:
On Monday, November 08, 2010 16:50:46 so wrote:
D arrays very powerful but you first need to understand what is going on.
You should check the book.
An inconsistency is the copy of static arrays at assignment, but necessary
one.
One thing i don't
I don't really have a preference. Note that for function arguments, you
can also use 'in' to mean const:
void foo(in int*, char *, in float*);
Isn't in the default (even if nothing is specified)?
On 11/26/2010 07:22 PM, Bruno Medeiros wrote:
But more importantly, there is a simple solution: don't write such code,
don't use arrays like if they are lists, preallocate instead and then
fill the array. So with this alternative behavior, you can still write
efficient code, and nearly as
I wonder what would be a good deprecation schedule. Consider
http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.
We should now slowly deprecate std.utf.count. How should we go about it?
T0: documentation marked as scheduled for deprecation.
T1: Function is deprecated and
On 11/26/10 12:22 PM, Bruno Medeiros wrote:
On 09/11/2010 01:43, Jonathan M Davis wrote:
On Monday, November 08, 2010 16:50:46 so wrote:
D arrays very powerful but you first need to understand what is going
on.
You should check the book.
An inconsistency is the copy of static arrays at
Bruno Medeiros schrieb:
On 25/11/2010 16:55, Daniel Gibson wrote:
On Thu, Nov 25, 2010 at 5:28 PM, Bruno Medeiros
brunodomedeiros+s...@com.gmail wrote:
On 05/11/2010 18:52, Daniel Gibson wrote:
Walter Bright schrieb:
It's infinitely worse. Null pointers do not result in memory
Andrei:
T0: documentation marked as scheduled for deprecation.
T1: Function is deprecated and documentation updated to mention has
been deprecated
T2: Function is eliminated
Question is, what are some good values for T1 - T0 and T2 - T1?
T0 = T1 = 0 seconds
T2 = 2 months (2 releases)
On Fri, 26 Nov 2010 18:22:46 +
Bruno Medeiros brunodomedeiros+s...@com.gmail wrote:
Making the array reallocate _every_ time that it's resized (to a greater
length) is actually not that unreasonable. Would it be highly
inneficient? Only if you write bad code. TDPL agrees with you, I
On 09/11/2010 12:42, Steven Schveighoffer wrote:
On Mon, 08 Nov 2010 21:29:42 -0500, Jesse Phillips
jessekphillip...@gmail.com wrote:
Well, if you can come up with a good definition for what increasing
the size of a class would do, then maybe it should be added.
It really doesn't matter.
On Fri, 26 Nov 2010 19:50:27 +
Bruno Medeiros brunodomedeiros+s...@com.gmail wrote:
On 09/11/2010 12:42, Steven Schveighoffer wrote:
On Mon, 08 Nov 2010 21:29:42 -0500, Jesse Phillips
jessekphillip...@gmail.com wrote:
Well, if you can come up with a good definition for what
== Quote from bearophile (bearophileh...@lycos.com)'s article
When I have suggested to add computed gotos (similar to the ones of GCC) to
D,
Walter has answered that they need some work to be implemented, and they have
limited usefulness, almost only to optimize interpreters.
But:
- D is a
On 26/11/2010 19:36, Pelle Månsson wrote:
On 11/26/2010 07:22 PM, Bruno Medeiros wrote:
But more importantly, there is a simple solution: don't write such code,
don't use arrays like if they are lists, preallocate instead and then
fill the array. So with this alternative behavior, you can still
Jonathan M Davis Wrote:
totally fries Clock.currAppTick(), which tells you how long the application
has
been running. The documentation for QueryPermanceCounter() and
clock_gettime()
give no indication that the clock stops counting when a thread is sleeping.
I think,
Bruno Medeiros Wrote:
Making the array reallocate _every_ time that it's resized (to a greater
length) is actually not that unreasonable. Would it be highly
inneficient? Only if you write bad code. TDPL agrees with you, I quote:
Challenge: make D slower than C#.
On Friday 26 November 2010 10:24:02 Trass3r wrote:
I don't really have a preference. Note that for function arguments, you
can also use 'in' to mean const:
void foo(in int*, char *, in float*);
Isn't in the default (even if nothing is specified)?
No. in is the same as const scope.
On 26/11/2010 19:16, Andrei Alexandrescu wrote:
On 11/26/10 12:22 PM, Bruno Medeiros wrote:
But more importantly, there is a simple solution: don't write such code,
don't use arrays like if they are lists, preallocate instead and then
fill the array. So with this alternative behavior, you can
On Friday 26 November 2010 11:03:03 Andrei Alexandrescu wrote:
I wonder what would be a good deprecation schedule. Consider
http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.
We should now slowly deprecate std.utf.count. How should we go about it?
T0: documentation marked as
bearophile:
Don:
It's just a bug that it doesn't at present.
I don't believe this. I think it's more probably not desired.
Seeing the spring cleaning that the good Andrei is doing in Bugzilla, and how
he has assigned bug 259, I have to say that you are right, as usual :-)
Sorry,
On Fri, 26 Nov 2010 21:59:37 +
Bruno Medeiros brunodomedeiros+s...@com.gmail wrote:
You could still do exponential capacity growth by manipulating the
length property, but yeah, that would create a host of complexity and
other issues (see my reply to Pelle). Yeah, my reasoning was really
On 26/11/2010 19:50, Bruno Medeiros wrote:
Well, saying _dynamic arrays_ are a hybrid, like you mentioned, is
perhaps the best way to describe them, with less misunderstanding.
However, if I had to say whether dynamic arrays are value types or
reference types, I would agree with Jesse and call
On 26/11/2010 22:12, spir wrote:
On Fri, 26 Nov 2010 21:59:37 +
Bruno Medeirosbrunodomedeiros+s...@com.gmail wrote:
You could still do exponential capacity growth by manipulating the
length property, but yeah, that would create a host of complexity and
other issues (see my reply to
Iain Buclaw:
I don't think this feature really warrants a new keyword.
I have not asked for a new keyword.
Something that *would* warrant perhaps a new keyword would be non-local
gotos, but
it's usefulness is very negligible...
I don't like those :-)
Bye,
bearophile
On 26/11/2010 19:16, Andrei Alexandrescu wrote:
One easy way out would be to always reallocate a upon appending to it
[...]
Although that behavior is easiest to implement, it
has serious efficiency problems. For example, oftentimes arrays are
iteratively grown in a loop:
int[] a;
foreach (i; 0
On 26/11/2010 21:30, Kagamin wrote:
Bruno Medeiros Wrote:
Making the array reallocate _every_ time that it's resized (to a greater
length) is actually not that unreasonable. Would it be highly
inneficient? Only if you write bad code. TDPL agrees with you, I quote:
Challenge: make D slower
T0 - As soon as there are concrete plans for a replacement. I'd also mark
sub-par modules aslooking for someone to replace this. Truth in advertising
is always appreciated.
T1 - As soon as replacement code is available or maybe a month after it's
available. Regardless, I'd update the scheduled
On Friday 26 November 2010 15:19:37 Jason House wrote:
T2 - This should be quite long. There's no
reason to leave active projects with a non-compiling code base just
because an API in a low priority area has changed. I would say something
like 6-12 months. What do other languages do?
Java
Andrei Alexandrescu schrieb:
I wonder what would be a good deprecation schedule. Consider
http://d.puremagic.com/issues/show_bug.cgi?id=5257 as an example.
We should now slowly deprecate std.utf.count. How should we go about it?
T0: documentation marked as scheduled for deprecation.
T1:
On Friday 26 November 2010 06:14:29 Michel Fortin wrote:
On 2010-11-26 08:59:58 -0500, Jonathan M Davis jmdavisp...@gmx.com said:
On Friday 26 November 2010 04:38:47 Michel Fortin wrote:
One thing I wonder about... what is the expected behaviour if you put
the computer to sleep in the
On 26/11/2010 23:44, Jonathan M Davis wrote:
snip
Java marks stuff as deprecated and then _never_ removes it. It makes the
deprecation a bit of a joke really. Many people continue to use the deprecated
stuff anyway. A prime example would be that they deprecated Date's most useful
constructors in
http://oredev.org/2010/sessions/c-s-greatest-mistakes
Andrei
On 11/26/2010 10:28, Bruno Medeiros wrote:
Yes, Walter's statement that it is impossible for a null pointer to
cause a security vulnerability is (likely) incorrect.
But his point at large, considering the discussion that preceded the
comment, was that null pointers are utterly insignificant
Rainer Deyke schrieb:
On 11/26/2010 10:28, Bruno Medeiros wrote:
Yes, Walter's statement that it is impossible for a null pointer to
cause a security vulnerability is (likely) incorrect.
But his point at large, considering the discussion that preceded the
comment, was that null pointers are
Daniel Gibson Wrote:
Rainer Deyke schrieb:
On 11/26/2010 10:28, Bruno Medeiros wrote:
Yes, Walter's statement that it is impossible for a null pointer to
cause a security vulnerability is (likely) incorrect.
But his point at large, considering the discussion that preceded the
comment,
On Friday 26 November 2010 18:38:20 Stewart Gordon wrote:
But does Java ever deprecate language features, or only API features?
In the latter case, it's a matter of other libraries/APIs, not other
languages.
That's true. I'm not sure that they've ever deprecated a language feature. I
don't
Andrei Alexandrescu wrote:
http://oredev.org/2010/sessions/c-s-greatest-mistakes
A summary for those who don't want to sit through it:
http://news.ycombinator.com/item?id=1942859
Static interfaces (same thing as c++ 0x's ditched concepts) seem very
useful. Did you consider them at some point?
Torarin
2010/11/27 Walter Bright newshou...@digitalmars.com:
Andrei Alexandrescu wrote:
http://oredev.org/2010/sessions/c-s-greatest-mistakes
A summary for those who don't want
Andrei Alexandrescu Wrote:
http://oredev.org/2010/sessions/c-s-greatest-mistakes
Andrei
I don't get these programming videos things. They look totally incoherent.
Video in programming is like mud in art.
Kagamin Wrote:
Video in programming is like mud in art.
Or like elephant in a kitchen... :-/
Walter Bright Wrote:
Andrei Alexandrescu wrote:
http://oredev.org/2010/sessions/c-s-greatest-mistakes
A summary for those who don't want to sit through it:
http://news.ycombinator.com/item?id=1942859
Yeah, covariance. Can bug 2095 be fixed in D2? Or is it too late?
Torarin Wrote:
Static interfaces (same thing as c++ 0x's ditched concepts) seem very
useful. Did you consider them at some point?
static interface seems consistent with C#, though, I think static class is
misdesing by itself. I'd prefer
template interface ISummable(T)
{
static T opAdd(T
Hello,
void f () {
static string[string] map = [1:un, 2:du, 3:tri];
}
==
Error: non-constant expression [1:un,2:du,3:tri]
I do not understand what is meant, and what I should do. I need 'static', it's
a constant value for the func.
static int[] a = [1,2,3]; is OK. Where's the difference?
spir:
void f () {
static string[string] map = [1:un, 2:du, 3:tri];
}
==
Error: non-constant expression [1:un,2:du,3:tri]
I do not understand what is meant, and what I should do.
Associative arrays are run-time things... well, enum associative arrays are
compile-time things in
In my mind there is some confusion about all this. Other people may give you
better answers.
A solution in such situations is to take a look at the asm, that has confirmed
my ideas:
string first_function(string k) {
immutable string[string] map1 = [bar : spam];
return map1[k];
}
On Fri, 26 Nov 2010 16:17:10 -0500
bearophile bearophileh...@lycos.com wrote:
spir:
void f () {
static string[string] map = [1:un, 2:du, 3:tri];
}
==
Error: non-constant expression [1:un,2:du,3:tri]
I do not understand what is meant, and what I should do.
Associative
On Friday 26 November 2010 11:16:08 spir wrote:
Hello,
void f () {
static string[string] map = [1:un, 2:du, 3:tri];
}
==
Error: non-constant expression [1:un,2:du,3:tri]
I do not understand what is meant, and what I should do. I need 'static',
it's a constant value for the func.
Jonathan M Davis:
At present, I don't believe that associative arrays are valid CTFE
You are wrong, the current situation with AAs is not so simple :-)
string foo(string k) {
string[string] map = [bar : spam];
return map[k];
}
enum string v = foo(bar);
static assert(v == spam);
void
why does the following code fail?
import std.bigint;
void main(){
BigInt b1 = 1;
BigInt b2 = 3;
BigInt e1 = 1;
BigInt e2 = 3;
BigInt[] b = [b1,b2];
BigInt[] e = [e1,e2];
assert(b == e);
}
http://d.puremagic.com/issues/show_bug.cgi?id=4106
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=4371
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from
http://d.puremagic.com/issues/show_bug.cgi?id=4371
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
http://d.puremagic.com/issues/show_bug.cgi?id=5266
Simen Kjaeraas simen.kja...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
http://d.puremagic.com/issues/show_bug.cgi?id=5268
Simen Kjaeraas simen.kja...@gmail.com changed:
What|Removed |Added
CC|
http://d.puremagic.com/issues/show_bug.cgi?id=4172
--- Comment #4 from nfx...@gmail.com 2010-11-26 01:00:56 PST ---
(In reply to comment #2)
(In reply to comment #1)
The clean way to fix this (and what LDC does) is to pack all arguments
(aligning them) in a stack allocated array, create
http://d.puremagic.com/issues/show_bug.cgi?id=2246
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
http://d.puremagic.com/issues/show_bug.cgi?id=3896
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Status|NEW |RESOLVED
1 - 100 of 191 matches
Mail list logo
