Hello SiegeLord,
BCS Wrote:
Also all of the imperial units that I don't care about, as well as
the more obscure physical units.
My lib has every SI unit I could fine and all the units I found that
I recognised. The current vertion can have a new unit added as a
single line of code.
SI has
Should we submit an add to this?
http://blog.stackoverflow.com/2010/01/open-source-ad-stats/
Nick Sabalausky wrote:
>
> A programming language *is* a set of enforced conventions. When something
> either can't be enforced mechanically (ex: accurate and meaningful variable
> names), or has real practical value in not having an enforced convention
> (ex: user-definable variable names, fre
Hello bearophile,
Matti Niemenmaa:
Your test6 is invalid: it reads beyond the bounds of the given array.
For example with input "th", it will check whether the third
character is 'i'; but the length of the array is only 2, so it
shouldn't be doing that.
Shame on me, I am sorry -.- Thank you.
On 2010-01-28 17:27:58 -0500, Andrei Alexandrescu
said:
The problem is not localized change. The result of stdin.byLine changes
the _entire_ stdin.
No. Calling byLine doesn't change the stream. It returns a different
view of stdin, which can be used to modify the stream, or not. I think
it
Andrei Alexandrescu Wrote:
> Michiel Helvensteijn wrote:
> > Andrei Alexandrescu wrote:
> >
> foreach (line; stdin.byLine()) { ... }
>
> vs.
>
> foreach (line; stdin.byLine) { ... }
>
> How do I choose?
> >>> byLine is a property. It is fetching a range on stdi
"Nick Sabalausky" wrote in message
news:hjtl33$1da...@digitalmars.com...
> "Andrei Alexandrescu" wrote in message
> news:hjtet5$111...@digitalmars.com...
>> Nick Sabalausky wrote:
>>> "Andrei Alexandrescu" wrote in message
>>> news:hjtcbd$r0...@digitalmars.com...
Nick Sabalausky wrote:
>
"Andrei Alexandrescu" wrote in message
news:hjtet5$111...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Andrei Alexandrescu" wrote in message
>> news:hjtcbd$r0...@digitalmars.com...
>>> Nick Sabalausky wrote:
And yes, I already pointed out that would make it a no-argument
function.
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:hjtcbd$r0...@digitalmars.com...
Nick Sabalausky wrote:
And yes, I already pointed out that would make it a no-argument function.
And that's precisely my point. If we accept that it's bad to paint a car
via its "@property" whee
"Andrei Alexandrescu" wrote in message
news:hjtcbd$r0...@digitalmars.com...
> Nick Sabalausky wrote:
>>
>> And yes, I already pointed out that would make it a no-argument function.
>> And that's precisely my point. If we accept that it's bad to paint a car
>> via its "@property" wheel, then how
"Andrei Alexandrescu" wrote in message
news:hjtbjh$pb...@digitalmars.com...
> Nick Sabalausky wrote:
>> "Pelle Månsson" wrote in message
>> news:hjt46j$5q...@digitalmars.com...
>>> I don't understand what any of this would improve. Is the byLine example
>>> less readable without the ()? Is it
Nick Sabalausky wrote:
"Bill Baxter" wrote in message
news:mailman.47.1264724411.4461.digitalmar...@puremagic.com...
On Thu, Jan 28, 2010 at 3:58 PM, Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:hjt449$5d...@digitalmars.com...
Bill Baxter wrote:
On Thu, Jan 28, 2010 a
"Bill Baxter" wrote in message
news:mailman.47.1264724411.4461.digitalmar...@puremagic.com...
>On Thu, Jan 28, 2010 at 3:58 PM, Nick Sabalausky wrote:
>> "Andrei Alexandrescu" wrote in message
>> news:hjt449$5d...@digitalmars.com...
>>> Bill Baxter wrote:
On Thu, Jan 28, 2010 at 2:27 PM, A
Nick Sabalausky wrote:
"Pelle Månsson" wrote in message
news:hjt46j$5q...@digitalmars.com...
I don't understand what any of this would improve. Is the byLine example
less readable without the ()? Is it more bug prone?
The only thing achieved as I can see is that every class designer makes up
"Pelle Månsson" wrote in message
news:hjt46j$5q...@digitalmars.com...
>
> I don't understand what any of this would improve. Is the byLine example
> less readable without the ()? Is it more bug prone?
>
> The only thing achieved as I can see is that every class designer makes up
> his own rules
On Thu, Jan 28, 2010 at 3:58 PM, Nick Sabalausky wrote:
> "Andrei Alexandrescu" wrote in message
> news:hjt449$5d...@digitalmars.com...
>> Bill Baxter wrote:
>>> On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
The problem is not localized change. The result of stdin.byLine changes
"Andrei Alexandrescu" wrote in message
news:hjt449$5d...@digitalmars.com...
> Bill Baxter wrote:
>> On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
>>>
>>> The problem is not localized change. The result of stdin.byLine changes
>>> the
>>> _entire_ stdin.
>>
>> Ok, so you have no problem wi
Nick Sabalausky wrote:
"Andrei Alexandrescu" wrote in message
news:hjt1ea$306...@digitalmars.com...
Good summary. I now wonder, could one overload based on @property?
auto a = container.empty; // check for emptiness
container.empty();// take the trash out
!
Why would that ever ente
"Andrei Alexandrescu" wrote in message
news:hjt1ea$306...@digitalmars.com...
>
> Good summary. I now wonder, could one overload based on @property?
>
> auto a = container.empty; // check for emptiness
> container.empty();// take the trash out
>
> !
>
Why would that ever enter into anyone
On Thu, Jan 28, 2010 at 2:49 PM, Andrei Alexandrescu
wrote:
> Pelle Månsson wrote:
>>
>> On 01/28/2010 11:23 PM, Michiel Helvensteijn wrote:
>>>
>>> Andrei Alexandrescu wrote:
>>>
I agree. So where's the consensus? Things seemed so clear when people
were beaten with @property over their
On Thu, Jan 28, 2010 at 2:48 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Thu, Jan 28, 2010 at 2:25 PM, Andrei Alexandrescu
>> wrote:
>>>
>>> Bill Baxter wrote:
On Thu, Jan 28, 2010 at 2:07 PM, Andrei Alexandrescu
wrote:
>
> Bill Baxter wrote:
>>
>>
Pelle Månsson wrote:
On 01/28/2010 11:23 PM, Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
I agree. So where's the consensus? Things seemed so clear when people
were beaten with @property over their head.
If I read the TLP correctly, @property seems not to be working correctly.
@pr
On 01/28/2010 11:23 PM, Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
I agree. So where's the consensus? Things seemed so clear when people
were beaten with @property over their head.
If I read the TLP correctly, @property seems not to be working correctly.
@property (or any other n
Bill Baxter wrote:
On Thu, Jan 28, 2010 at 2:25 PM, Andrei Alexandrescu
wrote:
Bill Baxter wrote:
On Thu, Jan 28, 2010 at 2:07 PM, Andrei Alexandrescu
wrote:
Bill Baxter wrote:
On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 15:
On 01/28/2010 11:28 PM, Andrei Alexandrescu wrote:
Lutger wrote:
On 01/28/2010 11:05 PM, Andrei Alexandrescu wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
foreach (line; stdin.byLine()) { ... }
vs.
foreach (line; stdin.byLine) { ... }
How do I choose?
byLine is a property
Bill Baxter wrote:
On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
wrote:
Bill Baxter wrote:
On Thu, Jan 28, 2010 at 2:11 PM, Andrei Alexandrescu
wrote:
Michiel Helvensteijn wrote:
Bill Baxter wrote:
byLine() is a function. It changes the state of stdin. Calling it
consecutively will
On Thu, Jan 28, 2010 at 2:25 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Thu, Jan 28, 2010 at 2:07 PM, Andrei Alexandrescu
>> wrote:
>>>
>>> Bill Baxter wrote:
On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
wrote:
>
> Steven Schveighoffer wrote:
On Thu, Jan 28, 2010 at 2:27 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Thu, Jan 28, 2010 at 2:11 PM, Andrei Alexandrescu
>> wrote:
>>>
>>> Michiel Helvensteijn wrote:
Bill Baxter wrote:
>> byLine() is a function. It changes the state of stdin. Calling it
Lutger wrote:
On 01/28/2010 11:05 PM, Andrei Alexandrescu wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
foreach (line; stdin.byLine()) { ... }
vs.
foreach (line; stdin.byLine) { ... }
How do I choose?
byLine is a property. It is fetching a range on stdin.
-Steve
Damn. I
Bill Baxter wrote:
On Thu, Jan 28, 2010 at 2:11 PM, Andrei Alexandrescu
wrote:
Michiel Helvensteijn wrote:
Bill Baxter wrote:
byLine() is a function. It changes the state of stdin. Calling it
consecutively will in general result in different return values. If
there
were two guys: stdin.curre
Bill Baxter wrote:
On Thu, Jan 28, 2010 at 2:07 PM, Andrei Alexandrescu
wrote:
Bill Baxter wrote:
On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
wrote:
foreach (line; stdin.byLine()) { ... }
Andrei Alexandrescu wrote:
> I agree. So where's the consensus? Things seemed so clear when people
> were beaten with @property over their head.
If I read the TLP correctly, @property seems not to be working correctly.
@property (or any other notation marking property getters/setters) should be
On 01/28/2010 11:05 PM, Andrei Alexandrescu wrote:
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
foreach (line; stdin.byLine()) { ... }
vs.
foreach (line; stdin.byLine) { ... }
How do I choose?
byLine is a property. It is fetching a range on stdin.
-Steve
Damn. I was sure the an
On Thu, Jan 28, 2010 at 2:11 PM, Andrei Alexandrescu
wrote:
> Michiel Helvensteijn wrote:
>>
>> Bill Baxter wrote:
>>
byLine() is a function. It changes the state of stdin. Calling it
consecutively will in general result in different return values. If
there
were two guys: stdin
Michiel Helvensteijn wrote:
Bill Baxter wrote:
byLine() is a function. It changes the state of stdin. Calling it
consecutively will in general result in different return values. If there
were two guys: stdin.currentLine (property) and stdin.nextLine(), it
would be a different story.
That's not
On Thu, Jan 28, 2010 at 2:07 PM, Andrei Alexandrescu
wrote:
> Bill Baxter wrote:
>>
>> On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
>> wrote:
>>>
>>> Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
wrote:
>
> foreach (line; stdin
Andrei Alexandrescu wrote:
Don wrote:
I think there are 3 cases:
(1) I want this to _always_ be treated as if it were a field;
(2) I want this to _always_ be treated as a function;
(3) I don't care. (this arises most frequently in generic code: you're
forced to choose between a field and a func
Bill Baxter wrote:
>> byLine() is a function. It changes the state of stdin. Calling it
>> consecutively will in general result in different return values. If there
>> were two guys: stdin.currentLine (property) and stdin.nextLine(), it
>> would be a different story.
>
> That's not how it works,
Bill Baxter wrote:
On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
wrote:
foreach (line; stdin.byLine()) { ... }
vs.
foreach (line; stdin.byLine) { ... }
How do I choose?
byLine is a property.
Michiel Helvensteijn wrote:
Andrei Alexandrescu wrote:
foreach (line; stdin.byLine()) { ... }
vs.
foreach (line; stdin.byLine) { ... }
How do I choose?
byLine is a property. It is fetching a range on stdin.
-Steve
Damn. I was sure the answer will be different.
byLine() is a function. I
Don wrote:
I think there are 3 cases:
(1) I want this to _always_ be treated as if it were a field;
(2) I want this to _always_ be treated as a function;
(3) I don't care. (this arises most frequently in generic code: you're
forced to choose between a field and a function, but you can't have bot
On Thu, Jan 28, 2010 at 1:55 PM, Michiel Helvensteijn
wrote:
> Andrei Alexandrescu wrote:
>
foreach (line; stdin.byLine()) { ... }
vs.
foreach (line; stdin.byLine) { ... }
How do I choose?
>>>
>>> byLine is a property. It is fetching a range on stdin.
>>>
>>> -S
Andrei Alexandrescu wrote:
>>> foreach (line; stdin.byLine()) { ... }
>>>
>>> vs.
>>>
>>> foreach (line; stdin.byLine) { ... }
>>>
>>> How do I choose?
>>
>> byLine is a property. It is fetching a range on stdin.
>>
>> -Steve
>
> Damn. I was sure the answer will be different.
byLine() is a fu
On Thu, Jan 28, 2010 at 1:26 PM, Andrei Alexandrescu
wrote:
> Steven Schveighoffer wrote:
>>
>> On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
>> wrote:
>>>
>>> foreach (line; stdin.byLine()) { ... }
>>>
>>> vs.
>>>
>>> foreach (line; stdin.byLine) { ... }
>>>
>>> How do I choose?
>>
>>
Pelle Månsson wrote:
On 01/28/2010 09:59 PM, Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad
wrote:
Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
wrote:
On Thu, Jan 28, 2010 at 11:47:45AM -0300, Lean
Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
wrote:
foreach (line; stdin.byLine()) { ... }
vs.
foreach (line; stdin.byLine) { ... }
How do I choose?
byLine is a property. It is fetching a range on stdin.
-Steve
Damn. I was sure the answer will be
On Thu, 28 Jan 2010 15:59:30 -0500, Andrei Alexandrescu
wrote:
Denis Koroskin wrote:
On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad
wrote:
Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
wrote:
On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandr
On 01/28/2010 09:59 PM, Andrei Alexandrescu wrote:
Denis Koroskin wrote:
On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad
wrote:
Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
wrote:
On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
Denis Koroskin wrote:
On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad
wrote:
Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
wrote:
On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
Andrei Alexandrescu, el 28 de enero a las 07:57 me
On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad
wrote:
Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
wrote:
On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
> I need
Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
wrote:
On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
> I need to put it for all front() and empty() declarations. By the
> way I d
Roman Ivanov Wrote:
> Lars T. Kyllingstad Wrote:
>
> > In the "Function calls" thread the question of "which attributes should
> > be in the @-namespace" has again come up.
> >
> >
> > Problem:
> > Currently, there doesn't seem to be any clear definition of which
> > attributes should be pref
Jesse Phillips, el 28 de enero a las 15:39 me escribiste:
> Lars T. Kyllingstad wrote:
>
> > In the "Function calls" thread the question of "which attributes should
> > be in the @-namespace" has again come up.
> >
> >
> > Problem:
> > Currently, there doesn't seem to be any clear definition of w
Lars T. Kyllingstad Wrote:
> In the "Function calls" thread the question of "which attributes should
> be in the @-namespace" has again come up.
>
>
> Problem:
> Currently, there doesn't seem to be any clear definition of which
> attributes should be prefixed with @ and which shouldn't. New
Lars T. Kyllingstad, el 28 de enero a las 15:38 me escribiste:
> >I think all D attributes should have the @, if you have a bunch of them,
> >maybe there should be a way to group them, like:
> >
> > @(safe nothrow private property) int foo() { ... }
> >
> >But I'm not sure that adds anything to
On 01/28/2010 04:28 PM, Steven Schveighoffer wrote:
On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
wrote:
On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
> I need to put it for all front() and empty() declara
Lars T. Kyllingstad wrote:
> In the "Function calls" thread the question of "which attributes should
> be in the @-namespace" has again come up.
>
>
> Problem:
> Currently, there doesn't seem to be any clear definition of which
> attributes should be prefixed with @ and which shouldn't. New
>
On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
wrote:
On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
> I need to put it for all front() and empty() declarations. By the
> way I decided that popFront() is no
On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
> Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
> > I need to put it for all front() and empty() declarations. By the
> > way I decided that popFront() is not a property. I don't know why.
>
> Because it denotes an
Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
> Steven Schveighoffer wrote:
> >1. Choosing between including @property or not is rare. Most
> >cases are obvious. If you worked with a language that requires
> >property notation (i.e. C#) this would not be as big an issue for
> >yo
On Thu, 28 Jan 2010 08:57:15 -0500, Andrei Alexandrescu
wrote:
Steven Schveighoffer wrote:
1. Choosing between including @property or not is rare. Most cases are
obvious. If you worked with a language that requires property notation
(i.e. C#) this would not be as big an issue for you.
Andrei Alexandrescu wrote:
Steven Schveighoffer wrote:
1. Choosing between including @property or not is rare. Most cases
are obvious. If you worked with a language that requires property
notation (i.e. C#) this would not be as big an issue for you.
I need to put it for all front() and empt
Leandro Lucarella wrote:
Lars T. Kyllingstad, el 28 de enero a las 09:46 me escribiste:
In the "Function calls" thread the question of "which attributes
should be in the @-namespace" has again come up.
Problem:
Currently, there doesn't seem to be any clear definition of which
attributes should
Don wrote:
Lars T. Kyllingstad wrote:
Currently, there doesn't seem to be any clear definition of which
attributes should be prefixed with @ and which shouldn't.
[snip]
Solution (?):
I therefore propose the following definition of @-namespace attributes:
The @-attributes of a function o
Lars T. Kyllingstad, el 28 de enero a las 09:46 me escribiste:
> In the "Function calls" thread the question of "which attributes
> should be in the @-namespace" has again come up.
>
> Problem:
> Currently, there doesn't seem to be any clear definition of which
> attributes should be prefixed with
Wed, 27 Jan 2010 18:34:57 +0100, Pelle Månsson wrote:
> I disagree, I find the function calls without the () to be really
> prettifying.
>
> But maybe that's just me.
>
> I don't think that it causes serious bugs, you would see that it's an
> integer the moment you try and use it. It also helps
Steven Schveighoffer wrote:
1. Choosing between including @property or not is rare. Most cases are
obvious. If you worked with a language that requires property notation
(i.e. C#) this would not be as big an issue for you.
I need to put it for all front() and empty() declarations. By the way
Lars T. Kyllingstad wrote:
Currently, there doesn't seem to be any clear definition of which
attributes should be prefixed with @ and which shouldn't.
[snip]
Solution (?):
I therefore propose the following definition of @-namespace attributes:
The @-attributes of a function only place co
Lars T. Kyllingstad Wrote:
> In the "Function calls" thread the question of "which attributes should
> be in the @-namespace" has again come up.
>
>
> Problem:
> Currently, there doesn't seem to be any clear definition of which
> attributes should be prefixed with @ and which shouldn't. New
On Wed, 27 Jan 2010 15:54:42 -0500, Andrei Alexandrescu
wrote:
downs wrote:
Adam D. Ruppe wrote:
On Wed, Jan 27, 2010 at 06:34:57PM +0100, Pelle Månsson wrote:
I disagree, I find the function calls without the () to be really
prettifying.
But maybe that's just me.
I don't think that it
In the "Function calls" thread the question of "which attributes should
be in the @-namespace" has again come up.
Problem:
Currently, there doesn't seem to be any clear definition of which
attributes should be prefixed with @ and which shouldn't. New
attributes get an @, while already existi
Michel Fortin wrote:
On 2010-01-27 15:54:42 -0500, Andrei Alexandrescu
said:
Now @property is in. That has created (as I had anticipated) the
unresolved issue of choosing between @property or just function for
any given parameterless function. Also I need to litter my code with
@property. T
72 matches
Mail list logo
