Re: Any F2003 help translating C++ map syntax?

From: Rich Townsend (rhdt_at_barVOIDtol.udel.edu)
Date: 02/11/05 

Date: Thu, 10 Feb 2005 23:09:41 -0500

Ryo wrote:
> Rich Townsend wrote:
>
>
>>After all, C++ includes a huge amount of functionality in
>>the STL (in the present case, hashtables); this is technically
>>part of the standard language, but makes a mockery of comparing
>>the efficiency of C++ to other languages.
>>
>>You might as include all of Netlib when comparing Fortran to
>> others...
>
>
> Nevertheless, it's good to have things in the official standard
> than in a separate library, however widely available the library
> may be.
>
> You can always get Netlib quite easily. I know that. But,
> you have to say that you use some of the Netlib routines
> and that the user of your code has to get them from such
> and such places. For the map(*) in the STL, you just use it
> without commenting on it. The user doesn't need to search
> the web, download and compile it.
>
> I sometimes miss convenient containers in the standard Fortran.
> The other day, I had to implement a linked list. That wasn't
> a big deal, but nevertheless I had to use a bit of energy
> to get it right. I wished a list is in the standard.
> Also, I often find myself wanting to use an associative array
> ("map" in the STL) in Fortran programs I write. It would in
> some cases lead a cleaner program although a solution using
> an associative array would likely be slower than one using
> a plain array. Sometimes efficiency doesn't matter.
>
> I know C++ compiler vendors had/have trouble to get templates
> right. That means that the standard STL might not be as
> portable as it should. But, I guess by this time (I left C++
> several years ago), the STL is (mostly) working.

But as others continually point out, it is a dog to diagnose bugs when
templates are involved.

>
>
>>[The STL] makes a mockery of comparing the efficiency of C++
>>to other languages.
>
>
> I think this is an unfair comment....

<snip>

I'll head you off there -- I wasn't criticizing C++ on the grounds that
the STL is inefficient *speed-wise*; I was pointing out that C++ is very
efficient, *coding-wise*, because so much useful stuff is already
included in the STL. Therefore, a language such as Fortran -- where
containers have to be implmenented "by hand" -- will always take many
more lines of code to achieve some tasks, than will C++, which can pass
off tasks to the STL.

   I bet you sometimes use
> formatted I/O in Fortran.

Actually, beyond very simple print output (to give the user something to
look at), I don't; all of my codes use HDF5. Which, with the appropriate
wrapper routines, is very convenient.

> By the way, I'm not advocating introduction of a container
> libray into the standard Fortran, although I for one would
> welcome such a thing. I also think the STL could be better
> than it actually is. That doesn't, however, mean that it is
> useless or a "mockery". That's my point.

Oh, but don't get me wrong. For all its faults, I think the STL is a
great idea. It's just that, like any large, complex corpus of
functionality, it contains many pitfalls for the unwary.

> It's a bit of nitpicking, but the "map" in the STL isn't
> a hash table, if I remember correctly. A hash table requires
> a hash function for the objects you want to store in it.
> The requirement is sometimes inconvenient. So, the "map"
> in the STL requires only the existence of comparison.
> I think I heard it's usually implemented as a balanced tree.
> I heard that implementations sometimes offer a non-standard
> hash container.

Sorry, that's just my laziness. By "hashtable" I meant "map", although I
prefer the Perl term "associative array". A hashtable is of course one
way of implementing a map/associative array -- and it happens to be the
implementation I use in my Fortran codes. But like you say, sometimes
hashing can get nasty -- especially when you use the hash functions
given by Knuth, which collide more than Paris drivers at rush-hour.

Relevant Pages

  • Re: Fortran2003 and STL
    ... >> When f2003 arrives will it have enough facilities for the STL ... >> (Standard Template Library) to be implemented? ... Fortran will never again be a simple, clear, ... > All the traditional advantages of the language will cease ...
    (comp.lang.fortran)
  • Re: Fortran2003 and STL
    ... could ruin Fortran as a language. ... You seem to argue against making the STL part of the Fortran standard, ...
    (comp.lang.fortran)
  • Re: VC9: STL: hash_set/map : hash_compare without operator < ???
    ... You mean the C++ standard library, not the STL. ... I do not expect an hash collection to sort the elements, ... implement template lesssimple by returning a!=b? ...
    (microsoft.public.vc.language)
  • Re: Fortran2003 and STL
    ... > could ruin Fortran as a language. ... > STL part of the Fortran standard, ...
    (comp.lang.fortran)
  • Re: Fortran2003 and STL
    ... could ruin Fortran as a language. ... You seem to argue against making the STL part of the Fortran standard, ...
    (comp.lang.fortran)