Borland C++ For Linux
Ardax writes: "Looks like Borland is going to be releasing C++ for Linux, according to this InfoWorld article. We'll be seeing more details at LinuxWorld in NY next week. The article doesn't mention whether this will be C++ Builder for Linux, or 'just' a command line compiler. No matter what, this is a sweet thing. I wonder how it will compare to gcc? (I wonder if it will be able to compile the kernel? :-) ) If it's the whole C++ Builder shebang, I wonder if there will be an Open Edition?
Borland's Community site has a blurb about this. There's no comments at the Borland community yet, but some interesting commentary might pop up there."
I could see there being a market for Borland if they released a nice GUI C++ development environment; but if it was just a command line program, can someone explain to me why they would use it instead of gcc. I just see no reason to pay for it if it is a command line program. I can't believe that they would offer some feature that gcc doesn't.
What good is a used up world, and how could it be worth having? --Sting
Borland has always put out wonderful tools, and really worked hard on making their compilers optimized on their platforms, but I think they've missed the boat here. This is most likely for easy porting of other applications written with Borland tools to Linux, because Linux already has a solid toolchain of its own. Regardless, I hope they get back on track.
What I miss most is the old text-based Borland IDE. That was the most productive development environment ever. RHIDE is close, but wasn't stable on Linux when last I checked.
pb Reply or e-mail; don't vaguely moderate.
Borland's IDEs (baring of licensing crap ;-) have always been exceptional. Current opensource IDEs are decent, but they are no where near the quality.
It comes down to maturity. Borland has been making powerful IDEs for a very long time. Development for opensource IDEs however is a fairly new thing (KDEvelop is good, but it is still fairly unreliable and not as featured as I'd like).
After years of tweaking, Borland's got it down pat.
Why bother.
It's not clear (at least from the sketchy information in the article) if there will be an Open Source/free version, but I hope so, and here's why: currently my university requires us to use Windows in our computer science classes, mainly because Microsoft gives us a lot of expensive software for free (if Microsoft makes it, students probably have access to it--Visual Studio 6, Visual SourceSafe, SQL Server, Windows XP Pro, ...)
That leaves people like me--who prefer to run Linux instead of Windows--at a disadvantage. I have to have a dual boot system, and I have to reboot to Windows every time I need to hack out some code for a class. Now, if Borland releases their C++ for Linux and makes it free, I know I could convince a couple of my professors to ditch the Microsoft stuff and use teach the class using Linux and Borland. That would enable me--and the rest of the university--to gain some practical experience coding on the Linux platform, and not just on Windows. Don't get me wrong, there isn't anything wrong with knowing how to code using Windows and Microsoft Visual Studio (in fact it's probably a good resume item), but I'd like to get familiar with some alternatives before I enter the workforce.
Quite a few people still buy Delphi. Delphi users moving to C++ often buy C++ Builder. Otherwise, most everybody else chooses Visual Studio. So, I could see a case made for opening C++ Builder, but not Delphi (which happens to fall under "their Windows products").
The kernel . . . is writen in C with a ton of GNU extentions. So the kernel is really tied to gcc. (which actually makes it more protable because gcc runs on a ton of machines)
Um, no. Using compiler-specific extensions does not make code more portable by any possible interpretation of the word. If it didn't use any extensions, then not only could GCC compile it, so could Intel's compiler, Sun's compiler, etc. That would be portable.
While we're on the subject, though, it would be nice to see at least some of the GCC extensions make it into other compilers. I try to write code without them as much as possible, but in particular I've found the typeof() construct useful, as well as the ability to initialize arbitrary members of a union (yes, I know I could just turn them into structs, but that's a waste of memory). Does anyone know alternate ways of doing things like this in standard C, or whether the GCC folks are doing anything to try and get their extensions included in the standard?
A really great thing with Linux (and NetBSD, and OpenBSD) is *portability* . These OS can run the same way on a variety of hardware.
Something designed on Linux x86 can run on Linux PPC with almost no change.
The master key to make it possible is GCC. Because GCC can compile (and even cross-compile) code for a lot of architectures.
Projects using Borlanc C++ specific features will work on Intel Linux. Nowhere else. This is pity. An opensource Operating System should be open to everyone.
{{.sig}}
Actually this was discussed on the borland.kylix.non-technical newsgroup a while ago. The aim is apparently to be able to compile ANY C/C++ Linux application, in fact the complete system, including the kernel. Thus it will need to emulate gcc's extensions.
We'll see if this turns out or not. That's just what I recall reading in discussions.
But if so it would be pretty sweet, assuming you're not a Free Software zealot (which I am, kind of, but I can see some coolness factor in this). If the pull it off, someone will be able to build an ENTIRE Linux distribution with their optimized compiler. Everything could run faster.
Having a new commonly used compiler for Linux would be a good thing. It would force GCC to better comply with the ANSI standards. As it stands, there are a number of 'minor' embrace-extend features of GCC that many coders aren't even aware of. Having to write their code to compile on multiple compilers shakes some of that kind of stuff out.
Borland is entering a tough market. The Linux system already comes with C++ compilers and IDEs. Perhaps not as good, but free (GPL). This makes any sale dubious. Their products may well be better, but how large a market is there for better products against already established free products?
One place where they have a big edge is in dialog building. Kylix already builds dialogs under Linux, so they know how.
Perhaps what their goal is, is to get people using their products on Linux to be cross-platform, but to make their pile selling compilers for the Windows versions? Sounds chancy to me, but it would let them sell the Linux system at around cost, and still make SOMETHING. I'm dubious about proprietary libraries, but I believe that the GPL (NOT LGPL!) version of the library is available at sourceforge. And that Borland holds sole rights, so they can license it commercially if you pay them.
This means that you can use Borland libraries in GPL software without cost, but if you want to sell the product, Borland gets a share. (Sounds fair to me. Viable? I don't know.)
Given this evaluation, past comments, etc., and what I expect is that this C product will be the C++ companion product to Kylix. And it will probably be available on the same basis.
As to what they'll call it, companies are unpredictable, but what I think they should call it is:
Kylix C++, a C++ environment for the Kylix family.
Then they could follow it up with:
Kylix Python, a Python environment for the Kylix family.
Kylix Java, a Java environment for the Kylix family.
etc.
The kicker would be that all of the various pieces could work together in a relatively seamless way. (This takes a bit of work, but SuperCede Java did this between Java, C, and C++ on the PC side years ago. They finally got bought out by someone who raised the price to $10,000 per copy, but it worked pretty well when it was affordable.) And, of course, gcc has always worked this way.
.
I think we've pushed this "anyone can grow up to be president" thing too far.
If performance is heavily FP dependent, you may be seeing one compiler inserting FP trap instructions (which stall the pipeline). Some compilers default to catching all FP exceptions where they occur using traps (for consistency & IEEE compliance) while other compilers default to letting FP exceptions propagate to keep the pipeline moving (for speed). On some platforms (e.g. Alpha) I've seen a 2:1 difference in execution speed depending on the FP exception handling options you specify.