RE: sc_vector proposal

Philipp, all,

comments below.

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Thursday, November 04, 2010 10:57 PM
To: Jerome CORNET
Cc: john.aynsley@doulos.com; P1666 Technical WG
Subject: Re: sc_vector proposal

> Since there seems to be consensus that we should not add extra levels
> in the hierarchy, I would propose to use another function name for this,
> since the elements are not "child objects" in the strict sense. Maybe
> 'get_elements' would be better?

> Shall we restrict the sc_view() technique to such (member) objects as
> well? This could keep the symmetry in the interface of sc_vector<T> and
> a corresponding sc_vector_view<T, & T::Member > by adding a
> 'get_elements' there as well.

Ok with that.

> I'm fine with creating vectors during simulation (if the elements
> support it). But I would prefer to tie the lifetime of the elements to
> the lifetime of the vector itself, and thus not supporting the dynamic
> expansion (or shrinking) of the vector.

> Having dynamically resizable vectors would require all kinds of
> dynamic checks during simulation and hamper the support of sc_vector for
> HLS tools. Init-only vectors can be supported by such tools quite
> easily (at least without custom Creator functors).

I don't fundamentally disagree with you on this, but I have some remarks.

- Not supporting vector's shrinking seems indeed simpler to avoid problems of
object lifetime.

- However, I don't see why we shouldn't support adding elements during the simulation
as:
   - This would by definition be only possible for user-derived sc_object (and not for sc_port/sc_module)
Therefore, this would have not much effects on HLS support, as HLS will focus on well-known sc_object(s) and not
user-defined classes (I guess).
   - There is no relation between expansion of the vector and object's lifetime since technically
the internal vector storage is holding object pointers (and this is transparent for the user).

Anyway, I have no strong motivation/use cases for requiring the vector expansion feature, so I am ok
to forbid it if necessary.

Jerome

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.