Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C++ Generated Code Fails to Compile #1420

Open
alexjackson1 opened this Issue Nov 30, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@alexjackson1
Copy link

commented Nov 30, 2018

Description

No generated C++ code compiles using default (or any) compilation tools.

Steps to Reproduce

  1. Create simple test.ump file e.g.
class Person { }
  1. Using command-line tool: run java -jar <path_to_umple_jar> -g RTCpp test.ump to generate C++ code
  2. Compiling using any of: cmake . ; make, or g++ test_Model.cpp -o model.o, or even clang++ test_Model.cpp does not compile due to (seemingly legitimate) C++ syntax errors.

Expected Results

Successful compilation of the generated C++ code to an executable as in (v1.26)

Actual Result

Log output is very long but to give a flavour the last error returned is always an issue with passing strings to std::exceptions.

In file included from Person.cpp:12:
./master_Model.h: In instantiation of ‘PT* AutoPtr<PT>::operator->() [with PT = DelegateBase]’:
./master_Model.h:1330:14:   required from here
./master_Model.h:773:18: error: no matching function for call to ‘std::exception::exception(const char [23])’
       throw std::exception("Null Pointer Exception");
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/c++/8.2.1/exception:38,
                 from /usr/include/c++/8.2.1/ios:39,
                 from /usr/include/c++/8.2.1/istream:38,
                 from /usr/include/c++/8.2.1/sstream:38,
                 from ./master_Model.h:34,
                 from Person.cpp:12:
/usr/include/c++/8.2.1/bits/exception.h:63:5: note: candidate: ‘std::exception::exception()’
     exception() _GLIBCXX_USE_NOEXCEPT { }
     ^~~~~~~~~
/usr/include/c++/8.2.1/bits/exception.h:63:5: note:   candidate expects 0 arguments, 1 provided
/usr/include/c++/8.2.1/bits/exception.h:60:9: note: candidate: ‘constexpr std::exception::exception(const std::exception&)’
   class exception
         ^~~~~~~~~
/usr/include/c++/8.2.1/bits/exception.h:60:9: note:   no known conversion for argument 1 from ‘const char [23]’ to ‘const std::exception&’
Person.cpp: In function ‘bool operator==(Person&, Person&)’:
Person.cpp:61:1: warning: control reaches end of non-void function [-Wreturn-type]
 }

Comments

**The last working version I could find was v1.26 (breaking at v1.26.1). **
Am I missing something obvious or is this just bad C++ code being generated?

@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Nov 30, 2018

@ahmedvc Please respond to this and fix if something is broken.

@alexjackson1

This comment has been minimized.

Copy link
Author

commented Dec 1, 2018

Some further information I have found through some digging:

The issue seems to have been introduced when this file was modified: here. I've highlighted the line which causes one (of the many) syntax errors thrown by the compiler. It should be replaced with Exception("Null Pointer Exception") as there is an additional class created by the author to pass strings to std::exceptions.
Modifying the generated code resolves that error but leaves a litany of others I just do not have the time to debug.
From the looks of things I would say that it would be best to revert the code and work from the c++ templates in v1.26 iteratively recompiling adding the features that have been added prior to the 1.26 release.
I can't help but think I may be missing a compilation step or something more trivial as I am sure this issue would've been thrown up before - I'm not an expert c++ programmer by any means - any advice would be appreciated

@ahmedvc ahmedvc self-assigned this Dec 3, 2018

@TimLethbridge

This comment has been minimized.

Copy link
Member

commented Dec 3, 2018

Contributors are actively working on solving this issue, which they suggest arose from a change in a dependency. They will also put in place robust testing to prevent regression. Expect a solution within a week or so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.