On 08/10/2010 00:42, Jonathan M Davis wrote:
On Thursday, October 07, 2010 16:39:15 Tomek Sowiński wrote:
http://en.wikipedia.org/wiki/Halting_problem
It's a classic problem in computer science. Essentially what it comes down to is
that you can't determine when - or even if - a program will hal
On Thu, 14 Oct 2010 06:04:24 -0400, Stewart Gordon
wrote:
On 13/10/2010 21:11, Steven Schveighoffer wrote:
No, what is suggested is that we build the complexity guarantees into
the interface. For example, if you had a List interface, and it could
only guarantee O(n) performance for get, you
Stewart Gordon wrote:
On 13/10/2010 21:11, Steven Schveighoffer wrote:
No, what is suggested is that we build the complexity guarantees into
the interface. For example, if you had a List interface, and it could
only guarantee O(n) performance for get, you'd call it e.g. slowGet(),
to signify
On 13/10/2010 21:11, Steven Schveighoffer wrote:
No, what is suggested is that we build the complexity guarantees into
the interface. For example, if you had a List interface, and it could
only guarantee O(n) performance for get, you'd call it e.g. slowGet(),
to signify it's a slow operation, an
On Tue, 12 Oct 2010 10:48:26 -0400, Stewart Gordon
wrote:
On 10/10/2010 02:05, Jonathan M Davis wrote:
On Saturday 09 October 2010 06:54:31 Stewart Gordon wrote:
Surely, what matters most for generic code is that in has consistent
_semantics_, rather than the computational complexity?
St
Stewart Gordon wrote:
Imagine, for instance, if we were to make Java's mistake of having List
be an
interface which ArrayList and LinkedList implement and that List has a
get()
function. Using ArrayList, get() has a complexity of O(1). Using
LinkedList, it
has a complexity of O(n).
Are y
On 10/10/2010 02:05, Jonathan M Davis wrote:
On Saturday 09 October 2010 06:54:31 Stewart Gordon wrote:
Surely, what matters most for generic code is that in has consistent
_semantics_, rather than the computational complexity?
Stewart.
_Both_ matter.
True, yet you don't address semantic
On Saturday 09 October 2010 06:54:31 Stewart Gordon wrote:
> On 07/10/2010 15:22, Steven Schveighoffer wrote:
>
>
> > The problem is with generic code. Generic code that accepts some type
> > that defines the "in" operator. What can that generic code expect for
> > performance when using "in"? As
On Sat, Oct 9, 2010 at 9:11 AM, Stewart Gordon wrote:
> On 08/10/2010 00:39, Tomek Sowiński wrote:
>
>
>> What's the halting problem?
>>
>
> Basically, it's the challenge of determining algorithmically whether an
> arbitrary algorithm given arbitrary input will eventually halt or carry on
> runn
On 10/9/10 12:12 CDT, Peter Alexander wrote:
On 9/10/10 5:25 PM, Andrei Alexandrescu wrote:
On 10/9/10 11:23 CDT, Peter Alexander wrote:
On 9/10/10 4:53 PM, bearophile wrote:
Andrei:
Currently std.algorithm.getPivot picks the middle of the range as the
pivot, but I made it modular such that
On 10/9/10 11:52 CDT, Sean Kelly wrote:
Andrei Alexandrescu Wrote:
In fact, guards can be put to ensure that the _expected_ (not average,
not best-case) complexity is O(n log n). This makes the risk of hitting
a worst-case scenario negligible in a principled manner.
http://en.wikipedia.org/wik
On 9/10/10 5:25 PM, Andrei Alexandrescu wrote:
On 10/9/10 11:23 CDT, Peter Alexander wrote:
On 9/10/10 4:53 PM, bearophile wrote:
Andrei:
Currently std.algorithm.getPivot picks the middle of the range as the
pivot, but I made it modular such that it can be improved in a
number of
ways (i.e. r
Peter Alexander Wrote:
> On 9/10/10 4:53 PM, bearophile wrote:
> > Andrei:
> >
> >> Currently std.algorithm.getPivot picks the middle of the range as the
> >> pivot, but I made it modular such that it can be improved in a number of
> >> ways (i.e. randomized, median-of-3, median-of-5, etc).
> >
>
Andrei Alexandrescu Wrote:
>
> In fact, guards can be put to ensure that the _expected_ (not average,
> not best-case) complexity is O(n log n). This makes the risk of hitting
> a worst-case scenario negligible in a principled manner.
>
> http://en.wikipedia.org/wiki/Quicksort#Randomized_quicks
On 10/9/10 11:23 CDT, Peter Alexander wrote:
On 9/10/10 4:53 PM, bearophile wrote:
Andrei:
Currently std.algorithm.getPivot picks the middle of the range as the
pivot, but I made it modular such that it can be improved in a number of
ways (i.e. randomized, median-of-3, median-of-5, etc).
Isn
On 9/10/10 4:53 PM, bearophile wrote:
Andrei:
Currently std.algorithm.getPivot picks the middle of the range as the
pivot, but I made it modular such that it can be improved in a number of
ways (i.e. randomized, median-of-3, median-of-5, etc).
Isn't median of 3 a better default?
Bye,
bearoph
Andrei:
> Currently std.algorithm.getPivot picks the middle of the range as the
> pivot, but I made it modular such that it can be improved in a number of
> ways (i.e. randomized, median-of-3, median-of-5, etc).
Isn't median of 3 a better default?
Bye,
bearophile
On 10/9/10 9:05 CDT, "Jérôme M. Berger" wrote:
Seth Hoenig wrote:
2010/10/8 "Jérôme M. Berger"
Steven Schveighoffer wrote:
On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke
wrote:
I can't say I've ever cared about the big-O complexity of an operation.
Then you don't understand how important
On 08/10/2010 00:39, Tomek Sowiński wrote:
What's the halting problem?
Basically, it's the challenge of determining algorithmically whether an
arbitrary algorithm given arbitrary input will eventually halt or carry
on running forever.
The point is that the halting problem is known to be un
Seth Hoenig wrote:
> 2010/10/8 "Jérôme M. Berger"
>
>> Steven Schveighoffer wrote:
>>> On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke
>>> wrote:
I can't say I've ever cared about the big-O complexity of an operation.
>>> Then you don't understand how important it is.
>> If big O c
On 07/10/2010 15:22, Steven Schveighoffer wrote:
The problem is with generic code. Generic code that accepts some type
that defines the "in" operator. What can that generic code expect for
performance when using "in"? As a general rule, generic programming must
always assume the worst case, and
Reading these boards, both new and old posts, i hardly find any topic
that i disagree with you.
This one is one of those rare cases.
It is really hard for me to connect "operator usage" and "operation
complexity". To me, operators are just "cute", and mostly meaningful
(and not necessarily)
On Fri, 08 Oct 2010 14:58:27 +0300, Steven Schveighoffer
wrote:
On Thu, 07 Oct 2010 21:18:56 -0400, Juanjo Alvarez
wrote:
On Thu, 7 Oct 2010 15:53:13 -0700, Jonathan M Davis
wrote:
Except that when you're dealing with generic code which has to deal
with
multiple container types (lik
On Fri, 08 Oct 2010 14:45:43 +0300, Juanjo Alvarez
wrote:
Pelle Wrote:
The only drawback I can see to having an "in" operator with all
containers is that some programmers would not read the documentation and
use it expecting it to be fast. But then that also happens with many
other lan
On Thu, 07 Oct 2010 17:52:10 +0300, Andrei Alexandrescu
wrote:
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find strin
"Jérôme M. Berger" wrote:
> Steven Schveighoffer wrote:
>> On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke
>> wrote:
>>
>>> On 10/7/2010 13:57, Andrei Alexandrescu wrote:
On 10/7/10 14:40 CDT, bearophile wrote:
> Another solution is just to accept O(n) as the worst complexity for
>
Jonathan M Davis wrote:
On Friday 08 October 2010 03:06:01 Stanislav Blinov wrote:
[...]
What I mean is you'll always have algorithms that will perform
differently for different containers, and you'll always have to choose
containers that best fit your needs [...]
All true. However, the po
2010/10/8 "Jérôme M. Berger"
> Steven Schveighoffer wrote:
> > On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke
> > wrote:
> >
> >> On 10/7/2010 13:57, Andrei Alexandrescu wrote:
> >>> On 10/7/10 14:40 CDT, bearophile wrote:
> Another solution is just to accept O(n) as the worst complexity
Steven Schveighoffer wrote:
> On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke
> wrote:
>
>> On 10/7/2010 13:57, Andrei Alexandrescu wrote:
>>> On 10/7/10 14:40 CDT, bearophile wrote:
Another solution is just to accept O(n) as the worst complexity for
the "in" operator. I don't understa
Tomek S.
> But I got a feeling we're heading for an overkill :)<
Yes, that's overkill, and it's not a good solution. But sometimes it's useful
to discuss even bad solutions to problems, because they may lead to different
and more acceptable solutions. During brainstorming you need to lower the
On 10/08/2010 01:45 PM, Juanjo Alvarez wrote:
Pelle Wrote:
On 10/08/2010 03:18 AM, Juanjo Alvarez wrote:
On Thu, 7 Oct 2010 15:53:13 -0700, Jonathan M Davis
wrote:
Except that when you're dealing with generic code which has to deal
with
multiple container types (like std.algorithm), you _
Juanjo Alvarez wrote:
> Steven Schveighoffer Wrote:
>
>> On Thu, 07 Oct 2010 21:18:56 -0400, Juanjo Alvarez
>> wrote:
>>
>> > On Thu, 7 Oct 2010 15:53:13 -0700, Jonathan M Davis
>> > wrote:
>> >> Except that when you're dealing with generic code which has to deal
>> > with
>> >> multiple conta
On Fri, 08 Oct 2010 09:46:54 -0400, Juanjo Alvarez
wrote:
Steven Schveighoffer Wrote:
That kind of "documentation" is useless, it doesn't prevent use, and it
doesn't feel right to the person who accidentally uses it. When I call
sort(x);
and it performs horribly, am I going to blame x o
Juanjo Alvarez wrote:
True! And that's the only drawback I see on generalizing "in", but there
are many things in programming languages that doesn't feel right when
you don't
know the language well. That doesn't mean that D should be the
"programming for dummies on rails with a constant au
Steven Schveighoffer Wrote:
> On Thu, 07 Oct 2010 21:18:56 -0400, Juanjo Alvarez
> wrote:
>
> > On Thu, 7 Oct 2010 15:53:13 -0700, Jonathan M Davis
> > wrote:
> >> Except that when you're dealing with generic code which has to deal
> > with
> >> multiple container types (like std.algorithm)
On 10/8/10 5:24 CDT, Torarin wrote:
2010/10/7 Andrei Alexandrescu:
In the end I figured there was only _one_
quadratic operation - appending to a vector that held document
lengths. That wasn't even the bulk of the data and it was the last thing I
looked at! Yet it made the run time impossible t
On Thu, 07 Oct 2010 19:07:55 -0400, Rainer Deyke
wrote:
On 10/7/2010 14:33, Steven Schveighoffer wrote:
On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke
wrote:
I can't say I've ever cared about the big-O complexity of an operation.
Then you don't understand how important it is.
Let me
On Thu, 07 Oct 2010 21:18:56 -0400, Juanjo Alvarez
wrote:
On Thu, 7 Oct 2010 15:53:13 -0700, Jonathan M Davis
wrote:
Except that when you're dealing with generic code which has to deal
with
multiple container types (like std.algorithm), you _need_ certain
complexity
guarantees about an
Pelle Wrote:
> On 10/08/2010 03:18 AM, Juanjo Alvarez wrote:
> > On Thu, 7 Oct 2010 15:53:13 -0700, Jonathan M Davis
> > wrote:
> >> Except that when you're dealing with generic code which has to deal
> > with
> >> multiple container types (like std.algorithm), you _need_ certain
> > complexity
>
On Thu, 07 Oct 2010 19:28:59 -0400, Michel Fortin
wrote:
On 2010-10-07 18:53:51 -0400, Andrei Alexandrescu
said:
"Input" == "Input to the program" i.e. not known during compilation of
the program.
Sorry, but my interpretation in this context is that "Input" should be
"Input to the 'i
On Friday 08 October 2010 03:06:01 Stanislav Blinov wrote:
> Yet still, generality ends at some point. You can't devise every
> possible algorithm for any possible types and have it have set-in-stone
> complexity independently of types.
>
> Take std.range.popFrontN(). It's generic, and it's used i
2010/10/7 Andrei Alexandrescu :
> In the end I figured there was only _one_
> quadratic operation - appending to a vector that held document
> lengths. That wasn't even the bulk of the data and it was the last thing I
> looked at! Yet it made the run time impossible to endure.
>From sgi's stl vect
Jonathan M Davis wrote:
On Thursday, October 07, 2010 14:44:50 Stanislav Blinov wrote:
But that is not a matter of library interface isn't it? It's a matter of
algorithm/container choice. It's not the push_back that was slow in the
end, it was std::vector (yes, that's arguable, but the point i
On 10/08/2010 03:18 AM, Juanjo Alvarez wrote:
On Thu, 7 Oct 2010 15:53:13 -0700, Jonathan M Davis
wrote:
Except that when you're dealing with generic code which has to deal
with
multiple container types (like std.algorithm), you _need_ certain
complexity
guarantees about an operation since
On Thu, 7 Oct 2010 15:53:13 -0700, Jonathan M Davis
wrote:
Except that when you're dealing with generic code which has to deal
with
multiple container types (like std.algorithm), you _need_ certain
complexity
guarantees about an operation since it could happen on any
container that it's
Th
Tomek Sowiński wrote:
Simen kjaeraas napisał:
Tomek Sowiński wrote:
Even if the attribute properties could see the arguments, how to deal
with things like
lhs.length + rhs.length? It has to be inspectable at compile-time. One
idea is to store the
expression's abstract syntax tree (we want A
On Thursday, October 07, 2010 16:39:15 Tomek Sowiński wrote:
> Simen kjaeraas napisał:
> > Tomek Sowiński wrote:
> >> Even if the attribute properties could see the arguments, how to deal
> >> with things like
> >> lhs.length + rhs.length? It has to be inspectable at compile-time. One
> >> idea is
Simen kjaeraas napisał:
> Tomek Sowiński wrote:
>> Even if the attribute properties could see the arguments, how to deal
>> with things like
>> lhs.length + rhs.length? It has to be inspectable at compile-time. One
>> idea is to store the
>> expression's abstract syntax tree (we want AST macros i
Tomek Sowiński napisał:
> Simen kjaeraas napisał:
>
>> Tomek Sowiński wrote:
>>
>>> __traits(getAttribute, opIn, @complexity).bigOh == O.constant
>>
>> How does this test for things like N log M?
>>
>> __traits(getAttribute, opIn, @complexity).bigOh == tuple( O.linear,
>> O.logarithmic )
>
>
Tomek Sowiński wrote:
Even if the attribute properties could see the arguments, how to deal
with things like
lhs.length + rhs.length? It has to be inspectable at compile-time. One
idea is to store the
expression's abstract syntax tree (we want AST macros in D3 anyway)...
But I got a feeling
On 2010-10-07 18:53:51 -0400, Andrei Alexandrescu
said:
On 10/7/10 16:23 CDT, Michel Fortin wrote:
On 2010-10-07 14:38:50 -0400, Andrei Alexandrescu
said:
At no point. "Linear" means "linear in the input size". I don't think
such arguments are valid.
It is linear in regard to the array l
Simen kjaeraas napisał:
> Tomek Sowiński wrote:
>
>> __traits(getAttribute, opIn, @complexity).bigOh == O.constant
>
> How does this test for things like N log M?
>
> __traits(getAttribute, opIn, @complexity).bigOh == tuple( O.linear,
> O.logarithmic )
Or:
__traits(getAttribute, opIn, @compl
On 10/7/2010 14:33, Steven Schveighoffer wrote:
> On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke
> wrote:
>> I can't say I've ever cared about the big-O complexity of an operation.
>
> Then you don't understand how important it is.
Let me rephrase that. I care about performance. Big-O comple
Daniel Gibson napisał:
> 2010/10/8 Tomek Sowiński :
>> bearophile napisał:
>>
>>> Another solution is to support the "in" operator for dynamic arrays too,
>>> and define a new attribute, like @complexity(), plus an Enum that allows
>>> to specify the worst case complexity. So associative arrays ar
On Thursday, October 07, 2010 14:44:50 Stanislav Blinov wrote:
> Andrei Alexandrescu wrote:
> > Complexity composes very badly. Issues tend to manifest at moderate
> > sizes and may make things unbearable at large sizes. I'm really grateful
> > I'm at a workplace where the exclamation "Damn! I was
On 10/7/10 16:23 CDT, Michel Fortin wrote:
On 2010-10-07 14:38:50 -0400, Andrei Alexandrescu
said:
At no point. "Linear" means "linear in the input size". I don't think
such arguments are valid.
It is linear in regard to the array length, the static array being the
input. That the length is
Tomek Sowiński wrote:
__traits(getAttribute, opIn, @complexity).bigOh == O.constant
How does this test for things like N log M?
__traits(getAttribute, opIn, @complexity).bigOh == tuple( O.linear,
O.logarithmic )
?
--
Simen
2010/10/8 Tomek Sowiński :
> bearophile napisał:
>
>> Another solution is to support the "in" operator for dynamic arrays too,
>> and define a new attribute, like @complexity(), plus an Enum that allows
>> to specify the worst case complexity. So associative arrays are annotated
>> with @complexity
bearophile napisał:
> Another solution is to support the "in" operator for dynamic arrays too,
> and define a new attribute, like @complexity(), plus an Enum that allows
> to specify the worst case complexity. So associative arrays are annotated
> with @complexity(O.linear), while the function tha
Stanislav Blinov wrote:
... make strong promises but would fit wider range of containers? After all,
std.algorithm offers ...
Sorry, that should be 'cases', not 'containers' there.
Andrei Alexandrescu wrote:
Complexity composes very badly. Issues tend to manifest at moderate
sizes and may make things unbearable at large sizes. I'm really grateful
I'm at a workplace where the exclamation "Damn! I was waiting like an
idiot for this quadratic append!" is met with understa
On 2010-10-07 14:38:50 -0400, Andrei Alexandrescu
said:
At no point. "Linear" means "linear in the input size". I don't think
such arguments are valid.
It is linear in regard to the array length, the static array being the
input. That the length is known at compile time doesn't make it less
On 10/7/10 15:23 CDT, Rainer Deyke wrote:
On 10/7/2010 13:57, Andrei Alexandrescu wrote:
On 10/7/10 14:40 CDT, bearophile wrote:
Another solution is just to accept O(n) as the worst complexity for
the "in" operator. I don't understand what's the problem in this.
That means we'd have to define
Steven Schveighoffer wrote:
On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke
wrote:
I can't say I've ever cared about the big-O complexity of an operation.
Then you don't understand how important it is. Here is an example of
how caring about the big O complexity cut the runtime of dmd to a
On Thu, 07 Oct 2010 16:32:22 -0400, Don wrote:
I actually see a very significant difference between 'in' on a
compile-time array literal, vs 'in' on a static array. When all values
are known, the compiler can make a perfect hash. So potentially it could
be O(1).
But 'find' on a static ar
On Thu, 07 Oct 2010 16:23:47 -0400, Rainer Deyke
wrote:
On 10/7/2010 13:57, Andrei Alexandrescu wrote:
On 10/7/10 14:40 CDT, bearophile wrote:
Another solution is just to accept O(n) as the worst complexity for
the "in" operator. I don't understand what's the problem in this.
That means w
Andrei Alexandrescu wrote:
On 10/7/10 12:11 CDT, Michel Fortin wrote:
On 2010-10-07 11:47:21 -0400, Andrei Alexandrescu
said:
On 10/7/10 10:39 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/7/10 9:59 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/7/10 6:54 CDT,
On 10/7/2010 13:57, Andrei Alexandrescu wrote:
> On 10/7/10 14:40 CDT, bearophile wrote:
>> Another solution is just to accept O(n) as the worst complexity for
>> the "in" operator. I don't understand what's the problem in this.
>
> That means we'd have to define another operation, i.e. "quickIn"
On 10/7/10 15:00 CDT, Manfred_Nowak wrote:
Andrei Alexandrescu wrote:
The size of the operand is constant, known, and visible.
The expected run time is known during compilation and independent of
the input size.
Seems that you are argumenting for some elaborated sort of hungarian
notation:
Andrei Alexandrescu wrote:
> The size of the operand is constant, known, and visible.
> The expected run time is known during compilation and independent of
> the input size.
Seems that you are argumenting for some elaborated sort of hungarian
notation: operators should be attributed by some ot
On 10/7/10 14:40 CDT, bearophile wrote:
Another solution is just to accept O(n) as the worst complexity for the "in"
operator. I don't understand what's the problem in this.
That means we'd have to define another operation, i.e. "quickIn" that
has O(log n) bound.
Andrei
On 10/07/2010 09:40 PM, bearophile wrote:
Andrei Alexandrescu:
I'm a bit leary of adopting this feature (it has been discussed). To me
"in" implies a fast operation and substring searching isn't quite it.
One thing that could be done is to allow "in" with literal arrays to
their right:
if (x
Andrei Alexandrescu:
> I'm a bit leary of adopting this feature (it has been discussed). To me
> "in" implies a fast operation and substring searching isn't quite it.
>
> One thing that could be done is to allow "in" with literal arrays to
> their right:
>
> if (x in ["abcde", "asd"]) { ... }
On 10/7/10 12:28 CDT, Austin Hastings wrote:
On 10/7/2010 10:52 AM, Andrei Alexandrescu wrote:
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how thi
On 10/7/10 12:11 CDT, Michel Fortin wrote:
On 2010-10-07 11:47:21 -0400, Andrei Alexandrescu
said:
On 10/7/10 10:39 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/7/10 9:59 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/7/10 6:54 CDT, atommixz wrote:
It would b
Adam D. Ruppe schrieb:
arr.find()
http://dpldocs.info/std.algorithm.find
With arrays, you can call free functions with the dot member
syntax so import std.algorithm and that just works.
Ah ok, I thought it was a property of arrays or something like that.
Thanks :-)
On Thu, 07 Oct 2010 13:51:36 -0400, Daniel Gibson
wrote:
Steven Schveighoffer schrieb:
On Thu, 07 Oct 2010 10:09:17 -0400, Daniel Gibson
wrote:
Steven Schveighoffer schrieb:
On Thu, 07 Oct 2010 07:54:14 -0400, atommixz
wrote:
It would be nice if it were possible to use the "in" exp
Steven Schveighoffer schrieb:
On Thu, 07 Oct 2010 10:09:17 -0400, Daniel Gibson
wrote:
Steven Schveighoffer schrieb:
On Thu, 07 Oct 2010 07:54:14 -0400, atommixz wrote:
It would be nice if it were possible to use the "in" expression
wherever
possible. Now it is only implemented for assoc
On Thu, 07 Oct 2010 13:28:51 -0400, Austin Hastings
wrote:
On 10/7/2010 10:52 AM, Andrei Alexandrescu wrote:
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression
wherever
possible. Now it is only implemented for associative. arrays. (Weird).
On 10/7/2010 10:52 AM, Andrei Alexandrescu wrote:
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Sea
On Thursday, October 07, 2010 08:37:19 Andrei Alexandrescu wrote:
> >>
> >> I'm a bit leary of adopting this feature (it has been discussed). To
> >> me "in" implies a fast operation and substring searching isn't quite it.
> >>
> >> One thing that could be done is to allow "in" with literal array
On 2010-10-07 11:47:21 -0400, Andrei Alexandrescu
said:
On 10/7/10 10:39 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/7/10 9:59 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in"
IMO this could be added, with the documentation specifying the implementation
doesn't need to best fast. So people who want quick development for things that
don't need high performance may use it, while people coding for performance
just need not use it. The compiler may try to optimize it if i
On 10/7/10 10:39 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/7/10 9:59 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression
wherever
possible. Now it is only implemented for
Andrei Alexandrescu schrieb:
On 10/7/10 9:59 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression
wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of
On 10/7/10 9:59 CDT, Daniel Gibson wrote:
Andrei Alexandrescu schrieb:
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find
Andrei Alexandrescu schrieb:
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character i
On 10/7/10 6:54 CDT, atommixz wrote:
It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an ite
On Thu, 07 Oct 2010 10:09:17 -0400, Daniel Gibson
wrote:
Steven Schveighoffer schrieb:
On Thu, 07 Oct 2010 07:54:14 -0400, atommixz wrote:
It would be nice if it were possible to use the "in" expression
wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Exam
Steven Schveighoffer schrieb:
On Thu, 07 Oct 2010 07:54:14 -0400, atommixz wrote:
It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search
On Thu, 07 Oct 2010 07:54:14 -0400, atommixz wrote:
It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
-
It would be nice if it were possible to use the "in" expression wherever
possible. Now it is only implemented for associative. arrays. (Weird).
Examples of how this could be used:
- Find string in string
- Search for a character in a string
- Search for an item in the array, array of characters, ar
92 matches
Mail list logo
