At Fortran Discourse https://fortran-lang.discourse.group/t/fortran-202x-features/388/3 the new paper by John Reid, "The new features of Fortran 202x", https://wg5-fortran.org/N2151-N2200/N2194.pdf was mentioned.hmmm...no bit strings :(
No more features have been added to the lists of obsolete and deleted features.
Some sections are
Language elements
Intrinsic procedures and intrinsic modules
Interoperability with C
Input-output
Coarrays
Procedures
Array features
Enumerations
hmmm...no bit strings :(bit strings are usually taken as implying a new type.
hmmm...no bit strings :(
Hi,
On Mar 23, 2022, Gary Scott wrote
(in article <t1ffb5$f4r$1...@dont-email.me>):
hmmm...no bit strings :(bit strings are usually taken as implying a new type.
New types are expensive for compilers, so to add a new type to the language you must find an important use case difficult to support without a new type.
Hi,
On Mar 23, 2022, Gary Scott wrote
(in article <t1ffb5$f4r$1@dont-email.me>):
hmmm...no bit strings :(bit strings are usually taken as implying a new type.
New types are expensive for compilers, so to add a new type to the language you must find an important use case difficult to support without a new type.
Just going through the document... a few thoughts.
# The limit of 255 continuation lines is removed and the limit on
# statement length is raised to a million characters.
# These relaxations are designed to support programs that are
# constructed mechanically. It not expected that they will be needed
# in programs written directly by people.
# These are hard limits. Processors are required to issue warnings
# if they are breached.
Love that one. A million also makes sure that this is clearly
recognizable as an artifical limit - had 1048575 been used,
somebody would have wondered about a 20-bit limitation somewhere.
Automatically allocating the length for get_command - great.
Saves me quite a few lines of code (inquiring about the length,
allocating the character, filling in the argument).
Splitting tokens - also quite useful. I'll probably get to
write it once, for libgfortran, instead of quite a few times
in my own programs.
selected_logical_kind: James will be pleased.
Plus there is some more - enums and coarray stuff.
Sounds like a few irksome things were fixed in that revision.
Looks good to me :-)
Dan Nagle <danl...@mac.com> schrieb:.
Hi,
On Mar 23, 2022, Gary Scott wrote
(in article <t1ffb5$f4r$1...@dont-email.me>):
hmmm...no bit strings :(bit strings are usually taken as implying a new type.
New types are expensive for compilers, so to add a new type to the language you must find an important use case difficult to support without a new type.
Bit strings can be implemented without too much trouble using the
existing intrinsic functions plus boz constants.
What I find difficult to get around sometimes is the lack of
an unsigned integer type, for exact interaction with C and for
reading or writing file formats which have unsigned lengths.
I usually resort to using C, then (the horror!)
On 3/23/2022 11:45 AM, Gary Scott wrote:
hmmm...no bit strings :(
See https://stevelionel.com/drfortran/2020/08/11/doctor-fortran-in-were-all-bozos-on-this-bus/
for some words on that.
selected_logical_kind: James will be pleased.
"Thomas Koenig" wrote in message news:t1fp0j$k3p$1@newsreader4.netcologne.de...
selected_logical_kind: James will be pleased.
James who?
Since there are different internal representations of .TRUE.: x
/= 0,
BTEST(x,0), TEST >= 0, and the gfortran representation, there may be different
kinds with the same size.
So
char([integer::Z'48',Z'65',Z'6C',Z'6C',Z'6F',Z'2C',Z'20',Z'77',Z'6F',Z'72',Z'6C',Z'64'])
but not
[character::Z'48',Z'65',Z'6C',Z'6C',Z'6F',Z'2C',Z'20',Z'77',Z'6F',Z'72',Z'6C',Z'64']
?
And still no
char(Z'21') !?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 231 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 107:23:03 |
| Calls: | 4,952 |
| Calls today: | 1 |
| Files: | 11,523 |
| Messages: | 3,984,824 |