John Harper <harper@[EMAIL PROTECTED]
> wrote:
> But AIMAG has another problem: it is both generic and specific, but the
> specific version is a default real function of a default complex
> argument only. Pity there isn't a specific DAIMAG intrinsic function,
> not to mention DCABS, DCCOS, DCEXP, DCLOG, DCONJ, DCSIN, DCSQRT.
This "problem" is pretty much universal to all the intrinsics. You won't
find *ANY* new specifics for them. The number of specific names required
would be huge, not to speak of the fact that even what specifics were
appropriate would be compiler-dependent (because the number of kinds is
compiler dependent, and it would be problematic if changing kinds meant
that you no longer had a specific).
Sorry... (well, not very), but specific intrinsics have been on the way
out since f77. Using specific intrinsic names is basically an f66
practice. Adding zillions of new specific intrinsics just to sup****t f66
styles isn't realistically going to happen. The number of places where
one actually needs a specific name for an intrinsic is miniscule to the
point of being essentially nonexistant. How many times do you actually
pass an intrinsic as an actual argument? Well, somehow I might believe a
non-zero answer from one or two people here, but if so, they are in a
pretty small minority.
And if you happen to have such an exceedingly rare case, it is usually
easy enough to work around by making a user-written specific procedure
as a wrapper. The number of cases where that workaround isn't viable
(because user procedures can't do some of the things that intrinsic ones
can) is even more rare. If you have such an unusual rarity, I'm afraid
that the cost benefit of throwing a zillion specifics into the standard
just isn't there.
For the most part, the answer is "don't do that."
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
|
