I don't know about "tricks," but it's just a question of either (a) making sure the entry points to the C++ code are declared extern "C", or (b) writing a thin wrapper around the C++ library, also written in C++, which exposes the necessary functionality in a C-compatible way, and is declared extern "C". That's the portable way to do it, anyway...
By 'tricks', I meant that you might attempt to do something rather insane, and try to map C to C++ directly. I wouldn't recommend that approach (and it'd be very hard, and rather non-portable).
The other techniques we've discussed are better.
Oh, I bet that trick does work with g++, because these guys explain
g++ is dependent on platform-specific functionality of the underlying linker, in at least two areas: template instantiation (handled by collect2, but assisted by GNU binutils, I believe, if available), and ctors/dtors invocation.
ctors/dtors refer to static initializers and destructors. On most Unix platforms I've seen, I believe gcc is smart enough to link in the appropriate crtN objects to make sure that ctors/dtors are invoked properly even if you're building a shared library. Vendor compilers may not be so smart but who uses them? I also don't believe you need to worry about ensuring that main() is compiled in C++ mode on either Linux or Solaris. In some cases, you can get away with linking via "gcc -lstdc++" but it's probably safer and easier to use "c++" for the final link phase.
Erm, Mac OS X is probably quite a bit scarier in regards to shared libraries, but the above comments should apply to OS X in other respects...
hmz, most probably any external implementation of openid is very hard to run in an event driven model. For that reason i'd vote against an external library.
By 'tricks', I meant that you might attempt to do something rather
insane, and try to map C to C++ directly. I wouldn't recommend that
approach (and it'd be very hard, and rather non-portable).
It's hard and nonportable and you can do it, but actually all you have to do is get a pointer to the function you want to call, pass it to your C program, and then dereference it () so it calls the function.
Some people would argue, however, that sticking to plain C is an
Depends on the C.
I think apache is fucking retarted (my opinion only) they jump through hoops like crazy to make their code unreadable so they can implement C++-like constructs in C. What's the point except to make everything harder and more difficult to read. They should have used the right tool for the job.
If you write C in C, it's the perfect tool for the job.
Ford (then again I've completely sold out and I write java) ][
really remember exactly what you're supposed to do to export those
symbols as C symbols, but that's what you need. Figure that out for
g++, and you'll have it.
turns off the C++ name mangling so the linker can find the functions you're referring to.
I realize openID is more than just an auth module, but the benefits weren't worth the hassle.
Well, I found this library: [ http://kin.klever.net/libopkele/ ] and I
would like to use it from within Citadel, which is written in C.
Well obviously it would just be easier to port citadel to C++. :-)
I tried openid a while ago, even with a library it was so hard to get
working, I found it easier to write my own auth module
I did too, but it only does OpenID 1.1, and we're getting to the point where RP's that don't support OpenID 2.0 are starting to become problematic.
I think apache is fucking retarted (my opinion only) they jump
through hoops like crazy to make their code unreadable so they can
Interestingly, the OpenID module for Apache makes use of libopkele. I wonder if it would be worth it to read through that code and see how they did it.
hm, libpokele is probably a bad sample to unwind and code after...
all missing in there at first short glance is templates.
kortlin, just another "java done right on the same old java interpreter"
after scala, ceylon....
Kotlin: looks incredibly similar to Scala, to the point of being kind of a "me too." Me-tos are kinda rude to the general community, cause fragmentation...
It seems that most of the ones being created nowadays aren't exactly breaking new ground.
Java has its share of problems that are most effectively addressed by changing the rules. Most glaring issues are the absence of the uniform access principle, and all that darn equals/hashCode boilerplate. Things like lambda expressions are being addressed within the context of java, but cleaner solutions can be found in a fresh language.
Actually my initial knee jerk on Kotlin may have been a little harsh. It looks like a nice language in some respects.
I think it's fair to ask: when *is* it appropriate to create a new
When there's a new architecture so vastly different from anything else, that a new language could make better use of it than hacking an existing language to do so, just because it is already popular.
That's my view anyway, and as such there hasn't been a need for a new language since the web.
One could argue that 'stupid programmers' is a new architecture that would require a new language, so the web and stupid programmers, there should be like 4 languages total and that's it.
In business-related, "real world" programming, I'm more inclined to agree that only a handful of languages are "necessary." However, if we stuck to what was just necessary, we'd probably all still be hand-crafting assembler programs.
In business-related, "real world" programming, I'm more inclined to
agree that only a handful of languages are "necessary." However, if we
stuck to what was just necessary, we'd probably all still be
hand-crafting assembler programs.
Yeah. and just imagine how much farther along we'd be today.