[swift-users] Using C++ libraries in Swift projects?

[Jonathan Prescott]

To take two lines from your example, you could do something like this if you don’t want to re-write Boost.Logging or build/use native Swift facilities to write to logs:

BoostLog.h:	// Use this to bridge to Swift via C-compatibility

extern “C” void logTrace(const char * str);
extern “C” void logDebug(const char * str);

BoostLog.cpp:		// this is the implementation

#include “BoostLog.h”
#include <boost/log/trivial.hpp>
#include <string>

void logTrace(const char* str)
{
	BOOST_LOG_TRIVIAL(trace) << std::string(str);
}

void logDebug(const char* str)
{
	BOOST_LOG_TRIVIAL(debug) << std::string(str);
}



You would then use logTrace and logDebug within Swift like any other C-functions(using the appropriate Swift<->C interoperability conventions).  How you package it up to include in your Swift project is another whole subject.

This is the general scheme by which you would include C++ into Swift (or any other language other than Obj-C++, for that matter, as Jens as noted previously).

Jonathan

> On Jan 13, 2017, at 12:37 PM, Ethin Probst via swift-users <swift-users at swift.org> wrote:
> 
> So you don't know how I could directly port this to Swift--or make an
> indirect port?
> 
> On 1/13/17, Jens Alfke <jens at mooseyard.com <mailto:jens at mooseyard.com>> wrote:
>> 
>>> On Jan 13, 2017, at 8:18 AM, Ethin Probst via swift-users
>>> <swift-users at swift.org> wrote
>>> 
>>> I was wondering how I could go about using the Boost library project
>>> (among others) in swift?
>> 
>> No, it’s generally not feasible to use C++ libraries from any other
>> language. The main reasons are that (a) name-mangling of C++ functions means
>> that there’s no reliable way to tell the other language the name of the
>> function you want to call, and (b) C++ has so many language features that
>> are tightly entwined with the way you call functions — constructors,
>> copying, assignment, references, implicit conversions, operator overloading,
>> etc.
>> 
>> In the simple example you gave there are several warning signs:
>> * BOOST_LOG_TRIVIAL etc. appear to be macros since they’re in all caps. Who
>> knows what functions they actually call?
>> * The “<<“ operator expands [unmangles] to some complex function name which
>> is very compiler-dependent.
>> * It’s very probable that the “<<“ operator is defined as an inline
>> function, so it may not even appear in the binary of the compiled Boost
>> library at all.
>> * The C string constants on the right hand side are probably being
>> implicitly converted to C++ std::strings before the call. Or maybe not. And
>> the conversion likely happens on the caller’s side, i.e. the compiler has to
>> know to create a std::string before calling and then destruct it
>> afterwards.
>> 
>> The only practical way to call a C++ API from another language is to write
>> glue code, a set of functions that call the library, but which have a plain
>> C API and use only C types. Pretty much any language has a way to call C
>> functions, so you can now call the C API which will call the C++ code.
>> 
>> —Jens
> 
> 
> -- 
> Signed,
> Ethin D. Probst
> _______________________________________________
> swift-users mailing list
> swift-users at swift.org <mailto:swift-users at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-users <https://lists.swift.org/mailman/listinfo/swift-users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170113/4a1af19c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1603 bytes
Desc: not available
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20170113/4a1af19c/attachment.p7s>