ordering function in Fortran

[Paul Wenk]

Hello everyone!
Is there a Fortran library which has an implementation of an ordering function, i.e., a function ordering(list) (like Ordering[] in Mathematica) which gives the positions in list at which each successive element of the sorted list appears?

I can implement it but I don't want to reinvent the wheel (and my wheel could be far from perfect...). Since it is so basic I was searching for a lib containing such list operations but failed to find one.

Do you have any suggestions?

Cheers,
Paul

[Thomas Koenig]

Paul Wenk <paul...@gmail.com> schrieb:

> Is there a Fortran library which has an implementation of an
> ordering function, i.e., a function ordering(list) (like Ordering[]
> in Mathematica) which gives the positions in list at which each
> successive element of the sorted list appears?

If you wanted to, you can use the C standard library function qsort
via C interoperability.

Here is an example (I'm sure that any shortcomings will shortly
be pointed out by other people on this newsgroup :-)

module sort
use iso_c_binding
implicit none
private
public:: qsort_float

interface
subroutine myqsort(array,elem_count,elem_size,compare) bind(C,name="qsort")
import
type(c_ptr),value :: array
integer(c_size_t),value :: elem_count
integer(c_size_t),value :: elem_size
type(c_funptr),value :: compare
end subroutine myqsort ! Deklaration von qsort
end interface

contains

subroutine qsort_float(a,n)
real(c_float), dimension(n), intent(inout), target :: a
integer(c_size_t), intent(in) :: n
call myqsort (c_loc(a(1)), n, c_sizeof (a(1)), c_funloc(compare_float))
end subroutine qsort_float

integer(c_int) function compare_float (a,b) bind(C)
real(c_float), intent(in) :: a, b

if (a > b) then
compare_float = 1
else if (a == b) then
compare_float = 0
else
compare_float = -1
end if
end function compare_float

end module sort

program main
use iso_c_binding
use sort
implicit none
real, dimension(10) :: a
call random_number(a)
call qsort_float(a, size(a,kind=c_size_t))
print *,a
end program main

[FortranFan]

On Monday, February 25, 2019 at 5:09:08 PM UTC-5, Paul Wenk wrote:

> ..
> Is there a Fortran library which has an implementation of an ordering function ..

First hit in a web search:
https://github.com/cphyc/Fortran-parallel-sort

GitHub and SourceForge are the places you may want to start looking.

[David Duffy]

Paul Wenk <paul...@gmail.com> wrote:
> Hello everyone!
> Is there a Fortran library which has an implementation of an
> ordering function, i.e., a function ordering(list) (like Ordering[] in
> Mathematica) which gives the positions in list at which each successive
> element of the sorted list appears?
>

Like SLATEC i/d/hpsort() you mean? Do you have to allow for missing
data values, duplicate values; want polymorphism?

[Paul Wenk]

Thank you Thomas!
I was rather searching for for a function which sorts the values and returns the order, e.g., given a list {-2,40,1} it would return {1,3,2}.

But one very general remark: Before I started my search of such a Fortran function I expected to find a list of "list manipulation functions" which a fundamental, every-day-in-use functions which I don't want to re-invent since there was for sure someone with the same mini-problem -- Fortran is not such a young language.

Cheers,
Paul

[Paul Wenk]

> Like SLATEC i/d/hpsort() you mean?

oh yes, thank you for the suggestion!

Since the "modern" version of SLATEC is GSL, one has to bind this C-code to Fortran to be able to use it, like in the code from Thomas Koenig, right?

[ga...@u.washington.edu]

On Monday, February 25, 2019 at 4:27:50 PM UTC-8, Paul Wenk wrote:
> Thank you Thomas!
> I was rather searching for for a function which sorts the values
> and returns the order, e.g., given a list {-2,40,1}
> it would return {1,3,2}.

I often do sort arrays directly with qsort(), but many people
like to sort an array of pointers, instead. You could even sort
an array of (structures of) pointers and index values, or,
for that matter, and array of float and index values.
Or an array of index values, and indirect compare the values.

Some C programmers might sort an array of pointers, and then
construct the offset values through pointer subtraction.

But I don't think you can do C pointer subtraction in Fortran.

[ga...@u.washington.edu]

On Monday, February 25, 2019 at 4:27:50 PM UTC-8, Paul Wenk wrote:

(snip)

