On Sunday, 16 February 2014 at 01:25:13 UTC, bearophile wrote:
Many of the things you say and write are still wrong or
confused. Usually the hard optimization of code is one the last
things you learn about a language
Well, actually, sometimes squeezing as much performance as you
can from a
francesco cattoglio:
Well, actually, sometimes squeezing as much performance as you
can from a test case can be a way to find out if a given
language checks all the boxes and can be used to solve your
problems.
Unless you know a language well, you will fail squeezing that.
This is true
On Saturday, 15 February 2014 at 16:26:28 UTC, Josh Phillips
wrote:
On Friday, 14 February 2014 at 20:36:42 UTC, Jeremy DeHaan
wrote:
Unless I am mistaken, it looks like the last time it was
updated was in 2011. You'd probably have to update a bunch of
stuff in the sources in order to get it
On Saturday, February 15, 2014 22:13:07 Steven Schveighoffer wrote:
On Fri, 14 Feb 2014 17:14:03 -0500, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, February 13, 2014 23:37:13 Timothee Cour wrote:
Is there a function to do this?
If not and I/someone writes it, is there
On 2/16/2014 4:20 PM, Denis Mezhov wrote:
On Sunday, 16 February 2014 at 07:17:48 UTC, Denis Mezhov wrote:
extern (Windows)
void main(string[] args)
{
HMODULE h;
I'm curious why you're declaring your main method as extern(Windows).
On Friday, 14 February 2014 at 20:29:50 UTC, Josh Phillips wrote:
I recently downloaded and tried to use DGUI but I can't get it
to work. Is there any tutorials on how to build an use it? Or
can anyone help me and tel me a way on how I can get it to work?
I know this isn't really related to
On Sunday, 16 February 2014 at 09:53:08 UTC, bearophile wrote:
Be instead amazed of the sometimes near-C++ performance levels
they have pushed Java to :-)
Sorry, but I fail to be amazed by what huge piles of money thrown
to a project for 10+ years can achieve. Those kind of
achievements are
Use a container adequate for the task at hand, e.g. red-black
tree.
Artem Tarasov:
Use a container adequate for the task at hand, e.g. red-black
tree.
If you have a limited number of small values (like 30 ints) using
a sorted array is quite efficient, and keeps low the binary size
and the pressure on the code L1 cache :-)
Arrays are awesome on modern
On Sunday, 16 February 2014 at 12:41:45 UTC, Artem Tarasov wrote:
Use a container adequate for the task at hand, e.g. red-black
tree.
Very often a sorted array is the most adequate set implementation
and we should have support for it in phobos.
Hello,
The call signature for opCmp in a struct is:
struct S {
int opCmp(ref const S s) const { ... }
}
int opCmp(ref const S s) const { return _val - s._val; }
This works fine if _val is 'int'. However, if _val is 'long' then
subtracting 2 longs may not result in an int - and therefore I
On 02/16/2014 02:59 PM, Saurabh Das wrote:
This does compile and run correctly, but are there any hidden
assumptions or requirements on the return value of opCmp that I should
be aware of? Is there any reason that doing this may be not be wise?
No, this is fine.
On 02/16/2014 04:13 PM, Timon Gehr wrote:
On 02/16/2014 02:59 PM, Saurabh Das wrote:
This does compile and run correctly, but are there any hidden
assumptions or requirements on the return value of opCmp that I should
be aware of? Is there any reason that doing this may be not be wise?
No,
Timon Gehr:
assert(S(1)S(2)); // passes. ok.
assert(S(int.min)S(int.max)); // passes. oops.
A possible solution is to add to Phobos (unless it's already
there) a variadic templated funcion cmpBuilder() that accepts an
even number of arguments, that are seen as pairs. Usage example:
On 02/16/2014 04:40 PM, bearophile wrote:
Timon Gehr:
assert(S(1)S(2)); // passes. ok.
assert(S(int.min)S(int.max)); // passes. oops.
A possible solution is to add to Phobos (unless it's already there) a
variadic templated funcion cmpBuilder() that accepts an even number of
BigInt is a struct == ValueType, suppose i can assign
const(BigInt) to BigInt
const(BigInt)/const(BigInt) do not compile.
Is it a bug or design considerations?
test.d
import std.stdio;
import std.bigint;
void foo(BigInt b)
{
std.stdio.writefln(foo(%s), b);
}
void main()
{
Ruslan Mullakhmetov:
Is it a bug or design considerations?
It was a const correctness bug, but it's already fixed in recent
D compilers.
Bye,
bearophile
On Sunday, 16 February 2014 at 20:36:32 UTC, bearophile wrote:
Ruslan Mullakhmetov:
Is it a bug or design considerations?
It was a const correctness bug, but it's already fixed in
recent D compilers.
Bye,
bearophile
recent D compilers.
i use v2.064.2. is it outdated ?
Ruslan Mullakhmetov:
i use v2.064.2. is it outdated ?
It will be fixed in dmd 2.065. It's not yet out but you can use
it already if you want to be on the bleeding edge, it's
currently in beta3 and most regressions are fixed, so it's
probably better than using dmd 2.064.2.
Bye,
bearophile
On Sunday, 16 February 2014 at 12:51:10 UTC, bearophile wrote:
If you have a limited number of small values (like 30 ints)
using a sorted array is quite efficient, and keeps low the
binary size and the pressure on the code L1 cache :-)
Yup, I admit I over-generalized.
But this sorted array
-
import std.math;
import std.stdio;
void main()
{
writefln(nextUp of %a is %a, 1.0, 1.0.nextUp());
real num = 1.0;
writefln(nextUp of %a is %a, num, num.nextUp());
}
-
This prints:
nextUp of 0x1p+0 is 0x1.1p+0
nextUp of 0x1p+0 is 0x1.0002p+0
Any
On 2/16/14, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
Any idea why the results are different?
Interestingly the literal versions end up calling nextUp which takes a
double rather than a real. So nextUp(1.0) calls the double overload,
nextUp(num) calls the real overload. Mystery solved.
On 02/16/2014 01:42 PM, Andrej Mitrovic wrote:
-
import std.math;
import std.stdio;
void main()
{
writefln(nextUp of %a is %a, 1.0, 1.0.nextUp());
That line uses doubles.
real num = 1.0;
writefln(nextUp of %a is %a, num, num.nextUp());
That one uses reals.
}
On Saturday, 15 February 2014 at 13:28:24 UTC, simendsjo wrote:
http://youtu.be/8TV9ZZteYEU
The content wasn't planned, and English is not my native tongue.
Hopefully it can still be useful for newbies.
This is pretty much a response to a recent discussion on the
lack of
Hiho,
thanks again for your answers!
I don't know where to start ...
@Stanislav Blinov:
I am not currently aware of the move semantics in D or what it
is called there. However, I am not quite sure if D does an
equally good job as C++ in determining if a value can be moved or
not. I have
On Sunday, 16 February 2014 at 22:57:44 UTC, Brad Anderson wrote:
(...)
Nicely done.
It's a bit quiet (I had to max out my volume and put on
headphones to hear).
Thanks. I'll crank up the volume for the next one.
On Sunday, 16 February 2014 at 23:47:08 UTC, Robin wrote:
I am not currently aware of the move semantics in D or what
it is called there. However, I am not quite sure if D does an
equally good job as C++ in determining if a value can be moved
or not. I have made some simple tests which showed
If you swap the line to
writefln(nextUp of %a is %a, 1.0L, 1.0L.nextUp());
you get the same result as the second case.
On Saturday, 15 February 2014 at 13:28:24 UTC, simendsjo wrote:
http://youtu.be/8TV9ZZteYEU
The content wasn't planned, and English is not my native tongue.
Hopefully it can still be useful for newbies.
This is pretty much a response to a recent discussion on the
lack of
Robin:
I always thought that D would be much easier to learn than C++
as all the people always say that C++ is the most complex
language. After what I have learned so far D seems to be much
more complex which isn't bad in general, but the learning curve
doesn't feel so well atm as I am
On Sunday, 16 February 2014 at 15:19:08 UTC, Timon Gehr wrote:
On 02/16/2014 04:13 PM, Timon Gehr wrote:
On 02/16/2014 02:59 PM, Saurabh Das wrote:
This does compile and run correctly, but are there any hidden
assumptions or requirements on the return value of opCmp that
I should
be aware
Why is it that with 32 bit compilation, int is 32 bits, but
apparently this convention is not followed in 64 bit compilation.
I have not installed the 64 bit compiler yet, but apparently
int len = parent.children.length+1;
provokes the following error
acomp.d(782): Error: cannot implicitly
On Monday, 17 February 2014 at 07:15:20 UTC, Steve Teale wrote:
Why is it that with 32 bit compilation, int is 32 bits, but
apparently this convention is not followed in 64 bit
compilation.
I have not installed the 64 bit compiler yet, but apparently
int len = parent.children.length+1;
On Monday, 17 February 2014 at 07:15:20 UTC, Steve Teale wrote:
Why is it that with 32 bit compilation, int is 32 bits, but
apparently this convention is not followed in 64 bit
compilation.
I have not installed the 64 bit compiler yet, but apparently
int len = parent.children.length+1;
On 2/17/2014 4:23 PM, evilrat wrote:
but it looks like length is not size_t but ulong in which case you need
explicit cast from larget to smaller type. check lenght signature
size_t is an alias to ulong on 64-bit. Aliases tend to show up in error
messages as the underlying type.
On 2/17/2014 4:15 PM, Steve Teale wrote:
parent is just a straightforward array
What is size_t for 64 bit?
It's ulong on 64-bit and uint on 32. size_t and ptrdiff_t are defined as
aliases in object.d.
On Monday, 17 February 2014 at 07:46:02 UTC, Steve Teale wrote:
On Monday, 17 February 2014 at 07:17:06 UTC, Steve Teale wrote:
What is size_t for 64 bit?
Steve
Sorry parent.children is just a straightforward array
Sorry again - forget about it. I'd forgotten that D actually
says int is
On Monday, 17 February 2014 at 07:17:06 UTC, Steve Teale wrote:
What is size_t for 64 bit?
Steve
Sorry parent.children is just a straightforward array
Sorry again - forget about it. I'd forgotten that D actually says
int is 32 bits, and ulong is 64, and size_t for a 64 bit machine
is
38 matches
Mail list logo
