Re: sc_vector proposal

Jerome, all,

to me, the main reason for not adding an API to add additional elements
to the vector apart from the init() function is to avoid the need for
verbose rules, under what circumstances and at what time it is OK to use
this API.

  The current proposal provides an init-once interface, which is far
easier to handle for an implementation. For more dynamic containers, I
think using plain std::vectors (or arrays) would be fine in the majority
of cases. Having dynamic sc_object derived instances without a default
constructor (which is the main showstopper for using an std::vector)
seems to be a rare requirement to me.

  So I would vote for keeping the init-interface as originally proposed.
 Future versions of the standard (and corresponding implementations) can
of course extend it, if the need shows up.
What do you think?

Thanks and Greetings from Oldenburg,
Philipp

On 05/11/10 18:32, Jerome CORNET wrote:
> 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
>
>

-- 
Philipp A. Hartmann
Hardware/Software Design Methodology Group
OFFIS Institute for Information Technology
R&D Division Transportation · FuE-Bereich Verkehr
Escherweg 2 · 26121 Oldenburg · Germany
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · http://www.offis.de/
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.