Thanks. The bug is created.
https://issues.dlang.org/show_bug.cgi?id=14469
This function works fine for large text files like 100Mb or 1Gb
but failed when I tried to read 6Gb file. This happens on Windows
x64.
The possible reason that it uses read(in char[], size_t) function
and on windows it calls GetFileSize. This function returns file
size as 32 bit value. If you
On Sunday, 22 February 2015 at 12:13:02 UTC, MrSmith wrote:
You can also fold all the function bodies in your editor, this
helps me to read massive sources.
Oh, I almost forgot about this feature, never used it in C++ but
for D it looks promising. Thanks!
On Saturday, 21 February 2015 at 20:56:26 UTC, anonymous wrote:
On Saturday, 21 February 2015 at 20:46:09 UTC, Kenny wrote:
b) Write DDocs and read documentation. The problem here is that
I'm going to use D only for my own projects and in the last
time
I tend to write less documentation, for ex
I like D modules and it's a major point in the list of major
points why I like D (there is also the second not so nice
wft-list but it's for another post). I'm annoyed with C++
includes and I'm tired to create 2 files every time when I need
to add something new to the project... But I must admit
i think you are mixing two things here. IEEE doesn't specify
which
internal representation compilers should use, it only specifies
the
results for chosen representation. so if D specs states that
`float`
calculations are always performing with `float` precision (and
specs
aren't), your sample
For example, according to IEEE-754 specification if we work
with 32bit floating point numbers (floats in D) then the
following pseudo code prints 'Works'.
F32 f = 16777216.0f;
F32 f2 = f + 0.1f;
if is_the_same_binary_presentation(f, f2)
Print("Works");
As I understand D does not guarantee th
nope, this is a bug in your code. compiler (by the specs) is
free to
perform intermediate calculations with any precision that is
not lower
than a highest used type (i.e. not lower that `float`'s one for
`while`
condition (`f + eps != f`). it may be even infinite precision,
so your
code may no
There is no right or wrong when you compare floating point
values for equality (and inequality) unless those values can be
represented exactly in the machine. 1.0 is famously not
representable exactly. (It is similar to how 1/3 cannot be
represented in the decimal system.)
Here I tested one a
The above code snippet works correctly when I use LDC compiler
(it finds expected 'f' value and prints it to console). I'm
wondering is it a bug in DMD?
p.s. the final code used by both compilers:
import std.stdio;
import std.conv;
int main(string[] argv)
{
const float eps = 1.0f;
flo
And sory for the typos, cannot find edit functionality here..
Hi, D community!
I have this program:
import std.stdio;
import std.conv;
int main(string[] argv)
{
float eps = 1.0f;
float f = 0.0f;
while (f + eps != f)
f += 1.0f;
writeln("eps = " ~ to!string(eps) ~ ", max_f = " ~
to!string(f));
return 0;
}
According
12 matches
Mail list logo