On Thursday, 20 January 2011 at 18:19:21 UTC, Jacob Carlborg
wrote:
On 2011-01-20 14:47, Justin Johansson wrote:
Not long ago the Java Language people introduced the idea of
annotations
together with an annotation processing tool (apt).
Now perhaps the idea of source code annotations is not
Suppose I have
class A
{
mixin t!A;
}
is there a way to replace the mixin template's dependence on the
class name?
e.g.,
class A
{
mixin t!This; // This turns in to A
}
(so, for example, renaming the above class only has to rename one
place instead of two)
On Thursday, 30 January 2014 at 03:28:57 UTC, Craig Dillabaugh
wrote:
So, there is a module core.stdc.config (referenced here):
http://dlang.org/interfaceToC.html
That is presumably part of the D Standard library. I am
curious to know why no mention of this library is included at:
On Thursday, 30 January 2014 at 09:03:17 UTC, Frustrated wrote:
mixin t!(typeof(this))
On Thursday, 30 January 2014 at 09:14:43 UTC, Cooler wrote:
Please stop explain me how fun3() works. I know that.
One of the main idea of D is that things must work as planned,
or would not compile at all. First and second variants follow
this idea. But fun3() can work not as planned on the
On Wednesday, 29 January 2014 at 17:12:57 UTC, Stanislav Blinov
wrote:
On Wednesday, 29 January 2014 at 17:11:32 UTC, Ary Borenszweig
wrote:
Yes, as there are other ways for body: _body, _body, Body,
HtmlBody, etc. But body is the best one.
torso? ;)
offspring =
On Thursday, 30 January 2014 at 09:14:43 UTC, Cooler wrote:
If you want to modify the slice and make changes visible in
caller, you should use ref. If you don't care whether changes
are visible in caller, you can omit any attributes and use
plain array. This belongs to the case you are asking
On Thursday, 30 January 2014 at 10:15:10 UTC, Chris wrote:
offspring = document.createElement(div);
document.torso.addOffspring(div);
Looks great! :D
Hi,
I just read this nice article about slices:
http://dlang.org/d-array-article.html
So I tried this code to see if I understood it correctly:
---
import std.stdio;
void main() {
auto a = new int[5];
auto b = a;
a[0] = 1;
for(auto i = 0; i 100; i++) {
a ~= 0;
}
a[0] =
This prints:
a[0] = 2
b[0] = 1
That is, a was resized to a point where it needed to
reallocate its contents. b still holds a reference to the old
data. When, after the for loop, I change a's data, b's data
doesn't change.
Is this expected behaviour?
That's how it is.
How can I safely
Cooler:
Again - stop consider current state of D implementation.
Consider how we can make D better. I think fun3() push
programmers to make errors.
I think functions like void fun(int[] a){} are bug prone, because
you seem to change the length of the array inside the function,
or if you
On Thursday, 30 January 2014 at 10:49:42 UTC, Cooler wrote:
Now I am trying to speak ideally. What ideal language should
be, not the practical implementation.
...
Again - don't look back. Consider how we can make D better.
...
Again - stop consider current state of D implementation.
I was, I think, able to call an interface's method. I had the
code like the following
interface A
{
void foo();
}
class B : A { void foo() { writeln(Hey); } }
class C : A { void foo() { writeln(You); } }
yet, when I called a.foo(); I did not get any output. (A being of
type A)
Now, I
On Thursday, 30 January 2014 at 11:19:58 UTC, Frustrated wrote:
I was, I think, able to call an interface's method. I had the
code like the following
interface A
{
void foo();
}
class B : A { void foo() { writeln(Hey); } }
class C : A { void foo() { writeln(You); } }
yet, when I called
On Wednesday, 29 January 2014 at 18:05:41 UTC, Stanislav Blinov
wrote:
Yep, doesn't seem to be simd-related:
struct S(T) { T v1, v2; }
void main() {
alias T = double; // integrals and float are ok :\
version (workaround) {
S!T[1] p = void;
} else {
On Wednesday, 29 January 2014 at 14:34:54 UTC, Cooler wrote:
Here is ambiguity.
void fun3(int[] x){ x ~= 5; ... }
auto a = new int[10];
fun3(a); // Here content of a may be changed or may be not
changed. Depends on the buffer size that system will allocate
for a array.
You use very
On Thursday, 30 January 2014 at 12:50:34 UTC, John Colvin wrote:
On Thursday, 30 January 2014 at 10:43:55 UTC, Ary Borenszweig
wrote:
Hi,
I just read this nice article about slices:
http://dlang.org/d-array-article.html
So I tried this code to see if I understood it correctly:
---
import
On Thursday, 30 January 2014 at 10:43:55 UTC, Ary Borenszweig
wrote:
Hi,
I just read this nice article about slices:
http://dlang.org/d-array-article.html
So I tried this code to see if I understood it correctly:
---
import std.stdio;
void main() {
auto a = new int[5];
auto b = a;
On Thu, 30 Jan 2014 05:43:55 -0500, Ary Borenszweig a...@esperanto.org.ar
wrote:
Hi,
I just read this nice article about slices:
http://dlang.org/d-array-article.html
So I tried this code to see if I understood it correctly:
---
import std.stdio;
void main() {
auto a = new int[5];
Compiling with DMD 2.064, I am NOT able to get any function in
interfaces accepted unless they are final. This means you cannot
provide default behavior in the interface, at least not in the
ways shown above.
kOn Wed, 29 Jan 2014 05:55:56 -0500, Cooler kul...@hotbox.ru wrote:
Consider 3 functions taking array as an argument:
void fun1(in int[] x){...}
void fun2(ref int[] x){...}
void fun3(int[] x){...}
auto a = new int[10];
fun1(a); // Guaranteed that a will not be changed
fun2(a); //
On Thursday, 30 January 2014 at 07:26:51 UTC, Jacob Carlborg
wrote:
On 2014-01-30 05:42, Mike Parker wrote:
All of the core.* modules are part of DRuntime, not Phobos.
Unfortunately none of the core.stdc.* modules are documented.
It's understandable that duplicating the documentation of the
On Thursday, 30 January 2014 at 13:43:49 UTC, Casper Færgemand
wrote:
Compiling with DMD 2.064, I am NOT able to get any function in
interfaces accepted unless they are final. This means you
cannot provide default behavior in the interface, at least not
in the ways shown above.
Yes the void
On Thursday, 30 January 2014 at 09:03:47 UTC, Gary Willoughby
wrote:
On Thursday, 30 January 2014 at 03:28:57 UTC, Craig Dillabaugh
wrote:
So, there is a module core.stdc.config (referenced here):
http://dlang.org/interfaceToC.html
That is presumably part of the D Standard library. I am
Ok, didn't need to wait for the weekend :)
Looks like both dmd and ldc don't optimize slice operations yet,
had to revert to loops (shaved off ~1.5 seconds for ldc, ~9
seconds for dmd). Also, my local pull of ldc had some issues with
to!int(string), reverted that to atoi :)
Here's the code:
On Thursday, 30 January 2014 at 11:29:55 UTC, TheFlyingFiddle
wrote:
On Thursday, 30 January 2014 at 11:19:58 UTC, Frustrated wrote:
I was, I think, able to call an interface's method. I had the
code like the following
interface A
{
void foo();
}
class B : A { void foo() { writeln(Hey);
On Thursday, 30 January 2014 at 14:17:16 UTC, Stanislav Blinov
wrote:
Forgot one slice assignment in toDobule2(). Now the results are
more interesting:
time ./nbody-cpp 5000:
-0.169075164
-0.169059907
0:05.20 real, 5.18 user, 0.00 sys, 532 kb, 99% cpu
time ./nbody-ldc 5000:
On Thu, 30 Jan 2014 09:18:40 -0500, Cooler kul...@hotbox.ru wrote:
Forgot to mention :)
I read the rest of the discussion. Arrays are hard to understand in D,
especially if you have preconceived notions from other languages. But
I would point out that fun2 does not guarantee anything more
On Thu, 30 Jan 2014 09:07:14 -0500, Cooler kul...@hotbox.ru wrote:
If I don't want that fun() will change my array, i have to use fun1()
variant.
If I want fun() will change my array, i have to use fun2() variant. What
fun2() do with it's argument inside it's body - not my business.
No.
On Thursday, 30 January 2014 at 14:31:05 UTC, Frustrated wrote:
I'm not asking about a work around but if what I am talking
about
can actually be done(does the vtable support this or can made to
support it?)
It would work if you changed the interface to an abstract class.
On Thu, 30 Jan 2014 09:31:05 -0500, Frustrated c1514...@drdrb.com wrote:
I'm not asking about a work around but if what I am talking about
can actually be done(does the vtable support this or can made to
support it?)
Yes. Interfaces have no concrete vtable. Only classes do. A concrete class
On Thu, 30 Jan 2014 10:24:14 -0500, Cooler kul...@hotbox.ru wrote:
On Thursday, 30 January 2014 at 14:40:36 UTC, Dicebot wrote:
On Thursday, 30 January 2014 at 13:42:53 UTC, Cooler wrote:
If I use fun2() I expect that fun2() will change the content of my
array, and all changes I will see. If
Stanislav Blinov:
Forgot one slice assignment in toDobule2(). Now the results are
more interesting:
Is the latest link shown the last version?
I need the 0.13.0-alpha1 to compile the code.
I am seeing a significant performance difference between C++ and
D-ldc2.
Bye,
bearophile
On Thursday, 30 January 2014 at 15:49:35 UTC, Cooler wrote:
I agree. I just want that the case can be expressed in
language syntax more obvious - something like fun(int[]
const x){} to emphasize that I understand that fun() can
change content of array, and cannot change the {pointer,size}
Here: http://dlang.org/operatoroverloading.html#FunctionCall
is this example:
import std.stdio;
struct F {
int opCall() {
return 0;
}
int opCall(int x, int y, int z) {
return x * y * z;
}
}
void main() {
F f;
This does not compile on Windows, but does compile on Mac:
---
module main;
void main()
{
import std.path;
enum bar = import(`dir` ~ dirSeparator ~ `bar.txt`);
}
---
The docs say:
http://dlang.org/expression.html#ImportExpression
Implementations may restrict the file name in
On Thu, 30 Jan 2014 10:49:34 -0500, Cooler kul...@hotbox.ru wrote:
On Thursday, 30 January 2014 at 15:29:50 UTC, Steven Schveighoffer wrote:
On Thu, 30 Jan 2014 10:24:14 -0500, Cooler kul...@hotbox.ru wrote:
On Thursday, 30 January 2014 at 14:40:36 UTC, Dicebot wrote:
I agree. I just want
void main() {
F f;
int i = f(3,4,5);
float f_ = f!float(6, 7, 8);
}
Does not work, it fails with:
Error: template instance f!float f is not a template
declaration, it is a variable
f.opCall!float(6, 7, 8);
On Thursday, 30 January 2014 at 16:24:00 UTC, Stanislav Blinov
wrote:
void main() {
F f;
int i = f(3,4,5);
float f_ = f!float(6, 7, 8);
}
Does not work, it fails with:
Error: template instance f!float f is not a template
declaration, it is a variable
Stanislav Blinov:
You mean with your current version of ldc?
Yes. The older version of LDC2 doesn't even compile the code. I
need to use 0.13.0-alpha1.
Your D code with small changes:
http://codepad.org/xqqScd42
Asm generated by G++ for the advance function (that is the one
that uses
On Thursday, 30 January 2014 at 16:28:42 UTC, Namespace wrote:
On Thursday, 30 January 2014 at 16:24:00 UTC, Stanislav Blinov
wrote:
void main() {
F f;
int i = f(3,4,5);
float f_ = f!float(6, 7, 8);
}
Does not work, it fails with:
Error: template instance f!float f
On Thursday, 30 January 2014 at 16:47:46 UTC, Frustrated wrote:
On Thursday, 30 January 2014 at 16:28:42 UTC, Namespace wrote:
On Thursday, 30 January 2014 at 16:24:00 UTC, Stanislav Blinov
wrote:
void main() {
F f;
int i = f(3,4,5);
float f_ = f!float(6, 7, 8);
}
On Thursday, 30 January 2014 at 15:28:24 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 09:31:05 -0500, Frustrated
c1514...@drdrb.com wrote:
I'm not asking about a work around but if what I am talking
about
can actually be done(does the vtable support this or can made
to
support it?)
On Thursday, 30 January 2014 at 15:59:28 UTC, Namespace wrote:
Here: http://dlang.org/operatoroverloading.html#FunctionCall
is this example:
import std.stdio;
struct F {
int opCall() {
return 0;
}
int opCall(int x, int y, int z) {
On Thursday, 30 January 2014 at 16:53:22 UTC, bearophile wrote:
Yes. The older version of LDC2 doesn't even compile the code. I
need to use 0.13.0-alpha1.
Hmm.
Your D code with small changes:
http://codepad.org/xqqScd42
That won't compile with dmd (at least, with 2.064.2): it expects
On Thu, 30 Jan 2014 11:48:50 -0500, Cooler kul...@hotbox.ru wrote:
Please understand - I am not against void foo(int[] x){}
From an earlier post by you:
May be just prohibit at language level the case of fun3() function, to
do not allow unpredictable behavior?
I thought that this meant
On Thu, 30 Jan 2014 12:07:07 -0500, Cooler kul...@hotbox.ru wrote:
On Thursday, 30 January 2014 at 16:18:33 UTC, Steven Schveighoffer wrote:
void foo(int x)
{
x = 5;
}
hey, why doesn't that work! Setting a parameter to another value
should be illegal!
Difference is here.
void foo(int
On Thursday, 30 January 2014 at 16:48:51 UTC, Cooler wrote:
On Thursday, 30 January 2014 at 16:18:33 UTC, Steven
Schveighoffer wrote:
void foo(int x)
{
x = 5;
}
hey, why doesn't that work! Setting a parameter to another
value should be illegal!
-Steve
Please understand - I am not
On Thu, 30 Jan 2014 11:58:15 -0500, Frustrated c1514...@drdrb.com wrote:
Essentially what it boils down to is treating interfaces like
classes that have no fields). To avoid the diamond problem simply
always choose the method that is not from the interface(since it
is default), which is done
On Thursday, 30 January 2014 at 14:10:37 UTC, Craig Dillabaugh
wrote:
I did as you suggested and had a look through what was on my
system. Having done so I now think that the documentation at:
http://dlang.org/phobos/index.html
is out of date.
If you look at the section under Imports, this
On Thursday, 30 January 2014 at 17:11:24 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 11:58:15 -0500, Frustrated
c1514...@drdrb.com wrote:
Essentially what it boils down to is treating interfaces like
classes that have no fields). To avoid the diamond problem
simply
always choose
On Thursday, 30 January 2014 at 16:53:33 UTC, Namespace wrote:
On Thursday, 30 January 2014 at 16:47:46 UTC, Frustrated wrote:
On Thursday, 30 January 2014 at 16:28:42 UTC, Namespace wrote:
On Thursday, 30 January 2014 at 16:24:00 UTC, Stanislav
Blinov wrote:
void main() {
F f;
On Thu, 30 Jan 2014 12:30:04 -0500, Frustrated c1514...@drdrb.com wrote:
On Thursday, 30 January 2014 at 17:11:24 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 11:58:15 -0500, Frustrated c1514...@drdrb.com
wrote:
Essentially what it boils down to is treating interfaces like
classes
Stanislav Blinov:
That won't compile with dmd (at least, with 2.064.2): it
expects constants as initializers for vectors. :( That's why I
rolled up that toDouble2() function.
I see. Then probably I will have to put it back...
With N = 5_000_000 my timings on an old CPU are 2.23 seconds
Also,
http://dlang.org/operatoroverloading.html#Dispatch
and possible solution to your problem:
http://www.digitalmars.com/d/archives/digitalmars/D/opDispatch_and_template_parameters_117095.html
Couldn't get code to compile though... but if it did, it should
solve your problem.
On Thursday, 30 January 2014 at 16:55:01 UTC, Meta wrote:
On Thursday, 30 January 2014 at 15:59:28 UTC, Namespace wrote:
Here: http://dlang.org/operatoroverloading.html#FunctionCall
is this example:
import std.stdio;
struct F {
int opCall() {
return 0;
}
On Thu, 30 Jan 2014 12:38:57 -0500, Cooler kul...@hotbox.ru wrote:
The D principle - The program compile and runs as expected, or not
compile at all.
This is a fantasy. The compiler cannot know what you expect.
The language is needed to express your intentions to the compiler.
Anything
On Thursday, 30 January 2014 at 17:46:19 UTC, Frustrated wrote:
Also,
http://dlang.org/operatoroverloading.html#Dispatch
and possible solution to your problem:
http://www.digitalmars.com/d/archives/digitalmars/D/opDispatch_and_template_parameters_117095.html
Couldn't get code to compile
On Thursday, 30 January 2014 at 18:11:49 UTC, Frustrated wrote:
BTW,
a() is replaced with a.opCall()
and you can use opDispatch on it.
an opCall is a member.
Either approach should work if you can get that archive example
to compile.
I am sure that the error is thrown before.
But please
On Thu, 30 Jan 2014 13:06:30 -0500, Frustrated c1514...@drdrb.com wrote:
On Thursday, 30 January 2014 at 17:38:26 UTC, Steven
Schveighoffer wrote:
This is a misunderstanding, you still need to declare a class, because
an interface is not a concrete type. But if there are default
On Thu, 30 Jan 2014 13:16:21 -0500, Steven Schveighoffer
schvei...@yahoo.com wrote:
http://dlang.org/phobos/std_typecons.html#.BlackHole
Sorry, black hole just does nothing. it's white hole you want:
http://dlang.org/phobos/std_typecons.html#.WhiteHole
-Steve
Stanislav Blinov:
That won't compile with dmd (at least, with 2.064.2): it
expects constants as initializers for vectors. :( That's why I
rolled up that toDouble2() function.
Few more changes, but this version still lacks the toDouble2:
http://codepad.org/SpMprWym
Bye,
bearophile
On Thursday, 30 January 2014 at 18:29:42 UTC, bearophile wrote:
I see you're compiling with
ldmd2 -wi -O -release -inline -noboundscheck nbody.d
Try
ldc2 -release -O3 -disable-boundscheck -vectorize -vectorize-loops
Stanislav Blinov:
Looks like both dmd and ldc don't optimize slice operations
yet, had to revert to loops
It's a very silly problem for a statically typed language. The D
type system knows the static length of those arrays, but it
doesn't use such information.
(Similarly several algorithms
On Thu, 30 Jan 2014 13:58:55 -0500, Cooler kul...@hotbox.ru wrote:
The D principle - The program compile and runs as expected, or not
compile at all.
This is a fantasy. The compiler cannot know what you expect.
The language is needed to express your intentions to the compiler.
Anything
On Thursday, 30 January 2014 at 17:11:24 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 11:58:15 -0500, Frustrated
c1514...@drdrb.com wrote:
Essentially what it boils down to is treating interfaces like
classes that have no fields). To avoid the diamond problem
simply
always choose
On Thursday, 30 January 2014 at 18:43:02 UTC, bearophile wrote:
It's a very silly problem for a statically typed language. The
D type system knows the static length of those arrays, but it
doesn't use such information.
I agree.
Unrolling everything except the loop in energy() seems to have
On Thursday, 30 January 2014 at 20:05:11 UTC, Tofu Ninja wrote:
I hear it thrown around a lot but what does it actually mean?
What does the ideal D code look like? What kind of things
should some one think about if they are trying to do idiomatic
D?
There is no official idiomatic style like,
I hear it thrown around a lot but what does it actually mean?
What does the ideal D code look like? What kind of things should
some one think about if they are trying to do idiomatic D?
On Tuesday, 21 January 2014 at 19:00:32 UTC, Jeroen Bollen wrote:
On Tuesday, 21 January 2014 at 17:51:44 UTC, monarch_dodra
Is that your actual code? MersenneTwisterEngine(seed) is not
valid code, you have to provide the template arguments.
I meant to answer to this by the way, sorry. (in
On Thu, 30 Jan 2014 14:58:42 -0500, Frustrated c1514...@drdrb.com wrote:
On Thursday, 30 January 2014 at 17:11:24 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 11:58:15 -0500, Frustrated c1514...@drdrb.com
wrote:
Essentially what it boils down to is treating interfaces like
classes
import std.stdio;
struct B
{
template opCall(T)
{
void opCall(T x)
{
writeln(x);
}
}
}
template a(T)
{
}
void main() {
B a;
a(3); // works because template parameter can
On Thursday, 30 January 2014 at 20:17:23 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 14:58:42 -0500, Frustrated
c1514...@drdrb.com wrote:
On Thursday, 30 January 2014 at 17:11:24 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 11:58:15 -0500, Frustrated
c1514...@drdrb.com
Stanislav Blinov:
Unrolling everything except the loop in energy() seems to have
squeezed the bits neede to outperform c++, at least on my
machine :)
That should be impossible, as I remember from my old profilings
that energy() should use only an irrelevant amount of run time.
Stanislav Blinov:
ldc2 -release -O3 -disable-boundscheck -vectorize
-vectorize-loops
All my versions of ldc2 don't even accept -vectorize :-)
ldc2: Unknown command line argument '-vectorize'. Try: 'ldc2
-help'
ldc2: Did you mean '-vectorize-slp'?
And -vectorize-loops should be active on
On Thursday, 30 January 2014 at 21:16:05 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 15:57:06 -0500, Frustrated
c1514...@drdrb.com wrote:
On Thursday, 30 January 2014 at 20:17:23 UTC, Steven
Schveighoffer wrote:
But it's important to note that A does not define an instance
of
On Wednesday, 29 January 2014 at 10:55:57 UTC, Cooler wrote:
Consider 3 functions taking array as an argument:
void fun1(in int[] x){...}
void fun2(ref int[] x){...}
void fun3(int[] x){...}
auto a = new int[10];
fun1(a); // Guaranteed that a will not be changed
fun2(a); // Guaranteed
I'm starting to use D out of curiousity. I've used both Eclipse +
DDT and Visual Studio + visualD and both give the same error in
my second test program (second to Hello World of course...) using
the Transmogrifier/CardboardBox example from TDPL :
Error 42: Symbol Undefined
Simple question.
What are the difference between an interface and a class?
I'm not talking about what the compiler does with them. I'm
talking about what they were created to do, how they came about
etc.
If you have to explain to someone what a class is and what an
interface is, then you diff
On Thursday, 30 January 2014 at 21:04:06 UTC, bearophile wrote:
Stanislav Blinov:
Unrolling everything except the loop in energy() seems to have
squeezed the bits neede to outperform c++, at least on my
machine :)
That should be impossible, as I remember from my old profilings
that
On 01/30/2014 01:28 PM, Martijn Pot wrote:
I'm starting to use D out of curiousity. I've used both Eclipse + DDT
and Visual Studio + visualD and both give the same error in my second
test program (second to Hello World of course...) using the
Transmogrifier/CardboardBox example from TDPL :
I think for your example, the first case works fine using
deduction.
Sure but this is not always possible. ;)
It seems that the problem occurs also with opIndex and so
probably with all op* methods. See:
On Thursday, 30 January 2014 at 21:28:08 UTC, Martijn Pot wrote:
Error 42: Symbol Undefined
_D1a14Transmogrifier12transmogrifyMFZv (void
a.Transmogrifier.transmogrify())
Typically that means the function isn't implemented, e.g. this:
void transmogrify();
instead of this:
void
Stanislav Blinov:
I meant that if I unroll it, it's not irrelevant anymore :)
If a function takes no time to run, and you tweak it, your
program is not supposed to go faster.
I was going to compare the asm listings, but C++ seems to have
unrolled and inlined the outer loop right inside
On Thu, 30 Jan 2014 16:23:55 -0500, Frustrated c1514...@drdrb.com wrote:
Again, you have to get off of what has been defined. You have the
mentality exactly the same as those that thought the earth was
flat, imaginary numbers were nonsense/useless, man couldn't go to
the moon.
OK, then. With
On Thursday, 30 January 2014 at 21:33:38 UTC, bearophile wrote:
If a function takes no time to run, and you tweak it, your
program is not supposed to go faster.
Right.
I was going to compare the asm listings, but C++ seems to have
unrolled and inlined the outer loop right inside main(), and
Stanislav Blinov:
G++:
http://codepad.org/oOZQw1VQ
LDC:
http://codepad.org/5nHoZL1k
You seem to have a quite recent CPU, as the G++ code contains
instructions like vmovsd. So you can try to do the same with
ldc2, and use AVX or AVX2.
There are the switches:
-march=string-
On 1/30/14, Martijn Pot martijnpo...@gmail.com wrote:
Indeed, making them public solved the problem. Is there more
stuff in the book that isn't working?
Check the errata page[1], which coincidentally seems to be down. I'll CC Andrei.
[1]: http://erdani.com/tdpl/errata/index.php?title=Main_Page
On Thursday, 30 January 2014 at 21:54:17 UTC, bearophile wrote:
You seem to have a quite recent CPU,
An aging i3?
as the G++ code contains instructions like vmovsd. So you can
try to do the same with ldc2, and use AVX or AVX2.
Hmm...
This is getting a bit silly now. I must have some
On 1/30/14, Andrej Mitrovic andrej.mitrov...@gmail.com wrote:
On 1/30/14, Martijn Pot martijnpo...@gmail.com wrote:
Indeed, making them public solved the problem. Is there more
stuff in the book that isn't working?
Check the errata page[1], which coincidentally seems to be down. I'll CC
On Thursday, 30 January 2014 at 21:33:09 UTC, Namespace wrote:
I think for your example, the first case works fine using
deduction.
Sure but this is not always possible. ;)
It seems that the problem occurs also with opIndex and so
probably with all op* methods. See:
Stanislav Blinov:
An aging i3?
My CPU is older, it doesn't support AVX2 and AVX.
This is getting a bit silly now. I must have some compile
switches for g++ wrong:
g++ -Ofast -fkeep-inline-functions -fomit-frame-pointer
-march=native -mfpmath=sse -mavx -mssse3 -flto --std=c++11
-fopenmp
On Thursday, 30 January 2014 at 21:42:39 UTC, Steven
Schveighoffer wrote:
On Thu, 30 Jan 2014 16:23:55 -0500, Frustrated
c1514...@drdrb.com wrote:
Again, you have to get off of what has been defined. You have
the
mentality exactly the same as those that thought the earth was
flat, imaginary
On Thursday, 30 January 2014 at 20:10:01 UTC, Dicebot wrote:
On Thursday, 30 January 2014 at 20:05:11 UTC, Tofu Ninja wrote:
I hear it thrown around a lot but what does it actually mean?
What does the ideal D code look like? What kind of things
should some one think about if they are trying to
Since my post someone has added a Fortran version based on the
algorithm used in the C++11 code. It's a little faster than the
C++11 code and it's much nicer looking:
http://benchmarksgame.alioth.debian.org/u32/program.php?test=nbodylang=ifcid=5
pure subroutine advance(tstep, x, v, mass)
On Thursday, 30 January 2014 at 22:56:46 UTC, MrSmith wrote:
I have some function which does some matrix calculations and
prints them. It is actually calculationg determinant of the
matrix and i need to call those functions several times in the
loop, until i get the final result. Here is the
On 01/30/2014 03:08 PM, MrSmith wrote:
On Thursday, 30 January 2014 at 22:56:46 UTC, MrSmith wrote:
I have some function which does some matrix calculations and prints
them. It is actually calculationg determinant of the matrix and i need
to call those functions several times in the loop,
On Thursday, 30 January 2014 at 22:45:45 UTC, bearophile wrote:
Since my post someone has added a Fortran version based on the
algorithm used in the C++11 code. It's a little faster than the
C++11 code and it's much nicer looking:
Yup, I saw it. They're cheating, they almost don't have to
On 31/01/14 00:08, MrSmith wrote:
Somehow if i comment out
//matrix = solveTemp(temp);
it works, but this method works fine, and after it done1 is printed. Strange.
That does rather suggest that it's that method that is causing things to get
stuck. Can you share what's inside it? And when
On Friday, 31 January 2014 at 00:08:02 UTC, Meta wrote:
On Thursday, 30 January 2014 at 22:40:24 UTC, Tofu Ninja wrote:
Got any tips?
Ranges, templates and structs.
~= CTFE ~ UFCS
1 - 100 of 116 matches
Mail list logo
