Conference turris::c_plus_plus

	Does CXXDEMANGLE still exist on VMS?  We have VMS V6.1 installed
	on both our Vaxen and AXPen but $ CXXDEMANGLE give unrecognized
	command, and $ HELP CXXDEMANGLE knows nothing.  I have no idea
	how to determine the version of CXX that we have....

CXXDEMANGLE does exist on OpenVMS - V5.4 of the compiler was its first release
(I'm 90% sure).

To check out the version 
cxx/ver/noobj nla0:

bjm

> CXXDEMANGLE does exist on OpenVMS - V5.4 of the compiler was its first release
                                      ^^^^^^^^^^^^^^^^^^^^

	Thanks.  That appears to explain it as with the command you supplied
	to get the version (I actually tried /version but got an error,
	guess you need the rest of the magic :-((():

DEC C++ V5.0-003 on OpenVMS Alpha V6.1

	which appears to be an earlier version than V5.4.

With DEC C++ V5.5 and earlier, you do need to input the filename
(nl: will suffice).

In the next version of DEC C++ on VMS, you should no longer need to
enter the filename. Here's what I see with the development version.

CXXC-> gemcxx /ver
DEC C++ X5.6-109 (GEM 3313) on OpenVMS Alpha V6.2-1H3

Many have agreed that this is an improvement.

-Jeff

	Ok, I found a test system that has V5.4 of DECC++ and it has
	the cxxdemangle command.

	However from reading the help pages, it appears the way it works
	is that it needs a data file generated when you compiled the
	module to map (using the mangled name as the key) to the
	de-mangled name :-(  I guess I wrongly assumed the mangled
	names themselves, like with DECC++ on Digital UNIX, encoded
	all the information needed to display the name demangled.  My
	guess this wasn't doable on VMS because VMS must have restrictions
	on the max length of a symbol in the object file? (what should
	I expect from an OS that requires a hack like transfer vectors
	and dependecies on the ordering of entry points, which only
	got partially solved, and introduced new problems, when it
	had the benifit of re-deisign for AXP :-).

	In any case, I'm told it will be at least a couple months
	before I can expect the compilers to be upgraded on the
	VMS build systems, so I'll try a different route ....

	Is it documented anywhere (either in the docs, or burried
	somewhere in this notesfile where I wasn't able to find it
	with an AltaVista NOTES search) the algorithm used to generate
	the mangled names on VMS?  That way I can start from our
	header file that contains the public api to generate mangled
	names to use for exporting from the shareable image (in which
	case it will also solve my problem of making sure to export
	data (vs. procedure entry points) symbols correctly on AlphaVMS.

	I can't wait to find out how the algorithm ensures a one to one
	(even though it's one-way) mapping to the mangled names .....

Re .8:

>... I guess I wrongly assumed the mangled
>	names themselves, like with DECC++ on Digital UNIX, encoded
>	all the information needed to display the name demangled.  My
>	guess this wasn't doable on VMS because VMS must have restrictions
>	on the max length of a symbol in the object file?

Yep, the mangling is essentially identical on all our platforms - its just that
the limit which triggers truncation and hashing is around on VAX/VMS and around
63 on Alpha/VMS, while its at least in the neighborhood of 1023 on Alpha/UNIX.
(We may never have shipped a compiler that even knows to truncate and hash on
MIPS/Ultrix).


>	Is it documented anywhere (either in the docs, or burried
>	somewhere in this notesfile where I wasn't able to find it
>	with an AltaVista NOTES search) the algorithm used to generate
>	the mangled names on VMS?  ...

Yes, in the _Using ..._ guide.  (There's a reference in my 708.20, which is in a
topic with the MANGLED_NAMES keyword).


>	I can't wait to find out how the algorithm ensures a one to one
>	(even though it's one-way) mapping to the mangled names .....

See my 2916.5 for an analysis of the mapping.
				/AHM

> Yes, in the _Using ..._ guide.  (There's a reference in my 708.20, which is in a
> topic with the MANGLED_NAMES keyword).

	Thanks for the pointer!  I'm heading over to topic 708 now!

> Yep, the mangling is essentially identical on all our platforms - its just that
> the limit which triggers truncation and hashing is around on VAX/VMS and around
> 63 on Alpha/VMS, .....

	It appears the truncation/hashing is occuring on Alpha/VMS at
	the same mangled name length as on VAX/VMS, ie. around 31.

	I'm not complaining as this makes it a bit easier for us in
	that we don't need two separate export lists for VAX and Alpha,
	I just want to make sure that it hasn't changed between versions
	of the compiler (which I doubt for the obvious backwards compatiblity
	reason), or that I've done something wrong.

	The versions on our VAX and Alpha systems are:

DEC C++ V5.0-003 on OpenVMS VAX V6.1
DEC C++ V5.0-003 on OpenVMS Alpha V6.1    

Re .11:

>>Yep, the mangling is essentially identical on all our platforms - its just
>>that the limit which triggers truncation and hashing is around on VAX/VMS and
>>around 63 on Alpha/VMS, .....
>
>	It appears the truncation/hashing is occuring on Alpha/VMS at
>	the same mangled name length as on VAX/VMS, ie. around 31.

Yep, I now see that's true.  I'll ask around for the rationale...
				/AHM/SIGH

From:	TLE::DECC::RMEYERS "Randy Meyers 381-2743 ZKO2-3/N30  17-Mar-1997 1728
-0500"   17-MAR-1997 17:33:46.13
To:	TLE::DECC::AMARTIN
...
Subj:	RE: Alpha/VMS truncates and hashes at 31, not 63?

>How come we don't make use of the longer linker symbols on Alpha/VMS?

The following reasons were used at the time:

	Allow VAX binaries translated to AXP to link with native binaries
	Keep the VMSes as similar as possible
	63 isn't that much bigger that 31
	They made the change after we got the code working

> Allow VAX binaries translated to AXP to link with native binaries

Sharable images use ordinals in the usual case.
There are no names allowed in the image activator as far as I know.

VEST doesn't do objects, only .EXEs.