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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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!Spring.edu.tw!news.nctu.edu.tw!feeder.seed.net.tw!netnews!not-for-mail From: "bubble" Newsgroups: comp.lang.ada Subject: Re: function "&" for strings type cause memory problem. Date: Fri, 11 Nov 2005 19:55:05 +0800 Organization: HiNetNews Message-ID: References: <1fxvr41a6cj64$.1cin7p2ro7ua2$.dlg@40tude.net> NNTP-Posting-Host: 211-21-128-195.hinet-ip.hinet.net X-Trace: netnews.hinet.net 1131710111 4766 211.21.128.195 (11 Nov 2005 11:55:11 GMT) X-Complaints-To: usenet@HiNetnews.hinet.net NNTP-Posting-Date: Fri, 11 Nov 2005 11:55:11 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2527 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Xref: g2news1.google.com comp.lang.ada:6344 Date: 2005-11-11T19:55:05+08:00 List-Id: "Dmitry A. Kazakov" ???????:1fxvr41a6cj64$.1cin7p2ro7ua2$.dlg@40tude.net... > On Fri, 11 Nov 2005 16:25:21 +0800, bubble wrote: > 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". > (:-)) Wow! so interesting define and good idea. if S ~ Normal distribution,thery are 99.73% in 3 sigma , maybe 2.5 sigma is big. >> 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. > > 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. Agree. minimizing risk is importing. sometime ,It difficult to choose which one is best. chooses are always trade-off, it's painful. 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. It's not in my expect. my expect is worse performace but error.(painful ,painful...) > 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 .