C++ and other languages

[Chalisque]

I asked a friend (finishing his PhD in computer graphics) about writing C++ libraries with a pure C API.  I found I had to have an extra chain function outside the extern "C" to call the C++ code and another within the extern "C" code to allow all other languages to call into it.  (This is because C++ uses name mashing to permit function overloading.)  So add one extra call and return that really shouldn't be there.  Then, when compiling, I needed to compile the objects separately and then link them (giving files to the linker in the right order for some reason) and then I took a look inside the binary with a hex editor.  The resulting mess would have made me sick if I hand an ounce of i486 code in my heart.  It is brutally ugly, with a few hundred long scary symbol names and stuff.

The exercise was this: if I want to reuse the C++ STL, and call it, but from a newer and better thought out language that hadn't been invented when C++ was born, how would I do it.  This was a trivial exercise doing the minimal amount of work necessary to use a C++ vector<int> from within C (compiled using a C compiler not in C++ mode).

The moral of this story is that C++ is fine for now, but be aware that when newer languages come along, and they will and are, and need to reuse code, whatever is written in C++ is effectively unreusable.  Use C++ for demos for sure, you can do wonders with only the template system if you want fancy stuff to impress a potential employer how is dazzled by shiny things.  In fact, C++ is the best language around for reusing the <wonder/mess/disaster/beautifulShiningExampleOfAnOperatingSystem:yourchoice> that is Windows.  For the rest of the computational world, C++ is best left behind at the prototyping stage unless you're dealing with one of those obscure corner cases in scientific programming where C++ actually makes sense.  (For reference, the last language that filled that role was FORTRAN, and if you don't know what it's like to program anything other than numerical methods using fortran, you're one of the lucky ones.  At least I got to have a go at it only as an undergrad maths student, and even then could always do things better with the Solaris C compiler with proper optimisation settings and code written with the processor architecture in mind.)

C is the Snow White of languages, and C++ is it's stepmother.  Obviously in this case the stepmother found a time machine that allowed her to arrive later rather than earlier.

[hellfire]

All programmers happen to love certain programming languages and hate others; sometimes for the strangest reasons...
What language are you using that's not able to call C++ code directly?
In a typical scenario you have a complete module written in C++ and you just add open/close/work functions to access it from another project.
Wrapping trivial data-structures into other languages makes absolutely no sense to me.

[Canopy]

were you looking at a "release" build binary, or are those symbol names really the mangled 'decorated' names where the functions aren't exported as C calling convertion properly? Using the Dependency Walker tool will whether show if the exports from what you're calling are decorated correctly by putting C and C++ next to the exports.

Usually you received and have to pass a 'context' back into a C export and in the entry point in the DLL dereference it to call into the class, is that what you mean?

The other alternative is for the DLL itself to have a global static for the class to the C function doesn't have to, but it still requires an extra "jump" inside the DLL to get back in to the context of the class.

Not sure about anything calling C++ directly, but every language under the sun I've every encountered has some way to call either stdcall or pascal style exports from API DLLs.

I'm a C/C++ programmer, have been since the mid 90s and on n off I've used prettty much every language out there. (Including porting stuff to salford fortran under clearwin). I also do some objective-c for os x and ios these days, its nice but has the potential for even more messy/confusing than mfc/c++ really nice language in some respects though.

Everything system level, on every O/S under the sun is written in C or C++, this is because its low level, real unmanaged code.  A lot of C++ code that isn't extending functionality or using C++ objects that are OO just group and tidy code in and isn't fully OO anyway.

Whats my language of choice for my demo projects? C For anything else like GUI or things without such a time critical nature I might use C++,  but for real-time stuff, C all the way.

No messing around, no garbage collection, what you code is what you get.

Data structures which are designed properly don't need C++ wrappers, and because of that I'm seeing endless possibilities for optimisation that I simply wouldn't notice with OO design, my structs and lists (self) organising my data are my objects.

However,  the golden rule of optimisation should not be broken. DO IT ONLY WHEN NECESSARY. I've been using the free Very Sleepy CPU profiler and the gDEBugger tool (also free from AMD or the original dev's) for profiling OpenGL to find out where any bottlenecks are.

[relsoft]

Garbage collection = yuck.  It's the boon and bane of my existence in java game development.

I miss c++.

Unless all compiler devs decide on a standardized name mangling scheme, I would like to see all 3rd party libs wrtten in c.