Re: fortran 2003 compiler
- From: gary.l.scott@xxxxxxxx
- Date: 26 Feb 2007 12:17:45 -0800
On Feb 26, 10:24 am, Dan Nagle <danna...@xxxxxxxxxxx> wrote:
Hello,
gary.l.sc...@xxxxxxxx wrote:
<snip>
This is the exact opposite of what I would want a bits datatype to
implement. I would want to to be a specifiable string of bits of any
length, not restricted to what's "most efficient". I've no problem
with special casing where the specified length is compatible with the
underlying hardware.
It's not only a question of efficiently, it's also a question
of the relationship among the bit size, the storage size and
the kind values of the entities involved.
Besides, the applications programmer already has the capability
to specify any bit string, due, in part, to the new LHS functions.
I've been programming bit string/arrays for processing bitmap images
for several decades in the form of integer arrays, I'm just hoping
that you smart standards people come up with something truly better,
even innovative. I'd rather not see something that offers very little
in terms of functional capability or "expressiveness" over integer
arrays and the existing bit intrinsics.
You're merely making the point that the standard is way too far ahead
of practice to know what's needed.
<snip>
--
Cheers!
Dan Nagle
Purple Sage Computing Solutions, Inc.
.
- References:
- fortran 2003 compiler
- From: Alinabi
- Re: fortran 2003 compiler
- From: Richard Maine
- Re: fortran 2003 compiler
- From: Dan Nagle
- Re: fortran 2003 compiler
- From: gary . l . scott
- Re: fortran 2003 compiler
- From: Dan Nagle
- fortran 2003 compiler
- Prev by Date: Re: Optional arguments in nested subroutines
- Next by Date: integer*8 speed vs integer*4 speed
- Previous by thread: Re: fortran 2003 compiler
- Next by thread: converting a R code to fortran
- Index(es):
Relevant Pages
|
