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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 10ad19,23963231b5359f74 X-Google-Attributes: gid10ad19,public X-Google-Thread: 101deb,23963231b5359f74 X-Google-Attributes: gid101deb,public X-Google-Thread: 10a146,23963231b5359f74 X-Google-Attributes: gid10a146,public X-Google-Thread: 107a89,23963231b5359f74 X-Google-Attributes: gid107a89,public X-Google-Thread: 103376,23963231b5359f74 X-Google-Attributes: gid103376,public X-Google-Thread: 1073c2,23963231b5359f74 X-Google-Attributes: gid1073c2,public X-Google-ArrivalTime: 2001-06-09 05:36:13 PST Path: archiver1.google.com!newsfeed.google.com!sn-xit-02!supernews.com!newsfeed.direct.ca!look.ca!newshub2.rdc1.sfba.home.com!news.home.com!sjc1.nntp.concentric.net!newsfeed.concentric.net!global-news-master From: Patricia Shanahan Newsgroups: comp.lang.ada,comp.lang.awk,comp.lang.clarion,comp.lang.java.programmer,comp.lang.pl1,comp.lang.vrml Subject: Re: Memory Allocation without pointer arithmetic ? (was: Long names...) Date: 09 Jun 2001 12:34:49 GMT Organization: Concentric Internet Services Message-ID: <3B221877.BBE3A49F@acm.org> References: <9f2nks$ibd$0@dosa.alt.net> <3B177EF7.2A2470F4@facilnet.es> <9f8b7b$h0e$1@nh.pace.co.uk> <9f8r0i$lu3$1@nh.pace.co.uk> <9fgagu$6ae$1@nh.pace.co.uk> <9fjgha$blf$1@nh.pace.co.uk> <35mqhtkdfma2rggv1htcaq6vfn2ihs67a1@4ax.com> <9fli1b$4aa$1@nh.pace.co.uk> NNTP-Posting-Host: 64.0.145.105 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en Xref: archiver1.google.com comp.lang.ada:8487 comp.lang.awk:2950 comp.lang.clarion:21541 comp.lang.java.programmer:74982 comp.lang.pl1:951 comp.lang.vrml:3689 Date: 2001-06-09T12:34:49+00:00 List-Id: Larry Kilgallen wrote: > > In article <3B219DB3.4BF2A68A@acm.org>, Patricia Shanahan writes: > > James Kanze wrote: > >> > >> Pete Thompson wrote: > >> > >> [...] > >> > Well, sure. Pointer arithmetic in C/C++ is inherently unsafe and > >> > encourages obfuscation. However, it also promotes flexibility. > >> > >> Just curious, but what can you do with pointer arithmetic in C/C++ > >> that you couldn't do otherwise, in a cleaner fashion? > > ... > > > > Manage memory. A memory allocator, such as malloc, or the corresponding > > kernel code, or the code underlying "new", has a split view of memory. > > It must perform calcuations to determine where to put the the newly > > created object. It must return a pointer to it. > > That is an interesting example, even though it should only occur once > per operating system. I have never tried to do that in Ada. I would expect a few times per OS. For example: 1. User malloc. That can also be the function underlying "new" in C++. 2. Implementation of Java "new". While I suppose it may be based on malloc, there may be additional requirements to support GC making it different. The fact that the Java heap has a predetermined size limit suggests that it is separate, because the malloc space is supposed to grow as big as the OS will let it. 3. Kernel equivalent of malloc. It can use similar algorithms to malloc, but will need different handling when it runs out of currently available memory. This may be subdivided depending on whether the allocations can be pageable or not. 4. Kernel buffer allocation. The kernel will need to allocate a lot of buffers whose sizes will be multiples of a moderately large power of two. It may be more efficient to use a different allocation system rather than throwing them into the main kernel pool. There may be other specialized allocators, tuned to particular types of requests, in either the kernel or in user programs. > > Does anyone have experience trying to subdivide memory objects (the > free pool) without using the equivalent of pointer arithmetic ?