> But one very general remark: Before I started my search of
> such a Fortran function I expected to find a list of
> "list manipulation functions" which a fundamental,
> every-day-in-use functions which I don't want to re-invent
> since there was for sure someone with the same mini-problem --
> Fortran is not such a young language.

Fortran isn't a young language, but it is for list manipulation.

Many list problems were, in the past, faked using arrays, and
more recently with arrays of structures.

[Arjen Markus]

You might also have a look at ORDERPACK - http://www.fortran-2000.com/rank/

Regards,

Arjen

[David Duffy]

Paul Wenk <paul...@gmail.com> wrote:
>> Like SLATEC i/d/hpsort() you mean?
>

> Since the "modern" version of SLATEC is GSL, one has to bind this
> C-code to Fortran to be able to use it, like in the code from Thomas
> Koenig, right?
>

No. You can call it transparently through the magic of Fortran's
backward compatibility. There is also a Fortran90 translation,
which is linked from
http://fortranwiki.org/fortran/show/Libraries

You earlier commented:

> I expected to find a list of "list manipulation functions"

As well as the other suggestions uplist, I would also highlight
the very beautiful
https://wavebitscientific.github.io/functional-fortran/
of Milan Curcic. Unfortunately for you, it lacks an
order() or rank(), but does have fold, map, filter, reverse etc.

Cheers, David Duffy.

[edmondo.g...@gmail.com]

I have used this one that returns and index that sorts the array.

http://www.fortran.com/fortran/quick_sort2.f

[edmondo.g...@gmail.com]

I just changed the length of the array lstk rstk to allow bigger arrays.
If I remember it should go as the base 2 logaritm of the length of the array.
I put it to 128 to be on the safeside.

[FortranFan]

On Monday, February 25, 2019 at 7:27:50 PM UTC-5, Paul Wenk wrote:

> ..

> I was rather searching for for a function which sorts the values and returns the order, e.g., given a list {-2,40,1} it would return {1,3,2}.

> ..

Fortran has gaps when it comes to writing truly generic functions (or subprograms) that can compactly be expressed for wide variety of data types and kinds (or for any). OP isn't clear/specific on the type and size of data to be handled, but for an integer array where stack size limitations ain't an issue, something like the following can be a quick approach to follow:

module m
implicit none
contains
function get_order( x ) result( order )
! Argument list
integer, intent(in) :: x(:)
! Function result
integer :: order(size(x))
! Local variables
logical :: mask(size(x))
integer :: i
mask = .true.
do i = 1, size(x)
order(i) = findloc( x, value=minval(x,dim=1,mask=mask), dim=1 )
mask(order(i)) = .false.
end do
return
end function
end module
use m, only : get_order
integer, allocatable :: x(:)
x = [ -2, 40, 1 ]
print *, "order of values in x: ", get_order(x)
end

Upon execution with gfortran, the output is only as expected:
order of values in x: 1 3 2

[Paul Wenk]

Thanks a lot for this solution!
But shouldn't this be part of a lib where the different types are covered using an interface? One could always say: Well, you can write it yourself. But sometimes there are this little tweaks and tricks which were found over the years of language use which you are not aware of.

Cheers,
Paul

[Paul Wenk]

Excellent, thank you for the links!

[Paul Wenk]

Very useful indeed, thanks!

[Wolfgang Kilian]

You are asking for a library analogous to the STL in C++. Such a
facility has been on the wishlist of many Modern-Fortran users for a
long time, and finally it appears as if the next revision of the
standard (Fortran 202X) may enable the creation of such libraries.

At present, this is not possible. The difficult part is the 'different
types are covered' bit. It is straightforward to implement algorithms
for the finite set of intrinsic types (others have pointed to examples).
A satisfactory solution that supports any (derived) type, without
major inconveniences for the user, is not possible within the scope of
present Fortran.

-- Wolfgang

--
E-mail: firstnameini...@domain.de
Domain: yahoo

[Ron Shepard]

On 2/27/19 1:33 AM, Wolfgang Kilian wrote:
> At present, this is not possible.  The difficult part is the 'different
> types are covered' bit.  It is straightforward to implement algorithms
> for the finite set of intrinsic types (others have pointed to examples).
>  A satisfactory solution that supports any (derived) type, without
> major inconveniences for the user, is not possible within the scope of
> present Fortran.

There is a straightforward way to achieve this goal in current fortran
(or f90, or f77 for that matter) for the requested task and for similar
sorting and ordering tasks.

