ultralite and swift on ios

[Former Member]

hello, i have developped an app on ios using objective-c and ultralite. (using sql anywhere 12) i am moving my programming to swift 3 now, but there's no way to add c++ modules into a swift based project (even if i create a bridging header, it's not working) what should i do? any hints?

[former_SQLA_member1694876]

Also note that SQL Anywhere 12 is no longer actively maintained by engineering. It would be good to take this opportunity to switch to version 17.

[former_SQLA_member1694876]

I think the best approach is to write an Objective-C++ cover for the UltraLite classes -- something that's tailored to your application needs and that also handles the conversion to/from Objective-C types. Then you can call this interface from Swift. In this way, you can definitely add C++ modules to your Swift project, you just can't call C++ directly from Swift.

[Breck_Carter]

There are a lot of goggle hits for "call objective c from swift".

[Former Member]

well, there are lots of documentations about calling objective c from swift.. however, very few talk about mixed c++ and swift.. i have read some tutorials on the net, but they mainly take very primitive c++ files and create bridging headers for them... the ultralite library is actually a complete set of .h files referencing each other.. with many custom typedefs that don't match anything similar in swift or objective c. i am just asking to see if there's already anyone who's done some basic work or if there are plans to add support for swift on ios.

[former_SQLA_member1694876]

Right - the UL headers are not trivial, but I don't think that really changes anything. You include the UL headers only in your .mm file(s) that implement the database interface you design for your app. And then you just include your interface header in the bridging header for Swift.

Your database interface may include a result-set object with methods like, say, next and stringForColumn:, or it could take a SQL statement and return an array of results in one step, or it could be less generic and directly manage application model objects that are persisted. In any case, your interface should be much simpler than the full UL C++ API.