![]() |
Telelogic TAU (steve huntington) | ![]() |
Topic Title: Grief with Namespaces in CppModel Topic Summary: Innumerable compile problems associated with "namespace" Created On: 17-Jun-2005 00:41 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: An intriguing question, Ron. Here's a bit more detailed description of the problem, and responses from the Tau Support team. 1. The top-level package contains two active (simple) classes, classA and classB. 2. The top-level package contains an active composite structure class, compositeClassC. 3. The composite structure class, compositeClassC, is composed of one instance each of classA and classB. 4. The top-level package contains a package called LogicalDataModel. 5. LogicalDataModel package contains Interfaces, Signals, DataTypes and Syntype definitions. 6. The top-level package contains a Class Diagram in which "access" dependencies are drawn between the LogicalDataModel package icon and the ClassA and ClassB icons. 7. compositeClassC structure diagram illustrates ports on each of the classA and classB instances, and the compositeClassC structure, with Required and Realized entities for all three being drawn from the available Interfaces defined in LogicalDataModel package. 8. The C++ code generation artifact creates header files for classA and classB which have a "using namespace LogicalDataModel;" statement contained within the classA and classB declaration statements. 9. If the "using namespace LogicalDataModel" statements are moved "up" one level in the declaration hierarchy, the code compiles successfully. That is, from within the class declaration, to prior to the class declaration. Tau Support replied that another (albeit manual) workaround would be to manually move the relation up one level in the UML model, by creating an "access" dependency between the package containing classA and classB and the LogicalDataModel package. As for future automated corrections, they said an enhancement request will be submitted to have the code generation artifact automatically move the relation up one level in UML prior to code generation, or to modify the transformation component to move the relation up one level in the generated code. Hope that helps. | |
![]() |
|
Is anyone out there having the same level of problems I am regarding namespace compilation errors?
I have a UML for CPP model in which the top-level model package contains several active classes, as well as a "sub"-package with signals, interfaces, passive classes, datatypes, etc. I have created access dependencies between the active classes and the "sub"-package. When the C++ code is generated, and compiled with MSVC++ .NET 2003, there are many errors related to namespaces. Data members are claimed to not belong to the specified namespace, but the IDE shows in a tool-tip when hovering over the data member that it indeed does belong to the namespace. Many errors of the form "Cannot convert type ' Really aggrevating. Anyone have these types of problems? Any suggested workarounds? Frustrated beyond belief, -Ron Edited: 17-Jun-2005 at 00:43 by Ron Grider |
|
![]() |
|
![]() |
|
An intriguing question, Ron. Here's a bit more detailed description of the problem, and responses from the Tau Support team.
1. The top-level package contains two active (simple) classes, classA and classB. 2. The top-level package contains an active composite structure class, compositeClassC. 3. The composite structure class, compositeClassC, is composed of one instance each of classA and classB. 4. The top-level package contains a package called LogicalDataModel. 5. LogicalDataModel package contains Interfaces, Signals, DataTypes and Syntype definitions. 6. The top-level package contains a Class Diagram in which "access" dependencies are drawn between the LogicalDataModel package icon and the ClassA and ClassB icons. 7. compositeClassC structure diagram illustrates ports on each of the classA and classB instances, and the compositeClassC structure, with Required and Realized entities for all three being drawn from the available Interfaces defined in LogicalDataModel package. 8. The C++ code generation artifact creates header files for classA and classB which have a "using namespace LogicalDataModel;" statement contained within the classA and classB declaration statements. 9. If the "using namespace LogicalDataModel" statements are moved "up" one level in the declaration hierarchy, the code compiles successfully. That is, from within the class declaration, to prior to the class declaration. Tau Support replied that another (albeit manual) workaround would be to manually move the relation up one level in the UML model, by creating an "access" dependency between the package containing classA and classB and the LogicalDataModel package. As for future automated corrections, they said an enhancement request will be submitted to have the code generation artifact automatically move the relation up one level in UML prior to code generation, or to modify the transformation component to move the relation up one level in the generated code. Hope that helps. Edited: 6-Jul-2005 at 16:11 by Ron Grider |
|
![]() |
Telelogic TAU
» TAU/Developer
»
Grief with Namespaces in CppModel
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.