Re: [sv-bc] size() array methods for packed, unpacked and associative arrays

From: Brad Pierce <Brad.Pierce_at_.....>
Date: Wed May 31 2006 - 12:27:37 PDT
I agree that if there's a size method, then it should be exactly like
$size, with its two arguments.  The second argument of any
array_dimension_function like $size() has a default value of 1, which is
why it's often omitted in calls.

The size() method for dynamic arrays currently only has the one implicit
array argument and no second argument for the dimension number.  Looks
like an erratum.

My personal bias is for methods, which are reminiscent of VHDL
attributes, for example, A'LENGTH(2).

-- Brad

-----Original Message-----
From: Greg Jaxon 
Sent: Wednesday, May 31, 2006 11:32 AM
To: Rich, Dave
Cc: Brad Pierce; sv-bc@eda.org; sv-ec@eda.org
Subject: Re: [sv-bc] size() array methods for packed, unpacked and
associative arrays

Rich, Dave wrote:
> Then you get into issues like a packed struct also creates a packed 
> array of the same name and then 'size' becomes a keyword.

Replying to Brad Pierce, who wrote:
>> We could define A.size() in terms of $size(A) and be done with it for

>> all array kinds.
>> 

Since arrays can be multi-dimensional, you'd want a different prototype.
"Size of the first dimension" is not the result I'd intuitively
expect.  Having a method notation for measuring objects of varying size
seems pretty natural to me, but it appears to be completely redundant
with the $size() system function.  I'd rather eliminate the method
calls!

Greg Jaxon

Disclaimer:  Personal biases again...
Received on Wed May 31 12:27:37 2006

This archive was generated by hypermail 2.1.8 : Wed May 31 2006 - 12:27:46 PDT