Re: [ALACPP] Notes -- Chapter 4

[Christopher Smith <x@xxxxxxxx>]

On Thu, 2003-06-05 at 14:32, Kevin Scaldeferri wrote:
> Here's my summary of yesterday's discussion & other notes from my
> reading.  
> 
> Chapter 4 of Alexandrescu -- Small Object Allocator
> 
> Okay, this chapter didn't make me cringe. Here's a example of where
> using C is nice, because you can override fairly fundamental parts of
> the system (i.e. how things are laid out in memory.) This is a lot
> harder, if not impossible, in most other languages.

I agree with this assessment, but I guess what I had trouble with was
understanding how this was taking advantage of any particular C++
features in a way that provided distinct advantages over C. I mentioned
a number of implementations of malloc out there:

http://www.cs.colorado.edu/~zorn/Malloc.html

Many of these implementations are much older than the book, so I'm kind
of suspect of where the inequities lay. I do know that prior to MSVC6,
the MSVC runtimes tended to have slow heaps, as compared to say
Symantec's C++ runtime. Maybe this was the key problem that he was
addressing (I still think it'd make just as much sense, if not more, to
drop in a malloc replacement, rather than override operator new/delete
for this). The only C++ advantage I saw was being able to enforce that a
particular allocator be used for a particular class, which I tend not to
think of as an "advanced" C++ concept, but perhaps my perspective is
skewed.

BTW, one thing that did trip me up here was his citing of Sutter
suggesting that you should always override delete(void*) as opposed to
delete(void*, size_t). Can anyone jog my memory as to why Sutter
suggested this rule?

> I got tripped up for a bit on a little issue of language semantics. The
> statement:
> 
> Lock lock; 

Yeah, this is a very common C++ idiom, but very different syntax from
Java.

BTW, I found this use of locking to be incredibly naive. This
essentially causes your heap to be single threaded, and therefore a
bottlneck for a lot of different types of applications. Most modern
heaps will at least allow threads to have their own heaps, and many
actually provide sophisticated mechanisms for low-contention parallel
access to the heap. Hoard and ptmalloc are probably good examples to
look at.

> does totally different things in C++ and Java. I'm used to Java, at this
> point, where this just creates a null pointer that you need to assign to
> later. However, in C++ this actually constructs a Lock object on the
> stack. Consequently, what looked to me like a bit of dead code can
> actually do something significant though the implicit invocation of the
> constructor and destructor (when you exit the block).

The trick is that in Java you are always constructing a pointer when you
do this. ;-)

-- 
Christopher Smith <x@xxxxxxxx>
_______________________________________________
alacpp mailing list
alacpp@xxxxxxxxxxx
http://lists.ellipsis.cx/mailman/listinfo/alacpp