Daniel Keep wrote:
>> int? value1 = atoi("0"); // 0
>> int? value2 = atoi("#!$"); // null
>
> Not quite; that assumes null isn't a valid value. What if the function
> was "getInstance"?
T?? value = getInstance();
> Here's how I understand it to work. Functions may return a Maybe!(T),
> which
> I only had a short look, is it the NaN known from floating point types
> generalized to all types?
Not quite; NaNs don't abort your program (ignoring signalling NaNs, of
course.)
> Yay, The Power of None! That's what I was referring to when proposed
> nullable types:
>
> int? value1 = atoi("0
在 Tue, 24 Mar 2009 19:25:55 +0800,Christopher Wright
写道:
davidl wrote:
在 Tue, 24 Mar 2009 06:59:56 +0800,Christopher Wright
写道:
bearophile wrote:
Jarrett Billingsley:
What you're doing here is a blatant abuse of the exception system.
I am sorry.
bearophile
Don't apologize to Jarr
davidl wrote:
在 Tue, 24 Mar 2009 06:59:56 +0800,Christopher Wright
写道:
bearophile wrote:
Jarrett Billingsley:
What you're doing here is a blatant abuse of the exception system.
I am sorry.
bearophile
Don't apologize to Jarrett, apologize to the exception system.
He's comparing two d
在 Tue, 24 Mar 2009 06:59:56 +0800,Christopher Wright
写道:
bearophile wrote:
Jarrett Billingsley:
What you're doing here is a blatant abuse of the exception system.
I am sorry.
bearophile
Don't apologize to Jarrett, apologize to the exception system.
He's comparing two different thing
在 Mon, 23 Mar 2009 16:59:47 +0800,bearophile
写道:
Part of the timings, seconds:
N = 4_000_000:
C: 0.36
Java:5.59
C++: 9.97
Psyco: 29.28
Python: 32.68
D: 48.76 SLOW=false
D: 88.45 SLOW=true
You can find it here, with C/D/Java/C++/Python code too:
http:/
"It should be a native language feature."
dsimcha wrote:
In your string->int conversion example, it's
perfectly reasonable that the caller of int() might have no idea what a
reasonable
course of action would be if the conversion fails and would want to pass the
buck
to its caller. Therefore, exceptions are a perfectly reasonable way t
bearophile wrote:
Jarrett Billingsley:
What you're doing here is a blatant abuse of the exception system.
I am sorry.
bearophile
Don't apologize to Jarrett, apologize to the exception system.
Mon, 23 Mar 2009 17:11:56 -0400, bearophile wrote:
> bearophile:
>> N = 1_000_000_000:
>> C++: 0.06 s
>> D: 5.10 s
>
> I think GCC compiles most things away, so the run time is constant.
Yes, I think it detected there was no side effects and eliminated the
whole loop. That's why my origin
On Mon, 23 Mar 2009 16:32:03 +0300, Daniel Keep
wrote:
bearophile wrote:
grauzone:
From your site:<
I don't own LiveJournal :-) That's just my blog, my site is elsewhere.
Using exceptions in a string->int conversion routine is really
horrible and incredibly stupid.<
I agree that i
bearophile:
> N = 1_000_000_000:
> C++: 0.06 s
> D: 5.10 s
I think GCC compiles most things away, so the run time is constant.
Bye,
bearophile
Sergey Gromov:
>Different languages require different idioms, that's my strong opinion.<
I agree a lot, but it seems I need quite more than one year to learn most D
idioms. I am just ignorant and willing to learn.
> One really important benchmark would be something like this:
> results
> D: 5.
grauzone wrote:
bearophile wrote:
grauzone:
From your site:<
I don't own LiveJournal :-) That's just my blog, my site is elsewhere.
Using exceptions in a string->int conversion routine is really
horrible and incredibly stupid.<
I agree that it's not nice looking, but in Python that's th
== Quote from grauzone (n...@example.net)'s article
> Using exceptions in a string->int conversion routine is really horrible
> and incredibly stupid. It raises all these issues, just because you
> can't signal failure in a better way. For parsing input, failure should
> be something to be _expecte
Mon, 23 Mar 2009 09:07:16 -0400, bearophile wrote:
> grauzone:
>
>>From your site:<
>
> I don't own LiveJournal :-) That's just my blog, my site is elsewhere.
>
>> Using exceptions in a string->int conversion routine is really horrible and
>> incredibly stupid.<
>
> I agree that it's not nice
Daniel Keep wrote:
bearophile wrote:
grauzone:
>From your site:<
I don't own LiveJournal :-) That's just my blog, my site is elsewhere.
Using exceptions in a string->int conversion routine is really horrible and
incredibly stupid.<
I agree that it's not nice looking, but in Python that's
bearophile wrote:
grauzone:
From your site:<
I don't own LiveJournal :-) That's just my blog, my site is elsewhere.
Using exceptions in a string->int conversion routine is really horrible and
incredibly stupid.<
I agree that it's not nice looking, but in Python that's the standard idiom
bearophile wrote:
> grauzone:
>
>>From your site:<
>
> I don't own LiveJournal :-) That's just my blog, my site is elsewhere.
>
>
>> Using exceptions in a string->int conversion routine is really horrible and
>> incredibly stupid.<
>
> I agree that it's not nice looking, but in Python that'
Jarrett Billingsley:
> What you're doing here is a blatant abuse of the exception system.
I am sorry.
bearophile
On Mon, Mar 23, 2009 at 4:59 AM, bearophile wrote:
> Part of the timings, seconds:
> N = 4_000_000:
> C: 0.36
> Java: 5.59
> C++: 9.97
> Psyco: 29.28
> Python: 32.68
> D: 48.76 SLOW=false
> D: 88.45 SLOW=true
>From the D "Handling errors" page
(http://www.digitalm
grauzone:
>From your site:<
I don't own LiveJournal :-) That's just my blog, my site is elsewhere.
> Using exceptions in a string->int conversion routine is really horrible and
> incredibly stupid.<
I agree that it's not nice looking, but in Python that's the standard idiom.
In D I do the sam
From your site:
>Having fast exceptions is getting more important, for example it's
>important to have fast exceptions in Python because there they are
>sometimes used to control flow too. For example to convert a string to
>int/float the common Python idiom is to use a try/except.
I disagree. E
bearophile Wrote:
[...]
> And I'd also like to know why using printf changes the situation so much.
>
After a first glimpse with profiling the difference
is that printf pulls in stdarg, whereas writfln doesn't. Which means we replace
one oddity with another.
Ciao
Tom D.
Part of the timings, seconds:
N = 4_000_000:
C: 0.36
Java:5.59
C++: 9.97
Psyco: 29.28
Python: 32.68
D: 48.76 SLOW=false
D: 88.45 SLOW=true
You can find it here, with C/D/Java/C++/Python code too:
http://leonardo-m.livejournal.com/78890.html
I'd like to see
25 matches
Mail list logo