Messages

1

General Board / Re: WRAP and WRAP_COMMENT macro problem

« on: May 17, 2005, 10:34:37 pm »

Thanks. I was a bit suspicious when WRAP wasn't highlighted.

WRAP_LINES works for us.

2

General Board / WRAP and WRAP_COMMENT macro problem

« on: May 17, 2005, 09:02:08 am »

The macros don't seem to work in EA 5.x. For example in

Code: [Select]


%if genOptGenComments != "T"%
%endTemplate%

%PI=""%
$wrapLen = %genOptWrapComment%
$style = %genOptCPPCommentStyle%
%if $style == "XML.NET"%
%XML_COMMENT($wrapLen)%
%elseIf $style == "JavaDoc"%
/**\n
%WRAP_COMMENT( classNotes, "80", "", "" )%
\n*/
%else%
%CSTYLE_COMMENT($wrapLen)%
%endIf%

the WRAP_COMMENT macro expands to nothing.

I'm trying to generate doxygen-compliant comments, but with a lighter notation than the built-in javadoc macro.

3

General Board / Re: C++ operator () reverse engineering

« on: April 25, 2005, 08:28:05 pm »

OK, Thanks. We can wait  

4

General Board / C++ operator () reverse engineering

« on: April 22, 2005, 02:03:32 am »

Another noob problem:

EA seems to have trouble reversing the function call operator in C++. Looks like the parser only looks at the first pair of ()s, and fails to notice the parameter list in the second pair.

So, the following class

Code: [Select]


class A
{
...
bool operator ()( X x, Y y );
...
};


Ends up with a method "operator(): bool" in the reversed model, instead of something like "operator()(x: X, y: Y): bool. Forward engineering works fine.

So, has this been addressed before, and could anyone point me to a workaround? Thanks.

5

General Board / Re: C++ Smart pointer forward engineering

« on: April 20, 2005, 08:54:23 pm »

$TYPE allows us to use the REPLACE in the above template more easily (it's just an arbitrary token). If we used #TYPE#, EA would perform the substitution before providing the linkAttCollectionClass macro to the template. This way we can use the normal EA collection classes with the type substitution parameter intact.

Of course, now the non-overridden Link Attribute Declaration template (the one without smart pointers) does have to be modified as well, to perform the type substitution in the template, since we are no longer using #TYPE# in collection classes, and lose the automatic substitution. It's all a bit of a hack, of course, but does seem to work.

6

General Board / Re: C++ Smart pointer forward engineering

« on: April 19, 2005, 11:58:37 pm »

For the record, here is our new stereotyped override for the Linked Attribute Declaration template and our new "shared" stereotype:

Code: [Select]


%PI=" "%
$type=%REPLACE(linkAttQualName,".","::")%
$qualType=%packagePath% + "::" + %linkAttName%
%if genOptCPPGenNamespace == "T" and $type == $qualType%
$type="boost::shared_ptr<"+%linkAttName%+">"
%endIf%
%if linkAttCollectionClass != "" and linkCard != "" and linkCard != "0" and linkCard != "0..1" and linkCard != "1"%
$type=%REPLACE(linkAttCollectionClass,"$TYPE",$type)%
%endIf%
$type
%if linkAttRole != ""%
%linkAttRole%;
%else%
%REPLACE(genOptDefaultAssocAttName,"$LinkClass",linkAttName)%;
%endIf%


This handles all the multiplicities, and integrates nicely with the collection classes, as long as you use $TYPE instead of #TYPE# in the collection class definition in the code generation options. So, we have smart pointers or, at our pleasure, containers of smart pointers. Just repeat for stereotypes "weak" and "scoped".

7

General Board / Re: C++ Smart pointer forward engineering

« on: April 19, 2005, 11:16:10 pm »

Thank you. The modification works very well for us, and is really kind of obvious (sheepish grin). We also use %linkStereotype% values of "shared", "scoped" and "weak" to refine pointer type selection, as per your suggestion.

8

General Board / C++ Smart pointer forward engineering

« on: April 19, 2005, 04:56:37 am »

I haven't seen this addressed before, so I'm going ahead:

There is a nice facility in EA to define collection classes for associations, along the lines of std::vector<#TYPE#> that generate the appropriate member type in code for an association with (ordered / qualified / other) multiplicity 0..* (or similar).

Would it be difficult to extend this functionality to handle multiplicities of 0..1 and 1? This would be useful in case you want to specify an aggregation using a smart pointer, like boost::shared_ptr<#TYPE#> for example. Or is there another way to get the same result in the generated code?

The types should probably take into account association type as well, so that we could have composition = scoped pointer, aggregation = shared pointer and simple directed association = weak pointer (for another boost example).

Reverse engineering of the most common templated smart pointers would be very nice as well, even if a generic,  customizable member-type-to-association reverse engineering would probably be very difficult to implement in the presence of arbitrary templated types. Perhaps the code generation association member types could be used in parametrizing
the reverse engineering process as well?

We use a lot of shared pointers, and the default EA pointer and reference associations do not really help us much. If we could at least generate smart pointer associations, that would be great. Reversing them: bliss.