Doing simple stuff like
for(int i = 0; i < s.length - 1; i++) fails catastrophically if s
is empty. To make right one has to reduce performance by writing
extra checks.
There seems to be no real good reason why size_t is unsigned...
Surely one doesn't require too many strings larger than 2^6
On 07/21/2013 08:47 PM, JS wrote:
> Doing simple stuff like
>
> for(int i = 0; i < s.length - 1; i++) fails catastrophically if s is
> empty. To make right one has to reduce performance by writing extra
checks.
Checks are needed for program correctness. If not in source code, in
compiler gene
On Mon, Jul 22, 2013 at 05:47:34AM +0200, JS wrote:
> Doing simple stuff like
>
> for(int i = 0; i < s.length - 1; i++) fails catastrophically if s is
> empty. To make right one has to reduce performance by writing extra
> checks.
I'm not sure if it's your intention, but your code above has an of
On Monday, 22 July 2013 at 03:58:31 UTC, Ali Çehreli wrote:
On 07/21/2013 08:47 PM, JS wrote:
> Doing simple stuff like
>
> for(int i = 0; i < s.length - 1; i++) fails catastrophically
if s is
> empty. To make right one has to reduce performance by writing
extra checks.
Checks are needed for pr
On Monday, 22 July 2013 at 04:31:12 UTC, H. S. Teoh wrote:
On Mon, Jul 22, 2013 at 05:47:34AM +0200, JS wrote:
Doing simple stuff like
for(int i = 0; i < s.length - 1; i++) fails catastrophically
if s is
empty. To make right one has to reduce performance by writing
extra
checks.
I'm not su
On 07/21/2013 09:36 PM, JS wrote:
> On Monday, 22 July 2013 at 03:58:31 UTC, Ali Çehreli wrote:
>> > There seems to be no real good reason why size_t is
>> unsigned...
>>
>> How about, every addressable memory locations must be countable?
>
> for strings themselves, I would prefer an int to be r
On Mon, Jul 22, 2013 at 06:43:47AM +0200, JS wrote:
> On Monday, 22 July 2013 at 04:31:12 UTC, H. S. Teoh wrote:
> >On Mon, Jul 22, 2013 at 05:47:34AM +0200, JS wrote:
[...]
> >>There seems to be no real good reason why size_t is unsigned...
> >[...]
> >
> >The reason is because it must span the ra
On Monday, 22 July 2013 at 03:47:36 UTC, JS wrote:
Doing simple stuff like
for(int i = 0; i < s.length - 1; i++) fails catastrophically if
s is empty. To make right one has to reduce performance by
writing extra checks.
Not really, you could instead just write your loop correctly.
1. Don't l
On Monday, 22 July 2013 at 07:12:07 UTC, monarch_dodra wrote:
On Monday, 22 July 2013 at 03:47:36 UTC, JS wrote:
Doing simple stuff like
for(int i = 0; i < s.length - 1; i++) fails catastrophically
if s is empty. To make right one has to reduce performance by
writing extra checks.
Not reall
On Monday, 22 July 2013 at 09:34:35 UTC, JS wrote:
On Monday, 22 July 2013 at 07:12:07 UTC, monarch_dodra wrote:
On Monday, 22 July 2013 at 03:47:36 UTC, JS wrote:
Doing simple stuff like
for(int i = 0; i < s.length - 1; i++) fails catastrophically
if s is empty. To make right one has to redu
> how about s[i - 1..n]?
>
> You going to go throw some ifs around the statement that uses that? Use
> a ternary if? So I'm forced to use a longer more verbose method, and
> also introduce bugs, because the most obvious, simplest, and logical
> solution, s[max(0, i-1)..n] won't work.
-1 as index
On Mon, 22 Jul 2013 04:47:34 +0100, JS wrote:
Doing simple stuff like
for(int i = 0; i < s.length - 1; i++) fails catastrophically if s is
empty. To make right one has to reduce performance by writing extra
checks.
There seems to be no real good reason why size_t is unsigned... Surely
On Monday, 22 July 2013 at 11:56:35 UTC, Regan Heath wrote:
If we were to design the perfect type for representing a size
or length it would hold the maximum value of an unsigned int,
but would not undeflow to max unsigned int, instead it would
truncate.
This type would have to be built on to
On 7/22/13, JS wrote:
> foreach doesn't allow you to modify the index to skip over
> elements.
It does:
-
import std.stdio;
void main()
{
int[] x = [1, 2, 3, 4, 5];
foreach (ref i; 0 .. 5)
{
writeln(x[i]);
++i;
}
}
-
Writes:
1
3
5
On Monday, 22 July 2013 at 12:51:31 UTC, Andrej Mitrovic wrote:
On 7/22/13, JS wrote:
foreach doesn't allow you to modify the index to skip over
elements.
It does:
-
import std.stdio;
void main()
{
int[] x = [1, 2, 3, 4, 5];
foreach (ref i; 0 .. 5)
{
writeln(x[i]);
On Monday, 22 July 2013 at 12:51:31 UTC, Andrej Mitrovic wrote:
On 7/22/13, JS wrote:
foreach doesn't allow you to modify the index to skip over
elements.
It does:
-
import std.stdio;
void main()
{
int[] x = [1, 2, 3, 4, 5];
foreach (ref i; 0 .. 5)
{
writeln(x[i]);
On Monday, 22 July 2013 at 15:39:11 UTC, Maxim Fomin wrote:
On Monday, 22 July 2013 at 15:04:25 UTC, monarch_dodra wrote:
On Monday, 22 July 2013 at 12:51:31 UTC, Andrej Mitrovic wrote:
On 7/22/13, JS wrote:
foreach doesn't allow you to modify the index to skip over
elements.
It does:
On 07/22/2013 08:04 AM, monarch_dodra wrote:
> On Monday, 22 July 2013 at 12:51:31 UTC, Andrej Mitrovic wrote:
>> On 7/22/13, JS wrote:
>>> foreach doesn't allow you to modify the index to skip over
>>> elements.
>>
>> It does:
>>
>> -
>> import std.stdio;
>>
>> void main()
>> {
>> int[]
On Monday, 22 July 2013 at 15:04:25 UTC, monarch_dodra wrote:
On Monday, 22 July 2013 at 12:51:31 UTC, Andrej Mitrovic wrote:
On 7/22/13, JS wrote:
foreach doesn't allow you to modify the index to skip over
elements.
It does:
-
import std.stdio;
void main()
{
int[] x = [1, 2, 3, 4,
On Monday, 22 July 2013 at 15:51:45 UTC, monarch_dodra wrote:
So... you are saying that if the grammar allows it, then the
behavior is specified?
You may argue that although grammar does allows it, the feature
is semantically not defined. However here it is known what "ref
int i" means, to
Am Mon, 22 Jul 2013 05:47:34 +0200
schrieb "JS" :
> Doing simple stuff like
>
> for(int i = 0; i < s.length - 1; i++) fails catastrophically if s
> is empty. To make right one has to reduce performance by writing
> extra checks.
And my opinion on the matter is that it is catastrophic style
to
On 7/22/13, monarch_dodra wrote:
> 99% sure that's unspecified behavior. I wouldn't rely on anything
> like that.
Actually it used to be a bug that writing to the index /without/ ref
would end up changing the iteration order, but this was fixed in
2.063. It's in the changelog:
http://dlang.org/c
On Monday, 22 July 2013 at 16:29:39 UTC, Maxim Fomin wrote:
This also compiles, but I used a different aggregate, yet
represents the same thing. Because it is implemented
differently, I get a completely different result. Unless I'm
mistaken, when a result depends on the implementation, and the
Andrej Mitrovic:
Actually it used to be a bug that writing to the index
/without/ ref
would end up changing the iteration order, but this was fixed in
2.063. It's in the changelog:
http://dlang.org/changelog.html#foreachref
The right design in my opinion is to have the iteration variable
im
On Monday, 22 July 2013 at 21:08:48 UTC, bearophile wrote:
So the standard idiom to use foreach on interval needs to be:
foreach (immutable i; 0 .. 10) { ... }
Bye,
bearophile
This comes with another issue embedded here
http://forum.dlang.org/thread/felqszcrbvtrepjtf...@forum.dlang.org
25 matches
Mail list logo
