On 02/04/12 02:03, Timon Gehr wrote:
On 02/03/2012 11:08 AM, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you, and in some instances, is
really
annoying.
On 02/04/2012 06:55 PM, Artur Skawina wrote:
On 02/04/12 02:03, Timon Gehr wrote:
On 02/03/2012 11:08 AM, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you, and
On 02/04/12 22:20, Timon Gehr wrote:
On 02/04/2012 06:55 PM, Artur Skawina wrote:
On 02/04/12 02:03, Timon Gehr wrote:
On 02/03/2012 11:08 AM, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const,
On 02/04/2012 11:23 PM, Artur Skawina wrote:
On 02/04/12 22:20, Timon Gehr wrote:
On 02/04/2012 06:55 PM, Artur Skawina wrote:
On 02/04/12 02:03, Timon Gehr wrote:
On 02/03/2012 11:08 AM, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it
On 02/04/12 23:44, Timon Gehr wrote:
On 02/04/2012 11:23 PM, Artur Skawina wrote:
On 02/04/12 22:20, Timon Gehr wrote:
On 02/04/2012 06:55 PM, Artur Skawina wrote:
Semi-related quiz:
immutable(char)[] a = a;
const(char)[] b = b;
auto aa = a ~ a;
auto bb = b ~ b;
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you, and in some instances, is really
annoying. Personally, I see no point in using in unless the parameter is a
reference type, and
On 03-02-2012 11:08, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you, and in some instances, is really
annoying. Personally, I see no point in using in unless
On 02/03/12 11:41, Artur Skawina wrote:
On 02/03/12 11:21, Alex Rønne Petersen wrote:
On 03-02-2012 11:08, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you,
On 03-02-2012 11:41, Artur Skawina wrote:
On 02/03/12 11:21, Alex Rønne Petersen wrote:
On 03-02-2012 11:08, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you,
On Friday, February 03, 2012 11:08:54 Artur Skawina wrote:
BTW, scope should have been the default for *all* reference type function
arguments, with an explicit modifier, say esc, required to let the thing
escape. It's an all-or-nothing thing, just like immutable strings - not
using it
On 02/03/12 13:06, Jonathan M Davis wrote:
On Friday, February 03, 2012 11:08:54 Artur Skawina wrote:
BTW, scope should have been the default for *all* reference type function
arguments, with an explicit modifier, say esc, required to let the thing
escape. It's an all-or-nothing thing, just
Jonathan M Davis:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you, and in some instances, is really
annoying.
Having const value types is useful because you can't change them later inside
the method. This helps you avoid
Artur Skawina:
Would marking the ctor as scope (similarly to const or pure) work for
your
case? (it is reasonable to expect that the compiler checks this by itself;
it's
per-type, so not nearly as expensive as analyzing the flow)
Maybe this is a topic worth discussing in the main D
Al 02/02/12 20:11, En/na Ali Çehreli ha escrit:
On 02/02/2012 11:00 AM, xancorreu wrote:
Al 02/02/12 19:18, En/na bearophile ha escrit:
Can I say serialize the first, second and third arguments as Class
Person?
I mean, if you define a class Person like:
class Person {
string name
uint
Al 02/02/12 20:40, En/na Jonathan M Davis ha escrit:
And whether that's the best way to handle it depends on what you're
trying to do in terms of user input and error messages. How on earth
is all of that going to be handled generically? It all depends on what
the programmer is trying to do.
Al 03/02/12 00:14, En/na bearophile ha escrit:
xancorreu:
But you only put a in in
recFactorial function argument. What this mean? **Why** this is more
efficient than mine?
It wasn't meant to improve performance. in turns a function argument to input only
(and eventually scoped too).
On 02/03/2012 11:08 AM, Artur Skawina wrote:
On 02/03/12 00:20, Jonathan M Davis wrote:
in is pointless on value types. All it does is make the function parameter
const, which really doesn't do much for you, and in some instances, is really
annoying. Personally, I see no point in using in
On 02/03/2012 01:06 PM, Jonathan M Davis wrote:
On Friday, February 03, 2012 11:08:54 Artur Skawina wrote:
BTW, scope should have been the default for *all* reference type function
arguments, with an explicit modifier, say esc, required to let the thing
escape. It's an all-or-nothing thing,
Timon Gehr:
However, it is
nice that the shortest storage class, 'in', implies scope.
I'd like to ask this to be valid, to shorten my code:
alias immutable imm;
Is this silly?
Bye,
bearophile
bearophile bearophileh...@lycos.com wrote in message
news:jgi3jn$2o6p$1...@digitalmars.com...
I'd like to ask this to be valid, to shorten my code:
alias immutable imm;
Is this silly?
Yes =)
immutable might be more characters than you want to type, but at this point
it's extremely unlikely
On 2/2/12 1:35 PM, xancorreu wrote:
In this code, how can I cast the args[0] string to int for computing
factorial(args[0])?
std.conv.to!int(…) or parse().
Hope this helps,
David
Use to!int(args[1])
I receive:
$ gdmd-4.6 factorial.d
factorial.d: In function ‘main’:
factorial.d:15:0: error: cannot cast expression of type string to int
Thanks in advance,
Xan.
Al 02/02/12 16:58, En/na David Nadlinger ha escrit:
On 2/2/12 1:35 PM, xancorreu wrote:
In this code, how can I cast the args[0] string to int for computing
factorial(args[0])?
std.conv.to!int(…) or parse().
to!int gives me this error:
$ ./factorial 222
Factorial requires a number
On Thursday, 2 February 2012 at 16:21:39 UTC, xancorreu wrote:
$ ./factorial 222
Factorial requires a number
args[0] is the name of your program.
(The first thing you typed on the command
line.)
Use args[1] to get that number.
parse() where is the doc?
Al 02/02/12 16:58, En/na David Nadlinger ha escrit:
On 2/2/12 1:35 PM, xancorreu wrote:
In this code, how can I cast the args[0] string to int for computing
factorial(args[0])?
std.conv.to!int(…) or parse().
Sorry, if condition was wrong. conv.to!int is perfect!
Thanks,
Hope this helps,
Why cast(int) does not work and I have to call another function?
Thanks,
Al 02/02/12 17:24, En/na Adam D. Ruppe ha escrit:
On Thursday, 2 February 2012 at 16:21:39 UTC, xancorreu wrote:
$ ./factorial 222
Factorial requires a number
args[0] is the name of your program.
(The first thing you
I get segment violation error with ./factorial 40
How can I resolve it?
My code is:
import std.stdio, std.bigint, std.string, std.conv, std.stream;
BigInt recFactorial(int n) {
if (n == 0)
return BigInt(1);
else
return (BigInt(n) * recFactorial(n - 1));
}
void
On 02-02-2012 17:26, xancorreu wrote:
Why cast(int) does not work and I have to call another function?
Thanks,
Al 02/02/12 17:24, En/na Adam D. Ruppe ha escrit:
On Thursday, 2 February 2012 at 16:21:39 UTC, xancorreu wrote:
$ ./factorial 222
Factorial requires a number
args[0] is the name
Alex Rønne Petersen Wrote:
On 02-02-2012 17:26, xancorreu wrote:
Why cast(int) does not work and I have to call another function?
Thanks,
Al 02/02/12 17:24, En/na Adam D. Ruppe ha escrit:
On Thursday, 2 February 2012 at 16:21:39 UTC, xancorreu wrote:
$ ./factorial 222
Factorial
Alex R. Petersen:
(Sorry for my last blank answer.)
Because D is a strongly typed language. Casting a string to an int
doesn't make sense from a type system perspective.
I think that D being strongly typed is not significant here. When you cast a
string to char* you are casting a 2 words
xancorreu:
I get segment violation error with ./factorial 40
How can I resolve it?
You are having a stack overflow. DMD currently doesn't print a good message
because of this regression that is being worked on:
http://d.puremagic.com/issues/show_bug.cgi?id=6088
On Windows with DMD you
On 02/02/2012 10:18 AM, bearophile wrote:
The cast() is meant to be a light and very quick conversion,
usually done at compile-time (unless it's a dynamic cast),
I first read it as if you were saying that dynamic cast is the only one
that is done at runtime. Actually many casts are done at
On Thursday, February 02, 2012 13:18:17 bearophile wrote:
Alex R. Petersen:
(Sorry for my last blank answer.)
Because D is a strongly typed language. Casting a string to an int
doesn't make sense from a type system perspective.
I think that D being strongly typed is not significant
On Thursday, February 02, 2012 10:36:06 Ali Çehreli wrote:
Just to be complete: You mean it for fundamental types. Of course user
types' opCast operators may throw:
import std.exception;
class C
{
int opCast(T : int)() const
{
enforce(false, Not good.);
return 42;
}
}
void main()
Al 02/02/12 19:30, En/na bearophile ha escrit:
xancorreu:
I get segment violation error with ./factorial 40
How can I resolve it?
You are having a stack overflow. DMD currently doesn't print a good message
because of this regression that is being worked on:
On 02/02/2012 11:00 AM, xancorreu wrote:
Al 02/02/12 19:18, En/na bearophile ha escrit:
Can I say serialize the first, second and third arguments as Class
Person?
I mean, if you define a class Person like:
class Person {
string name
uint age
dead bool
}
could you serialize the input
On Thursday, February 02, 2012 11:11:28 Ali Çehreli wrote:
On 02/02/2012 11:00 AM, xancorreu wrote:
Al 02/02/12 19:18, En/na bearophile ha escrit:
Can I say serialize the first, second and third arguments as Class
Person?
I mean, if you define a class Person like:
class Person
On 02/02/2012 08:04 PM, xancorreu wrote:
Al 02/02/12 19:30, En/na bearophile ha escrit:
xancorreu:
I get segment violation error with ./factorial 40
How can I resolve it?
You are having a stack overflow. DMD currently doesn't print a good
message because of this regression that is being
On Thu, Feb 02, 2012 at 10:55:06PM +0100, Timon Gehr wrote:
On 02/02/2012 08:04 PM, xancorreu wrote:
[...]
For the other hand, how can increase the stack in linux?
[...]
I don't know, but it is best to just rewrite the code so that it does
not use recursion.
(This kind of problem is
On Thu, Feb 02, 2012 at 02:47:22PM -0800, H. S. Teoh wrote:
[...]
int fib(int n) {
if (n = 2) return 1;
else return fib(n-2) + fib(n+1);
[...]
Ugh. That should be fib(n-1), not fib(n+1). But no matter, such a thing
shouldn't ever be actually written and
xancorreu:
But you only put a in in
recFactorial function argument. What this mean? **Why** this is more
efficient than mine?
It wasn't meant to improve performance. in turns a function argument to
input only (and eventually scoped too). Generally when you program in D2 it's
a good
On 02/02/2012 11:47 PM, H. S. Teoh wrote:
On Thu, Feb 02, 2012 at 10:55:06PM +0100, Timon Gehr wrote:
On 02/02/2012 08:04 PM, xancorreu wrote:
[...]
For the other hand, how can increase the stack in linux?
[...]
I don't know, but it is best to just rewrite the code so that it does
not use
Timon Gehr:
This is not a tail-recursive function. And neither is recFactorial, my
bad. Anyway, my point was that the compiler should not generate code
that blows up on a (in principle) perfectly sane implementation.
Is it possible to create a function attribute like @tail_recursive that
On Thursday, February 02, 2012 18:14:25 bearophile wrote:
xancorreu:
But you only put a in in
recFactorial function argument. What this mean? **Why** this is more
efficient than mine?
It wasn't meant to improve performance. in turns a function argument to
input only (and eventually
On Thursday, February 02, 2012 18:17:36 bearophile wrote:
Timon Gehr:
This is not a tail-recursive function. And neither is recFactorial, my
bad. Anyway, my point was that the compiler should not generate code
that blows up on a (in principle) perfectly sane implementation.
Is it
On Fri, Feb 03, 2012 at 12:10:01AM +0100, Timon Gehr wrote:
[...]
LList!ulong fib(){
LList!ulong r;
r=cons(st(1UL),cons(st(1UL),lz(()=zipWith((Lazy!ulong a,
Lazy!ulong b)=lz(()=a+b),r,r.tail)(;
return r;
}
Whoa. A caching recursive definition of fibonacci. Impressive!
Now I
On 02/02/2012 03:10 PM, Timon Gehr wrote:
LList!ulong fib(){
LList!ulong r;
r=cons(st(1UL),cons(st(1UL),lz(()=zipWith((Lazy!ulong a, Lazy!ulong
b)=lz(()=a+b),r,r.tail)(;
return r;
}
Sorry, wrong newsgroup. alt.comp.lang.perl is around the corner. :p
Ali
On Thu, Feb 02, 2012 at 03:26:52PM -0800, Ali Çehreli wrote:
On 02/02/2012 03:10 PM, Timon Gehr wrote:
LList!ulong fib(){
LList!ulong r;
r=cons(st(1UL),cons(st(1UL),lz(()=zipWith((Lazy!ulong a, Lazy!ulong
b)=lz(()=a+b),r,r.tail)(;
return r;
}
Sorry, wrong newsgroup.
48 matches
Mail list logo
