On 8/6/12 11:42 AM, Andrei Alexandrescu wrote:
Not sure whether this has been announced here:
http://www.gamedev.net/blog/1140/entry-2254003-binding-d-to-c/
Andrei
And on reddit:
http://www.reddit.com/r/programming/comments/xrppn/binding_d_to_c_4parts_blog/
Andrei
On 2012-08-06 17:42, Andrei Alexandrescu wrote:
Not sure whether this has been announced here:
http://www.gamedev.net/blog/1140/entry-2254003-binding-d-to-c/
Andrei
I'm pretty sure it has.
--
/Jacob Carlborg
On Monday, 6 August 2012 at 15:42:48 UTC, Andrei Alexandrescu
wrote:
Not sure whether this has been announced here:
http://www.gamedev.net/blog/1140/entry-2254003-binding-d-to-c/
Andrei
Really cool)
I think std.hash is ready for review now. I'm not sure if any other
module in the review queue is ready, but as there was no clear response
in the last review thread I assume we can start the std.hash review.
We still need a review manager though.
---
std.hash.hash is a new module
On Sunday, 5 August 2012 at 16:10:51 UTC, João Matos wrote:
I think so. I'll be taking a look at this soon, I'm interested
in getting it to work on Windows. If someone wants to
collaborate on it, feel free to mail me.
I'd be happy to help if you have any questions regarding the LDC
side of
In D it's not possible to make opCast operators implicit.
Therefore I see no way of making transparent wrappers; like
structs which could be used as a drop-in replacement for plain
old data types.
E.g if I wanted to make a SafeInt struct, that behaves otherwise
just like an int, but when
Tommi , dans le message (digitalmars.D:174314), a écrit :
In D it's not possible to make opCast operators implicit.
Therefore I see no way of making transparent wrappers; like
structs which could be used as a drop-in replacement for plain
old data types.
E.g if I wanted to make a SafeInt
On Mon, 06 Aug 2012 15:29:47 +0200, Tommi tommitiss...@hotmail.com wrote:
If you use alias this to _reveal_
the internal int value of SafeInt, then that int value's default
operators are used, and thus no overflow checking.
No.
--
Simen
Jonathan M Davis , dans le message (digitalmars.D:174310), a écrit :
IMO, the behavior should be this: when trying to call the template with
a argument that is an enum type based on string, the compiler should try
to instanciate the template for this enum type, and isSomeString should
fail.
E.g if I wanted to make a SafeInt struct, that behaves otherwise
just like an int, but when operators like +=, *=, ++, -- etc are
used with it, my custom SafeInt operators would check that
there's no integer overflow.
If you use alias this to _reveal_
the internal int value of SafeInt, then
On 8/1/12 21:10 , Walter Bright wrote:
8. Lexer should be configurable as to whether it should collect
information about comments and ddoc comments or not
9. Comments and ddoc comments should be attached to the next following
token, they should not themselves be tokens
I believe there should
On Monday, 6 August 2012 at 13:59:30 UTC, jerro wrote:
Wouldn't you have the exact same problem with implicit casts in
C++? If you want to use custom operators, you should just
define those, same as you would in C++. You can even implement
just some operators and use alias this for
On 08/06/12 15:29, Tommi wrote:
In D it's not possible to make opCast operators implicit.
Therefore I see no way of making transparent wrappers; like
structs which could be used as a drop-in replacement for plain
old data types.
E.g if I wanted to make a SafeInt struct, that behaves
On 5 August 2012 06:33, F i L witte2...@gmail.com wrote:
core.simd vectors are limited in a couple of annoying ways. First, if I
define:
@property pure nothrow
{
auto x(float4 v) { return v.ptr[0]; }
auto y(float4 v) { return v.ptr[1]; }
auto z(float4 v) {
On 7/28/12, Kai Nacke k...@redstar.de wrote:
Build instructions are here:
https://github.com/ldc-developers/ldc/wiki/Building-and-hacking-LDC-on-Windows-using-MSVC
Can LDC compile D apps that use Phobos? It says never tried to use
Phobos here:
Le 04/08/2012 23:09, Jonathan M Davis a écrit :
At present (though it didn't used to work this way until about 4 months ago -
the change is in 2.060), a number of std.traits templates - including
isSomeString - evaluate to false for enums. So,
enum E : string { a = hello }
static
Le 05/08/2012 14:38, Christophe Travert a écrit :
Jonathan M Davis , dans le message (digitalmars.D:174267), a écrit :
On Saturday, August 04, 2012 15:22:34 Jonathan M Davis wrote:
On Sunday, August 05, 2012 00:15:02 Timon Gehr wrote:
T fun(T)(T arg) if(isSomeString!arg){
return
It is known that some part of D are very dmd's implementation defined.
One of the part is manipulation function as first class objects and
implicitly calling them.
Some digressions about functional programing first.
Functional programming emphasis function purity, function as first class
On 07/31/2012 03:27 PM, Dmitry Olshansky wrote:
On 31-Jul-12 20:10, Kai Meyer wrote:
On 07/05/2012 06:11 AM, Denis Shelomovskij wrote:
There are more and more projects requiring parsing D code (IDE plugins,
DCT and dfmt now).
We definitely need a _standard_ fast D parser (suitable as
deadalnix:
The same way, the difference between a delegate and an expression don't
exist anymore.
int fun();
int fun(int t);
One solution would be to find a way that would enable fun to be both a
function and its return type, and that would enable 1.fun to be both
delegate and its return
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the language.
On Saturday, 4 August 2012 at 20:53:53 UTC, Adam D. Ruppe wrote:
On Saturday, 4 August 2012 at 19:08:58 UTC, Jacob Carlborg
wrote:
foo += 10;
Is rewritten as:
auto __tmp = foo;
foo = __tmp + 10;
I did this and now I think this thing is almost done
===
int a;
@property int funcprop() {
On Monday, 6 August 2012 at 15:28:04 UTC, Andrej Mitrovic wrote:
Can LDC compile D apps that use Phobos? It says never tried to
use
Phobos here:
https://github.com/ldc-developers/ldc/wiki/Project-Status
Does that apply only for 64bit builds? I'm interested in a
32bit build.
This only
On 08/06/2012 08:08 AM, Artur Skawina wrote:
There's sort-of limited support for implicit-casts - 'alias this'
with a getter. That does not force exposure of the internal
representation, but has other problems. The main one is of course
that there can only be one 'alias this'.
Luckily, it's
Le 06/08/2012 19:25, Timon Gehr a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the language.
We already have bizantine language rule here.
Le 06/08/2012 19:20, Christophe Travert a écrit :
What do you think?
The implicit cast is likely to create madness, especially for template
instantiation.
Le 05/08/2012 11:47, Simen Kjaeraas a écrit :
On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum jakobov...@gmail.com
wrote:
On Friday, 3 August 2012 at 19:19:24 UTC, Alex Rønne Petersen wrote:
Does anyone else find this behavior too strict?
Yes. Sounds like yet another case of forcing bitwise
On Monday, 6 August 2012 at 16:40:02 UTC, deadalnix wrote:
It is known that some part of D are very dmd's implementation
defined. One of the part is manipulation function as first
class objects and implicitly calling them.
...
To me, the first big failure of D to implement functional style
Le 04/08/2012 15:45, Dmitry Olshansky a écrit :
On 04-Aug-12 15:48, Jonathan M Davis wrote:
On Saturday, August 04, 2012 15:32:22 Dmitry Olshansky wrote:
I see it as a compile-time policy, that will fit nicely and solve both
issues. Just provide a templates with a few hooks, and add a Noop
To me, the first big failure of D to implement functional style
is to not have first class functions. You get a function using
operator. But does it really make sense ? See code below :
void foo(){}
void bar(void function() buzz) {}
void main() { bar(foo); } // This will execute foo, and so
On 06-08-2012 19:57, deadalnix wrote:
Le 05/08/2012 11:47, Simen Kjaeraas a écrit :
On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum jakobov...@gmail.com
wrote:
On Friday, 3 August 2012 at 19:19:24 UTC, Alex Rønne Petersen wrote:
Does anyone else find this behavior too strict?
Yes. Sounds
On 05-08-2012 11:47, Simen Kjaeraas wrote:
On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum jakobov...@gmail.com
wrote:
On Friday, 3 August 2012 at 19:19:24 UTC, Alex Rønne Petersen wrote:
Does anyone else find this behavior too strict?
Yes. Sounds like yet another case of forcing bitwise
On 08/06/2012 07:54 PM, deadalnix wrote:
Le 06/08/2012 19:25, Timon Gehr a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the language.
We already have
On 08/06/2012 06:40 PM, deadalnix wrote:
It is known that some part of D are very dmd's implementation defined.
One of the part is manipulation function as first class objects and
implicitly calling them.
Some digressions about functional programing first.
Functional programming emphasis
On 08/06/2012 08:05 PM, David Piepgrass wrote:
...
I'm not sure if I understand your point perfectly, but I definitely feel
that the way D handles optional parens is awful. The other day I noticed
that the following is a syntax error (DMD 2.059):
class A { void B() {} }
auto a = new A().B();
Consider following program abc.def:
import std.stdio;
void main()
{
foo();
abc.foo();
}
string val = abc.val;
void foo()
{
writeln(abc.val);
}
It produces expected results. Now create new module def.d:
import std.stdio;
void foo()
{
writeln(def.foo);
}
@property string
Le 06/08/2012 20:01, Mafi a écrit :
This comes from the 'real' function type is 'void f()' whose usage is
deprecated in D except for any function-/method-declaration:
Imagine a C-style declaration of the fuction type and you'll come to the
conclusion it's the way one defines functions in
I cut my teeth on perl, so everything gets compared to perl in my mind.
In perl, I can 'precompile' a regular expression, so I can avoid some
overhead. So something like this:
while(STDIN){
if($_ =~ m/someregex/){
some work;
}
}
Would end up re-compiling the regex on
On Mon, Aug 6, 2012 at 8:03 PM, deadalnix deadal...@gmail.com wrote:
The most complex thing that is needed is the policy to allocate identifiers
in tokens. It can be made by passing a function that have a string as
parameter and a string as return value. The default one would be an identity
On Monday, 6 August 2012 at 18:29:38 UTC, deadalnix wrote:
Le 06/08/2012 20:01, Mafi a écrit :
This comes from the 'real' function type is 'void f()' whose
usage is
deprecated in D except for any function-/method-declaration:
Imagine a C-style declaration of the fuction type and you'll
come
On 2012-08-06 21:00, Philippe Sigaud wrote:
Yes, well we don't have a condition system. And using exceptions
during lexing would most probably kill its efficiency.
Errors in lexing are not uncommon. The usual D idiom of having an enum
StopOnError { no, yes } should be enough.
Especially when
Le 06/08/2012 20:15, Timon Gehr a écrit :
To me, the first big failure of D to implement functional style is to
not have first class functions.
Last time I checked, D still had closures. The 'first big failure of D
to implement functional style' is the lack of most of the other
features
On 06-Aug-12 22:52, Philippe Sigaud wrote:
I cut my teeth on perl, so everything gets compared to perl in my mind.
In perl, I can 'precompile' a regular expression, so I can avoid some
overhead. So something like this:
while(STDIN){
if($_ =~ m/someregex/){
some work;
}
}
On Mon, Aug 6, 2012 at 9:31 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote:
Of course regex is first compiled to bytecode (same thing as compile in
perl). Moreover if you use regex pattern directly it is compiled on first
use and put into TLS cache of compiled patterns. From now on it's used
Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the language.
What exactly do you consider byzantine here,
Le 06/08/2012 21:07, Mafi a écrit :
No dereferencing is done in the compiled code anyway. BTW, an «
address of » operation is done on the type mentioned above.
I don't get what you are saying here. For me there's an inherent
difference between a fuction and a function pointer. You shouldn't
The intention was that std.simd would be flat C-style api,
which would be
the lowest level required for practical and portable use.
Since LDC and GDC implement intrinsics with an API different from
that used in DMD, there are actually two kinds of portability we
need to worry about -
On 06-Aug-12 23:43, Philippe Sigaud wrote:
On Mon, Aug 6, 2012 at 9:31 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote:
Of course regex is first compiled to bytecode (same thing as compile in
perl). Moreover if you use regex pattern directly it is compiled on first
use and put into TLS cache
Le 06/08/2012 21:42, Christophe Travert a écrit :
Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the
On 06-Aug-12 23:59, Dmitry Olshansky wrote:
And there is a second version - compiled native code. Unlike perl it's not
bytecode and thus usually much faster.
Which?
Compiled native code is faster. Perl is slower.
--
Dmitry Olshansky
On 06-Aug-12 22:03, deadalnix wrote:
Le 04/08/2012 15:45, Dmitry Olshansky a écrit :
On 04-Aug-12 15:48, Jonathan M Davis wrote:
On Saturday, August 04, 2012 15:32:22 Dmitry Olshansky wrote:
I see it as a compile-time policy, that will fit nicely and solve both
issues. Just provide a
On 8/6/2012 12:00 PM, Philippe Sigaud wrote:
Yes, well we don't have a condition system. And using exceptions
during lexing would most probably kill its efficiency.
Errors in lexing are not uncommon. The usual D idiom of having an enum
StopOnError { no, yes } should be enough.
That's why I
On 08/06/2012 09:42 PM, Christophe Travert wrote:
Timon Gehr , dans le message (digitalmars.D:174329), a écrit :
On 08/06/2012 07:20 PM, Christophe Travert wrote:
What do you think?
Creating byzantine language rules to cater to unimportant or
non-existent use cases will slaughter the
On 06-Aug-12 14:36, Johannes Pfau wrote:
I think std.hash is ready for review now. I'm not sure if any other
module in the review queue is ready, but as there was no clear response
in the last review thread I assume we can start the std.hash review.
We still need a review manager though.
Hm,
Le 06/08/2012 22:45, Timon Gehr a écrit :
It isn't. My point is that there actually is no issue that would
require some complex solution.
Actually, we have a very complex solution with no issue. That is in
itself, an issue, especially when that very complex solution isn't
defined properly
On 08/06/2012 09:33 PM, deadalnix wrote:
Le 06/08/2012 20:15, Timon Gehr a écrit :
To me, the first big failure of D to implement functional style is to
not have first class functions.
Last time I checked, D still had closures. The 'first big failure of D
to implement functional style' is the
On 2012-08-06 22:26, Dmitry Olshansky wrote:
No.
And doing Tokens as special comment token is frankly bad idea. See
Walter's comments in this thread.
Also e.g. For compiler only DDoc ones are ever useful, not so for IDE.
Filtering them out later is inefficient, as it would be far better not
On 07-Aug-12 01:48, Jacob Carlborg wrote:
On 2012-08-06 22:26, Dmitry Olshansky wrote:
No.
And doing Tokens as special comment token is frankly bad idea. See
Walter's comments in this thread.
Also e.g. For compiler only DDoc ones are ever useful, not so for IDE.
Filtering them out later is
FYI, I believe that bugs 8370 and 8375, to do with std.path.sep
being deprecated, are fixed in the latest version.
Does anybody have any clues how to proceed with bug 8250
dirEntries fails to generate file list when compiled with
-inline. I also hit this bug, on my second day of playing with D
On Tuesday, August 07, 2012 00:00:49 Philip Daniels wrote:
This exhibits the problem when compiled with -inline. I then
removed the import std.file line and copied and pasted the
entire contents of file.d into this test harness, so that it is
self contained. dirEntries now works correctly.
Hi,
Has anyone managed to get the 2.060 .deb working on Ubuntu 12.04? On all
12.04 systems I have access to, all D programs consistently segmentation
fault in gc_init().
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
On Thursday, 2 August 2012 at 04:48:56 UTC, Walter Bright wrote:
On 8/1/2012 9:41 PM, H. S. Teoh wrote:
Whether it's part of the range type or a separate lexer type,
*definitely* make it possible to have multiple instances. One
of the
biggest flaws of otherwise-good lexer generators like lex
On 07-08-2012 02:12, Alex Rønne Petersen wrote:
Hi,
Has anyone managed to get the 2.060 .deb working on Ubuntu 12.04? On all
12.04 systems I have access to, all D programs consistently segmentation
fault in gc_init().
Seems to only occur for 64-bit binaries built with DMD. 32-bit ones work
On Monday, 6 August 2012 at 15:15:30 UTC, Manu wrote:
I think core.simd is only designed for the lowest level of
access to the
SIMD hardware. I started writing std.simd some time back; it is
mostly
finished in a fork, but there are some bugs/missing features in
D's SIMD
support preventing me
F i L wrote:
On a side note, DMD without SIMD is much faster than C# without
SIMD, by a factor of 8x usually on simple vector types...
Excuse me, this should have said a factor of 4x, not 8x.
On 07-08-2012 02:59, Alex Rønne Petersen wrote:
On 07-08-2012 02:12, Alex Rønne Petersen wrote:
Hi,
Has anyone managed to get the 2.060 .deb working on Ubuntu 12.04? On all
12.04 systems I have access to, all D programs consistently segmentation
fault in gc_init().
Seems to only occur for
On Mon, Aug 6, 2012 at 10:00 PM, Dmitry Olshansky dmitry.o...@gmail.com wrote:
On 06-Aug-12 23:59, Dmitry Olshansky wrote:
And there is a second version - compiled native code. Unlike perl it's
not
bytecode and thus usually much faster.
Which?
Compiled native code is faster. Perl is
On Tuesday, 7 August 2012 at 04:58:05 UTC, Philippe Sigaud wrote:
Sorry, I meant: what second version? How do you distinguish
between
bytecode-producing and compiled-code producing ctRegex?
As far as I know, ctRegex _always_ produces machine code.
Bytecode is what the runtime implementation,
On Tue, Aug 7, 2012 at 2:12 AM, Alex Rønne Petersen a...@lycus.org wrote:
Hi,
Has anyone managed to get the 2.060 .deb working on Ubuntu 12.04? On all
12.04 systems I have access to, all D programs consistently segmentation
fault in gc_init().
That won't help you much, but on Kubuntu 12.04
On Tue, Aug 7, 2012 at 7:02 AM, David Nadlinger s...@klickverbot.at wrote:
As far as I know, ctRegex _always_ produces machine code. Bytecode is what
the runtime implementation, i.e. regex, uses.
That's what I had in mind too, but Dmitry seemed to say things are
more complicated. Maybe I
On 07-Aug-12 09:11, Philippe Sigaud wrote:
On Tue, Aug 7, 2012 at 7:02 AM, David Nadlinger s...@klickverbot.at wrote:
As far as I know, ctRegex _always_ produces machine code. Bytecode is what
the runtime implementation, i.e. regex, uses.
That's what I had in mind too, but Dmitry seemed to
class A { void B() {} }
auto a = new A().B();
// ^ semicolon expected following auto declaration, not '.'
Obviously. No clue what this snippet is trying to do.
Well I meant int B() { return 0; } of course. I think you
deliberately miss the point.
Dear,
1/
i would like have a code near as this haskell code:
fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
main = do
print $ sum (filter even (takeWhile (400) fibs))
Ii know in D:
- auto fib = recurrence!(a[n-1] + a[n-2])(1, 1);
- std.algorithm.until
- std.algorithm.filler
-
On Mon, 06 Aug 2012 11:53:18 +0200, bioinfornatics
bioinfornat...@gmail.com wrote:
Dear,
1/
i would like have a code near as this haskell code:
fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
main = do
print $ sum (filter even (takeWhile (400) fibs))
Ii know in D:
- auto fib =
On Mon, 06 Aug 2012 11:59:29 +0200, Simen Kjaeraas
simen.kja...@gmail.com wrote:
This is what you want, isn't it?
recurrence!((a,n)=a[n-1]+a[n-2])(1,1).until!(a=a=4)()
That is, the meat of it. The full line:
I'd like to share my files with you.
Here is the not_null_parser: http://dpaste.dzfl.pl/c522bd9f
re_name: http://dpaste.dzfl.pl/96928cd6
And the precompiler (which uses the above two):
http://dpaste.dzfl.pl/59de30f4
If you want to use it, compile all three and move them into
dmd(2) windows
I want to write a fibonacci(n) function that calculates the
result.
a) if n is known at compile time, use a template
b) if not, use a normal function
I know how to write a template version:
template fib(ulong n)
{
static if( n 2 )
const fib = n;
else
On Mon, 2012-08-06 at 12:15 +0200, Simen Kjaeraas wrote:
[…]
writeln(recurrence!((a,n)=a[n-1]+a[n-2])(1,1).until!(a=a=4)().filter!(a=a%2==0)().reduce!((a,b)=a+b)())
Do a JVM backend to D and D could wipe the floor with Scala :-)
--
Russel.
On Monday, 6 August 2012 at 13:10:50 UTC, Russel Winder wrote:
On Mon, 2012-08-06 at 12:15 +0200, Simen Kjaeraas wrote:
[…]
writeln(recurrence!((a,n)=a[n-1]+a[n-2])(1,1).until!(a=a=4)().filter!(a=a%2==0)().reduce!((a,b)=a+b)())
Do a JVM backend to D and D could wipe the floor with Scala
On Mon, 2012-08-06 at 15:13 +0200, Tobias Pankrath wrote:
On Monday, 6 August 2012 at 13:10:50 UTC, Russel Winder wrote:
On Mon, 2012-08-06 at 12:15 +0200, Simen Kjaeraas wrote:
[…]
writeln(recurrence!((a,n)=a[n-1]+a[n-2])(1,1).until!(a=a=4)().filter!(a=a%2==0)().reduce!((a,b)=a+b)())
Maybe you need a cast before malloc to convert it to a
s_blockInfo*?
On Monday, 6 August 2012 at 12:21:38 UTC, Minas Mina wrote:
I want to write a fibonacci(n) function that calculates the
result.
a) if n is known at compile time, use a template
b) if not, use a normal function
I know how to write a template version:
template fib(ulong n)
{
static if( n
Something like this:
template fib(ulong n)
{
static if( n 2 )
const fib = n;
else
const fib = fib!(n-1) + fib!(n-2);
if( n 2)
return n;
return fib(n-1) + fib(n-2);
}
It doesn't work of course, as I am in
On Monday, 6 August 2012 at 13:22:08 UTC, Minas Mina wrote:
Maybe you need a cast before malloc to convert it to a
s_blockInfo*?
Just did, and compiled. Errored out with (from my IDE):
(9:54:32 AM) AccessViolation-Exception
(9:54:32 AM) c005
(9:54:32 AM) Exception in debugger client
See the following code:
interface A{
}
class B : A{
this(string name){this.name = name;}
~this(){
writefln(Destructor %s, name);
}
string name;
}
void main(){
B b0 = new B(b0);
B b1 = new B(b1);
A a = b0;
clear(a);
clear(b1);
}
Output:
Destructor
On Monday, 6 August 2012 at 13:59:35 UTC, CrudOMatic wrote:
On Monday, 6 August 2012 at 13:22:08 UTC, Minas Mina wrote:
Maybe you need a cast before malloc to convert it to a
s_blockInfo*?
Just did, and compiled. Errored out with (from my IDE):
(9:54:32 AM) AccessViolation-Exception
(9:54:32
On Monday, 6 August 2012 at 13:46:14 UTC, Tobias Pankrath wrote:
You can check for compile time with
static if(__ctfe)
No, you can't.
__ctfe is a CTFE-ed(?) value.
But you can do something like that :
http://dpaste.dzfl.pl/e3f26239
Minas : I don't know if your PC is outdated, but it's
On Monday, 6 August 2012 at 14:14:12 UTC, Eyyub wrote:
On Monday, 6 August 2012 at 13:59:35 UTC, CrudOMatic wrote:
On Monday, 6 August 2012 at 13:22:08 UTC, Minas Mina wrote:
Maybe you need a cast before malloc to convert it to a
s_blockInfo*?
Just did, and compiled. Errored out with (from
On 08/06/12 15:46, Tobias Pankrath wrote:
On Monday, 6 August 2012 at 12:21:38 UTC, Minas Mina wrote:
I want to write a fibonacci(n) function that calculates the result.
a) if n is known at compile time, use a template
b) if not, use a normal function
I know how to write a template version:
On Monday, 6 August 2012 at 14:25:29 UTC, Eyyub wrote:
On Monday, 6 August 2012 at 13:46:14 UTC, Tobias Pankrath wrote:
You can check for compile time with
static if(__ctfe)
No, you can't.
__ctfe is a CTFE-ed(?) value.
But you can do something like that :
http://dpaste.dzfl.pl/e3f26239
On Mon, Aug 6, 2012 at 3:54 PM, Minas Mina minas_mina1...@hotmail.co.uk wrote:
Something like this:
template fib(ulong n)
{
static if( n 2 )
const fib = n;
else
const fib = fib!(n-1) + fib!(n-2);
if( n 2)
return
On Monday, 6 August 2012 at 15:18:22 UTC, Minas Mina wrote:
That's what I tried to calculate:
static x = fib(40);
ulong fib(ulong n)
{
if(n 2)
return n;
else
return fib(n-1) + fib(n-2);
}
Maybe because it has a lot of recursion?
That
On Monday, 6 August 2012 at 14:55:05 UTC, CrudOMatic wrote:
In C it was just declare and go...
Really ? I don't think, because : s_blockHeader* m_blockList;
Here, m_blockList is a pointer to s_blockHeader struct, and so
the default value is `null`.
So, trying to access to(?) a struct member
On Monday, 6 August 2012 at 15:21:38 UTC, Philippe Sigaud wrote:
On Mon, Aug 6, 2012 at 3:54 PM, Minas Mina
minas_mina1...@hotmail.co.uk wrote:
Something like this:
template fib(ulong n)
{
static if( n 2 )
const fib = n;
else
const fib =
On Mon, Aug 6, 2012 at 3:17 PM, Russel Winder rus...@winder.org.uk wrote:
Do a JVM backend to D and D could wipe the floor with Scala :-)
Why is that? Can't Scala do the same?
Scala can definitely do the same, possibly more, but it's syntax gets
annoying and compilation time is horrendous.
On Monday, 6 August 2012 at 15:21:38 UTC, Philippe Sigaud wrote:
On Mon, Aug 6, 2012 at 3:54 PM, Minas Mina
minas_mina1...@hotmail.co.uk wrote:
Something like this:
template fib(ulong n)
{
static if( n 2 )
const fib = n;
else
const fib =
On 8/6/12, Eyyub eyyub.pangeara...@gmail.com wrote:
Tell me if I'm wrong. (I did not programming in C since 2 years)
You're not wrong. m_blockList is a pointer and OP needs to allocate an
s_blockHeader instance before he uses it:
s_blockHeader* m_blockList =
On Monday, 6 August 2012 at 15:36:03 UTC, Andrej Mitrovic wrote:
On 8/6/12, Eyyub eyyub.pangeara...@gmail.com wrote:
Tell me if I'm wrong. (I did not programming in C since 2
years)
You're not wrong. m_blockList is a pointer and OP needs to
allocate an
s_blockHeader instance before he uses
On Mon, Aug 6, 2012 at 5:32 PM, Philippe Sigaud
philippe.sig...@gmail.com wrote:
What I'd like to know and may test myself is: is there any speed
difference in this functional-oriented D code and a more standard
(C-ish) way to obtain the same result?
Here it is. Answer: no noticeable
On Mon, Aug 6, 2012 at 5:33 PM, Minas Mina minas_mina1...@hotmail.co.uk wrote:
// calcuated at O(1) woohoo!
return cast(ulong)(a * pow(r0, cast(double)n) + b * pow(r1,
I wonder if there is any rounding error going on with these pow, but
yes, even better this way.
double f =
1 - 100 of 127 matches
Mail list logo
