Re: function "&" for strings type cause memory problem.

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 11 Nov 2005 19:55:05 +0800, bubble wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 

> may be I need rethink the strategies of string types.
> and the ARM do not say string merge may raise error when lack of stack 
> space.

Storage_Error is an "implied" exception.

> It's not in my expect.
> my expect is worse performace but error.(painful ,painful...)

It is not always the best possible behavior. The answer depends on whether
appearance of large objects is a design fault or an artefact of deployment
(the machine is too weak for the problem.) In the former case, an earlier
error detection (a crash, yes) is preferable in the long term perspective.
Observe the resource starvation problems many Windows and Linux
applications suffer. Most of them just cover some design faults. MS-Office
loads all opened documents into RAM, should it be so? Too many people are
ready to buy a new workstation each 3-4 years... Last time I stumbled upon
this, was a 13 GB log file (ASCII! (:-)). I was amazed that there were no
editor capable to open it at once. The best I found was UltraEdit. 15-20
years ago nobody would buy such "editor." Technical progress is how people
call it!

>> Well, should it be Visual Basic? OK, you need not answer this! (:-))
> 
> I am lazy man. and my programers have no any IT background.
> VB is much easy for us to do "RAPID" GUI development. ^^||
> Gwindows/C/C++/java is too hard to non-IT .

I am even more lazy, so I'm using raw Windows GUI API even with C++. The
time you might win using VB, Delphi or C++/MFC, you can easily loose if
something turns wrong. The probability of this to happen is inversely
proportional to what customer is ready to pay for the project! (:-))
Usually customers have quite silly requests, looking pretty innocent, from
their point of view of course, but almost impossible to implement without
turning everything upside down. Using Windows GUI I at least know what's
going on. One example: I tend to design GUI working in a polling way as
opposed to usual event-controlled manner. It is more difficult from the
start, but it guaranties definite response time. You'll have more or less
exact figures of how it will work in the worst case, you will also know how
much of CPU time GUI eats, it is fixed. And last but not least, it is
multitasking friendly from the very beginning. This pays off later (or not
(:-)).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de