Re: New draft LRM and progress

Done.

(insert
  sc_vector_assembly( const sc_vector_assembly& );

  Replace  sc_vector_assembly( sc_vector<T>& , member_type )
  with     sc_vector_assembly& operator=( const sc_vector_assembly& );
)

John A

-----owner-systemc-p1666-technical@eda.org wrote: -----
To: alan.fitch@doulos.com
From: "Philipp A. Hartmann"
Sent by: owner-systemc-p1666-technical@eda.org
Date: 11/30/2010 01:09PM
Cc: systemc-p1666-technical@eda.org
Subject: Re: New draft LRM and progress

Alan,

I'll try to answer the sc_vector related comments below.

On 30/11/10 11:35, alan.fitch@doulos.com wrote:
>
> Section 9.5.7
> What is the reason for
>
> "The value of the relation &V[i] + j == &V[i + j] is undefined for all vectors v and for all indices i
> and j."
>
> Standard (STL) vectors are guaranteed to be laid out contiguously in memory such that you can just take
> the address of the first element and access the contents as though they were a standard C array.

sc_vector<T> is essentially a wrapper around std::vector<T*> internally,
but its iterators (and operator[]) are hiding this indirection layer
from the user. Therefore, the contiguous memory guarantee can not be
extended to sc_vector<T> automatically.

  It would be possible to add this guarantee to sc_vector, although this
would require the use of placement-new in user-defined Creator
functions, which further complicates this use case (for quite little
benefit).

  But since std::vector gives this guarantee while sc_vector does not, I
think it is important to include this restriction in the LRM.

> p423
> "Class sc_vector_assembly shall be copyable"
> I don't have the C++ standard to hand - but does copyable always also mean "assignable"?

  Copyable does not include Assignable. I guess, supporting both would
be Ok. Since sc_vector_assembly is not default-constructible, and more
or less meant for rather short-lived expressions, I don't see a pressing
need to support assignment explicitly, though.

  But at least Copyable is required, to make the binding adapters work.
I think, we need to add an explicit copy-constructor to the class
definition as well, as it is done for the other classes even if the
compiler-generated ones suffice (c.f. sc_event_and_list).

public:
 sc_vector_assembly( const sc_vector_assembly & );

 // optionally "private:" and disabled? or just public?
 sc_vector_assembly& operator=( const sc_vector_assembly );

  Also note, that the private constructor in sc_vector_assembly is not
disabled (as it says in the LRM now) but rather implementation-defined,
since sc_vector_assembly instances are meant to be created via the
sc_assemble_vector function only. It should probably be dropped from
the LRM.

Greetings from Oldenburg,
  Philipp

-- 
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 · http://offis.de/en/
Phone/Fax: +49-441-9722-420/282 · PGP: 0x9161A5C0 · Skype: phi.har
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
 
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.