Generating C++ code

Hi,
I’ve just started to work with DB-VA to find out if it is appropriate for our project and I have several problems with generating C++ code.

  1. Why are the checkboxes for generating getters and setters disabled for Persistable class attributes? (I’ve created class diagram from ERD)

  2. When I create new class manually options for getters and setters are enabled, but when I check them no getters and setters are generated after using C++ Round-trip -> Generate code.

  3. Is it possible in DB-VA to write code that generates C++ code according to Class attributes? (I need to loop through all the class attributes to generate code which contains attribute names)

Could you please help me with these problems or acknowledge me if it’s not possible to do with this tool.

Thank you.

Thank you for your message and I think you got some mix up about the code engineering feature supported in DB-VA. DB-VA provide the following code engineering features:

  1. Object-Relational Mapping (ORM) code generation (in Java, C# and PHP)
  2. Java & C++ Round-trip code engineering
  3. Instant Reverse

These 3 code engineering features are independent with each other. For the classes with ORM Persistable stereotype, they are solely related to ORM code generation. Since ORM code generation is for generate a ready-to-use library source code, the getter & setter are handle automatically.

In C++ round-trip, they are simply transform between class model and C++ code, and you can right click on the attribute and select Generate getter/setter to generate the getter & setter operations. Once they are created they will be generated into source code.

For the moment we do not support generate ORM code for C++. So if you want to generate C++ code, it can only via the standard round-trip engineering.

Feel free to contact me for further queries.

Best regards,
Rain

Luke, GORM works esnsetially by using Java reflection.I have personally found two main disadvantages to this approach1. The dynamically generated methods are not there at development time. This makes it hard (impossible?) to take advantage of compile time type safety one of the features that makes Java often a better choice than Groovy/Ruby/Python for large projects.2. Performance. The spring guys stated that one of their goals was for Roo not to degrade performance, extensive use of the reflection api rules out the GORM approach.