Re: [sv-ec] Problems with Appendix D - "Linked List"

Gord,

So would you also be in favor then of removing the `include <filename>
syntax described in 23.3?

-- Brad

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Gordon Vreugdenhil
Sent: Monday, April 03, 2006 9:08 PM
To: Neil.Korpusik@Sun.com
Cc: SV_EC List
Subject: Re: [sv-ec] Problems with Appendix D - "Linked List"



Neil Korpusik wrote:
> Doesn't a queue sometimes have more overhead in terms of simulation
performance?

Absolutely -- that is whay I mentioned the different methods.

There are two sub-questions:
   1) how important are the mid-list operations at this point?
   2) do we want to start adding other "STL" like structures in the LRM
      rather than having that be up to the user?  Why only have a
      fairly heavy-weight list as opposed to both uni-directional
      and bi-directional List types?  etc, etc.

There is almost nothing ("purge" being the egregious exception) in
List that can't be implemented in SV source.  So why have this in
the LRM?

<begin soap box>
If we really want to go with STL like infrastructure, shouldn't
we be examining the entire infrastructure for consistent methodology
and approches that actually compose in a reasonable manner?

There are many ad hoc solutions throughout the language (array
manipulators, STL like iterators, "magic" built-in methods, etc)
with no apparent regard for consistent language design.  Personally,
if we're going to change List anyway, I'd rather remove it
for now and try to get a more consistent approach in place
than to continue the kitchen sink approach that we seem to
have adopted.
<end soap box>

Ok, I feel better now.

That being said, as I mentioned initially, the simplest short
term solution is to just move "List" into package std.  I am
not at all convinced that this is the best long term
solution, but it is better than leaving a broken definition
in the LRM.

I do have an objection to "purge" in terms of it being yet
another magic method, but that is a different issue.

Gord.


> 
> If additions and deletions mainly occur at the ends of the "list" then
> a queue may be as efficient, but if a lot of operations take place
> in the middle of the list, I would expect the linked list to be more
> efficient, since elements are being moved around.
> 
> Neil
> 
-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com