The general approach is that the sort/ordering program always works with
the integer indexing array. One argument to the sort routine is a dummy
function, written by the programmer, that returns the result of
comparisons between two array elements given their integer indices. The
sort routine never needs to see or declare the user defined type that is
being compared, so there is no problem with allowing it to work on any
intrinsic or user defined type. Also, elements of those derived types
are never copied or swapped, it is only the elements of the integer
index array that are swapped. This is a nice feature of this approach
for complicated derived types that have, for example, big memory
footprints or allocatable members of arbitrary size. This approach also
works well when arbitrary subsets of the underlying data are sorted.

I remember a similar discussion to this a few years ago here in CLF, and
I think I posted an example of a heap sort that worked this way. If what
I'm explaining isn't obvious, I can try to dig out that routine and
repost it. I personally like heap sort over the other alternatives for
these kinds of sorting tasks. It sorts in-place with no extra memory
requirements, it is O(N*log(N)) scaling, and that is also its worst-case
behavior. Also, heap sort is easy to understand and implement in
fortran, it can be done with loops rather than recursion, and so on.

A previous post referred to a library that was mostly based on merge
sorts. Merge sorts are also easy to understand and implement in fortran,
but they are not in-place, they require intermediate work arrays. Qsort
was also mentioned. Its downside is that its worst case behavior is N^2
rather than N*log(N). And someone also posted a brute force N^2
selection sort, which is easy to implement, but has no place in an
efficient library of sort and order routines. There are special
situations in which all of those algorithms are appropriate, of course,
but heap sort is a nice general purpose approach particularly when used
with an index vector to order arbitrary elements of arbitrary types.

$.02 -Ron Shepard

[ga...@u.washington.edu]

On Wednesday, February 27, 2019 at 8:45:24 AM UTC-8, Ron Shepard wrote:

(snip)

> A previous post referred to a library that was mostly based on merge
> sorts. Merge sorts are also easy to understand and implement in fortran,
> but they are not in-place, they require intermediate work arrays. Qsort
> was also mentioned. Its downside is that its worst case behavior is N^2
> rather than N*log(N). And someone also posted a brute force N^2
> selection sort, which is easy to implement, but has no place in an
> efficient library of sort and order routines. There are special
> situations in which all of those algorithms are appropriate, of course,
> but heap sort is a nice general purpose approach particularly when used
> with an index vector to order arbitrary elements of arbitrary types.

Some object-oriented languages have libraries of general routines
that can work with appropriate data structures. Java has an inteface
(Java term) called List, which is implemented (again, Java term) by
list-like classes, such as LinkedList and ArrayList.

This allows one to use the appropriate methods, without needing
to know the underlying class details. List has a sort() method,
which well either sort based on the comparator of the class of
the list elements, or a supplied comparator.

As for specific details, it seems that List.sort() copies the data
to an array, sorts the array, and then copies it back. That is much
more efficient than sorting a list in place.

As noted previously, C has a qsort routine (which may or may not
implement quicksort) to sort an array of arbitrary sized elements,
including structs. C has the ability to copy a struct knowing
only its size, and not its contents.

On the other hand, there is no data structure in Java similar
to an array of struct. Non-primitive data in Java is always
handled indirectly through a reference. Instead of an array of
structures, Java will have an array of references to arbitrary
objects. I don't know that one can find list positions,
after sorting a list, other than putting index numbers in to the
list elements before sorting.

As well as I know it, the OO features of Fortran can implement
something like a Java List. I don't know that there is anything
like the Java interface, to generalize some things, but one should
be able to implement a LinkedList in Fortran, with a sort method.

It is still an inconvenience of Fortran not to have arrays
of pointers.

[Ron Shepard]

On 2/27/19 8:36 PM, ga...@u.washington.edu wrote:
> It is still an inconvenience of Fortran not to have arrays
> of pointers.

One can have an array of a derived type in fortran whose only member is
a pointer. Is there anything that could be done with an array of
pointers that cannot be done with the derived type array? Is there any
loss of efficiency with the fortran approach? Is there any loss of clarity?

Sorting the members of a linked list efficiently requires something like
the indexed sort mentioned by the original poster. Swapping elements of
a linked list is problematic, as is referencing some arbitrary element
somewhere in the middle, so performing the sort through the integer
index array solves both of those problems.

