list index out of bounds?
Donald Shimoda
for i := 0 to ComponentCount - 1 do
if Components[i] is TDACDSDataTable then
DescargarScript(TDaCdsDataTable(Components[i]));
It raises a list out of boubds(123) error.
that works:
for i := 0 to ComponentCount - 2 do
if Components[i] is TDACDSDataTable then
DescargarScript(TDaCdsDataTable(Components[i]));
Yesterday my delphi updater detect a update to update 2 (i believe already
installed, so reinstall it) and after that i start getting that error (the
code work before that update).
Very strange.
--
Donald Shimoda
http://blogs.remobjects.com/blogs/donald/
Dennis Landi
"Donald Shimoda" <shimod...@hotmail.com> wrote in message
news:46df...@newsgroups.borland.com...
Uh Oh! Which version of Delphi?
DelphiUser
If the list is empty then the for-loop will be entered although you don't
want this to happend.
"DelphiUser" <delph...@atwork.com> wrote in message
news:46dfad1c$1...@newsgroups.borland.com...
> This give also a nice index out of bounds error.
>
> procedure TForm1.Button1Click(Sender: TObject);
> var
> i:cardinal;
> _list:TStrings;
> begin
> _list:=TStringList.create;
> try
> for i:=0 to _list.count-1 do begin
> showmessage(_list[i]);
> end;
> finally
> _list.free;
> end;
> end;
>
>
>
> "DelphiUser" <delph...@atwork.com> wrote in message
> news:46dfaca7$1...@newsgroups.borland.com...
>> How is variable "i" declared ?
>>
>>
>> "Donald Shimoda" <shimod...@hotmail.com> wrote in message
>> news:46df...@newsgroups.borland.com...
DelphiUser
procedure TForm1.Button1Click(Sender: TObject);
var
i:cardinal;
_list:TStrings;
begin
_list:=TStringList.create;
try
for i:=0 to _list.count-1 do begin
showmessage(_list[i]);
end;
finally
_list.free;
end;
end;
"DelphiUser" <delph...@atwork.com> wrote in message
news:46dfaca7$1...@newsgroups.borland.com...
> How is variable "i" declared ?
>
>
> "Donald Shimoda" <shimod...@hotmail.com> wrote in message
> news:46df...@newsgroups.borland.com...
DelphiUser
"Donald Shimoda" <shimod...@hotmail.com> wrote in message
news:46df...@newsgroups.borland.com...
Robert Wachtel
Robert
--
http://blog.robertsoft.de
"DelphiUser" <delph...@atwork.com> schrieb im Newsbeitrag news:46dfadf4$1...@newsgroups.borland.com...
Martijn Tonies
>
> If the list is empty then the for-loop will be entered although you don't
> want this to happend.
I'm not sure if that's the error, a cardinal (i) can be compared
to an integer (list.count - 1 = -1) just fine.
--
Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, NexusDB, Oracle &
MS SQL Server
Upscene Productions
http://www.upscene.com
My thoughts:
http://blog.upscene.com/martijn/
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com
Rudy Velthuis [TeamB]
> This give also a nice index out of bounds error.
>
> procedure TForm1.Button1Click(Sender: TObject);
> var
> i:cardinal;
> _list:TStrings;
> begin
> _list:=TStringList.create;
> try
> for i:=0 to _list.count-1 do begin
> showmessage(_list[i]);
> end;
> finally
> _list.free;
> end;
> end;
Only if you have range checking off. You should NEVER have range
checking off.
--
Rudy Velthuis [TeamB]
"Pascal /n./ A programming language named after a man who would
turn over in his grave if he knew about it."
-- From the Jargon File
DelphiUser
It's turned off by default when you start a new project.
So beginners will fall into that trap sooner or later.
B)
As I had to learn recently, in certain crypt/hash components/library you
need to
switch off the range checking.
"Rudy Velthuis [TeamB]" <newsg...@rvelthuis.de> wrote in message
news:xn0favmqf...@newsgroups.borland.com...
Dave Nottage [TeamB]
> Only if you have range checking off.
..and if you have it on, you get a range check error. The docs claim
that if the FinalValue is less than the InitialValue then the code in
the loop will never execute.
It's a bug.
--
Dave Nottage [TeamB]
Donald Shimoda
Integer.
componentcount = 123
Donald Shimoda
news:46df...@newsgroups.borland.com...
> Uh Oh! Which version of Delphi?
The only one working with delphi updater, D2007 update 2.
John Herbster
"DelphiUser" <delph...@atwork.com> wrote
> ... As I had to learn recently, in certain
> crypt/hash components/library you need to
If code within a components / library needs range
checking off, then it should be the responsiblity of
the library programmer to code range checking off
within the library or components module. --JohnH
Don Strenczewilk
temporarily replace it with something simple like:
for i := 0 to ComponentCount - 1 do
if Components[i] is TDACDSDataTable then
Memo1.Lines.Add(TDaCdsDataTable(Components[i]).Classname);
"Donald Shimoda" <shimod...@hotmail.com> wrote in message
news:46dff22e$1...@newsgroups.borland.com...
Michael C.
<snip>
> Only if you have range checking off. You should NEVER have range
> checking off.
I disagree with the above opinion.
Turning off range checking is extremely useful for certain applications.
My documentation also states
"Enabling range checking slows down your program and makes it somewhat larger, so use the {$R+} only for debugging."
See the documentation for more details.
Dennis Landi
>I dontknow, maybe is too late but that code dont must work?
>
> for i := 0 to ComponentCount - 1 do
> if Components[i] is TDACDSDataTable then
> DescargarScript(TDaCdsDataTable(Components[i]));
>
What does DescargarScript do? Is it by any chance affecting the number of
component-children under TDaCdsDataTable?
-d
Donald Shimoda
news:46df...@newsgroups.borland.com...
> What does DescargarScript do? Is it by any chance affecting the number
> of component-children under TDaCdsDataTable?
Nop.
Just change a property inside the compo.
Dennis Landi
"John Herbster" <herb-sci1_AT_sbcglobal.net> wrote in message
news:46e00cc5$1...@newsgroups.borland.com...
>> > ... You should NEVER have range checking off. ...
>
> "Michael C." <Mich...@spamfree.net> wrote
>> I disagree with the above opinion. Turning off
>> range checking is extremely useful for certain
>> applications. My documentation also states
>> "Enabling range checking slows down your program
>> and makes it somewhat larger, so use the {$R+}
>> only for debugging." See the documentation for
>> more details.
>
> "Before posting questions in newsgroups about
> access violations, try testing your code compiled
> with range checking *ON*."
So was this Donald's problem?
-d
John Herbster
"Michael C." <Mich...@spamfree.net> wrote
> I disagree with the above opinion. Turning off
> range checking is extremely useful for certain
> applications. My documentation also states
> "Enabling range checking slows down your program
> and makes it somewhat larger, so use the {$R+}
> only for debugging." See the documentation for
> more details.
To which should be added:
"Before posting questions in newsgroups about
access violations, try testing your code compiled
with range checking *ON*."
--JohnH
Dave Nottage [TeamB]
> So was this Donald's problem?
No, and I doubt it has anything to do with Update 2.
Unfortunately there's very little information to go on, including no
reproducible test case. (I've also tried to reproduce it)
--
Dave Nottage [TeamB]
Don Strenczewilk
value of 'i'?
"Dennis Landi" <na...@nada.com> wrote in message
news:46df...@newsgroups.borland.com...
>
Frans van Daalen
"Donald Shimoda" <shimod...@hotmail.com> wrote in message
news:46df...@newsgroups.borland.com...
try a "downto" and "ComponentCount - 1" if this generates no error then
there is something in the "DescargarScript" which in creating the error.
John Herbster
"Donald Shimoda" <shimod...@hotmail.com> wrote
> for i := 0 to ComponentCount - 1 do
> if Components[i] is TDACDSDataTable then
> DescargarScript(TDaCdsDataTable(Components[i]));
Donald,
Where is ComponentCount defined and what is it defined
to be? If it is supposed to be a property of a form, how
does its value compare with self.ComponentCount?
What happens if you change the loop to be
for i := ComponentCount - 1 downto 0 do ... ?
HTH, JohnH
Dave Nottage [TeamB]
> Or maybe something in DescargarScript is overwriting the stack,
> changing the value of 'i'?
That would probably result in a random value for i, rather than one out
of range (123).
I suspect a component is being removed during loop execution. That
would explain why ComponentCount is 123 at the start of the loop, yet
out of range when the code fails.
--
Dave Nottage [TeamB]
Don Strenczewilk
that's true, something in the property's Set method might be screwing up the
stack. If he's running with the same data every time (looks like it), the
Set method may corrupt the stack the exact same way when it's called and
i=122.
"Dave Nottage [TeamB]" <qni...@enqfbsg.pbz.nh> wrote in message
news:46e015c2$1...@newsgroups.borland.com...
Rudy Velthuis [TeamB]
> A)
> It's turned off by default when you start a new project.
> So beginners will fall into that trap sooner or later.
>
> B)
> As I had to learn recently, in certain crypt/hash components/library
> you need to switch off the range checking.
No, you don't need to. But if you blindly copy C code, you'll get
different results. So don't copy it blindly, copy it intelligently.
--
Rudy Velthuis [TeamB]
"If the brain were so simple we could understand it, we would
be so simple we couldn't." -- Lyall Watson
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
>
> > Only if you have range checking off.
>
> ..and if you have it on, you get a range check error. The docs claim
> that if the FinalValue is less than the InitialValue then the code in
> the loop will never execute.
Well, if you have range checks off, it should run from $00000000 to
$FFFFFFFF (unsigned). $FFFFFFFF is not less than 0. <g>
--
Rudy Velthuis [TeamB]
"Comedy is simply a funny way of being serious."
-- Peter Ustinov (1921-2004)
Rudy Velthuis [TeamB]
IMO, we simply don't know enough about the code to help him. It would
help if he showed a complete piece of compiling code which displays the
problem.
--
Rudy Velthuis [TeamB]
"If it wasn't for C, we'd be writing programs in BASI, PASAL, and
OBOL." -- unknown
Rudy Velthuis [TeamB]
The "slow down" is generally hardly noticeable, and optimizing for
speed when there is no need is IMO not a good base for programming.
Only optimize for speed if you notice that some part is indeed too
slow. That requires proper profiling. If you profiled your code, and
have found the bottleneck(s), then only optimize those.
Make sure your code runs well under range checking, and you'll never
get any unnoticed range problems. If it is turned off, you might get
the wrong results without ever noticing it.
IOW, range checking should ALWAYS be turned on.
--
Rudy Velthuis [TeamB]
"I was raised in the West. The west of Texas. It's pretty close
to California. In more ways than Washington, D.C., is close to
California." -- George W. Bush
Johnnie Norsworthy
news:46df...@newsgroups.borland.com...
>I dontknow, maybe is too late but that code dont must work?
>
> for i := 0 to ComponentCount - 1 do
> if Components[i] is TDACDSDataTable then
> DescargarScript(TDaCdsDataTable(Components[i]));
>
>
>
>
> for i := 0 to ComponentCount - 2 do
> if Components[i] is TDACDSDataTable then
> DescargarScript(TDaCdsDataTable(Components[i]));
Donald,
I use this unit for testing things that would take forever in the debugger:
http://www.swissdelphicenter.ch/en/showcode.php?id=2280
Simply add a call to DebugString in the for loop:
DebugString('i='+IntToStr(i)+' ComponentCount='+IntToStr(ComponentCount));
Leaving this type of code in production software isn't even too bad of an
idea, there are programs such as in cnPack that can monitor the debug output
on standalone running applications.
It doesn't make a difference, but I always use the form:
Pred(ComponentCount)
instead of
ComponentCount-1
That "1" is a constant and therefore I consider it bad style to use it. I
wonder if the compiler cares?
-Johnnie
Donald Shimoda
> No, and I doubt it has anything to do with Update 2.
And how can you be sure? You are sure have nothing to do with update 2 but
in the other hand you haven't enough information. have a lot sense... :P
>
> Unfortunately there's very little information to go on, including no
> reproducible test case. (I've also tried to reproduce it)
Unfortunately have not enough time to provide more information, altough i
doubt the provided one is not enough. Maybe Codegear need the complete
project to get where is the bug, as you can see, is a obvious bug in the
compiler, dont matter how anyone want to disturb.
Don Strenczewilk
allowing us the opportunity to try to solve this problem for you!
"Donald Shimoda" <shimod...@hotmail.com> wrote in message
news:46e0...@newsgroups.borland.com...
Donald Shimoda
news:46e04cfe$1...@newsgroups.borland.com...
> Thank you for providing the information you had time to gather and for
> allowing us the opportunity to try to solve this problem for you!
Sorry, i never post that message to make sombody trying to help me. I
already solve in the hard way, like many times is needed with delphi 2007
(by example i cannot use MSBUILD and must disbale it).
Then, i just think all that people is commenting just for fun, sorry by my
mistake.
As i remember never ask for solving that, or yes?
Best regards.
Don Strenczewilk
There is no need to apologise. It seems that you are under a lot of
pressure, or worse.
"Donald Shimoda" <shimod...@hotmail.com> wrote in message
news:46e0542e$1...@newsgroups.borland.com...
Farshad
"Rudy Velthuis [TeamB]"
> IOW, range checking should ALWAYS be turned on.
Not ALWAYS, you only need it at developement stage. Otherwise, performance
loss can be very noticable in tight loops. For example if you're doing image
processing the {$R+} can be a performance killer.
Michael C.
<snip>
>
No, it shouldn't be always turned on
-especially for certain applications where the range checking gets in the way.
Enough said.
Dave Nottage [TeamB]
> > No, and I doubt it has anything to do with Update 2.
>
> And how can you be sure?
Since there were no changes to the Delphi compiler in Update 2.
> as you can see, is a obvious bug
It's not obvious at all, since there's not enough information provided.
--
Dave Nottage [TeamB]
Dave Nottage [TeamB]
> But he said above that DescargarScript merely changes a property.
Right, that's what he says. Hard to tell whether it's the case without
seeing the code.
--
Dave Nottage [TeamB]
John Herbster
> ... as you can see, is a obvious bug in the compiler, ...
If your problem is a bug; It is *not* obvious to me!
Further, if your problem happened to me, I am sure
that I could easily track it down using some of the
suggestions offered in this thread. --JohnH
John Herbster
> ... as you can see, is a obvious bug in the compiler, ...
If your problem is a compiler bug; it is *not*
Donald Shimoda
> Nope, you didn't ask anyone to help solve it. All responses were
> voluntary. There is no need to apologise. It seems that you are under a
> lot of pressure, or worse.
LOL.Actually dont, but thanks for worry about me. ;)
Loren Pechtel
<delph...@atwork.com> wrote:
>This give also a nice index out of bounds error.
It would.
>
>procedure TForm1.Button1Click(Sender: TObject);
>var
>i:cardinal;
>_list:TStrings;
>begin
> _list:=TStringList.create;
> try
> for i:=0 to _list.count-1 do begin
0 - 1 = -1. Out of bounds for a cardinal.
> showmessage(_list[i]);
> end;
> finally
> _list.free;
> end;
>end;
Donald Shimoda
>I dontknow, maybe is too late but that code dont must work?
My apologize to the comunnity. Another thread destroy some components at the
same time that part of code running.
Thanks to all wanting to help me to find the cause, was my mistake, not was
a compiler error at all. As i guess at the start, was so late at nigth when
i run in that error.
Best regards.
Rudy Velthuis [TeamB]
> Rudy Velthuis [TeamB] wrote:
> <snip>
> >
> > IOW, range checking should ALWAYS be turned on.
>
> No, it shouldn't be always turned on
> Yes, it should.
> -especially for certain applications where the range checking gets in
> the way. Enough said.
Turning off range checks is not the way to make apps faster. Changing
the algorithms is much more effective.
BTW, do you have an example when range checks get in the way?
--
Rudy Velthuis [TeamB]
"Never raise your hands to your kids. It leaves your
groin unprotected." -- Red Button
Rudy Velthuis [TeamB]
> On Thu, 6 Sep 2007 09:32:47 +0200, "DelphiUser"
> <delph...@atwork.com> wrote:
>
> > This give also a nice index out of bounds error.
>
> It would.
>
> >
> > procedure TForm1.Button1Click(Sender: TObject);
> > var
> > i:cardinal;
> > _list:TStrings;
> > begin
> > _list:=TStringList.create;
> > try
> > for i:=0 to _list.count-1 do begin
>
> 0 - 1 = -1. Out of bounds for a cardinal.
Exactly. But if there is no range and overflow check, it will become
$FFFFFFFF, and that is a pretty high number, so index errors are to be
expected.
--
Rudy Velthuis [TeamB]
"Ah well, then I suppose I shall have to die beyond my means."
-- Oscar Wilde, dying words
Rudy Velthuis [TeamB]
> "Donald Shimoda" <shimod...@hotmail.com> wrote in message
> news:46df...@newsgroups.borland.com...
> > I dontknow, maybe is too late but that code dont must work?
>
> My apologize to the comunnity. Another thread destroy some components
> at the same time that part of code running.
OMG! Threads should not be allowed to do that.
--
Rudy Velthuis [TeamB]
"A good pun is its own reword."
Don Strenczewilk
contain apologies?
"Rudy Velthuis [TeamB]" <newsg...@rvelthuis.de> wrote in message
news:xn0fax14e...@newsgroups.borland.com...
John Herbster
Rudy Velthuis [TeamB]
> Do you you mean Threads that destroy components or Threads in
> non-tech that contain apologies?
LOL! I meant the ones that destroy components, especially if they do it
behind the back of the main thread.
--
Rudy Velthuis [TeamB]
"Premature optimization is the root of all evil." -- Donald Knuth
Donald Shimoda
news:xn0fax14e...@newsgroups.borland.com...
>
> OMG! Threads should not be allowed to do that.
Programers working too late is the cause, please dont make thread guilty for
that. <g>
Q Correll
| Turning off range checks is not the way to make apps faster. Changing
| the algorithms is much more effective.
Perhaps not "the" way but it is "a" way. <g> Run-time Range checks
shouldn't really often be necessary after an app is debugged and
released. A couple of my apps make extensive use of arrays and
dynArrays iterations. Run-time range checking DOES slow them down.
And there's not much chance of "algorithmic improvements."
--
Q
09/07/2007 09:28:45
XanaNews Version 1.17.5.7 [Q's salutation mod]
David Erbas-White
> Rudy,
>
> | Turning off range checks is not the way to make apps faster. Changing
> | the algorithms is much more effective.
>
> Perhaps not "the" way but it is "a" way. <g> Run-time Range checks
> shouldn't really often be necessary after an app is debugged and
> released. A couple of my apps make extensive use of arrays and
> dynArrays iterations. Run-time range checking DOES slow them down.
> And there's not much chance of "algorithmic improvements."
>
Unless you change the algorithm to exclude range-checking... <G>
David Erbas-White
Don Strenczewilk
"Rudy Velthuis [TeamB]" <newsg...@rvelthuis.de> wrote in message
news:xn0fax37s...@newsgroups.borland.com...
Q Correll
| Unless you change the algorithm to exclude range-checking... <G>
<giggle>
Anyone ever tell you that you're a wise-*ss? ;-)
--
Q
09/07/2007 12:34:29
David Erbas-White
> David,
>
> | Unless you change the algorithm to exclude range-checking... <G>
>
> <giggle>
>
> Anyone ever tell you that you're a wise-*ss? ;-)
>
Who, me??? Whatever would give you that idea???
David Erbas-White
Q Correll
| Who, me???
Yeah,... you. <g>
--
Q
09/07/2007 13:41:25
Pieter Zijlstra
> Rudy,
>
> > Turning off range checks is not the way to make apps faster.
> > Changing the algorithms is much more effective.
>
> Perhaps not "the" way but it is "a" way. <g> Run-time Range checks
> shouldn't really often be necessary after an app is debugged and
> released. A couple of my apps make extensive use of arrays and
> dynArrays iterations. Run-time range checking DOES slow them down.
> And there's not much chance of "algorithmic improvements."
Just to have an idea of how much it would slow down in tight loops I
made a little quick test with and without range checking. Test code is
below where N is number of elements in dynamic array and M number of
iterations.
N = 100, M = 10000000
w/o 7.4s w 8.8s
N = 1000, M = 1000000
w/o 3.6s w 5.0s
N = 1000000, M = 1000
w/o 4.7s w 5.5s
Now if instead integers doubles are used...
N = 100, M = 10000000
w/o 17.7s w 18.3s
N = 1000, M = 1000000
w/o 13.8s w 14.3s
N = 1000000, M = 1000
w/o 15.7s w 15.8s
It's up to you if that is to much of a slow down, for me it isn't. I'm
with Rudy never turn off range checking, also not in production code.
(that is on application level, on unit level or procedure level I might
turn off range checking in specific situations, but only after
extensive testing with range checking).
BTW this was with Optimization and Overflow Checking on (my opinion
about the later, see Range Checking :)
// << TESTCODE
type
TVarType = Integer; // Double
TArray = array of TVarType;
TResult = TVarType;
function SumArray(A: TArray): TResult;
var
I: Integer;
begin
Result := 0;
for I := Low(A) to High(A) do
Result := Result + A[I] - 1;
end;
procedure TForm1.btnStartClick(Sender: TObject);
const
N: Integer = 1000;
M: Integer = 1000000;
var
A: TArray;
I: Integer;
J: Integer;
TotalTime: Double;
QPF, QPC1, QPC2: Int64;
begin
SetLength(A, N);
QueryPerformanceFrequency(QPF);
TotalTime := 0;
for J := 0 to M - 1 do
begin
QueryPerformanceCounter(QPC1);
for I := Low(A) to High(A) do
A[I] := I;
SumArray(A);
QueryPerformanceCounter(QPC2);
TotalTime := TotalTime + (QPC2-QPC1) / QPF;
end;
mmoResults.Lines.Add(Format('%.3f s', [TotalTime]));
end;
// >>
--
Pieter
Q Correll
| N = 100, M = 10000000
| w/o 7.4s w 8.8s
That's about 19% slower with RC. A no-brainer for the apps I'm talking
about. Which pretty much tallies with my memory of one function test I
ran where the app ran for 20 minutes with RC and about 15 minutes
without. (The function used Sets, not Ints.)
Thanks!
--
Q
09/07/2007 20:47:02
Dave White
news:xn0faxw7...@newsgroups.borland.com...
>
> It's up to you if that is to much of a slow down, for me it isn't. I'm
Maybe for you it isn't, but in my case, my application works with
chromatographic data which is heavily array based - a chromatogram is a two
dimensional array of time vs intensity - and range checking KILLS
performance. One of the main functions of my app is to generate Level 4
reports. These average about 600 pages and take about 30 minutes to
generate. With range checking on, they take almost twice that, and for
production code, that's unacceptable.
Once in a while I'll tell the analysts that I've enabled debugging, and
things may run a little slower - I get a lot of grief those times.
Rudy Velthuis [TeamB]
> Rudy,
>
> > Turning off range checks is not the way to make apps faster.
> > Changing the algorithms is much more effective.
>
> Perhaps not "the" way but it is "a" way. <g> Run-time Range checks
> shouldn't really often be necessary after an app is debugged and
> released.
But it can't hurt to leave them on. No app is without bugs, and, like I
said before, it is better to get a range check error than to go on with
an unnoticed bad result.
> A couple of my apps make extensive use of arrays and
> dynArrays iterations. Run-time range checking DOES slow them down.
> And there's not much chance of "algorithmic improvements."
Then, like I also said before, only turn it off for those parts, but
not generally.
--
Rudy Velthuis [TeamB]
"Men and nations behave wisely once they have exhausted all the
other alternatives." -- Abba Eban (1915-2002)
Rudy Velthuis [TeamB]
> Oh, sor[REMAINDER OF POST CANCELED DUE TO OVERLY APOLOGETIC TONE]. :)
You are not a Canadian, by chance, are you? <g>
--
Rudy Velthuis [TeamB]
"Guard against the impostures of pretended patriotism."
-- George Washington
Rudy Velthuis [TeamB]
> Q Correll wrote:
>
> > Rudy,
> >
> > > Turning off range checks is not the way to make apps faster.
> > > Changing the algorithms is much more effective.
> >
> > Perhaps not "the" way but it is "a" way. <g> Run-time Range checks
> > shouldn't really often be necessary after an app is debugged and
> > released. A couple of my apps make extensive use of arrays and
> > dynArrays iterations. Run-time range checking DOES slow them down.
> > And there's not much chance of "algorithmic improvements."
>
> Just to have an idea of how much it would slow down in tight loops
Then turn it off temporarily, for those tight loops only (i.e. with
{$R-} and {$R+} surrounding them). But not generally, i.e. not in the
project options.
--
Rudy Velthuis [TeamB]
"Java, the best argument for Smalltalk since C++." -- unknown
Rudy Velthuis [TeamB]
> "Pieter Zijlstra" <p.zylstr...@hccnet.nl> wrote in message
> news:xn0faxw7...@newsgroups.borland.com...
> >
> > It's up to you if that is to much of a slow down, for me it isn't.
> > I'm
>
> Maybe for you it isn't, but in my case, my application works with
> chromatographic data which is heavily array based - a chromatogram is
> a two dimensional array of time vs intensity - and range checking
> KILLS performance.
That is still not a good reason to turn it off for the entire app, IMO.
--
Rudy Velthuis [TeamB]
"If everything seems under control, you're just not going fast
enough." -- Mario Andretti
Q Correll
| But it can't hurt to leave them on. No app is without bugs, and, like
| I said before, it is better to get a range check error than to go on
| with an unnoticed bad result.
Except, it seems, that in this, my particular, case it wouldn't have
made any difference. <g>
--
Q
09/08/2007 09:35:37
Rudy Velthuis [TeamB]
> Rudy,
>
> > But it can't hurt to leave them on. No app is without bugs, and,
> > like I said before, it is better to get a range check error than
> > to go on with an unnoticed bad result.
>
> Except, it seems, that in this, my particular, case it wouldn't have
> made any difference. <g>
You mean you produced bad data anyway? <g>
--
Rudy Velthuis [TeamB]
"Throughout American history, the government has said we're in an
unprecedented crisis and that we must live without civil
liberties until the crisis is over. It's a hoax."
-- Yale Kamisar, 1990.
Q Correll
| You mean you produced bad data anyway? <g>
No. :-P
I mean Range Checking did not find, and would not have found, the
problem at the point of the range error occurrence. Please see Pieter
Z.'s "discovery" posts.
--
Q
09/08/2007 15:01:05
Rudy Velthuis [TeamB]
> Rudy,
>
> | You mean you produced bad data anyway? <g>
>
> No. :-P
>
> I mean Range Checking did not find, and would not have found, the
> problem at the point of the range error occurrence. Please see Pieter
> Z.'s "discovery" posts.
Ah, OK. Seems to work in D2007, though.
--
Rudy Velthuis [TeamB]
"Despite the high cost of living, it remains popular."
Q Correll
| Ah, OK. Seems to work in D2007, though.
Yes. That's also what Uffe typed over in 3rd Party.
--
Q
09/08/2007 17:00:01
Rudy Velthuis [TeamB]
> Rudy,
>
> > Ah, OK. Seems to work in D2007, though.
>
> Yes. That's also what Uffe typed over in 3rd Party.
Oh, cool.
--
Rudy Velthuis [TeamB]
"To iterate is human, to recurse divine." -- L. Peter Deutsch
Don Strenczewilk
leaked into the lake.
"Rudy Velthuis [TeamB]" <newsg...@rvelthuis.de> wrote in message
news:xn0faykf6...@newsgroups.borland.com...