Hi Damian --
This question ("shouldn't we support sizeof()?") came up internally last
month and at the time I wrote the following response (slightly edited
here):
---
We've traditionally been opposed to supporting a sizeof() equivalent
directly in Chapel because:
(a) people are used to sizeof() being param-ish (compile-time computed),
yet due to Chapel's current use of a back-end compiler architecture
(and more specifically, giving it the option to do things like record
layout), we can't reliably predict what the sizes of all types will
be.
(b) we anticipate that the number of instances where one needs a sizeof()
equivalent are small (e.g., Chapel has no malloc()s or memcpy()s) and
that providing it is more likely to lead users into danger than to
help them.
(c) it's easy enough to prototype C's sizeof() as an extern if you really
want it (and arguably maybe that's the right thing to do -- you're
dropping to a system level query anyway). We do this in our internal
modules at points, for example.
I think that's been the historical rationale, though one could clearly do
it if they wanted. With sufficient effort, one could even take questions
like record layout out of the back-end compiler's hands by building Chapel
records from scratch.
---
For the specific example you give:
> // find out what the size of a variable is
>
> if vr.bits == 64 then
> {
> writeln("64 bit quantity");
> }
> else
> {
> writeln("not 64-bits at all");
> }
Note that there is a numBits() function that returns the number of bits in
a basic scalar type as a param. This permits you to say something like:
numBits(vr.type)
or:
var i: int(numBits(vr.type));
See documentation for it at:
http://chapel.cray.com/docs/latest/modules/standard/Types.html#Types.numBits
In retrospect, I think this probably should've been a method rather than a
standalone function (though maybe it's not too late for that).
> I apologize if bits is meaningful in other contents. And it also begs the
> other question of whether one's brain, when in 'mode=Chapel', should think
> in terms of bits or bytes.
There's also a corresponding numBytes() function.
For Chapel's type definitions, we chose to focus on bits primarily because
it seemed more general (would support bool(1) or int(1) if we ever wanted
to go down that path, say... though I hope we don't). It also seemed to
me that seeing int(64) and int(32) as common cases would be more intuitive
("unlikely to be bytes") as compared to seeing int(8) ("could be either
bits or bytes").
> Now this time as I keep getting reminded, I did go fishing in
>
> README.*
>
> in
> doc/{release,}/technotes
>
> and could not find anything relevant. It might be there but I could not
> find it. If it is, then I need to go and start shopping for glasses. I
> also could not find this in the primary documentation.
I don't think it came up in the previous thread, but I wanted to note that
for the upcoming release cycle, we have a goal to convert all the
README-based documentation to web-based documentation to reduce the number
of distinct places to look for Chapel documentation and make more of it
web-oriented.
> Also, as an aside, what other attributes of types beside '.type' are
> predefined.
Hmm, that's a good memory test. I can't think of any offhand, but am sure
I'm overlooking something simple. Most of the capabilities that look like
this are simply methods defined on types.
> P.S. And while we are at it, on a philsophical point,
>
> Is something as fundamental to a variable as say the absolute value of a
> number 'x', floating or integral, or even say its sign, given by
>
> a) attribute of the number, i.e. given by
>
> x.abs
>
> b) method applied to that number, i.e. given by
>
> x.abs()
>
> c) some function call
>
> abs(x : T) : T
>
> Not looking for a religious war here. Just some feedback.
Are you asking, should other things be supported as methods on a variable
as opposed to standalone functions? Quite possibly (and note that one can
define such methods themselves as a library or as one-offs in code). For
the specific case of abs() I think we were simply following C's precedent,
but don't know that it received a lot more thought than that.
-Brad
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