$.02 -Ron Shepard

[ga...@u.washington.edu]

On Wednesday, February 27, 2019 at 10:34:56 PM UTC-8, Ron Shepard wrote:

(I wrote)

> > It is still an inconvenience of Fortran not to have arrays
> > of pointers.

> One can have an array of a derived type in fortran whose only member is
> a pointer. Is there anything that could be done with an array of
> pointers that cannot be done with the derived type array? Is there any
> loss of efficiency with the fortran approach? Is there any loss of clarity?

Slightly less convenient, slightly more ugly, but probably no difference
in efficiency.

PL/I, I believe inherited from COBOL, has partial qualification
where you can reference a structure member leaving out some qualifiers
if the result uniquely identifies one member.

I believe one reason for this in COBOL is that COBOL doesn't
directly allow multidimensional arrays, but instead array of
structure of array of ..., so partial qualification allows for
something that looks like a multidimensional array.

Partial qualification would remove the ugliness and increase
the convenience.

> Sorting the members of a linked list efficiently requires something like
> the indexed sort mentioned by the original poster. Swapping elements of
> a linked list is problematic, as is referencing some arbitrary element
> somewhere in the middle, so performing the sort through the integer
> index array solves both of those problems.

Or an array of pointers (or references).

Java will pass the reference for two elements to the comparator
method (almost wrote function), which then, as with qsort, returns
a negative, zero, or positive value.

I think what Java does is to allocate an array of Object, the
superclass of all classes, copy all the references, sort the array,
then copy them back, or recreate the list. Since all references
to a List should be through the appropriate methods, the actual
internal structure is hidden from the user.

I haven't tried OO Fortran enough to know how easy it is to do.

[Alberto Ramos]

In the numeric library

https://github.com/ramos/afnl

you have a qsort routine for the basic data types (int,real,double
precision). This routine sorts in place the array and optionally
returns an index with the positions.

It would be easy for you to copy the array before the call, and just
get the index.

Example code follows:

program foo

use nonnumeric

implicit none

real :: data(10)

call random_number(data)
write(*,*)data

call qsort(data)
write(*,*)data

write(*,*)
call random_number(data)
write(*,*)data

call qsort(data,ipt)
write(*,*)data
write(*,*)ipt

stop
end program foo

[spectrum]

