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!news1.google.com!proxad.net!proxad.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: Date: Fri, 11 Nov 2005 10:43:00 +0100 Message-ID: <1fxvr41a6cj64$.1cin7p2ro7ua2$.dlg@40tude.net> NNTP-Posting-Date: 11 Nov 2005 10:43:00 MET NNTP-Posting-Host: 1e4bf2ee.newsread4.arcor-online.net X-Trace: DXC=Q>PJkebW=07F:^Y;boJ3Y0:ejgIfPPld4jW\KbG]kaM81BZS;MmC656FEBT[5LE7Z=WRXZ37ga[7:n919Q4_`Vj9B8=X\UUgbk4 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:6341 Date: 2005-11-11T10:43:00+01:00 List-Id: On Fri, 11 Nov 2005 16:25:21 +0800, bubble wrote: > maybe the subject should be > function "&" crash in thread's stack size is too small, even if you have a > big heap memory. > > I knew to allocate a "large" object in stack is a bad idea.(another > question:how to define "large" to stack?) Let Si be a set of all objects simultaneously existing in the program P at its execution state i. Si/|Si| is an average object size. Calculate its expectation value for all possible states i=1..N. Now if the object's size deviates from that in more than 3 sigma, the object is called "large". (:-)) > and I allocate the large object in heap memory in previous case. > It's seem so beauty :) > if "&" is creating its result on the stack ,it still has potential risk. Memory allocation is always a risk. An important objective of software design is to minimize risks. One can ignore allocation issues as long as objects are small. Otherwise some static analysis is required to ensure that in any case the memory pool will be large enough to hold all objects. There is no difference between stack and heap here. Even if, for example, the heap can be enlarged on demand while the stack not, it is all OS specific issue. > in others. > I don't want to tell my programer: > " you can not use & for string or array,it has 1% probability to crash" > > I want to say. > " & for string or array merge don't crash, but you will get worst > performace" > " you can change code and you will get better performance" Actually Ada provides 3 types of strings reflecting different memory management strategies. Reconsider your design. For example, if objects are large, then you need to drop that nice "functional programming" style, and switch to hard core in-place operations. That is "Append" instead of "&". You can also move the burden of allocation to the caller side, which usually knows it better. BTW, this is what Microsoft did with you. You are required to specify the stack size. If something goes wrong, then your program will crash, instead of showing some worse performance. There will be no any performance. Basically, you have to decide who is responsible for what. > To Jeff and Dmitry. > > in fact. > the the kernel(ada part) just crash "few" times. > It work perfectly until now after I change something like new test case . > > my string are not so big, > I give you the extreme example. > because I just want to say bugs often happen in extreme case. > and I have not find any documents to increasing stack size in VB6. Well, should it be Visual Basic? OK, you need not answer this! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de