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


"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
???????:1fxvr41a6cj64$.1cin7p2ro7ua2$.dlg@xxxxxxxxxxxxx
> 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 .



.

Relevant Pages

  • Re: function "&" for strings type cause memory problem.
    ... > and I allocate the large object in heap memory in previous case. ... Memory allocation is always a risk. ... There is no difference between stack and heap here. ...
    (comp.lang.ada)
  • Re: ten thousand small processes
    ... them roughly in the middle you take space away from heap and stack ... identical across two processes as is the case with large shared memory ... There is no special allocation for virtual address space that is ... the standard libc or at least not the standard malloc implementation. ...
    (freebsd-performance)
  • Re: [RFC] [PATCH] A clean approach to writeout throttling
    ... IOW, we know that it's below its allocation limit, ... very low and the reserve very high, and run a bio through the stack (what ... By also running a real bio through the stack we can discover ... We a-priori decide to limit a particular stack's peak memory usage to ...
    (Linux-Kernel)
  • Re: alloca / _alloca / dynamic stack memory
    ... on the heap, then to allocate Foo the default new operator needs to be called ... Dynamic stack allocation is scoped to a specific stack frame. ... memory allocator to use at runtime to best suite your needs. ...
    (microsoft.public.vc.language)
  • Re: If Macs have no spyware....
    ... >had made a complete code review of its operating system and removed all ... and writing new data into those memory locations would ... >but when the data exists on the stack, it can cause very large problems. ... >location that needs to be written in place of the correct execution ...
    (comp.sys.mac.advocacy)