From: Eduardo on
dpb escribi�:

> Bounds checking is, in most current languages, as in VB, a
> user-selectable option that _most_ people turn off in debugged
> production code for speed.

I don't think most people turn it off, but it's an opinion.

>> I think it's a remain from the old days and also an inheritance from
>> low level languages, but it's not good for a high level language.
>> A high level language must be rather friendly with the programmer...
>> and humans count starting with 1.
>
> That is a _VERY_ narcissistic and provincial way to think of a language
> design--just because you prefer one thing doesn't mean that's best for
> everybody who might use the language and certainly lacking flexibility
> is _NOT_ a feature to be wished for in any programming language.

It's my preference, and I also think it's best for everybody. At least
for everybody "new" without preconceptions.

And there would be exactly the same flexibility.

>> OK, you have some cases where 0 is the better and less confusing
>> choice, but in the most of the cases 1 is the less confusing choice.
>
> What if the person developing code works in the "0 is better" field
> exclusively? Your preference should still reign over their development
> environment? I don't think so... :)

Do a census.
Does the minority who need 0 have to reign over all the majority who need 1?


>> The 'Option Base' declaration could serve to set the dafault lower
>> bound to 0, the opposite as it's in VB6.
>
> It _does_ serve to set it at either on user choice as it should.

I mean that the default should be 1.

[some meaningless things cut]
From: dpb on
Eduardo wrote:
> dpb escribi�:
>
>> Bounds checking is, in most current languages, as in VB, a
>> user-selectable option that _most_ people turn off in debugged
>> production code for speed.
>
> I don't think most people turn it off, but it's an opinion.

read comp.lang.fortran for a while and see that performance/optimization
is _very_ high on the list of subjects discussed. For Fortran
compilers, the choice of most (all???) compilers is to turn
bounds-checking off by default instead of on; this is by compiler
vendors who respond to customer wishes that "out-of-the-box", compilers
should produce faster code over safer/error-catching code and leave the
debugging switches for specific, requested usage.

I'm trying to add some breadth to your viewpoint here to get you out of
this provincial-thinking mode...

>>> I think it's a remain from the old days and also an inheritance from
>>> low level languages, but it's not good for a high level language.
>>> A high level language must be rather friendly with the programmer...
>>> and humans count starting with 1.
>>
>> That is a _VERY_ narcissistic and provincial way to think of a
>> language design--just because you prefer one thing doesn't mean that's
>> best for everybody who might use the language and certainly lacking
>> flexibility is _NOT_ a feature to be wished for in any programming
>> language.
>
> It's my preference, and I also think it's best for everybody. At least
> for everybody "new" without preconceptions.

Again, unequivocally "No", it is _not_ "better", it's different, and
it's absurd to think one individual's choice can be used to define a
general-purpose programming language and leave that language
flexible-enough for that purpose. Again, step back and consider the
diversity of uses/users.

>
> And there would be exactly the same flexibility.
>
>>> OK, you have some cases where 0 is the better and less confusing
>>> choice, but in the most of the cases 1 is the less confusing choice.
>>
>> What if the person developing code works in the "0 is better" field
>> exclusively? Your preference should still reign over their
>> development environment? I don't think so... :)
>
> Do a census.
> Does the minority who need 0 have to reign over all the majority who
> need 1?

And vice versa, of course. "goose/gander" :)

Again, to reiterate--the same "minority" who need 0 may, on another
occasion, "need" 1. There _IS_ no "better" universally.

>>> The 'Option Base' declaration could serve to set the dafault lower
>>> bound to 0, the opposite as it's in VB6.
>>
>> It _does_ serve to set it at either on user choice as it should.
>
> I mean that the default should be 1.
>
> [some meaningless things cut]

They were not meaningless at all; they're the crux of my message that
your viewpoint is entirely too provincial to be of any value in
developing conventions for a general-purpose programming language that
would be of any benefit in either expanding the target base of
applications/users of that language or in useful enhancements to the
language itself.

Whether the default Option Base is 0/1 is immaterial in reality as one
can create templates in the IDE that will set it automagically to your
choice so you don't even have to make the selection more than once so
it's a non-starter as an enhancement request.

Changing the default behavior of VB is a non-starter because of
compatibility--there's no way one could justify breaking existing code
which does rely on default behavior for the minute supposed benefits
outlined in the arguments here (which many would argue would not be a
benefit, anyway).

Lastly, the choice of 0 over 1 likely was made for compatibility with C
and the Win API in the original MS choice although that is hypothesis;
I've never seen any documentation or reference material on the design
decisions behind it. I don't recall ottomh whether Option Base is
inherited from BASIC or not, either.

The specifics of the argument around it is really essentially immaterial
to my larger point of your obsessing over trivia and overlooking the
fundamentals. My only reason for participating is to try to provide
some impetus to "don't do that!" and give some reason for you to
appreciate the bigger picture.

So, having made my say, I'm done...

--
From: Schmidt on

"Eduardo" <mm(a)mm.com> schrieb im Newsbeitrag news:hb8uet$arf$1(a)aioe.org...

> >> The 'Option Base' declaration could serve to set the dafault
> >> lower bound to 0, the opposite as it's in VB6.
> >
> > It _does_ serve to set it at either on user choice as it should.
>
> I mean that the default should be 1.

I'd vote against that - the "ZeroBased-thinking" is not only
there, because "C introduced it this way" ... it has math-
backgrounds and eases the Array-Handling in many
common Algorithms/Loops/scenarios.

