Slashdot Mirror
The Challenge of Cross-Language Interoperability
CowboyRobot writes "David Chisnall of the University of Cambridge describes how interfacing between languages is increasingly important. You can no longer expect a nontrivial application to be written in a single language. High-level languages typically call code written in lower-level languages as part of their standard libraries (for example, GUI rendering), but adding calls can be difficult. In particular, interfaces between two languages that are not C are often difficult to construct. Even relatively simple examples, such as bridging between C++ and Java, are not typically handled automatically and require a C interface. The problem of interfacing between languages is going to become increasingly important to compiler writers over the coming years."
I don't even like .Net, but they won this round years ago.
I don't even know why anyone would even bother with c++. If it's a good fit, just use c.
Torvalds is right about the language; even though he's right for the wrong reasons.
Required reading for internet skeptics
What do you need multiple languages for anyway? Java does everything you could want. Java is a powerful, object-orientated, cross-platform language, with fully developed GUIs, such as Swing.
To demonstrate the superiority of Java, I can point to such leaders in their field as Eclipse, Minecraft, and this awesome applet I saw on someone's homepage once.
Anyone still using ancient and difficult to use languages such as C++ (let alone C!) are obviously crazy, and probably should be committed for their own good before they go on spree of shooting (not just themselves, but) other people in the foot. Java makes it almost impossible to shoot yourself, let alone others, in the foot.
Moreover, because Java is licensed under the GNU GPL, you can leverage the wisdom of crowds, and the powerful "many eyes make bugs shallow" concept to be confident that Java is the best.
And with just-in-time, Java is as fast as any other language, so you don't have to worry about the speed of execution. Instead, you can focus on developer time, and Java's just faster in that regard.
With built-in, from the ground up, support for Unicode, Java is there for the future, and is ready to be used across the multiverse (as soon as those aliens get their scripts into Unicode). Beat that C, with your lack of a string type.
And if you aren't convinced, tell me why do so many top enterprises use this language? You don't see ads from Fortune 500 companies looking for Ruby "developers" do you?
HELP MY ACCOUNT HAS BEEN HACKED BY AN ILLIBERAL ART STUDENT SET TO DESTROY THE INTERWEBZ!
The fault here lies specifically with Java and C++. Java's JNI is poorly designed and makes no serious attempt to make interoperability easy because it is against Java's philosophy. C++'s runtime is deliberately completely implementation dependent because C++'s designers thought that might let implementors squeeze out a little bit of performance.
Nevertheless, tools like Swig make even Java/C++ interoperation fairly easy, and many other languages try to accommodate C++ well (cf. Boost::Python).
Theoretically in a large organization with a huge and demanding application allowing developers to be able to interface with some sort of API with whatever language they choose may seem like a very flexible solution. I would be very worried that after a few years your code base would not only include a broad spectrum of languages but even potentially a broad spectrum of versions of those languages.
I suspect that you would find yourself having to learn Haskell for one emergency and Erlang for the next.
Where a multi language compatible API would be great though is when you start to migrate your system from one language to another. If you could do it piece by piece deploying each small well tested piece before moving on to the next I would suspect that many a disaster would be avoided.
Because C++ lets people automate resource management and error handling, things that in C are manual and error prone. C++ also provides standards for abstraction, encapsulation, and substitutability, something that in C is not standardized and handled differently by every library. Despite C++'s many flaws and unnecessary complexity, it still is a better language than C for many projects.
Better as long as you don't want to cross it with a different language I suppose.
In particular, interfaces between two languages that are not C are often difficult to construct
(Yes, I know what they mean. I think they meant to write "In particular, interfaces between two languages (when neither is C) are often difficult to construct". :)
Still, it amuses me to think about making an interface from C... to C
I'm sitting right now and coding an interface between Java and Erlang using JInterface, and the actual JInterface part is pretty good. It makes Java act as an Erlang node. But Java is just a horrible, horrible language.
Everything on the Java side gets so bloated it is just silly. What would take one line on the Erlang side can easily take 20 lines on the Java side.
I know you are just trolling, but...
Swing is the most horrible toolkit I've ever tried to use. Even monkeys can make a better one.
Eclipse is never needed for a real language, if you need an IDE, there is something wrong with your language.
Java does the opposite of trying to help you shoot yourself in the foot, by making the code bloated and spread out. More lines = more bugs, that is the simple fact.
Just-in-time does not make java "just as fast" automatically. I have 8 cores on my machine, and I can easily and safely make Erlang programs that max out all of them, and without any mutexes. The mutex model is just broken and as we move to more and more cores, you need languages that can easily and safely scale.
"Java unicode from the ground up", MY ASS! Why would you even make .toString() the default when converting from one type to the next. You always want .getBytes()!!!!
And stop smoking your crack for at least 5 seconds before lying to yourself about Fortune 500 companies not hiring anything but Java programmers. What do you think they coded Facebook chat in, for just one example? Not Java!
That should be enough fodder for the trolls.
Better as long as you don't want to cross it with a different language I suppose
Er, no.
C++ has C as almost a complete subset. Interfacing other languages is usually done in mostly the C subset. Except you get to wrap other-language structs in an RAII object so you never screw up resource management.
SJW n. One who posts facts.
Torvalds is right about the language; even though he's right for the wrong reasons.
Bsically no.
He's a very good kernel engineer and wrote a very good DVCS. But he's full of shit when it comes to C++. Not a single point of his stands up to any sort of logical scrutiny.
I'd be quite surprised if anyone here will make such points either.
SJW n. One who posts facts.
"You can no longer expect a nontrivial application to be written in a single language." ... that hugely depends on your definition of "nontrivial", but generally: yes, I can expect that and see no counter-indication for it.
The only exception is to have a kind of "core framework" which can be scripted and has an embedded interpreter (eg. python or similar), but that scripting language is then not a first-class-citizen on equal footing with the rest of the program, but a sort of "slave system" (does that make any sense?).
So what you basically do is interfacing between C++ and C, and then between C and some other language.
Use sockets. In majority of cases the performance is more than good enough, especially if designed properly, and you get network transparency "for free".
Sure there are cases where sockets are not appropriate, but IMHO they are far too seldom used.
Not a single point of his stands up to any sort of logical scrutiny.
I guess you missed this part: "he's right for the wrong reasons."
I don't know why you're so defensive of the language. C++ hasn't exactly improved over the years.
Required reading for internet skeptics
One facet of this is that increasingly, any application of any great interest runs over the network, often using HTTP, so its UI is coded in JavaScript or somesuch and the back end can be any motley arrangement you like that happens to work.
Even traditionally single-host applications like word processors nowadays involve mechanisms for installing software updates and online dictionaries or cloud-based functionality. As for games, you can't even launch most single-player games that should have no need of a network connection without having to log in.
The popularity of the mobile app model is such that this trend is only going to increase. As such, the issue is not about binary runtime language compatibility frameworks like SWIG, but more about network protocols.
On this aspect, Python does handle interoperability pretty well (at least with C and C++). It might just have a little bit too many options: .h-like file
* ctypes: connect to any C library directly (you just have to not do any mistake in parameters, as there is not check)
* Python C extention: write a wrapper in C.
* SWIG: "automatically" generates the wrapper, based on some
* cython: write C code using python syntax
Personally, I just use ctypes or cython, and it's quite easy to interpolate with any software library I need.
Not to mention C++14.
WoW uses Lua, which is actually known for having a very simple and easy to use interface with C code. I even found an example on the Wikipedia page: http://en.wikipedia.org/wiki/Lua_(programming_language)#C_API
What about C++11?
That's my point entirely. :)
Required reading for internet skeptics
C++ is a superset of C, and none of C++'s runtime features interfere with cross-language interoperability unless you actually use them and expose them. So, you're never worse off using C++, since you can always write your code the same way you would have done so in C and use C++ features only in a way that don't alter interfaces.
The only real disadvantage of C++ over C is the enormous complexity of C++. Functionally, it is superior in pretty much every way.
As someone who's done a fair bit of the reverse, and has recently needed to write C bindings for a few other languages (go, ruby), I thought this shouldn't be nearly so hard as you describe. Here's what I've come up with:
Example.cpp: Implements a class and C bindings for that class (The bindings could obviously be in a different file)
#include "ExampleCBindings.h"
#include
class Example {
public:
Example(int v) { value = v; std::cout << "New Example(" << v << ")\n"; }
~Example() { std::cout << "Deleting Example(" << value << ")\n"; }
int getValue() { return value; }
private:
int value;
};
extern "C" {
Example_class* newExample(int value) { return (Example_class*) new Example(value); }
void deleteExample(Example_class* example) { delete (Example*) example; }
int ExampleGetValue(Example_class* example) { return ((Example*) example).getValue(); };
}
ExampleCBindings.h: Public C bindings // what I love most is that Example_t never exists ;)
#ifdef __cplusplus
extern "C" {
#endif
typedef struct Example_t Example_class;
Example_class* newExample(int value);
void deleteExample(Example_class* example);
int ExampleGetValue(Example_class* example);
#ifdef __cplusplus
}
#endif
main.c: Simple C driver program that uses the api
#include "ExampleCBindings.h"
int main() {
Example_class * ex1 = newExample(5);
Example_class * ex2 = newExample(ExampleGetValue(ex1) + 2);
deleteExample(ex1);
deleteExample(ex2);
return 0;
}
Limitations include:
* Does not support objects existing on the stack. You're in C, this is the norm for opaque data structures.
* Need to individually wrap every function. Would need to create separate wrappers for overloaded functions, or write a variadic function that doesn't enforce types (Sigh, neither language supports reflection)
However, if you only wish to implement public functions, writing a script that autogenerates a wrapper like this would be fairly easy (I've done similar for a mocking framework for C code - now that's actually painful (not the script, inserting stubbed functions into a binary)). A little googling came up with a more formal attempt here.
That is true, but C++ does it in a way that makes programming dangerous.
That's why the D language was developed. It's something like C++, but done correctly with a clean sheet of paper. You can even understand the syntax! C++ programmers can easily learn it.
The question is whether D will ever catch on. It's not, or at least doesn't have the image, of a cool new language. The only chances I see for its success are 1) it'll be used on a lot of FOSS projects, so eventually enough people will want to darg it into their day jobs, and/or 2) some well known company starts using it internally. I'm not a big Facebook fan, but it would be a likely candidate, as Andrei Alexandrescu (C++ author and #2 guy on D) works there.
P.S. I also like Ada. At one time you had to be careful admitting that, but it's ok now because not many people know what you're talking about. It's dying though, and has been for many years. It's probably already a common topic at the Old Programmer's Home. D has a chance in part because it's newer (and more up-to-date).
I use VHDL (Ada's little brother). It is a better language, if you like extreme-typing.
The typing stuff is a bit overdone, but I still much prefer it to Verilog. I'd rather spend time fighting the compiler than tracing down bugs in simulation that could have been caught earlier.
But your VHDL program is proven (and then aggressively optimised) by the synthesizer (a compiler that produces a netlist to create electronics/FPGA to run your program), it does take a while for the synthesizer to be done.
Synthesis is a step that simply doesn't exist in software. How does the synthesizer "prove" anything though, other than that you have a synthesizeable design?
Seriously,
This is the plight of windows ecosystems. Linux/Unix has had abilities in this regard for many many years. It's stable it's rock solid and it performs.
Java is a bit of a nightmare for performance. But a ton of Enterprise is written in Java. Depending on your role you would argue the same thing for python, perl ruby etc. The later languages tend to perform better when calling native libs and vice versa. .NET is an abomination of performance an security disasters. These issues are backed into it's architecture and require far to much skill and background to avoid.
Now compilers are NOT the issue. It's runtime binding that is the issue. Compilers do a great job. Runtime binding is where things really fall down. Again .NET. The more you can resolve binding issues prior to the runtime event the better. For example I'm sure a ton of people on /. can rant about the issue with RMI and the destruction it inflicts at runtime. I call RMI SUPER LATE BINDING. .NET is founded on the similar principles and it SUCKS.
Apps like SWIG allow you to create compile time bindings between libraries. Which though not perfect create far more robust interfaces between high level languages. Something you can actually test. Since interfaces from libs also tend to be stable. The are also robust.
Yes of course it is possible to build robust integrations which bind at run time. But the level of effort is ridiculous and is rarely justified in budgets of medium to small Enterprise.
I didn't sleep well. I'm tired and pissed off. Therefore a great distraction is to start a flame war!
He's a very good kernel engineer
Agreed.
and wrote a very good DVCS
Yes, bad user interfaces and mish-moshes of barely portable shell and C are the hallmarks of a good design. Mercurial is better, and has been chosen by most people/companies that have sat down and tried to make an objective comparison (e.g. Google, Fog Creek). Git is winning out mostly because it's what Linus, the ultimate cool kid, uses, and a lot of geeks still dream of sitting at the cool kids table.
But he's full of shit when it comes to C++. Not a single point of his stands up to any sort of logical scrutiny.
The one thing Linus does better than running the kernel project, is being an opinionated loudmouth. IIRC his hatred of C++ stem from an attempt in the ancient days of the kernel project to use it. At the time g++ seriously sucked. Small wonder it had problems. Or maybe Linus has a fear of objects because he was struck by one as a child, and doesn't like classes because he had to attend them (I said I didn't get much sleep).
A quine chain in ~50 languages: https://github.com/mame/quine-relay
Now that's what I call cross-language interoperability.
For bonus points, they're even in alphabetical order.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
The joy of a least common denominator.
What's with classes and objects? You can use that with C, it's just not built into the language.
GTK+ is written in C but it offers bindings for many other languages including C++. This is very easy since C has good interoperability.
It it surprising to me that the article makes no mention of language workbenches, when they are a good solution to the problem the article describes. See our preprint https://peerj.com/preprints/112v2/ for an example of language interoperability, and references therein for descriptions of language workbenches.
Oh no...
xxxx is better than yyyy because..
Langugages (and really the platform / libraries are more important) ech have their own strength.
What you don't want to do is to solve a problem, add a prgramming language, because then suddenly tou have 3 problems instead of one:
-being to able to write in 2 langugages. (the subset of emplyess able to do that is much much smaller than those having good skills in one languges
-interface between them (rarely done, so few people understand the details.
-maintaining for a long time mulple languages.
If you run a JAVA enterpise. Fine. If you run perl/php, Fine. If you run C? ueh....cobol? Keep it!
I really don't see the need to use any language other than C. It is simple, elegant, straightforward, portable and versatile, it allows you to do everything you need without too much cargo cult and there is an enormous number of tools available.
Similarly I think that these newfangled "word processors" or even text editors are ridiculous. What can't you do with pencil and paper?
I use C daily for deeply embedded stuff (no OS, ultra-low latency, etc.) and it's still the best choice for that and similar work (e.g. kernels). Sometimes I even use assembly language. But for 20 years now C has been an inappropriate language for "general purpose" applications (i.e. don't talk directly to hardware, etc.). It's too primitive and needlessly dangerous. C was originally created as a systems implementation language, and became popular for other stuff on Unix mostly because the compiler was there, and back in the day when tweaking your Unix box meant modifying the source code, everybody knew it.
Shlaer-Mellor / Executable UML have been offering this type of language independence for over 20 years. The method works from business to embedded software. All that's required is model compiler support for the target language, which can be bought off the shelf or made in-house. Currently model compilers exist for C, C++, Java, Ada, System C, and I'm sure there's more that I haven't encountered.
I am not so sure about that. At least, it still is a quite viable platform. You can learn the language and do useful stuff with it, including GUI apps, and you can distribute them without problems. Many of the libs are quite up-to-date.
But who uses it for anything other than legacy code? Even the DoD dropped their mandate 16 years ago. F-22 software is written in Ada, but F-35 software in C++ (remind me to find deep shelter if I'm ever near an F-35 base).
Old languages (even if they've been updated like Ada) that never really caught by a certain point almost always die, even if very slowly. A newer language has a better chance. It's more of a sociological issue than a technical one, but that doesn't alter the reality of it.
Anyway, why did you have to be careful admitting you liked Ada?
Because sometimes my Nomex underwear was in the wash. Back when people had heard of it, any mention of Ada brought all sorts of ignorant criticism and flaming. Eventually I got tired of the argument. I knew I was right, and to hell with anyone who didn't realize it :)
I guess you missed this part: "he's right for the wrong reasons."
No, I saw it. He's wrong AND his reasons are crap.
I don't know why you're so defensive of the language.
I'm not. I use C++ a lot and I quite like it. If you have an open mind, I'll happily bore you to death with all the things I hate about C++ and why I wish they were better.
It is however impossible to have a sensible discussion about C++ with people who know almost nothing about it yet strongly hold opinions about it out of some misguided sense of fashion.
C++ hasn't exactly improved over the years.
Which is yet another statement which strongly indicates that you don't actually know anything about C++. If it turns out you do use it, then contratulations: you've managed to isolate yourself from reality.
Again, I could happily bore you with all the many things that have changed for better or worse up to 1998, between 1998 and 2011 and the merits and demerits of C++ 11 and C++14.
But you hold your opinions firmly and out of ignorance so it would be a complete waste of time on my part.
SJW n. One who posts facts.
Verilog won the popularity contest
Does that make it a better language?
Also VHDL is still quite popular some places. I've worked for several companies in the last 10-15 years that use it. I suspect VHDL and Verilog will continue to co-exist. As far as tool chains are concerned, they're both essentially front ends. It's not hard to support both, and most do.
And the English language suffices for bad puns (though I understand Mandarin is even better).
What's with classes and objects? You can use that with C, it's just not built into the language.
Same reason lisp ultimately never catches on. If you work with other programmers then you have to communicate with them.
You can do almost everything in C that you can do in C++, but you have to do it by hand. But in C you have to do everything by hand and everyone does everything slightly differently.
It's useful to have the class notion baked into the language for the same reason it's useful to have the for loop baked into the language. It reduces overhead to read and write and makes the common case much less error prone.
SJW n. One who posts facts.
Yes, bad user interfaces and mish-moshes of barely portable shell and C are the hallmarks of a good design.
Fair enough. I was not an early adopter. I gather it was really not very good in the early days until someone wrote some moderately sane UI code to go around it. The main reason I use it instead of mercurial is momentum: git is popular with OSS so I had to learn enough to get by. Then it because a question of learning another system (Hg) or sticking with something moderately familiar.
Git is very good in that it works well for a lot of people. It's not necessarily the best :)
SJW n. One who posts facts.
Same reason lisp ultimately never catches on.
I wanted to start a flame war for fun, but you're throwing rocket fuel on the fire. Using that four letter word practically guarantees a conflagration.
The main reason I use it instead of mercurial is momentum: git is popular with OSS so I had to learn enough to get by.
Ditto. It's just that it's always a sore point with me when an inferior design wins out for silly reasons, especially when I have to live with the inferior product. But it's hardly important enough for me to spend the rest of my life decrying the injustice of Git winning over Hg (10 or 20 years of ranting should suffice).
I get annoyed when the premise is so flawed, but stated as fact.
Major projects have been cross-language for decades. In the 70s, Fortran + C + Assembly were in most big languages. Or large systems using COBOL having to interface to non-COBOL systems. By the 80s, many had bits of Pascal (Borland was huge, remember?) and BASIC, with important routines hand-optimized in assembly. Or C. By the 90s, we had SQL and native code, DLLs written in random languages, and often VB for the UI. Most of what you use on a daily basis probably is browser-hosted but includes active controls in C# or C++, back end code in PHP or Java, database code in SQL and browser code in JavaScript or ActionScript. Many of my Android apps are mostly Java with some kernel-level support in C.
Yes, each language has it's own way... COM, exports, dllimport, etc. Until it has one, it's not a very functional language. But this isn't a new development.
Because some syntaxes are better at expressing some concepts while others are better at expressing other concepts.
Facebook started using D a month or two back.
Do you even lift?
These aren't the 'roids you're looking for.
The success of Android (Java) and iOS (Objective-C) showed us that allowing several languages on a platform just adds unnecessary complexity. One language is sufficient to develop great applications.
Nice! I hope it sees widespread use there because, like I said, that may be about the only way the language will really catch on. Right now I get the feeling a lot of people either don't know or don't care about the language, because I every time I mention it here there's almost no reaction. A flame war would be better than ignoring it.
BTW, I've only recently started using it, although I've known about it for years. From what I understand, up until fairly recently, it had some rough edges. They seem to have been polished D2 has completely superseded D1, the old Phobos vs. Tango library issue is gone (only Phobos now - Tango is thankfully dead).
The one thing that seems to still need some polish is the GC implementation. Right now they have a "stop the world" GC, but someone is porting the Boehm GC. Currently alpha, but looks good.
What is so dangerous about C?
Dereference errant or even NULL pointers, exceed array bounds, foot loose and fancy free type conversions, I'm sure you've heard these and more. If you really like to write code without the safety net, use assembly language (I sometimes do). As for making "coders sloppier", I find that's true of all these newfangled HLL's. I'm never more careful or more disciplined than when writing assembler.
I know how to avoid the dangers of C, and dare say I'm pretty good at it. I rarely make a mistake, but rarely isn't never. Also sometimes I work with other programmers that frankly aren't as good at avoiding the dangers. Makes integration fun. The situation is even more fun when security is a major concern (it generally isn't for what I do).
Some may make some dangers more implicit
What does that mean and what's an example? No snark - I honestly don't understand the point.
IBM solved this problem 20 years ago with their Integrated Language Environment (ILE), not that anyone cares.
(Damn noobs think every problem they encounter is new and unique).
Proverbs 21:19
Instead of getting my programmers from Glasgow, I am sending my current programmers -- broke, penniless, desperate -- to live on the streets of Glasgow for a year.
Those that survive the ordeal will return to my Xanadu-like pleasure palace, where they will serve out their remaining years in matchless luxury.
-kgj
Paul Graham liked to blog about how awesome Lisp is. Apparently, he did some web back-ends in Lisp and was able to stay ahead of the competition. Now, Lisp has some awesome features. The two that stick out to me are (a) Lisp macros, which are arbitrary Lisp code run at compile time that emits arbitrary Lisp code that gets compiled, allowing some seriouly powerful constructs to be created very concisely and (b) massive libraries. That being said, I suspect that Paul Graham and his cohorts were more successful at using Lisp compared to another back-end language because they were both very skilled at the language and also super smart. The language they chose is actually MUCH less important. If they’d chosen another language, they would have done probably just about as well.
If you’re not a super smart programmer, I recommend Java (among other languages). Pass-by-reference and garbage collection obviate a lot of coding mistakes. And with Jit compilation, you get pretty darn fast code. Under 99% of circumstances Java performance is way better than adequate and makes MUCH better use of programmer engineering time.
But if what you want is super fast performance, a super smart C++ programmer will beat a super smart Java programmer. It’s a lot HARDER to get better results from C++, but the ceiling is higher. Some reasons for this:
- In memory-constrained environments, garbage collection imposes some overhead. I’ve worked on huge programs near the VM size limit whose performance was limited by GC performance. Most of the time, incremental GC in another thread is a win, but it can be a huge liability in memory constrainted environments. Instead, manual memory management in C++ allows you to make tighter use of the memory space and performs better in a memory-constranied environment.
- In a CPU-constrained environment, background GC steals cycles away from computation.
- Just like how macros are a huge win in Lisp, C++ templates generate customized code at compile time that can have huge perfrormance benefits. This is why C++ sort is faster than the C library qsort: The C++ sort is a template that inlines the comparison function for the type you’re sorting, rather than making a method call. In Java, you MIGHT get some of this from a fabulous JIT compiler.
- Compiling to bytecode is a huge information loss. If you used gcj to compile Java to native code, there’s the potential to have less information loss and therefore optimize better based on the programmer intent. But normally, Java uses bytecode as an intermediate. With more programmer intent knowledge, the C++ compiler can make smarter optimizations.
I could add more things, but I have other real work to do. Before I go, I’ll cap this off with two practical thoughts. You CAN get better performance from C++ than Java. Do you WANT to?
- Java has massive libraries too, where the critical parts are written in optimized native code, so if you make heavy use of Java libraries, you’ll see almost no difference in performance with regard to CPU throughput (GC being a separate issue). With no perceptible impact on peformance, less code to write, fewer common programming errors, and better use of engineering time, Java is quite often just an all-around practical win over C++. I say this as a programmer who prefers C++.
- If you’re REALLY REALLY concerned about performance, use Fortran. The language is more restrictive, providing the compiler with even more freedom to optimize. (For instance, no aliasing, no recursion.)
OMG tried to tackle the language interoperability with CORBA ( Common Object Request Broker Arch ).
They created another language: IDL
wait.
- these are not the droids you are looking for -
C++ is indispensable for 3d engine programming for the following reasons.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
Yeah, there are a bunch of games/engines that use Lua for their scripting now (and others that use Javascript, and some that implemented their own language, eg. QuakeC).
Not sure why my original post was labeled "flamebait". I guess someone out there in "CS academia" had mod points :) (it was a joke, people!)
auto_ptr has been depricated
Required reading for internet skeptics
On the web we have tens of languages on the server side communicating to browsers & crawlers. Crawlers are written in nearly every language.
How did we do it? A standard protocol.
So, stand up 2 programs, have a standard for message passing, and continue working. Forget library-like integration: you don't want some giant code in your process space anyway.
- Testing is simpler.
- Fractional deployment is equal to having DLLs, but simpler resource file management.
- Crashes are easier to debug, and far less insulation is necessary for a good overall experience.
- Scalability becomes simpler.
- The initiator of an internal issue can be hard to determine, but many solutions exist & it's often unnecessary to know.
Summary: Do one thing, do it well
Science & open-source build trust from peer review. Learn systems you can trust.
Fine, unique_ptr then. Regardless, auto_ptr was only ever 10 lines of code, if it was to be removed completely, it could still be re-added in 2 minutes. Point is, in C++ you can write pointers that free themselves. Destructors are super useful for everything, I use them to free all kinds of memory, as well as to release mutexes and stop timers when the it returns, breaks or gotos out of a block.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
You do realize that you can read and write C interfaces in C++. And you also get all the goodness of C++, which is a lot if you actually know what you are doing. The only real problem with the language is that it takes too long to learn how to use properly. But that also means that C++ developers are generally smart.
Like all pain, suffering is a signal that something isn't right
You're right. We should all eschew C++ for C, because the bindings to foreign-function interfaces don't require you to write extern "c" {}.
Like all pain, suffering is a signal that something isn't right
C++ is not a superset of C, since minimum a decade.
There are plenty of examples of valid C programs that don't compile in a c++ compiler, google and stackoverflow are your friend.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Verilog won the popularity contest
Does that make it a better language?
Also VHDL is still quite popular some places. I've worked for several companies in the last 10-15 years that use it. I suspect VHDL and Verilog will continue to co-exist. As far as tool chains are concerned, they're both essentially front ends. It's not hard to support both, and most do.
As far as I can tell, SystemVerilog won the popularity contest. This imports a number of VHDL ideas into verilog that make life easier. What it fails to do is import the operator overloading and resolution functions that works so effectively in VHDL. In VHDL if you want to define a new logic value, like say 'P' for values driven from unpowered logic, you can simply overload the std_logic operators, or replace std_logic, and the simulator will work for you. No so in Verilog. The logic values (1, 0, H, L, X etc) are wired into the language. You can't add a 'P'. Consequently, SystemVerilog makes it really difficult to verify low power fine-grained power gated designs.
Of course nobody making tool purchasing decisions considers these things.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Whether D is something that's "done correctly" is, shall we say, extremely arguable.
The price for that is the major pain that using countless macros to implement your "classes" is in GObject, where the same thing in C++ is literally a single line of code.
Let me explain, since you seem to have a bit of trouble with the history and usage. C++ has never been a strict superset of C as a language; there have always been C programs that were not valid C++ programs. Therefore, when C++ programmers say that "C++ is a superset of C", it always means that you can take any C program and with only small modifications turn it into a valid C++ program that works and links the same way as the C program you started with.
Well, *once* C++ was a *real* superset of C.
Your claim here is bogus, you just try to not lose face, rofl.
Afterwards I guess it started mid 90th the designer deliberately broke stuff and made it noticeable different in C++. So I would say porting badly written C (especially K&R C) to C++ is not as easy as you seem to believe.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
There are numerous other examples. The interesting behaviour of sizeof() when you have a class and a variable of the same name is one of my favourites.
I am TheRaven on Soylent News
Ok, argue it.
Why the difference between "int function(int)" and "int delegate(int)"? Why not a single type for callables?
Don't forget the template system. While it can be very tricky to write for, and error messages are often bad, it's dead easy to use. std::sort is not only easier to use than C's qsort(), it's very often more efficient because it doesn't require as much indirection. The STL idea is very powerful.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
I have decidedly mixed feelings about the template system. C++'s implementation of templates is a bit brute force but very efficient, and that's nice to have around.
But I think neither its template system nor the STL are particularly well designed.
In particular, interfaces between two languages that are not C are often difficult to construct
I'm under the impression that this one of the primary use cases of service-oriented architecture.
Because the semantics of the body are different - one also closes over the control flow (i.e. the meaning of break and return), the other one does not.
C++'s template system is roughly equivalent to Lisp macros, which are elegant and incredibly powerful but hard to work with, in a much more awkward form. The STL, on the other hand, looks generally well designed to me. It takes a few basic concepts (containers, iterators, algorithms) and puts them together in very useful ways. What problems do you see with it?
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
No, C++'s template system is nothing like Lisp macros. Lisp macros were straightforward tree rewrites. C++'s template system interacts in very complicated ways with overloading, inheritance, and other language features.
As for STL, its basic notions of containers, iterators, and algorithms exist in most languages and predate it by a couple of decades. STL is bloated and complex in comparison. The justification for the additional complexity in STL was efficiency, but STL isn't actually significantly better than simpler designs.
C++'s template system is equivalent to Lisp macros in that both give compilers a Turing-complete way to generate code. I'm not claiming that it's anywhere near as elegant.
I'd be interested in knowing what languages in common use had something equivalent to STL containers, iterators, and algorithms, and what that was. I know a bit about computer languages, and I don't know of anything actually equivalent. The complexity is mostly on the implementation end, not the use end, and I don't see why you say it's bloated and complex.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Even printf+system("cc") is equivalent to the Lisp macro system at that level; we've been talking about language design.
C++'s template system was not intended as a Turing-equivalent compile-time code generator; that was something people figured out over time. In fact, many people saw that early on but refrained from using it because compilers couldn't handle it; they took it more as a sign that the C++ designers were screwing up than as a good language feature.
OCAML, F#, SML, CommonLisp, Smalltalk, Python, to name just a few. STL is a poor imitation.
Most of the algorithms and data structures it provides have don't belong in, and aren't useful in, in a general purpose library. And STL's pointer-like iterator abstraction makes things that should be easy to express in a container library tedious and cumbersome.