| Title: | C++ |
| Notice: | Read 1.* and use keywords (e.g. SHOW KEY/FULL KIT_CXX_VAX_VMS) |
| Moderator: | DECCXX::AMARTIN |
| Created: | Fri Nov 06 1987 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3604 |
| Total number of notes: | 18242 |
I'm looking for help on a problem I'm seeing with DEC C++ under OpenVMS.
CXX/VERSION gives me:
DEC C++ V5.5-017 on OpenVMS Alpha V6.2-1H3
although I've seen the same behavior under C++ V5.4.
The project I'm working on makes extensive use of the templated list classes
(e.g., RWTIsvSlist<T>) provided by Rogue Wave's Tools.h++ library. I have
compiled the library myself (version 7.00), with very little problem.
I'm using the defaults for template instantiation, meaning that templates
are instantiated automatically into the repository directory, and then
resolved uniquely by CXXLINK. The problem is that CXXLINK is complaining
about certain undefined symbols that are, to the best of my knowledge, not
legitimate C++ external symbols. Here's an example:
%LINK-I-UDFSYM, RWTValSlist< >::RWTValSlist(const RWTValSlist< > &)
and then (split for easy reading)
%LINK-W-USEUNDEF, undefined symbol
RWTValSlist< >::RWTValSlist(const RWTValSlist< > &) referenced
in psect $LINK$ offset %X00000700
in module MOPHYDEVICE file
DKA0:[DDUVAL.QUASAR.VMS-PORT.QUASAR.SERVER.MANAGEDOBJECTS]MANAGEDOBJECTS.OLB;1
As you can see, C++ appears to believe that I'm instantiating a template
class using a null type parameter. A search of the listing file for
MOPhyDevice.cpp doesn't show such an instantiation, and I would have expected
the compiler to complain if it found such a thing.
Any clues to what I might be doing wrong?
Thanks,
Dan Duval
Storage Subsystems
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3562.1 | we need some clues | DECCXX::MITCHELL | Thu May 08 1997 12:01 | 12 | |
I talked to one of our template experts about this about how we might get a clue about what's going on without having to get all of your sources. Initially could you search your code and provide source snippets for all places in your code where you instantiate RWTValSlist. This might tell us what types the template is instantiated with and indicate which instantiation is causing the problem. Also could you search CXX$DEMANGLER_DB in your repository directory ([.CXX_REPOSITORY] by default) for RWTValSlist and provide what you find. | |||||
| 3562.2 | relevant information provided separately | SUBSYS::DDUVAL | Thu May 08 1997 18:55 | 19 | |
It proved difficult simply to extract all of the places where an RWTValSlist
was instantiated, since in some cases such a list gets created as part of
creation of a larger data structure. What I've done instead is put the
results of "CXX/LIST/SHO=ALL" of module MOPHYDEVICE (since that's one in
which the symbol comes up undefined) in:
SUBSYS::R5$USER1:[DDUVAL.PUBLIC]
The C++ source file (.CPP) is in there as well.
I've also put in there a file called RWTVALSLIST.SEA, which contains the
results of searching CXX$DEMANGLER_DB for RWTValSlist.
Finally, if it would make this easier to track down, I could give you
access to the machine I use for building this image. Just let me
know.
Cheers,
Dan
| |||||
| 3562.3 | Fixed in T5.6 | DECC::FOLTAN | Thu May 15 1997 16:36 | 52 | |
Hi Dan,
The information you provided was very helpful, thanks!
The good news is that this problem is fixed in our
current development stream and should be coming your
way soon via DEC C++ T5.6.
Lois Foltan
DEC C++ Development
If you are interested I was able to reproduce the
problem with this small example:
//template.h
typedef enum {
DriveDead,
DriveDegraded
} DriveState;
template <class T> class R {
public:
void get(T p);
};
template <class T> void R<T>::get(T p) { return; }
//main.cxx
#include "template.h"
int main()
{
R<DriveState> r;
r.get(DriveDead);
return 0;
}
$ cxx main.cxx
$ cxxlink main.obj
typedef R< > __dummy_;
........^
%CXX-E-TEMPARGCOUNT, In this declaration, an incorrect number of arguments are s
upplied for the template "R".
at line number 2 in file GEM_C$:[FOLTAN.WORK.CXX_REPOSITORY]R___10DRIVESTATE.CXX
;1
%LINK-W-NUDFSYMS, 1 undefined symbol:
%LINK-I-UDFSYM, void R< >::get()
%LINK-W-USEUNDEF, undefined symbol void R< >::get() referenced
in psect $LINK$ offset %X00000020
in module MAIN file GEM_C$:[FOLTAN.WORK]MAIN.OBJ;7
| |||||
| 3562.4 | Is there a workaround? | CSC32::EHA | Flip | Wed May 21 1997 11:42 | 8 |
Hello Lois,
I have a customer that seems to be having the same problem. Is there a
workaround?
Thank you!
Al Eha
Digital Customer Support
| |||||