In Rhapsody 126.96.36.199 for c++ with flat code generation... I have several sub packages called Interface. For example Package A has Interface sub package and so does package B. If A::Interface has global variable "int test" and B::Interface has global variable "bool test" then only one variable "test" is generated inside of Interface.h. This is a problem because the compiler doesn't care and I could be using the wrong global variable in my code without realizing it.
IS that intended behavior and what is the workaround? Do people make sure they never have two packages with the same name? OR is there a property you can override to make the generated names unique? I noticed CG::Package::Filename, but it would be annoying if you had to do this for every package with the same name. Is there a way to make this property create more unique names by setting it to something like $parent$name? I tried that and $parent does not resolve to anything. This brings up a more general question... where can I find a list of variables like $name that can be used in properties.
This topic has been locked.
1 reply Latest Post - 2012-11-11T13:58:49Z by SystemAdmin
Pinned topic subpackages with the same name
Answered question This question has been answered.
Unanswered question This question has not been answered yet.
Updated on 2012-11-11T13:58:49Z at 2012-11-11T13:58:49Z by SystemAdmin
SystemAdmin 110000D4XK1305 PostsACCEPTED ANSWER
Re: subpackages with the same name2012-11-11T13:58:49Z in response to sdibmHi,
By default when you create in the model Package with name of existing package - you get warning and can make your decision if to give the same name or not.
Using of the property CG::Package::Filename to get different file to Packages with same name is good.
I don't think there is a keyword that will be helpful for this case, but here is the list: http://pic.dhe.ibm.com/infocenter/rhaphlp/v8/index.jsp?topic=%2Fcom.ibm.rhp.reference.doc%2Ftopics%2Frhp_r_ref_predefined_keyword_variables.html
Another solution will be to use CG SDK to set the file name during code generation, but this sound as overkill, while you can give different names to the packages in the first place.