C/C++ style Crashes?

Sebastian Biallas groups.5.sepp at spamgourmet.com
Mon Jan 15 08:54:57 PST 2007


Steve Horne wrote:
> On Fri, 12 Jan 2007 04:02:50 +0100, Sebastian Biallas
> <groups.5.sepp at spamgourmet.com> wrote:
> 
>> Steve Horne wrote:
>>> In a systems language, pointer arithmetic is a necessity. There are
>>> things you simply cannot do without it - data structures that require
>>> it, for instance.
>> Can you give an example?
> 
> A particular favorite of mine allows doubly-linked list behaviour
> using a single link per item - very useful if you need extremely large
> lists of small items (though a custom allocator is essential). 

I know of these lists. But they don't seem to be particulary useful:

a) Where do you need extremely large lists? Lists have a search time in
O(n). Ok, you have a O(1) insertion/deletion here, but only at one
place, since your iterators get void after an insertion/deletion
(contrary to normal double linked lists)
b) They don't work in a GC-enviroment or require special handling.

Are they really used somewhere out of the IOCCC? I'd be curious to see a
real world example.

> In addition, pointer casting is useful for managing template bloat.
> The basic approach is to write type-unsafe non-template code, and then
> use a template to add a typesafe wrapper. 

This works with normal pointer casting (no need for arithmetik). Hey,
this was even the normal usage of Java-Containers before they had the
template stuff.

> But in many cases, more
> flexibility is needed than can be handled using simple pointer
> casting.
> 
> For example, consider a library to handle flexible tree data
> structures. The container being implemented may or may not have a key
> field. It may or may not have a data field. It may or may not have
> subtree summary data stored within nodes. The non-template part needs
> a way to access fields such that the position within a node struct (of
> an unknown datatype) is determined at run-time.

I don't think it's a good idea to trade portability for a few cycles.
And this might be even slower, since you confuse the compiler
(alias-analysis etc).



More information about the Digitalmars-d mailing list