# List of non-standard intrinsic functions and their standard alternatives **URL:** \ **Category:** Uncategorized\ **Created:** [January 19, 2025, 6:36pm UTC](https://fortran-lang.discourse.group/t/list-of-non-standard-intrinsic-functions-and-their-standard-alternatives/9107 "2025-01-19T18:36:30Z")\ **Posts on this page:** 6\ **Page:** 2
**Author:** ![cmaapic](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/cmaapic/32/659_2.png) [@cmaapic](https://fortran-lang.discourse.group/u/cmaapic)\ **Post date:** [January 29, 2025, 12:26pm UTC](https://fortran-lang.discourse.group/t/list-of-non-standard-intrinsic-functions-and-their-standard-alternatives/9107/21 "2025-01-29T12:26:28Z")
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 ---
**Author:** ![wspector](https://avatars.discourse-cdn.com/v4/letter/w/47e85d/32.png) [@wspector](https://fortran-lang.discourse.group/u/wspector)\ **Post date:** [January 29, 2025, 5:16pm UTC](https://fortran-lang.discourse.group/t/list-of-non-standard-intrinsic-functions-and-their-standard-alternatives/9107/22 "2025-01-29T17:16:52Z")
> [@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.) ---
**Author:** ![sblionel](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/sblionel/32/853_2.png) [@sblionel](https://fortran-lang.discourse.group/u/sblionel)\ **Post date:** [January 29, 2025, 5:35pm UTC](https://fortran-lang.discourse.group/t/list-of-non-standard-intrinsic-functions-and-their-standard-alternatives/9107/23 "2025-01-29T17:35:53Z")
> [@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. ---
**Author:** ![msz59](https://avatars.discourse-cdn.com/v4/letter/m/3d9bf3/32.png) [@msz59](https://fortran-lang.discourse.group/u/msz59)\ **Post date:** [January 31, 2025, 4:54pm UTC](https://fortran-lang.discourse.group/t/list-of-non-standard-intrinsic-functions-and-their-standard-alternatives/9107/24 "2025-01-31T16:54:18Z")
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. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [January 31, 2025, 5:13pm UTC](https://fortran-lang.discourse.group/t/list-of-non-standard-intrinsic-functions-and-their-standard-alternatives/9107/25 "2025-01-31T17:13:57Z")
> [@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. ---
**Author:** ![urbanjost](https://avatars.discourse-cdn.com/v4/letter/u/0ea827/32.png) [@urbanjost](https://fortran-lang.discourse.group/u/urbanjost)\ **Post date:** [January 31, 2025, 10:48pm UTC](https://fortran-lang.discourse.group/t/list-of-non-standard-intrinsic-functions-and-their-standard-alternatives/9107/26 "2025-01-31T22:48:19Z")
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. ```fortran 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. [Previous page](https://fortran-lang.discourse.group/t/list-of-non-standard-intrinsic-functions-and-their-standard-alternatives/9107.md?page=1)