Re: sc_vector proposal

I agree we can put aside sc_vector and HLS.

Mac

----- Original Message -----
From: Jerome CORNET <jerome.cornet@st.com>
To: Philipp A. Hartmann <philipp.hartmann@offis.de>; Michael (Mac) McNamara
Cc: john.aynsley@doulos.com <john.aynsley@doulos.com>; P1666 Technical WG <systemc-p1666-technical@eda.org>
Sent: Mon Nov 08 01:11:49 2010
Subject: RE: sc_vector proposal

Philipp, Mac, all,

I think that at this point of the discussion we all lack a concrete example of use of user-defined
classes (not deriving from sc_port or sc_module) within sc_vector.

Mac: I understand that your HLS tools perfectly support user-defined classes, but what would be the
use within a sc_vector?

Anyway, let's move on, I agree with your argument Philipp. We are in a grey
area which is very close to situations where a std::vector would be preferable.

Let's avoid creating additional elements during simulation then.

Regards,

Jerome

-----Original Message-----
From: Philipp A. Hartmann [mailto:philipp.hartmann@offis.de]
Sent: Friday, November 05, 2010 8:04 PM
To: Jerome CORNET
Cc: john.aynsley@doulos.com; P1666 Technical WG
Subject: 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

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