simple RingBuffer-example (i.e. implemented in a class):

Private Const RingBufSize& = 8
Private Arr(0 To RingBufSize - 1) 'i.e. in C a direct: Arr[RingBufSize]
Private WriteIdx as Long, ReadIdx as Long

Public Sub WriteEntry(Entry)
Arr(WriteIdx) = Entry
WriteIdx = (WriteIdx + 1) Mod RingBufSize
End Sub
Public Function ReadEntry() 'for "delayed reading"
ReadEntry = Arr(ReadIdx)
ReadIdx = (ReadIdx + 1) Mod RingBufSize
End Function

Or simple Buffer-growings, i.e. in a small StringBuilder-Class:

Private Buf() as Byte, BufBytesAllocated As Long, TotalStrLenW as Long

Public Sub AddString(S As String)
Dim StrLenWNewPart As Long
StrLenWNewPart = LenB(S)
If StrLenWNewPart = 0 Then Exit Sub

'simple check for "realloc-necessary?"
If TotalStrLenW + StrLenWNewPart > BufBytesAllocated Then
BufBytesAllocated = 2 * (TotalStrLenW + StrLenWNewPart)
ReDim Preserve Buf(0 To BufBytesAllocated - 1)
End If

CopyMemory Buf(TotalStrLenW), ByVal StrPtr(S), StrLenWNewPart
TotalStrLenW = TotalStrLenW + StrLenWNewPart
End Sub

Public Function GetContent() As String
If TotalStrLenW = 0 Then Exit Function
GetContent = Space$(TotalStrLenW \ 2)
CopyMemory ByVal StrPtr(GetContent), Buf(0), TotalStrLenW
End Function

Now, if you try to write all of the above with OneBased Arrays,
the whole "index-fiddling" would become much more "unnatural"
or "unelegant" (from a programmers point of view) ....... IMO ;-)

Olaf


From: Scott M. on

"Eduardo" <mm(a)mm.com> wrote in message news:hb8uet$arf$1(a)aioe.org...
> dpb escribi�:
>
>> Bounds checking is, in most current languages, as in VB, a
>> user-selectable option that _most_ people turn off in debugged production
>> code for speed.
>
> I don't think most people turn it off, but it's an opinion.
>
>>> I think it's a remain from the old days and also an inheritance from low
>>> level languages, but it's not good for a high level language.
>>> A high level language must be rather friendly with the programmer... and
>>> humans count starting with 1.
>>
>> That is a _VERY_ narcissistic and provincial way to think of a language
>> design--just because you prefer one thing doesn't mean that's best for
>> everybody who might use the language and certainly lacking flexibility is
>> _NOT_ a feature to be wished for in any programming language.
>
> It's my preference, and I also think it's best for everybody. At least for
> everybody "new" without preconceptions.
>
> And there would be exactly the same flexibility.
>
>>> OK, you have some cases where 0 is the better and less confusing choice,
>>> but in the most of the cases 1 is the less confusing choice.
>>
>> What if the person developing code works in the "0 is better" field
>> exclusively? Your preference should still reign over their development
>> environment? I don't think so... :)
>
> Do a census.
> Does the minority who need 0 have to reign over all the majority who need
> 1?
>
>
>>> The 'Option Base' declaration could serve to set the dafault lower bound
>>> to 0, the opposite as it's in VB6.
>>
>> It _does_ serve to set it at either on user choice as it should.
>
> I mean that the default should be 1.
>
> [some meaningless things cut]


I'll put another log on the fire....


I'm for the zero-based array, not because it's easier or harder than
something else. I think ANY programmer (even a new one) has to be adept
enough with numbers and math to be able to handle a list that starts with 0
and/or a list that starts with 1 - I really don't think that is a
show-stopper.

The reason I'm for zero-based arrays is simply because, im my experience,
zero-based is the more common approach in most modern programming languages
and since these days, programmers are being asked to become familiar with
more than just one language, having more of them support the same standard
makes jumping back and forth easier and makes careless mistakes because over
there I use zero, but over here I use 1, not an option.

We haven't even mentioned that in corporate America (and corporate
non-America), programmers don't program in a vacuum. They write code that
must integrate with other code. Having all programmers code according to
the default array starting index just makes more sense to me in an
Enterprise, than having some people use one and others using zero. Can you
say "standards"?

Just my 1 cents (but please start your cent count from zero).

-Scott


From: Nobody on
"Schmidt" <sss(a)online.de> wrote in message
news:%23JOLL4nTKHA.1236(a)TK2MSFTNGP05.phx.gbl...
>
> "Eduardo" <mm(a)mm.com> schrieb im Newsbeitrag news:hb8uet$arf$1(a)aioe.org...
>
>> >> The 'Option Base' declaration could serve to set the dafault
>> >> lower bound to 0, the opposite as it's in VB6.
>> >
>> > It _does_ serve to set it at either on user choice as it should.
>>
>> I mean that the default should be 1.
>
> I'd vote against that - the "ZeroBased-thinking" is not only
> there, because "C introduced it this way" ... it has math-
> backgrounds and eases the Array-Handling in many
> common Algorithms/Loops/scenarios.

I think you already know this, but didn't mention it. Using 1 would also
have a small performance hit, because the compiler has to subtract one from
the index. While the compiler can do the subtraction at compile time in
certain cases, Ex: A(5), it cannot do that when a variable is used as the
index.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: Array of pointers
Next: Will this object get destroyed?