[Insight-developers] linked list implementation

[Miller, James V (CRD)]

I side with Bill.  The default allocator should be fine for your application and as he pointed out
the iterators are already provided.

Why do you think that you need derive from stl::list?

As for the method of accessing a list, iterators are the way people implement/use link lists now.
The concept of separating your position in a list from the list container was a major development in
reusable code. 

Jim

-----Original Message-----
From: William A. Hoffman [mailto:bill.hoffman@kitware.com]
Sent: Wednesday, March 28, 2001 3:33 PM
To: Damion Shelton; insight-developers@public.kitware.com
Subject: Re: [Insight-developers] linked list implementation


I would say this should be a last resort.   TargetJr had 12 or so lists in it,
and it was VERY confusing to users.   I don't really see the strong case
for using you own list in this case.

1. stl is templated, but it is written, and when you instantiate it over 
your type,
it will be a single class.

2. you may not like the interface, but ever student of C++ will learn that
interface, and think that your interface is non-standard and strange.

3. Why do you have to write an allocator and iterator?  They should
already be part of the stl list.

As long as the memory foot print and storage is not an issue, I would say
go with the standard.   Insight is complicated enough, we don't want people
to have to learn our own list class.

With the matrix class, there is no standard.   The problem is with the 
memory foot
print of the vxl vector.

-Bill


At 03:15 PM 3/28/01 -0500, Damion Shelton wrote:
>Hi all...
>
>Our work on a linked list pixel type is progressing well, but I have a
>question of style... would it be considered "uncouth" to use our own linked
>list class (which already exists), rather than the STL list class? After
>playing with the STL implementation, the overhead of having to write an
>allocator and iterator seems a bit wasteful. Here's the pro and con
>arguments, from my POV, re. STL vs. our own class:
>
>Pros:
>
>Our linked list does not need the flexibility of templating, since it's only
>intended to hold one type of object, and I find the STL method of accessing
>list entries a bit counterintuitive.
>
>We would have to derive a specialized class from list in any case, since our
>"pixels" need to be able to do more than "ordinary" pixels.
>
>Cons:
>
>We would be duplicating existing functionality (sort of - we would still
>need to specialize the list class and add extra functionality)
>
>The STL implementation would in theory be more general / promote recycling
>of our work.
>
>
>This seems to be a problem analogous to the ongoing matrix discussion: do we
>rewrite functionality for the sake of clarity or wrap for the sake of
>portability? Any thoughts?
>
>-Damion-
>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers


_______________________________________________
Insight-developers mailing list
Insight-developers@public.kitware.com
http://public.kitware.com/mailman/listinfo/insight-developers