From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,23ace43a488fab29 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news.glorb.com!npeer.de.kpn-eurorings.net!news.n-ix.net!news2.arglkargh.de!noris.net!newsfeed.arcor.de!news.arcor.de!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: function "&" for strings type cause memory problem. Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1fxvr41a6cj64$.1cin7p2ro7ua2$.dlg@40tude.net> Date: Fri, 11 Nov 2005 14:45:53 +0100 Message-ID: <5h23dl2sire9.hk0tsc5bj1ot.dlg@40tude.net> NNTP-Posting-Date: 11 Nov 2005 14:45:53 MET NNTP-Posting-Host: db0f167f.newsread2.arcor-online.net X-Trace: DXC=df;m=4F]ZNK?_CdR_9TKXAQ5U85hF6f;DjW\KbG]kaMHQ>n?D9BSA]L2l84:\?TkBI[6LHn;2LCVN7enW;^6ZC`D<=9bOTW=MNN X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:6346 Date: 2005-11-11T14:45:53+01:00 List-Id: On Fri, 11 Nov 2005 19:55:05 +0800, bubble wrote: > "Dmitry A. Kazakov" > 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