Although this may be already mentioned in the above replies, *lasrt() routine
may also be a possible candidate, if the list of interest is of primitive type?
(But I've never used these routines so far, so not sure about the performance...)

Lapack
http://www.netlib.org/lapack/explore-html/d2/d24/group__aux_o_t_h_e_rcomputational_ga88a9fb57b6459176b68f21720d3d2ad2.html

MKL
https://software.intel.com/en-us/mkl-developer-reference-fortran-lasrt2

[Dominik Gronkiewicz]

W dniu wtorek, 26 lutego 2019 22:15:38 UTC+1 użytkownik Paul Wenk napisał:
> Thanks a lot for this solution!
> But shouldn't this be part of a lib where the different types are covered using an interface? One could always say: Well, you can write it yourself. But sometimes there are this little tweaks and tricks which were found over the years of language use which you are not aware of.

This is one of many things that are wrong with Fortran. Almost no libraries (besides outdated 40 years old codes), you have to write everything yourself or use C interfaces. And this is unlikely to change since distribution of Fortran libraries is a nightmare, there are no generics in the language so everyone just moves to C++.

[Ron Shepard]

On 3/9/19 9:55 AM, Dominik Gronkiewicz wrote:
> This is one of many things that are wrong with Fortran. Almost no libraries (besides outdated 40 years old codes), you have to write everything yourself or use C interfaces.

What kind of libraries? Numerical libraries? Many of those used in other
languages are based on those written in fortran 40 years ago: LAPACK, etc.

> And this is unlikely to change since distribution of Fortran libraries is a nightmare,

How is this different from any other language, C, C++, etc.? You take
the source, compile it, and link it with your application, same as any
other language.

> there are no generics in the language so everyone just moves to C++.

There were generics in fortran before they were in C, C++, etc. It is
true that in the 80s there was a long delay in getting that
functionality from intrinsics up to the user-written code, but it did
make it. However, as I pointed out in this thread a few weeks ago, there
is no need for generics in the language to implement the requested task,
it could be implemented in f77 for any intrinsic type, and it can easily
be implemented in f90 and later for any user defined type.

$.02 -Ron Shepard

[Ian Harvey]

The intrinsic or user-written generics being discussed in the last
paragraph are different from the meaning of "generics" (generic
programming, really) as discussed in the earlier paragraph.

The integer indexing array approach discussed in the other post places
requirements on the client source code that are above a generic
programming approach.

[robin....@gmail.com]

On Sunday, March 10, 2019 at 2:55:52 AM UTC+11, Dominik Gronkiewicz wrote:
> W dniu wtorek, 26 lutego 2019 22:15:38 UTC+1 użytkownik Paul Wenk napisał:
> > Thanks a lot for this solution!
> > But shouldn't this be part of a lib where the different types are covered using an interface? One could always say: Well, you can write it yourself. But sometimes there are this little tweaks and tricks which were found over the years of language use which you are not aware of.
>
> This is one of many things that are wrong with Fortran. Almost no libraries (besides outdated 40 years old codes),

Try Numerical Recipes.

> you have to write everything yourself or use C interfaces.
> And this is unlikely to change since distribution of Fortran
> libraries is a nightmare, there are no generics in the language
> so everyone just moves to C++.

Generic functions were introduced in FORTRAN 77, while generic procedures
were introduced in Fortran 90.

[spectrum]

On Sunday, March 10, 2019 at 6:52:04 PM UTC+9, robin....@gmail.com wrote:
> Generic functions were introduced in FORTRAN 77, while generic procedures
> were introduced in Fortran 90.

Dear Robin,
As Ian suggested above, I believe the meaning of "generic" is somewhat (or rather
greatly) different here - it is more like this one. The key point is that a library routine
can be used for types that are developed *after* the routine was written.

https://en.wikipedia.org/wiki/Generic_programming

# I haven't read the above Wiki in detail, but it is interesting to see that
Ada has it even from 1970's (??) and has made generic container libraries in 2005.

[spectrum]

On Sunday, March 10, 2019 at 12:55:52 AM UTC+9, Dominik Gronkiewicz wrote:

> This is one of many things that are wrong with Fortran. Almost no libraries (besides outdated 40 years old codes), you have to write everything yourself or use C interfaces. And this is unlikely to change since distribution of Fortran libraries is a nightmare, there are no generics in the language so everyone just moves to C++.

Though the lack of various things (including generics) is certainly a factor, I also think
that another critical factor is the lack of popular "ecosystem(s)" or repositories
for efficient reuse of libraries and communication about the usage etc. So, new users
need to search for available tools by themselves, learn the installation method (sometimes
very time-consuming), validate them (this is crucial!), and finally use them.
(Sometime before, I need to find some special function codes, but it took really a lot of
time to find a good one. Some initial libraries I tried were almost useless...)

[Ron Shepard]

On 3/10/19 4:00 PM, spectrum wrote:
> On Sunday, March 10, 2019 at 12:55:52 AM UTC+9, Dominik Gronkiewicz wrote:
>
>> This is one of many things that are wrong with Fortran. Almost no libraries (besides outdated 40 years old codes), you have to write everything yourself or use C interfaces. And this is unlikely to change since distribution of Fortran libraries is a nightmare, there are no generics in the language so everyone just moves to C++.
>
> Though the lack of various things (including generics) is certainly a factor, I also think
> that another critical factor is the lack of popular "ecosystem(s)" or repositories
> for efficient reuse of libraries and communication about the usage etc.

Yes, such as netlib, which is about 30 years old. Netlib distributes
AMPL, BLAS, EISPACK, LAPACK, LINPACK, MINPACK, QUADPACK, and SLATEC.

In my field of quantum chemistry, we have done this even longer with
such things as QCPE at Indiana University, which dates back to 1963, and
the NRCC which was active in the early 1980s. Other scientific areas
such as astronomy and high energy physics also have had code
repositories. Of course, that all started before the internet, so things
can be done differently now.

I am one of the COLUMBUS developers, and we began distributing our codes
with anonymous FTP in the 1980s. I think we were the first quantum
chemistry code to do this. Now, there are several open source
programming projects, NWChem, DALTON, MOLCAS, and many others.

> So, new users
> need to search for available tools by themselves,

Yes, but the same is true for any language.

> learn the installation method (sometimes
> very time-consuming),

Same for any language.

> validate them (this is crucial!),

Yes, the same for any language.

> and finally use them.
> (Sometime before, I need to find some special function codes, but it took really a lot of
> time to find a good one. Some initial libraries I tried were almost useless...)

This will always be a problem for any kind of library in any language,
and especially for open-source projects where anyone can contribute or
modify the source code.

$.02 -Ron Shepard

[ga...@u.washington.edu]

On Sunday, March 10, 2019 at 2:00:33 PM UTC-7, spectrum wrote:
> On Sunday, March 10, 2019 at 12:55:52 AM UTC+9, Dominik Gronkiewicz wrote:
>
> > This is one of many things that are wrong with Fortran.
> > Almost no libraries (besides outdated 40 years old codes),
> > you have to write everything yourself or use C interfaces.

(snip)

> Though the lack of various things (including generics) is certainly
> a factor, I also think that another critical factor is the lack
> of popular "ecosystem(s)" or repositories for efficient reuse of
> libraries and communication about the usage etc. So, new users
> need to search for available tools by themselves, learn the
>installation method (sometimes very time-consuming), validate
> them (this is crucial!), and finally use them.

Languages like Java have a large library of classes for common type
of problems solved with Java. Generics like lists, trees, and hash
tables are some, and also the ability to sort many classes.

Not so much in the numerical libraries that Fortran users
would want, though.

> (Sometime before, I need to find some special function codes,
> but it took really a lot of time to find a good one. Some initial
> libraries I tried were almost useless...)

I bought this book some years ago, though I don't remember
now how I knew about it.

https://www.amazon.com/Computation-Special-Functions-Shanjie-Zhang/dp/0471119636

It does seem that some of the older libraries could be updated,
maybe just with wrappers that use newer features.

[FortranFan]

On Monday, March 11, 2019 at 2:44:16 AM UTC-4, Ron Shepard wrote:

> ..

> > So, new users
> > need to search for available tools by themselves,
>
> Yes, but the same is true for any language.
>
> > learn the installation method (sometimes
> > very time-consuming),
>
> Same for any language.
>
> > validate them (this is crucial!),
>
> Yes, the same for any language.
>
> > and finally use them.
> > (Sometime before, I need to find some special function codes, but it took really a lot of
> > time to find a good one. Some initial libraries I tried were almost useless...)
>
> This will always be a problem for any kind of library in any language,

> ..


OP never quite explained with any clarity (in my opinion) what's of interest and presently appears to have disappeared from this thread. And that other reader who mentioned "everyone just moves to C++" doesn't quite explain that or the surrounding comments either; things are not that straightforward with C++, there's a very high price that language extracts from its practitioners.

Now of course a trend long seen in technical and scientific computing is for those with *quick* or (from a CPU usage perspective) *less demanding* tasks to utilize specialized environments for their needs such as commercial or open spreadsheet/math/interactive/interpreted computing/programming environments where access to and consumption of many utilities and libraries is relatively straightforward and which is also getting more and more easier and widespread by the day. If this is what OP had in mind, then OP should clarify but then should also explain why Fortran is being considered.

The question in the original post appears to be seek a Python-like scenario in Fortran i.e., with Python, one would quickly get the NumPy package (a breeze for most users these days on their rather high-powered devices) and simply do:

import numpy as np
x = np.array([-2, 40, 1])
y = np.argsort(x)

But things ain't so 'easy' with Fortran or C++ or any other language that imposes type-safety and whose employment ordinarily requires compilation and linking with tool-chain dependent builds and where particular attention to algorithm(s) and with optimization relative to hardware and software is imperative for computational efficiency and performance.

Sure Fortran in general can do better and things are improving; what might concern some is the pace of advancement.

Regardless, in posts such as this one, it helps when an original poster makes clear what is of interest so readers can point OP in some useful directions: perhaps toward Python or some other interactive/interpreted environment, or C++ and its STL, or a specific Fortran library or how to home-brew one, or even to the standard committee for Fortran for better facilities in the language.

[Ev. Drikos]

On 09/03/2019 5:55 PM, Dominik Gronkiewicz wrote:
> ...
> ..., there are no generics in the language so everyone just moves to C++.
>

IMHO, the argument makes sense, generics is a must.

On the other hand, templates might have surprises also. About 15 years
ago ie I wrote a small C++ project and unluckily I wrote just 3 function
templates that I had to adjust twice (nearly every 7 years).

If I've to change it once more in the near future any benefit is lost.