Okay, I am sort of amazed that a language standard or compiler would place a
hard limit on something like this, as there is no need in the compiler code
itself - I have implemented symbol tables without length limitations
multiple times. Now, what I observe happening, that sort of drives me crazy
with the ifort compiler, is they will look at the global name length (ie., a
combo of module name + subroutine name + variable name + various junk they
throw in for you between the fields), and decide that the given name is too
long, and front-truncate with a warning. Okay, this has in general been
annoying but harmless. Now, I don't know if this stuff is subject to some
sort of standard, but having the amalgam that results in the "global name"
subject to this garbage (some arbitrary length restriction) is bad (and
really not all that necessary). Now, when you all say "hard limit", but the
compiler front-truncates, that in general is not all that ruinous, on the
assumption that the back end of the var name is typically disambiguating
within scope (and you will die if two things truncate to the same name -
pretty sure). So I still don't get really excited about having namelength
policing - I would hate like heck to have to get all my global names within
64 chars, or whatever they seem to be allowing. I think you guys are just
trying to draw me back into the fold for supporting a c++ product ;-)
(really, I would probably like it better in various ways, but still feel
that fortran matches math + more casual coder better).
- Bob
----- Original Message -----
From: "Scott Brozell" <sbrozell.rci.rutgers.edu>
To: "AMBER Developers Mailing List" <amber-developers.ambermd.org>
Sent: Tuesday, March 31, 2009 3:05 PM
Subject: Re: [AMBER-Developers] Usage of long symbol names
> Hi,
>
> On Tue, 31 Mar 2009, Joe Krahn wrote:
>
>> Robert Duke wrote:
>>> I am of the opinion that fighting over maximum name lengths is a waste
>>> of time, and completely contrary to the flow in evolving good software
>>> engineering practice. I suppose that if I were to see a fortran
>>> compiler that patently fails on some >n name length, I would feel
>>> otherwise.
>
>> That is partly why I posted the question: Are there any current compilers
>> that hard limit of 31? Intel Fortran has a hard-limit of 63 characters,
>> which is the F2003 standard, and probably good to enforce.
>
>
> Staying on message<.:-| the question to ask is Are there any compilers
> that a fair number of users have
> that have a hard limit of 31?
>
>
>
> I do not know, but 31 seems like a decent practical limit to me
> (and Im the King of long descriptive names).
> See p 262 of mcconnell2004; 8 to 20 characters is a good ballpark
> with exceptions.
>
>
> Here's what my first stab uncovered:
>
> pgf90 6.0-8 32-bit target on x86 Linux
> pgf90 -c -fast -O3 -Mfree -o charmm.o _charmm.f
> PGF90-W-0016-Identifier, charmm_atom_type_numerical_label, truncated to 31
> chars (_charmm.f: 214)
> 0 inform, 1 warnings, 0 severes, 0 fatal for charmm
>
>
> pgf90 7.0-4 64-bit target on x86-64 Linux
> pgf90 -c -fast -O3 -Mfree -o charmm.o _charmm.f
> PGF90-W-0093-Type conversion of expression performed (_charmm.f: 1302)
> PGF90-W-0093-Type conversion of expression performed (_charmm.f: 1304)
> 0 inform, 2 warnings, 0 severes, 0 fatal for
> charmm_calc_cmap_from_phi_psi
>
> Scott
>
>
> .book{mcconnell2004,
> author = "{Steve McConnell}",
> title = "Code Complete",
> edition = "Second",
> publisher = "Microsoft Press",
> address = "Redmond, WA",
> year = 2004 }
>
> You guessed it; this is another classic and probably the only
> encyclopedic guide to software development.
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Apr 01 2009 - 01:17:08 PDT
