List of non-standard intrinsic functions and their standard alternatives

[cmaapic]

The C++ 17 standard introduced parallel functionality into the STL.
You will need a companion C++ compiler that is therefore C++17 compliant.
You will also need a companion C++ compiler that supports STL parallelism.

The Intel compiler provides parallel support via TBB and is automatically available.

The g++ compiler by default has no parallel STL support. It can be made available by
installing the Intel oneapi based toolkit and linking against TBB.

The Nag compiler has by default no parallel STL support.
It can be made available by installing the Intel oneapi base toolkit
and linking against TBB.

We’ve written an example that shows how to do this.

The parallel sorting times are about 10% of the serial sorting times.

Ian Chivers

[wspector]

@cmaapic

The C++ 17 standard introduced parallel functionality into the STL.
You will need a companion C++ compiler that is therefore C++17 compliant.
You will also need a companion C++ compiler that supports STL parallelism.

The Intel compiler provides parallel support via TBB and is automatically available.

The g++ compiler by default has no parallel STL support. It can be made available by
installing the Intel oneapi based toolkit and linking against TBB.

The Nag compiler has by default no parallel STL support.
It can be made available by installing the Intel oneapi base toolkit
and linking against TBB.

We’ve written an example that shows how to do this.

The parallel sorting times are about 10% of the serial sorting times.

There are a lot of parallel features defined in C++ 17, additional sorting algorithms being some of it. The exclusive and inclusive scan idioms are in there as well. Sort, grade, and the scan functions were all defined in HPF 30 years ago. (And APL 50+ years ago.) Yet they are still not in the Fortran standard…

Like PXF, several vendors did implement HPF. Then quietly removed anything that wasn’t required for Fortran 95. I can see removing the HPF directives - as OpenMP directives became much more popular. However IMHO the library functions should have remained. (At least for sorting and scans. Granted the ‘scatter’ functions may have been a bridge too far.)

[sblionel]

@certik

I agree that the string utilities would get more use than sind. The best answer I can come up with is that upper can be implemented in an external library (like stdlib above), while sind might require a very specific internal compiler implementation and optimizations. @sblionel might remember more

sind, etc., were added because nearly all compilers already provided them, so this was mainly documentation change. The major trig functions also tend to be implemented using private, high-performance interfaces.

[msz59]

With the advent of additional CHARACTER kinds, all three have become non-trivial.
And even with the default CHARACTER type, it seems to transparently support UTF-8 strings, so here it would also be non-trivial to properly implement any case-involving operations. In C, one has to use locale stuff to do it right for non-ASCII text.

Surely one could say SORT, UPPER, LOWER work for ASCII text only but I guess that at the Standard level, that would not be cool, as if it stated that one can compute square root of default REAL type values only.

[RonShepard]

@msz59

With the advent of additional CHARACTER kinds, all three have become non-trivial.

I would add the len(), len_trim(), scan(), and index() intrinsics to that list too. When it comes to variable-byte-length character kinds, the len() intrinsic no longer just counts bytes, it must scan the contents and count actual characters, right? Also, operations that involve substrings or replacing, deleting, or inserting characters within a string must work correctly when the characters have variable numbers of bytes.

[urbanjost]

It would seem that adding an intrinsic type of arrays of strings of varying size would then let you define support of UTF8 character arrays where each element represents a single letter, but each “letter” can be multi-byte. That fits more the C model where each element of the array represented an ASCII character more than the potentially multi-character STRING type but Fortran has always allowed one to work with either model – arrays of single characters (even integer arrays more like old C whch at least at one time were usually far faster than CHARACTER types to manipulate) or arrays of multibyte characters (but all of the same length)

. Allowing only one character per string, but the string being able to be multi-byte supports UTF8 almost trivially; and allowing arrays of values of different length has been desired for a long time, even after a user-defined type lets you do that relatively easily yourself.

module M_utf8
type :: utf8_chars
   sequence
   character(len=:),private,allocatable :: raw
end type utf8_chars
end module M_utf8

program testit
use M_utf8, only : utf8_chars
end program testit

you can get close to that now yourself, but I cannot think of a way to enforce putting only one character in an element accept perhaps by making an “alphabet” of the characters you want to support and defining them all as parameter constants. It could be cumbersome with languages with thousands of characters, but if you had to define an “alphabet” it could have multiple elements to switch between when “uppercase” or “lowercase” was requested, and the order of the alphabet could define a custom collating sequence as well.

If not done where each element represents a glyph/letter making procedures that operate on the strings seems to get problematic very quickly, as mentioned above.