Slashdot Mirror
Java for EGCS
Drew writes "Anybody who thinks java is slow should check this out. The company soon to be formerly known as Cygnus released libgcj today. "libgcj" is the runtime library for gcj, the java front end to egcs. Find out more at sourceware.cygnus.com "
"The company soon to be formerly known as Cygnus"? What are they going to change their name to?
Alas,
It seems my technical interpretation skills are lacking today. In layman's terms, what does this libgcj actually do?
Is a java source to native binary compiler?
Does it produce native binary libraries from the stuff you get in the JDK? Aarg, someone please help me out and explain what it is and why it is important.
Thanks,
Too-ashamed-to-be-named
why would c be a given? you wont actually see much c programming these days, it's mostly c++, java, and (believe it or not) vidual basic. though i will admit that alot of the c++ i see does look alot like c :(
Hate to say it about an otherwise cool community, but Linux coders in general (with some great exceptions) are extremely biased against C++. I've seen many projects build their own object model in C rather than use C++ (ugh). It's probably partly due to gcc being a lousy C++ compiler, but that's not the whole story I'm sure. I think people just aren't interested in taking the time to learn C++. (Egcs is pretty good now, I use that.)
Heh, sorry. But really, I've been coding in Java for three years now. I don't really miss the operator overloading that much at all. The benefits of more than make up for the loss of things like operator overloading and multiple inhearitance.
Getting rid of operator overloading??? That's dumb.
:)
not as dumb as you think.
Why write c = a.add(b); when c = a + b; is SO much better?
well it certainly does look innocent enough dosent it? but it's not. operator over loading only leads to confusion and misuse.
Just because operator overloading has been abused doesn't mean that it should be removed from the toolbox!
well yes it does! it's not just that operator overloading has been abuse in the past, it's that operator overloading continues to be abused all the time. sure it may seem like an inocent easy shortcut when you are the only person working on a small program but what about when you are one of 8 ppl working on a large project? also dont forget that it's not always the same 8 ppl, some move on to other jobs and take information with them and new ppl come on and need to be brought up to speed. operator overloading is just to ambiguous to rely on.
i admit that i used to think that it was very cool to when i was in college, but my first year of programming c++ in the real world taught me otherwise. today i make an explicit point of avoiding operator overloading and all the other bad shortcuts in my code and i encourage those that i work with to do the same, i even try to get such things officially in the local coding standard when i can. hopefully you will learn to before too much damage is done
Oh please, Interfaces solve 98% of the same problems as multiple inheritance without the confusion. In almost all cases multiple inheritance is misused from a design stand point and just creates a maintanance nightmare.
Java's lack of it is a plus, not a minus, just like operator overloading..
I don't think it's that much of a loss. With Interfaces and regular inheritance you can generally get around the same functionality without the problems of multiple inheritance. :P
That and I don't have to bother with pointers...
Unfortunately so do I, owing to the huge mass of
scientific library code and all the code resources I've built myself. And I've been burned when I want to generalise a program to a broader problem.
OTOH, if you add memory allocation and data structures Fortran becomes useable, if ugly.
Unfortunately there is no F90 compiler on Linux though.
Java lacks templates and overloaded operators, which makes it a fairly useless language for generic programming. Don't forget about C++ just yet.
TedC
I just started using Java (I'm a C++ programmer at heart) and I have to say that I'm very happy about the portability of the language. But there are two things that bug me. Getting rid of pointers... I can live with that. Getting rid of operator overloading??? That's dumb.
Given how classes are defined in C++/Java, it's not dumb at all, imo.
If classes were slots + generic functions with multiple-dispatch (like in CLOS and Dylan), and there was a decent macro system available (again, like in Dylan or Lisp) then operator overloading could be handled in a completely sane fashion.
Since Java is basically C++ minus all the completely broken bits, they couldn't really shake up the object model to make use of the good experiences in OO language design. *sigh*
Not me. Getting read of pointers renders Java fairly useless as a systems programming language.
TedC
http://www.gmd.de/SCAI/lab/adaptor/adaptor_home.ht ml
True, C++ is a lot more involved, but it's not *that* tough to get the hang of. And what's obscure about making a virtual base class anyway? It may not be as elegant as java, but it's certainly not a difficult concept to learn. Anyone who has done work on the kernel, or even anyone who has made a halfway useful app, should have no problem making the transition to C++. As for C being a "portable assembler", I'd choose OO programming to assembly any day.
Mike.
http://www.vcpc.univie.ac.at/information/software/ shpf/
t ml
and
http://www.crpc.rice.edu/HPFF/compilers/index.h
and this may help
http://www.mhpcc.edu/doc/hpf/hpf.html.
Enjoy.
IBM's hpj runtime does load classes dynamically,
even though its a native compiler (or post-compiler, if you prefer.)
Of course, the classes being loaded also have to be fully compiled, not bytecode.
Why do you need to load many VMs?? Why not just the one you have loaded run all your Java code?
Why would a natively compiled executable built with this technology lack the ability to dynamically load java bytecode? A VM built into libgcj could load bytecode classes using the libgcj format and provide a means of switching between compiled methods and bytecode methods in much the same way as JITs now switch between bytecode and compiled. In fact, I believe that this is the ultimate goal of Cygnus' engineers (A belief gleaned from a post to java.lang.??? by Per Bothner in late '97)
Java lacks templates and overloaded operators, which makes it a fairly useless language for generic programming. Don't forget about C++ just yet.
overloaded operators are a cheap shortcut that are not needed in any language and templates are not needed in java becase it has a more consistent and uniform object heirarchy than c++ does. templates in c++ are nothing more than a hack to allow you to do what java was designed from the start to do.
if your gonna slam java at least come up with facts and not FUD!
Another free (as in free beer) f90 capable
compiler comes fromm Pacific-Sierra Research
check
http://www.psrv.com/linux.html
It is a f90 to f77 translater though, but it works
ok and is free for evaluation (does not expire)
and personal use.
Interesting. I've never seen a C programmer confused over operator overloading.
:)
i dont recall anyone even mentioning C, we were talking about C++, and in C++ it happens alot especially when you are getting up to speed on a codebase. more often than not you are using other ppls code instead of writing from scratch.
Would you argue that C should replace a + b with addi(a,b), addl(a,b), and addd(a,b)?
again who said anything about C but if you meant somthing along the lines of replacing
a = a + b;
with
a.add(b);
where a and b are say ints, i would advocate that, but such an example is trivial because adding numbers is a well understood concept (even java has predefined operator overloading on all the basic types). try something a little more difficult where a and b are nontrivial data structures and
a += b;
is certainly not as clear as
a.append(b); (for lists, arrays, etc...)
a.insert(b); (for trees, maps, etc...)
etc...
That may seem strawman, but it's the point. When dealing with mathematical structures on which + is defined (complex, hypercomplex, vectors, etc.) it's clearer to use the mathematical symbol.
well it may only be clearer to somebody who has an explicit math background but yes you are right that most ppl should have no problem understanding the + operator in terms of mathematical structures, but not all structures are mathmatical. see my explenation above.
It expresses the problem in terms I can understand, and makes it simpler for me to program it.
while such an attitude works when you are working on a project alone and that only you will have to maintain, it dosent work well when you have to deal with other that have diferent experiences and perspectives.
I have plans to avoid those things forever.
good luck in working alone for the rest of your career. in my experiance you will mostly be working directly with anywhere from 2 - 10 other ppl on a project depending on it's size.
Many people writing in Java are writing one person programs, and they should be catered to as much as the large projects.
not really sure what you mean by this.
Anyway, in a large project you need naming standards and others, so just add no overloading on to the list.
exactly what i said. also just because you dont _need_ a coding standard on a small project dosent mean you shouldnt have one! if you didnt have to learn how to develop a coding standard in one of your college cs courses then you certainly missed out on an enlightening experiance (especially when the rest of the class reviews your standard
1. It's much clearer to say a + b (where a & b are complex numbers) than it is to say a.add(b).
yes, but as i have said, only when a and b are numbers. when dealing with objects of a higher level of complexity then it can become very ambiguous.
2. As someone else pointed out, virtual functions and overloading can make it pretty hard to figure out what a function's from anyway. Translate a + b to a.operator+(b) and look it up like you normally would.
virtual functions and overloading are only confusing when dealing with multiple inheritance (another C++ evil that should be avoided at all costs because it actually is rarely needed). the goal should be to write code that is self documenting and shouldnt have to be looked up.
You'd be surprised at how many companies still use straight C.
actually no i wouldnt. but i think you might be suprised to see how much code is written in languages other than c and then compare that to how much code is written in c.
this is all highly dependant on your natural learning tendacies. when i was first learning to program i had a terrible time with c but when i started learning c++ i took to it naturaly. i have found that OO more closely resembles the way i solve problems and the feature of languages like java and c++ make writing programs much easyer for me than in languages like c.
:)
it's alot like when you are half way through your first proigramming course and you realize their are 2 kinds of ppl, those who naturally take to and love recursion and those who just dont get it and hate recursion. in my first class it was about 40:60 favouring banning recursion from the planet, but i loved it anyways
... but Java still sucks as a language. I like garbage collection and the object model (dynamic loading/probing of classes), but otherwise, it's completely inferior to C++. Those features, obscure as they may be, were added to C++ for a reason. You don't need any one of them 95% of the time, or even any of them 75% of the time, but when you need them, you need them.
On the multiple inheritence vs. interfaces war: interfaces subsititute for a lot of MI. However, they're still a subset, and sometimes you need the full power of MI. A language should give the programmer as much power and flexibility as possible, and a programmer should know when not to use it. Having a programming language enforce what it considers good programming practice results in disasters like Ada, Pascal and Java.
Either way, I'm happy, and I think Cygnus is working on a valuable thing here. No matter how poor Java is, it's a common language, and having a native compiler will make GNU/Linux a much better platform for Java development and deployment.
- pmitros at mit.edu
PIZZA has better constructs for generic Java .class files
.class files AND .java source files as
programming than the Java language itself, and
compiles to compatable JVM runnable code.
(PIZZA is just one example, there are dozens
of other compilers that generate
without anything to do with Java, per se)
So, in effect, the better Java is not a Java
language compiler at all; it's just one that
produces compatable bytecodes.
I believe that Cygnus stated their compiler will
accept
input.
If not, could someone with knowledge of this
please inform us of Cygnus' new path.
I pity you. Want MI, use Eiffel or other serious MI OOPL, not C++ which MI is crap, as well as most of C++'s OO.
yes or no?
There are those who like recursion, those who don't like ...
recursion, and those who think there are 3 kinds of people,
those who like recursion, those who don't
Sorry, it's been a long day.
How about facts? You've just spouted off a bunch of (pardon me) ignorant reasons for disliking C++ and one real one: that C++ is more complex. I don't think anybody will argue with that.
* You don't have to use streams for parsing input if you don't want to. You can still use scanf() et. al. Streams are very usefull for many things but if they aren't for what you're doing then don't use them.
* Try{} Catch{} like playing baseball? You're objecting to the word, "catch"? For all the writing you did, you certainly didn't do much thinking.
* "People are more likely to write more elegant code in C" One of the reasons OO programming is so successful (with those with the mental capacity to use it) is that it does allow you to write code more elegantly than non OO languages.
* "OO frame of mind rather than a logical frame of mind." Honestly, you're comments are so misinformed that I can't possibly belive you have any programming experience. At least I hope you don't, for everyone's sake.
It's funny that you mention how the two languages "feel" or your "feelings" about them and one of your main complaints is that C++ is not logical. I think it's you that is not logical.
Recall the statement:
To iterate is human
To recurse, devine
Personally I'm of the opinion that features with a valid use shouldn't be removed because of invalid uses. Depend on people knowing when to use them.
:(
i agree but, and this is the crux of my argument, the vast majority of ppl out there writing code do not know how to properly use the extra features like operator overloading.
as i said in mathmatical contexts operator overloading is natural but the problem is ppl tend to use operator overloading in everything and it leads to chaos. i have seen ppl using operator overloading with data strictures, database objects, and a whole number of other things where it is very inappropriate. i dont know why ppl do it, it could be inexperience, haste, novelty, but what ever the reason is, i do know that they do it often.
The idea is that gcj is just a front end to gcc. So, any architecture that gcc supports will be supported by gcj. Now go check the list of supported architectures and see if there is one which one doesn't have a gcc port. If you're concerned, mention it to Cygnus. If you are really concerned (as in "I'm about to lose $20,000,000.00 dollars because I don't have a compiler for my obscure platform") then you can hire Cygnus to port gcc for you. They will then donate the work you hired them for to the Free Software community. That's their business model. It's all about funding Free Software development. Very noble way to rake in some scratch! Drew
I won't comment on everything so said, but here are a few points:
C++ is a multi-paradigm language, not just an OO language. It supports generic programming in addition to OO programming, for example. Alexander Stepanov, godfather of generic-programming and the STL, HATES OO. But he still chose to use C++ to implement his Standard Template Library. Why? Because it supported templates and operator-orverloading, which he needed. He just ignored the OO stuff that he didn't need. If you look at the STL, you'll see that it has no virtual functions, minimal inheritance (mainly for convenience - the STL was originally implemented without inheritence, I think), and seperation between alogrithms and data -- not very OO at all! The point is that you can do this sort of thing in C++, while writing the STL in C would be extremely difficult and error prone, and impossible in Java (there have been attempts, by ObjectDesign I think and others, but they don't meet the STL's performance requirements -- which was one the main points of the STL). The STL is extremely logical.
Supporting multi-paradigms makes C++ big and complex, which is a bad thing, but it also makes it a favorite of experienced programmers who know how to handle the complexity and appreciate the diversity. C is like vi -- simple and basic (but still powerful). C is like emacs -- it can do everything and the kitchen sink (but C++ code can be as efficient as C code). They all serve different purposes. Kernels that work tend to be written in C (i.e. Linux), and complicated gui programs that work tend to be written in languages like C++, because the language offers tools for handling the complexity. Like public and private, so other developers can't stomp on your data. If you think this is just classroom stuff, look at big UI projects written in C -- they're probally buggy, with lots of unforseen interactions between the components, interactions which could have been elminated via data abstraction mechanisms like public and private. If E and Gnome were written in intellegent C++, they might actually work.
Also, the C++ streams library can do everything that C's stdio library can do. If you prefer stdio, that's fine, but it's just a preference. I still use sprintf() a lot, even when I could use sstream, for example. But that's just a preference on my part -- they do the same thing.
The nice thing about the streams library is that you can easily expand it to handle user defined types.
Steve Molitor
The idea is that gcj is just a front end to gcc. So, any architecture that gcc supports will be supported by gcj. Now go check the list of supported architectures and see which one doesn't have a gcc port. If you're concerned, mention it to Cygnus. If you are really concerned (as in "I'm about to lose $20,000,000.00 dollars because I don't have a compiler for my obscure platform") then you can hire Cygnus to port gcc for you. They will then donate the work you hired them for to the Free Software community. That's their business model. It's all about funding Free Software development. Very noble way to rake in some scratch! Drew
More interesting to me would be if I could use egcs to comile C to java bytecode. Does anyone know of any projects to compile other languages to the java virtual machine (besides Ada)?
Good one!
I get the impression that you've never heard of generic programming (as in STL).
TedC
TedC
I had a brief encounter with Java in a project that was canned by upper management. Mostly I'm an old C dog. :-)
Java has references which for all intents and purposes are pointers, but without all of the potential to be abused.
Java references are probably just the thing for applications programmeing, but they're not as general as pointers. I guess I think of references as implicitly dereferrenced pointers with certain restrictions; you can't perform pointer arithmatic on then, for example.
Maybe lack of pointers limits java's usefulness if you are writing device drivers, but other than that, why do you need pointers?
I was thinking of operating systems, device drivers, compilers, database systems (implementing them), etc.
TedC
Its only gcj's source parser that doesn't support 1.1 features. You can still compile your java 1.1 source to class files (using jikes or javac) and compile those to native code.
If the majority of people don't know how to use overloaded operators, then their code sucks and their programming skills are atrocious.
:)
i couldnt agree with you more, but the industry keeps sucking them up!
Don't however, take away a powerful tool like operator overloading just because there are idiots in the world.
but this is just what happens with everything. it only takes one bad apple to ruin a whole bunch and in this case we have quite a few more than one!
Clarity and cleanliness is so much easier to attain when code uses symbols to mean certain things.
well this is just meaningless, a.add(b) is just as symbolic as a = a + b, it just dosent use _mathematical_ symbols.
string1 + string2 is a straightforward concept.
is it really? i think it is only straightforward to you and me because we learned its meaning shortly after we started programming but ask a child who knows enough about math to be able to understand 3 + 5 = 8 and ask them what "abc + def = ". you might be suprised at the answer you get.
How would you conceive string1 - string2,
well maybe if string2 is a substring of string1 then you would remove string2 from string 1 but if it isnt a substring then it seems odd that the result would still be string1, but maybe.
or string1 / string2?
not sure about this one.
I can see string1 * int, but not string1 * string2.
maybe something akin to matrix multiplication but i'm not sure how usefull that would ever be.
Please email me with an answer to this, too.
and reveal my secret identity?!?
Oh my God! Why the hell would you want C compiled to byte code!!?!?!? That has to be the stupidist idea I've heard in a long, long time. This just proves my asertion that the Linux crowd is so biased towards C that unless a language is C they're not interested. Expand your horizons just a wee little bit won't you?
I get the impression that you've never heard of generic programming (as in STL).
of course i have heard of it, but what's your point? if you are implying that java dosent do generic programming then you are flat out wrong. the reason why c++ needs templates and java dosent is that java has a pervasive object heirarchy (every class is a subclass of Object) and c++ dosent. so c++ needs something to allow generic programming and templates were the answer. java was designed with generic programming in mind and didnt need it to be added after the fact because some ppl thought it would be a neat feature.
Er, IBM also have the same JDK ported to Win32.
Just download sockperf from http://alphaworks.ibm.com/ it has included the IBM JDK 1.1.7 for Win32
- Robert
answer: see recursion.
begin ...
I am forced to program in Delphi at work
to have to type a.add(b) instead of a+=b
would seem trivial to me at this point
those pascal people just love to type, type,
type
end.
depends on what you mean by "see"
TedC
That's because a large percentage of the Linux community is composed of CSci students who have a lot of opinions, but not much experience. Talking about programming is fun, even for people who don't know what the hell they're talking about. :-)
TedC
I don't have a problem with what Sun's done with Java. They needed to keep control of it to prevent someone like Microsoft proprietizing the language. Their goal was to make an operating system independent language and they have succeeded. Too bad it's been too slow for too long; but they knew that would be a problem going in. They figured that hardware would catch up. Java 2.0 is very clean and the Swing set is very malleable to suit your GUI needs. It's very easy to program; beginners can easily write a Browser Applet to do cute and useful things AND distribute runnable code to the world in a safe manner. Give it a try! Congrats so far to the javaheads at Sun.
I had to jump in on this.. I have written a commercial app in Java 2 doing lots of graphics2D stuff and international text etc. Having programmed in various laguages ( yes C++ too) and used various function/class libs etc... I have to say Java class libs have some of the cleanest design and (believe it or not) nicest documentation. The reason is simple... an xyz library usually has documentation coming from one source... the vendors and maybe a couple of books from independent authors... but Java not only has lots and lots of vendor docs ( Sun) but there are a huge number of excellent books out there. All that and the basic JDK is free ( + emacs ) and I don't need a fscking bloated/propeitary IDE... ( although JBuilder on NT is quite decent and I could use a windows debugger as nice as ddd). Yes the only platform with a decent Java2 implementation is NT ( I don't have solaris and linux one is not out of beta yet) but I have no doubt that every platform that matters WILL get only better and better JDK's over time. I think Java is a godsend for those whose projects don't demand blinding speed and who want a nice clean graphics/networking/i18n etc etc library with a lots of clear documentation....
Why do you assume that only the Java language
should target the JVM?
Use the right language for any task
using the least effort.
If only "C" had garbage collection.
Btw, the word logical was probably a bad choice of words. I was trying to refer to the opposite of OO programming
I believe the often used terminology would be functional vs object oriented languages.
Yo, I'm so there with you on this. With the release of KDE 1.1 and the Mandrake distribution, which integrates RedHat 5.2 and KDE 1.1 together, I've decided to adopt Linux as my java development platform. I used to be a solid NT 4 user, but now that Microsoft has thrown out the baby with the bathwater what with their apparent drop of Java support I've decided I need the features of Linux to continue to be productive. I have all sorts of NT developer tools like Rational Rose Java edition and JBuilder Pro, but I decided I don't really need them. The only thing I really need is a good modeller tool, and Together/J does that for me; since Together/J is 100% Pure Java, I can use it on my Linux box. However, there is no good IDE for Java on Linux; there is NetBeans, which is 100% Pure Java, but unlike Together/J NetBeans is as slow as my arse (Together/J rocks my world). If Symantec released their IDE for Java on Linux I would buy it IN A SECOND. IF YOUR OUT THERE SYMANTEC, I would to give you my money! Especially if they bundle some sort of native compiler with the IDE (TowerJ just doesn't do it for native compilation; I NEED native compilation of AWT and Swing interfaces, which TowerJ doesn't support). Let's start a campaign to tell Symantec that Java developers have been moving over to Linux! I know I have. Linux may not be completely ready as my grandma's desktop system, but it sure darn is ready as a graphical development workstation system (KDE 1.1 is beautiful - *great* job guys).
thanks,
Brad Neuberg
VP of Technology, BaseSystem Inc.
Yo, I'm so there with you on this. With the release of KDE 1.1 and the Mandrake distribution, which integrates RedHat 5.2 and KDE 1.1 together, I've decided to adopt Linux as my java development platform. I used to be a solid NT 4 user, but now that Microsoft has thrown out the baby with the bathwater what with their apparent drop of Java support I've decided I need the features of Linux to continue to be productive. I have all sorts of NT developer tools like Rational Rose Java edition and JBuilder Pro, but I decided I don't really need them. The only thing I really need is a good modeller tool, and Together/J does that for me; since Together/J is 100% Pure Java, I can use it on my Linux box. However, there is no good IDE for Java on Linux; there is NetBeans, which is 100% Pure Java, but unlike Together/J NetBeans is as slow as my arse (Together/J rocks my world). If Symantec released their IDE for Java on Linux I would buy it IN A SECOND. IF YOUR OUT THERE SYMANTEC, I would to give you my money! Especially if they bundle some sort of native compiler with the IDE (TowerJ just doesn't do it for native compilation; I NEED native compilation of AWT and Swing interfaces, which TowerJ doesn't support). Let's start a campaign to tell Symantec that Java developers have been moving over to Linux! I know I have. Linux may not be completely ready as my grandma's desktop system, but it sure darn is ready as a graphical development workstation system (KDE 1.1 is beautiful - *great* job guys).
thanks,
Brad Neuberg
VP of Technology, BaseSystem Inc.
Err, Java doesn't use pointers. It uses object references, but they're not really the same thing.
In general banning pointers from a language is a good thing (imho), as apart from for Systems programming, you don't need them, and they can cause all kinds of difficult to trace problems.
And it's a shame that Java-the-language is going to have to live down the reputation of being slow merely because it's coupled in everyone's minds to Java-the-virtual-machine, which is the (arguably inherently) slow part.
I think that happened to Pascal - the P-code to which UCSD Pascal compiled was slow, ergo, Pascal was slow.
Also, all functional programming languages have suffered because of the cost of GC - which used to be prohibitive.
http://www.freebuilder.org/
http://sunsite.auc.dk/jde/
What am I missing?
"Take, for example, a string class in C++. Many beginners will build a string from characters by concatenating each character to the end of the string (thestring += thechar). This resizes the string on every character added..."
Tell them to use reserve(). What I've found is that lots of people are being taught C++ by people who haven't taken the time to understand the language properly themselves, or who are long time C programmers, and are prejudiced against it anyway. C++ is a vastly better programming language than C, and I wouldn't choose C for any project where C++ was available - even if I was planning not to use classes.
PS: Prior experience with C is, if anything, a handicap to learning C++, especially is C is the only language the learner has previously used.
Nein, nein, nein!
People who call languages like C a "functional" programming language are doing so because they are misled by the confusing habit that C programmers have of calling their version of subroutines (or procedures) "functions". The proper term to use in describing C is "block-structured procedural language". (C++ is an "object-oriented procedural language".)
There is a separate category of functional programming languages which are very different from C. Such languages (examples are Haskell, Miranda) are modelled around the mathematical idea of a "function", so the code you write never has side effects and always has a return value. Functional languages are a subcategory of declarative languages (which include LISP and Prolog). Certain kinds of programming problems are solved much more elegantly in a functional style.
You can write in a functional style in C, but it requires discipline and a suitable support library. Care is needed, too, to avoid writing very inefficient code. In C++, there is a header that is designed to support programming in a functional style - it is not as cute as using a proper functional language, but it is a boon nonetheless.
It's not fair on C++ to call it simply an Object-Oriented procedural language. It is really a multi-paradigm language which supports procedural, OO and functional paradigms, as well as the generic programming paradigm. I happen to think this is the most important thing about C++.
I also think that templates are brilliant.
I certainly agree.
I learned C, then C++. (I'm skipping several other languages that aren't relevant). As a result, I wrote C++ in a certain way that was sort of a complicated C, or C with object wrappers.
Then, I went off for a while, worked in other languages, then learned Java, spent a long time with it, and then came back to C++. (For shrinkwrapped app development, Java wasn't there yet.)
Upon returning to C++, I found myself looking at it entirely differently from before. Java (plus a whole bunch of OO books that now made sense) had trained me to be a real OO programmer. (Eiffel or Smalltalk could have done likewise, perhaps even better.)
Fortunately, C++ itself hadn't stood still, and we had quite a few new features in what is now Standard C++ that allowed me to give up old C-isms. No more of the nonsense of char* pseudo-strings. Standard C++ let me start using first-class Unicode string objects. No more pointer arithmetic-based arrays. I now use vectors, except in the most performance-sensitive inner loops. I now actually design using real polymorphism, inheritance or composition as appropriate, etc.
No more using C++ as a more complicated C. Going from Java to C++ was a huge advantage over going from C to C++ (though now I can't believe that we still tolerate the stupidity of header files.) Now, C++ seems more like a full-featured, compiled Java to me, and I like it more than ever.
You only incur the overhead of a vtable if you want one. Java forces one on you whether you want it or not. Isn't that what the "final" identifier is for?
>Most projects in Java are probably Web Applets or similarly small stuff that is programmed by one person.
Bollocks. Most Java projects are not web applets. Most projects are probably either to do with Corba, Databases, or servlets. And in the bank I work for, the smallest project has three people working on it. Applets are pretty much a toy - the crap implementations of the JVM by Netscape and Microsoft saw to that.
>Personally I'm of the opinion that features with a valid use shouldn't be removed because of invalid uses. Depend on people knowing when to use them.
Yeah I used to think that. Then I got a job and had to maintain other people's crap code, where they had misused features. Operater overloading and multiple inheritence rapidly lead to unmaintainable code. Of course you plan to remain in academia, so noone will ever use the code you write anyway, so don't worry about it I guess.
Cian (lost me password, innae)
As a programmer with significant experience in OO and procedural programming, I love C++ and Perl. I think they are great tools. But I have learned to stay away from legacy commercial projects that are written in C++ and Perl, because the code in such projects tend to be basically unworkable.
C++ and Perl suffer from the same problem: they are too powerful. There are too many ways to solve a given problem. And in a project that hasn't benefitted from peer review, you'll often wind up with mixed programming styles (weird mixtures of bit-twiddling and OO in a C++ program) and a complete lack of design.
I would never use C++ or Perl in a bazaar-mode open source development project for exactly this reason. The skill level of potential contributors varies too widely. There are too many different programming styles. A C++/Perl bazaar-mode programming project would quickly turn to unmanagable sludge.
The prejudice of Linux programmers against C++ is not entirely unfounded. C++ and Perl are powerful tools. Too powerful, in fact, for the average coder.
Sorry, but you clearly don't get it. What generic programming gives you that OO a-la-java doesn't is the ability to write highly general code without losing compile-time type checking.
Generic programming is not just a hack or a slight improvement over the old text-oriented preprocessor, but a major new paradigm of programming as important as, or possibly more important than object orientation.
I've been thinking about this for sometime. It wouldn't be hard to add a preprocessor to Java for this. All you need is some form of syntax that is recognised by the preprocessor for both defining a template, and a form of syntax for instantiating a template. Then the preprocessor inserts the necessary casts/ throws up an error when an invalid cast is made.
Anyone interested in doing this as open source?
As an aside, what Java really needs is an open source repository, like the perl-mod libraries. That would really help the take up of the language.
Cian (lost my password. Yadda, yadda)
FTP your code (foo.c) to Linux and comment out ...
.gt. are html)
one line of code
#if 0
#include "windows.h"
#endif
(never mind the "'s ; slashdot will think
.lt. &
Now type
gcc foo.c
That's what Microsoft did to the language! It's not going anywhere soon.
FTP your code (foo.c) to Linux and comment out
...
.gt. are html)
one line of code
#if 0
#include "windows.h"
#endif
(never mind the "'s ; slashdot will think
.lt. &
Now type
gcc foo.c
That's what Microsoft did to the language! It's not going anywhere soon.
Why do you assume that only the Java language should target the JVM?
Uhhg, I didn't say that
Use the right language for any task using the least effort.
Ok, I agree with that and I don't have any problem with the idea of compiling other languages to byte code. I think it's a good idea for some languages. The problem is that when you've taken away the performance aspect of C (by using byte code) then you've taken away the primary reason for using C. C is "the right language" primarily because it is fast. When speed is no longer the primary consideration, there are much better languages to choose from. Java is by far a better language than C, and even C++ in many ways.
Do yourself a favor and try some Java coding. You'll never want to go back to C.
Did someone just steel your girlfriend, btw? You sound awfully hot tempered for someone ponding to a simple post on language choices that said that C++ is not the one true way
I am tired of clueless people that are too lazy to learn anything but C or think that the C language is the pinnacle of programming languages or just that it's "cool" to program in C. I never said that C++ was the one true way, BTW. I programmed in C for many years and switched to C++ as soon as it was available, because it (and OO languages in general) are better languages for many things. I've worked in CLOS and Scheme, Smalltalk and assembly. Its in any coder's best interest to learn different languages, doing so opens your mind to different ways of thinking about programming problems, and improves your coding ability in any language.
It's those pesky pointers. There's nothing quite like them in Java. Which happens to be one of Java's strong points. Making stupid pointer tricks impossible prevents a multitude of buffer overflow bugs.
It's a bummer about all that legacy code in C and C++ though. You'll need soem hard core AI to machine-translate that into Java.
I once fantasized about a superset of Java that would allow pointers, just so we could machine-translate C and C++ to this. But it would be kind of a Frankenstein's monster. The villagers might burn me at the stake for it, and I'm not sure I'd blame them.
Not so much of a pipe dream. My large Java app, which was developed on Windows and purchased by a Unix-based company (for $1.5M), worked on their Solaris systems on the _first_try_ with no problems.
Cross-platform Java isn't as tough as the press likes to make it out -- sure, you have to test it on every target platform, but cross-platform Java is easier to handle than single-platform Windows programming. I've never seen a Java program that works unless you have a Matrox Millenium in 16-bit color mode -- such problems are standard in Windows.
> Do yourself a favor and try some Java coding.
> You'll never want to go back to C.
Been there.
Done that.
I'm back.
Java does have its strong points. Me, thinking in C simply gives me less of a headache. And before someone starts yelling at me for being backward for liking to think in C, my next favorite language is Smalltalk.
I've felt the same thing from time to time. As a Java fan, I've got to say that NOW there is a much better base on which to diverge than there has been before ... Java 2 is a platform that's reasonably complete.
Divergence always happens, of course. The questions of relevance then include
There's more of course. I think Sun really does want Java (tm) to be too big for other companies to reverse engineer, and that's not part of what the Web is about.
This EGCS based compiler is indeed quite cool. I hope it can be made to use the JDK 1.2 runtime environment, so it really is just coolness instead of (exclusively) something to subvert mainstream Java, which is (like it or not) controlled by Sun. At least, for now and the next couple years.
There's been great promises for Java native compilation for years. Yet no one seems to be delivering -- with the exception of Tower Technologies.
The problem with all the native Java compilers seems to be the same. As a Java developer I am forced to give up features of Java should I want to compile them to native binaries (JIT not included). And these are important features I need to give up -- quite frankly, I would find it very unappealing to use Java without things like dynamic class loading or Java Foundation Classes.
So what if you don't need any those "nice" features of Java.. you can use native compilation then, right? Wrong. Unless you're willing to write your whole project from scratch by yourself. Java by its nature has excellent support for componentized programming/design and code reuse. So if I want to use a bean for example, from someone else, I'm forced to go look through their source code -- if it's even available -- to see if they use the features my Java-to-native-binary compiler doesn't do. Not very good.
So there doesn't seem to be alot of competition in Java native compilers. And it's starting to show. IBM already beats Tower's Java native binaries on Linux with their Java Virtual Machine + JIT compiler on OS/2. And others won't be too far behind. All the research, development, and competition is in the Virtual Machine and JIT space, and it shows.
Java native compilation today is not a good solution because of its restrictions. It hasn't been a good solution for the last 2 years it has been promised to bring Java to lighning speed. There doesn't seem to be a lot intentive to push this area to do great things. All the work is done in JVMs. So the only place I can see Java native compilation have use at the moment is the embedded space, where the memory resource pigs, JVM + JIT, cannot be accommodated.
Jay, without an account.
Judging by your e-mail address, you're a student, which probably explains your remarks, which sound like the voice of inexperience more than anything. And don't forget that the worst part of programming is not writing the code, but maintaining and changing it. That's where OO *can* really come into its own.
The fact is, that in the real world, most problems do break easily into an OO framework. I work in a financial instituation, and we deal, not with data or algorithms, but objects. Decent OO analysis of a problem (rare, but it can happen), can lead to a problem being broken down into its logical components, leading to code that it is clean, loosely couple and (this is crucial) easily modifiable. In a well designed system, code should know as little about other parts of the system as possible. This is far easier to achieve using an OO language.
I'm not desperately fond of C++ myself (though for different reasons to the ones you cited), however I *do* think that OO programming was a massive step forward. Unfortunately for OO, a lot of programmers who came across OO, concentrated on the inheritence aspects of it, rather than the componentisation aspects of it. Inheritence is responsible for spaghetti code that makes one long for GOTOs everywhere. If you want to see good examples of OO thinking, read the Design Patterns book
Streaming is a good thing. Not only does it give one some very elegent tools for filtering, but it allows a high degree of abstraction, that simply isn't possible with printf. In fact the way it works, is very similar to the way that the TCP/IP protocol stacks are designed. You can change one layer, without affecting the layer to levels above.
Proper error handling without try and catch is almost impossible. Return values really don't cut it. Fine if you wrote all the code yourself, but what happens when you start using other people's code? What if their code doesn't handle errors properly? What if the best place to deal with an error is several layers down the stack (this might be true with a file exception, for example, as this might require some form of rollback).
Private, protected and public keywords are essential in a large programming environment. They're not enough, mind. What C++ (and Java) really lack are contracts. What you are doing is designing by interface, and in effect saying to other programmers, these are the bits you can rely on, other bits may change. So this gives you flexibility to modify your code, knowing that you won't break other's code, because this is enforced by the language.
It's arguable as to whether C code is faster than C++ code with modern compiler optimisations. A lot of the optimisations that C programmers make in their code, can in fact make the optimiser's job impossible, leading to inefficient code.
There's nothing that one can do in any language, that you can't do in another. Does that mean we should all still be using assembly?
One can do all these things in C, but C++ makes one's job far easier, making one far more productive, and able to concentrate on the things that matter
Cian (who's lost his password)
Sun should have done something like this a long time ago instead of using the lame Java Virtual Machine. The whole concept of a VM is what made Java so unappealing to everyone. The only unfortunate thing about this is that it's taken a third party to figure this out... Ah well, this is a good thing - it puts Java back in it's proper place, being a LANGUAGE, not a language+virtual computer+bytecode+windowing systems (AWT, Swing), etc...
-- Dave
I totally agree...I've been looking for a good IDE for a long long time (syntax highlighting, build/compile options, debugging features)similar to Cafe. Anyone know of a good IDE for linux?
-xyster
It is very much easier to get a decent hang of C than to learn all the different rules for C++. While pointers might be a bit hard the first time, it is nothing compared to obscure rules for virtual base classes and whatnot. It is much easier to get lost in C++.
C has the nice property that, basically, the computer does what you tell it to do - line for line. (After all, the saying is that C is merely a portable assembler). This makes it much easier to debug for the beginner. If you cannot even quite figure out which function gets called (and in C++, it is not that clear with overloading and polymorphism), you are not being very productive.
So, for hobby programmers (which the Linux community mostly is), there is not much reason to initially go to the trouble of learning C++, or Java. I guess that is much of the reason why C is used as much even though C++/Java are generally believed to be better tools (in that you are free to use what you do not like of them, and C is mostly contained inside both of these languages). And once you are stuck in C, learning another similar, but harder, language is NOT easy.
--
I am trying to learn C++ myself but I find that I usually end up wrapping mostly pure C code into some classes. I do not take advantage of the many useful parts of C++, and that bothers me.
However, C++ does have a whole lot of different things and getting used to them will require some time. Sure, concept by concept, it is probably rather easy to learn, but one has a long way to go before he is reasonably comfortable with the majority of C++.
For a newcomer to programming, I believe all the different concepts will be confusing. C, while simple, is very small and as a programmer you use most of it all the time; therefore you get very used to it and make fewer mistakes.
I am not arguing that C++ is a bad language, only that it takes time to learn and without proper guidance you are likely to get lost.
--
You may be right with regard to the different learning techniques, of course!
Yes, I recall people having great difficulties understanding the concepts of recursion when we were taught programming (SML) in first year of University.
Also, pointers seem to be a great problem until you figure out just what they are about. Then they are easy and powerful (though a bit error prone).
I actually quite dislike Java for using pointers almost all the way but never telling programmers about it. I think that is likely to create a bit of confusion. In C(++) you at least know when you are getting into the area.
--
When I do
:-).
MyObject a, b;
a.value = 1;
b = a;
a.value = 2;
and suddenly b.value == 2, I feel that a and b are indeed pointers. The actual term might be different, I do not know, but indeed they work rather like pointers. If not, touching a.value should not change the value of b.value
This is why I think that it might be a bit confusing. If you have to say *a you will at least realize that you are dealing with a pointer and there might be other pointers pointing at the same memory. I guess...
Then again, I never did much Java, so perhaps I should just start shutting up
--
Is "1" + "2" == "3" or "1" + "2" == "12" ?
I have seen in some commercial toolkits (like e.g. ObjectStore) that every kind of operator (including the comma, makes nice method invocations) is overloaded. This makes code simply ugly!
I can use dynamic loading of classes in an Objective-C application that is as native as possible (the dynamic classes reside in a shared library, the main classes in the app). Why won't that be able then in a compiled Java app?
This is not a Just-In-Time compiler. The goal of the project is to produce a complete development tool set for compiling Java to native code just like you compile C to native code. I'm guessing Cygnus probably plans to market this to the embedded systems market as well as to the free software community.
Well, there are several problems with C++ IMHO, but the main problem is that it's much much easier to write inefficient code in it. Sure, it's possible for there to be both efficient C code and efficient C++ code, but it's much harder to write *really* inefficient C code. That's why I think starting out beginners with C is a good thing.
Take, for example, a string class in C++. Many beginners will build a string from characters by concatenating each character to the end of the string (thestring += thechar). This resizes the string on every character added, as a new array is created (1 char bigger), the old data is copied over, and the old char array is deleted - all internally and automatically by the string class. Sure, this is really easy, and that's the problem - the beginner doesn't realize how much inefficiency is going on behind his back.
Doing the same thing in C leads to much less temptation to be inefficient. A C programmer would not follow the above example because it'd be a pain to keep resizing your char arrays (keep malloc()'ing new arrays and free()'ing old ones). Therefore, the C programmer would be forced to do use the more efficient method of deciding the array size before hand, then just putting the characters into it.
Sure, this is a fairly trivial example, but there's lots more of similar cases. I'm not saying it's not possible to write great, small, fast, C++ code, it's just that it's a lot easier to write big, bloated, slow code in C++ than it is in C.
So even though C++ is easier in many respects for beginners (the compiler automatically takes care of reference parameters, automatically determines the data types for outputting and inputting to/from the console, etc.), I still think it's a good idea to learn C first, to understand how things really work, and then to learn C++. Of course, most schools don't agree with me. Oh well.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
I like the IDE of Borland Turbo C/C++. It's a nice textmode interface with great syntax highlighting, quite customizable, and every menu command is mapped to the keyboard for those of us mouse-haters. Sure it's for DOS, and a bit dated (1992), but I still haven't found anything nearly as good. Graphical IDEs just don't sit well with me for some reason...editing text in 800x600 just seems wrong; editing text in 80x50 textmode is much nicer.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Are schools starting people out with C++? I came to my first Comp Sci class with C under my belt, but was forced to learn Pascal.
Well, in colleges, it really depends...I know of several colleges that start out with C, and several that jump straight into C++. Thanks to the AP board, all high schools now start with C++, since the AP test covers C++ (it switched from Pascal to C++ this year).
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Tell them to use reserve(). What I've found is that lots of people are being taught C++ by people who haven't taken the time to understand the language properly themselves, or who are long time C programmers, and are prejudiced against it anyway. C++ is a vastly better programming language than C, and I wouldn't choose C for any project where C++ was available - even if I was planning not to use classes.
Oh, sure they can go use reserve() or one of the many other ways to optimize things like this. The problem is that you don't have to, and a beginner will typically not do things that they don't need to do to get their program working, if they even know those things exist at all. A C beginner will most certainly do things the correct way, simply because they're forced to - it's easier to do things correctly than to do weird things like resize arrays constantly.
As for which language to use when you're not using classes, it depends largely on personal preference I suppose. Several of C++'s C++-as-a-better-C features are nice (such as being able to declare variables just about anywhere), but I prefer using real arrays (what the computer science books call "C-style arrays") rather than range-checked vector/matrix classes.
PS: Prior experience with C is, if anything, a handicap to learning C++, especially is C is the only language the learner has previously used.
I disagree - knowing what is going on internally is always a good idea. If you know how a vector or a string or some other class works internally (and the internals of classes often are very similar to straight C code), you know more about what things to do to more efficiently use the class.
In fact, having a basic idea of computer internals and assembly language is a good idea, IMHO. Extensive programming in assembly or knowledge of minute details of hardware is not necessary, but having a basic idea of how everything works low-level is a good idea. More knowledge rarely hurts.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Yeah, I was under the impression that gcc, cc and egcs just compiled C and C++. All the frontends do is just translate the original source language like objectiveC, Fortran, Pascal, Ada, Modula-*, Java etc... into optimized C then invokes the C compiler. Just like you have to have the devel and binary libraries for additional funtionality like GTK, libMesa, and ncurses, you have a Java library that provides the same thing.
This could mean that Linux is going to supercede Windows when it comes to Java support.
Codifex Maximus ~ In search of... a shorter sig.
If Java were a bytecode and a JIT, its point could be "write once, run anywhere".
But Java's not JUST a bytecode, it's a language and a class library also. Why? Doing "write once, run anywhere" this way is more than the simplest possible solution, which makes it Too Much.
Why not just write passthroughs to the existing C library? Then the only remaining thing would be a simple windowing API; implementing that would be relative simplicity (particularly if it were open, or based on an existing cross-platform windowing API). There are plenty of other ways of doing it other than making it a Big Bloated Mess.
Posted by FascDot Killed My Previous Use:
Has Cygnus also simplified their C++ compiler to get rid of all that class stuff?
Hello! VM's are what Java is all about! If you get rid of the VM, what's the advantage of Java? Buzzword compliance?
Posted by alanx:
Not me, but I'm willing to be convinced.
Send me a URL, recommend a book, anything... I'm not a fan of inner classes, probably only because I haven't seen their usefullness.
Please, explain...
Posted by alanx:
///
Ok, I was exaggerating a bit, I've actually seen inner classes used twice before in one interesting manner. (Once on the patterns mail list, and later at a client) Essentially, it was used as a sort of inverted proxy pattern.
So you have this sort of doWith operation.
class With
{
public static void doWith(SomethingToBeDoneWith s);
doSomethingInteresting();
try
{
s.doSomethingSpecific();
}
catch (Exception e)
{
}
finally
{
endSomethingInteresting();
}
}
where SomethingToBeDoneWith was implemented with an inner class.
Thanks for the feedback.
alan
Thank god!
You say this because you have chosen Definition #3 of what the word "Java" means ("a virtual machine") and ignored the other equally true definitions.
Java is also a language. It is a good language. I would like to write programs in it.
Virtual machines are cool. Security models that allow network-distributed code are cool. Serialization and agent-like behavior is also cool.
But these are not what I'm most interested in. There are a lot of people who are most interested in those things, but me, I just want to write a program that will run on some suitable number of architectures. I'm happy distributing binaries for each architecture to do that. Sure, having one binary that ran on everything would be nice, but you know, it's just not a hard requirement.
Today, I program in C.
I think C is a pretty crummy language. I would like to write the same kinds of programs in a better language.
I would like that language to be Java.
It's just that simple, and that's why this is great news.
The reason I like Java is because it's a language that both supports implicit storage management well (meaning, at the language level) and because it provides good tools for programming in an object oriented style.
Note that there is no such thing as an ``object oriented language.'' You can write code that looks like assembler in Java too, if you want. Java is cool because it makes sensible style easy.
Unlike, for example, C++.
C is a fairly crummy language, but the reason is that C is basically a set of macros on top of PDP-10 assembler, and who wants to hack in assembler? That abomination we know as C++ is a set of macros on top of C that try to bring it kicking and screaming into the early 80s, and the end result is, well, object-oriented assembler.
Not to mention that while both K&R C and ANSI C have proven to be extremely portable, C++ has proven to be anything but.
But the main problem with C++ is that it has poisoned so many young minds.
There is a whole generation of programmers who think that these broken, rusty tools that C++ provides have anything to do with an object-oriented programming style! They don't even think to question that C++ has a difference between ``virtual'' and ``non-virtual'' functions: as if a real language would have any other kind!
When I program in an object-oriented style, I do it in C, because C is a better language for writing object-oriented programs (in fact, any programs) than C++.
If you made it this far without gagging, then probably the C++ worms haven't eaten in to your brain yet, and you should go grab yourself a copy of Structure and Interpretation of Computer Programs, and learn what object oriented programming is actually all about. (If you're interested, you can read a mini-review of it I wrote at mozillazine.org.)
Java-the-language is not without its faults, but it's so much better than C or C++ it's not even funny. Yeah, I'd rather use CLOS, but that's just not even remotely practical any more.
This is true of most (all?) Lisp dialects as well. Nothing new here.
What exactly did Microsoft do to C++?
I'm familiar with Sun's arguments that they need to hold tight control over Java because of the threat from big-bad-bully Microsoft. I just think their arguments are nonsense. Believe it or not, competition is a good thing. Sun is locking everyone out of inovating in the Java space, because they see it as being better that nobody be able to do anything new than Microsoft be able to do it first.
I'm no fan of Microsoft, obviously, but this is throwing out the baby with the bathwater.
If Microsoft invents a variant of the Java language that's better than the one Sun invented, more power to them. If it's better, I'll use their dialect instead of Sun's, and so will others, and the state of the art will have been thereby improved.
Would you like it if the FSF had been legally forbidden from extending the ANSI C language as they have?
Of course you can, you just need to check version numbers. Users and implementors of shared libraries do this all the time. Good programmers provide backward-compatible interfaces when they make improvements, to keep legacy code running.
And Java 1.0 and Java 2.0 are not the same language, you know.
We do. Dramatically so, in the case of C. And yet, the world muddles along, and portable programs still get written.
This is true of any high-level language, really. This is something we learned well in the Lisp world: the barrier to entry for high-level languages like Lisp is so low, and for low-level languages like C is so high, that by the time a C programmer gets their program to even compile, they've already had to jump through so many hoops that they probably know a fair amount about what's going on.
It's easier for a bad programmer to get something done in a high-level language than it is for them to get something done in a low-level language.
Does that mean low-level languages are better, or that they encourage better programming? No, you just see fewer but better programs, because they take longer to write and exclude people who aren't really good at programming from even participating.
It's a shame when a language gets a reputation for being slow or bloated as a result of people having seen bad programs from bad programmers, whereas assemblers like C get a reputation for being efficient because you have to be a serious guru before you can get anything done at all.
And it's a shame that Java-the-language is going to have to live down the reputation of being slow merely because it's coupled in everyone's minds to Java-the-virtual-machine, which is the (arguably inherently) slow part.
All that said, I think it's easier for novices to write good (and portable) programs in Java than in C++ because Java leaves less land-mines scattered around. With C++, there are just so many parts of the language that you simply must not go near if you want the end result to be portable or efficient. Java is much more straightforward in this respect, by virtue of being significantly less complex.
If you were listening all those times, you would have heard me saying that I love programming in Java, I think it's a great language, and it's too bad that it's just not yet practical to write and deploy real end-user programs in it.
Having a Java front-end for a real native code compiler is a great thing, and an important first step. Once there's a corresponding complete Java runtime library (like the classpath.org folks are working on) then Java will be on equal footing with C.
But not until.
I'm looking forward to that day, because I really do think Java is a much better language than C or C++. My objections to it have always been that it's just not ready yet. I want to use it, but I can't.
What FUD? You're confusing "FUD" with "facts."
I think it's a damned shame how much Sun screwed this up. Java could have been genuinely useful years ago if they hadn't tried to maintain control so tightly, and hadn't tried to conflate so many completely different things (a language, an enormous class library, a virtual machine, and a security model) under one name.
yeah, there's one called XEmacs...
it does... well, everything. From inside it I can...
0) read Web Tools Review
1) check email
2) autorespond to email
3) compile stuff
4) debug stuff in DDD
5) check stuff out of/into CVS, and
6) play Tetris.
what else would you use a computer for?
it takes some getting used to, however. (XEmacs)
Remember that what's inside of you doesn't matter because nobody can see it.
>Java lacks templates and overloaded operators, which makes it a fairly useless language for generic programming.
Note that there is a Generic Java spec as well as the Pizza effort that add templates to Java. I don't know if this stuff can be hooked into the egcs system easily, but if it is, one of your (and my) two complaints would be gone.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Because Sun knows that the best part about Java is that you can load classes into a running program. That cannot be done with a compiled version of Java.
While I think this is all good news for the java
community, and as long as careful consideration is
given to these system-dependant binaries, this
still isn't going to be fully acceptable for
all java users. One of the things this can't
do is the dynamic loading of classes, which is
very much necessary for doing anything along
the lines of plugins (Yes, I've programmed a
java plugin routine for a program that's sitting
on the back burner. The language has it all).
I doubt this will be a setback for very long;
I'm sure that someone will discover a way to
still dynamically load code with this compiler
with the help of native functions or such.
However, the VM will still have it's place (and
once Sun and others push the speed up in it,
then Java will provide the serious blow it needs
to deliever to a certain Redmond-based company).
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
If you want an IDE with syntax higlighting I recommend that you try XEmacs (or GNU Emacs). Hairy syntax highlighting, automatic configurable code layout, RCS/CVS revision control, diff/merge interface, tags searching, compiler interface, debugger interface, it's all there. When you cone to write documentation it's the best tool there is (even Neal Stephenson says so, so this must be true). It's got a vi emulation mode if your fingers are wired to the hjkl keys. M-x 1000 praise-emacs! Flames to alt.religion.emacs.
--
W.A.S.T.E.
W.A.S.T.E.
Java is also a language. It is a good language. I would like to write programs in it. this was the argument used by many to justify microsoft's Win32 specific extensions :0)
Actually, there are two Java related projects for egcs. The first is to add a Java frontend to the compiler. The second is to add a JVM backend to the compiler.
If done right, this means:
1) Java-the language will no longer be restricted to JVM, but can produce code for _any_ of the egcs backend.
2) You will be able to use _any_ of the egcs frontends for producing code to the JVM backend.
What Cygnus is doing is simply to create a Java system, without the restrictions of a single backend (virtual) machine or a single frontend language.
Making a native Java compiler may help speeding up the pace of application development. The drawback is that you loose the lovely cross platform ability you get with Java. If you don't use the platform it has been compiled for, you're screwed. Most of us will probably release our Java code GPL:ed or something similar, and this will not make a problem out of it. Unfortunately a few others won't GPL their work, and only compiles native code for a specific system.
To a small degree, this may slow the JVM development pace down since many people will run the native compiled code. I work with varying OS:es and hardware, from OS/2 and NT on regular PC:s and Solaris on Ultra5:s. If I can make an application run on each of those platforms without rewriting the code, thinking of MSB / LSB issues and some other not-so-funny stuff, it would be lovely. This is the issue with Java, besides having a clean and efficient language. If Cygnus had released a JVM with the same performance as IBM:s JDK 1.1.7 for OS/2, I would have cheered and danced naked on the streets.
War is one of the most horrible things a human can be exposed to. And one of the worlds largest industries.
I wish people abstained from posting comments claiming "X it's finally here!" when X is not even in alpha. A better heading would be "X is looking for volunteers to complete it!" or something of that sort.
E
http://eugeneciurana.com | http://ciurana.eu
vim, http://www.vim.org sort of a cross b/w a better 'vi' and smaller 'emacs' available on almost any platform u choose.
peterrenshaw ~ Another Scrappy Startup
The gnu 2.x compiler (and thus egcs) can use different front ends, until recently only C, C++, Objective C and Fortran 77. These frontends share the same intermediate optimzations and backends/code generators.
egcs has also frontends for chill and java.
A front end does nothing more than translating the source language, here java, into object code. So you need quite a lot of supporting libraries (startup code, Java system libraries, eg. for graphics). That is what libgcj will be.
It is big step, but still have a long way to go. Learning Java means learning the Java language (that is kind of a cut down C++) and becoming aquainted to the large libraries for graphics and other stuff. The latter taking most of the time IMHO.
I read some nice argument why JIT compilers are a bad idea, but I don't remember why exactly and where I read it - likely it was here on Slashdot.
I know, see my above posting. The question about the JIT came up at my work today and I just hoped to get it answered here, where some Java Slashdotters are likely to show up.
Last time I looked, gcj compiled from bytecode, rather than source, so I can't see that you loose any cross-platform compatability.
It actually does both, as well as source->bytecode.
On the other hand TowerJ suports dynamically loaded classes. Does the Cygnus compiler?
...richie - It is a good day to code.
Yah, what you are saying is valid and true in a sense but I'd estimate I've written approximately 100 to 200 thousand lines of java (at least) in my time and the number of times I've actually encountered the ClassCastException you describe would have to be less than 5. I don't tend to create a Vector (say) and pass it around to every class under the sun and just hope they don't add a Dog object to my Vector of Windows. I'm not saying templates aren't cool/useful (I do a *lot* of c++ programming too and I like it a lot) it is just that this argument smacks of "because of x the result must be y" while ignoring that in practice the real outcomes is "despite x, very rarely y".
there are two kinds of people in this world - those who divide people into two groups and those who don't
Agreed, I certainly didn't mean to cast aspersions at your point in general - it is a good one. It is always the classic struggle isn't it? Compile time safety vs. flexibility with dynamic typing. Personally I love the flexibility that java/smalltalke/etc. give you but in practice deferring that many potential errors to runtime can certainly cause you a lot of grief. A (possibly) interesting observation about c++'s templates - they actually provide a new type of inheritance in a way, the allow you to plug in any class that has the acceptable methods (the ones you call in the template) without requiring that those classes actually inherit from a common base class. I suppose my final word on the whole deal is that with c++ (with possibly much pain) you can create OO, shippable, speedy software today - java definitely gives you the OO but the speed is sadly just unacceptable for a large percentage of programming projects.
there are two kinds of people in this world - those who divide people into two groups and those who don't
You're asking the wrong question. The question you should be asking is "What language should I learn next?"
To be a great programmer you have to be able to pick the right language for the job. This means knowing C, Bourne Shell, Perl and Makefile, certainly. It probably also means knowing C++, Python, Lex, Yacc. Maybe SQL for certain kinds of applications. Awk, Scheme, Lisp for extra credit. You'll frequently end up using several of these in a single project. This is not an exhaustive list of useful languages. See Jon Bentley's books Programming Pearls and More Programming Pearls as well as Kernighan and Pike's The Practice of Programming for more discussion of these issues.
For example, the project I'm working on at work uses C, C++, SQL, and Bourne shell directly. Also Awk on the side.
You've completely missed the point of exceptions. In the real world, many bugs are in the end tracked down to poor checking of return values. For programs with significant amounts of external interaction, error-handling code can take up as much as 50 percent of the program.
Exceptions can provide a way to do this in a way that will ensure that all those errors are caught, and can be recovered from at the appropriate level. They're not always appropriate, but they can be extremely valuable.
These are features that are essential for very large projects. They also turn out to be useful for small ones too, particularly if you propose to re-use your code. IMHO if you can't see the point of hiding the implementation of an object from its user while still exposing its interface, you haven't grasped one of the funamentals of object-oriented design.blockquote Anyhow, I haven't seen any really good reasons for prefering one language over the other.
There aren't any. There is no single "better" language. It all depends on the application. For any given application, the "best" language mught be C++. It mught be C. It might be Perl, Awk, Yacc/Lex, Lisp, Python, or something else.
Sure, and therte is nothing that you can do in Perl that you can't do in C, either. It's just more time-consuming to do it in C. The reverse can also be true, too.
I'm still waiting for the day I can buy a product off the shelf and the install procedure converts it from Java bytecode into my machine/OS code. The company benefits from having to develop only one product, while the consumer still gets all the speed benefits.
Of course, OpenSource would be even better.
Is that it takes three ideas (a pure OOP language, a portable virtual machine & byte code specification, and a nice GUI library) with lots of promise, then it locks those ideas irrevocably together. If developers could compile to native code, link to existing object files, etc. Java would have a lot broader usefulness. Good job, Cygnus.
No. What it does is use the types of all arguments to a function to determine which version of the function to call, and not just one.
To illustrate with an example: In single-dispatch languages such as Java and C++ (to name the two most relevant to this thread), method calls look like this: obj.foo(arg1, arg2, arg3), where obj is an instance of some class. The version of method foo() that gets invoked depends on what class obj belongs to.
In Dylan, method calls can use the above syntax, but they're really treated as if they use the alternate form foo(obj, arg1, arg2, arg3). Here, nothing is special in particular about the first argument, rather, the types of all arguments to foo() are used to determine which version to run.
What this means is that you can specialize a function based on more than a single argument. In single dispatch languages, you can only specialize functions based on a single type tree. That limitation doesn't apply to multiple dispatch, where function calls are specified by the types of all arguments. In fact, Dylan's singleton types allow you to even specialize functions on particular instances of a type!
The ideal is that Dylan compilers are able to determine the real types of all arguments at compile-time, which would make multiple dispatch calls no more expensive at runtime than a static dispatch call in C. If the types can't be accurately determined by the compiler, then it's usually the same as a dynamic dispatch call in a single dispatch language such as Smalltalk or Objective-C. Of course, this makes Dylan compilers rather difficult to write.
For more information on Dylan, I recommend checking out Gwydion Dylan, a free software project to create working Dylan tools.
Colin
On the other hand TowerJ suports dynamically loaded classes. Does the Cygnus compiler?
Not yet. It is planned.
I did. I was pointing out operator overloading is in regular use and is not confusing in that use, so claiming it's always too confusing to be worth it is wrong.
a = a + b; with a.add(b);
You misunderstood. a = a + b; means a = a.add(b);
Oh, I guess mathematical notion is less likely to be misunderstood, eh?
try something a little more difficult where a and b are nontrivial
data structures and
a += b;
is certainly not as clear as
a.append(b); (for lists, arrays, etc...)
a.insert(b); (for trees, maps, etc...)
Anything can be nonclear when abused. Operator notion is not appropriate here.
As for projects, two points:
I never have plans for leaving college. Working on research projects as a professor is my plan.
Most projects in Java are probably Web Applets or similarly small stuff that is programmed by one person.
only when a and b are numbers. when dealing with objects of a higher level of complexity then it can become very ambiguous.
Not of a higher level, of a type where operator notion is unclear. a+b is clearly defined for vectors, matrices, all types of numbers, strings, ect. It's appropriate and clearer to use them here, so they should be available.
Personally I'm of the opinion that features with a valid use shouldn't be removed because of invalid uses. Depend on people knowing when to use them.
Templates in C++ are primarily a way to provide container classes. It's true that Java can do container classes without templates, but it doesn't do them in a type-safe way, and it's not quite as efficent as true templates are.
Interesting. I've never seen a C programmer confused over operator overloading. Would you argue that C should replace a + b with addi(a,b), addl(a,b), and addd(a,b)?
That may seem strawman, but it's the point. When dealing with mathematical structures on which + is defined (complex, hypercomplex, vectors, etc.) it's clearer to use the mathematical symbol.
it may seem like an inocent easy shortcut when you are the only person working on a small program
It is. It expresses the problem in terms I can understand, and makes it simpler for me to program it.
but what about when you are one of 8 ppl working on a large project?
I don't care. I have plans to avoid those things forever. Many people writing in Java are writing one person programs, and they should be catered to as much as the large projects. Anyway, in a large project you need naming standards and others, so just add no overloading on to the list.
operator overloading is just to ambiguous to rely on.
1. It's much clearer to say a + b (where a & b are complex numbers) than it is to say a.add(b).
2. As someone else pointed out, virtual functions and overloading can make it pretty hard to figure out what a function's from anyway. Translate a + b to a.operator+(b) and look it up like you normally would.
To a real OO programmer, multiple inheritance separates the Javas and ObjC's of the world from the C++'s of the world. C++ is simply superior for this reason. =)
I'm serious in concept, but joking in tone. Java has it's place, too. ("I sort glass. Don't throw me away.")
--
Kyle R. Rose, MIT LCS
[ home ]
So yes, anything programmable can be programmed using GOTO, IF and arithamatic (or just assembly language). But just because it can be done doesn't mean it's a good idea.
Host your own websites, anywhere!
Yes.
(RTFM)
Those who think Open Source is now a misnomer
and want to call it "viewable source" should
look at the name SourceWare.
Incidentally, Cygnus is a good example of how
to make money from free software.
Unfortunately, there is no AWT support for GJC. Without AWT support, there surely won't be any GTK AWT plaf (pluggable look and feel).
This is a nice solution for server-side java. However, for client-side java, we're still stuck with slow, JIT compiled (or, worse, interpreted) Java.
Anyone know if this circumvents Java's array bounds checking? I suspect it doesn't. When using a good JIT, this is the biggest impediment to fast Java (at least with my code).
Hey, Java is a great programming language. However, until you can turn of bounds checking, and compile code with a GUI, it will remain slow.
W
--Be human.
Why use Java? Because most people I know are about 4-5x more productive when programming in Java, relative to C++. It's a better designed language.
Yes, it falls down on speed issues. That will change, though.
--Be human.
Boy, it appears as though this author has never programmed in Java before. If you need multiple inheritance, your design is flawed. If you need templates, look at the Generic Java page:
http://wwwipd.ira.uka.de/~pizza/gj/
Templates save some time typing, but that's about it.
Templates and multiple inheritance can be implemented well. However, using these usually ends up in difficult to read, and thus difficult to maintain, code.
A computer language should be set up to facilitate writing code. If "arbitrary" rules are set up within the language such that the resulting code can be written quicker, and is easier to maintain, then that language is not necessarily inferior.
When it comes down to it, all a language needs are basic boolean and arithmetic operators, jumps (gotos, loops, etc), and conditionals (if/then). I believe this was even logically proven (my computer logic courses are too distant now). Java allows for all these. Thus, literally any program that can be written, can be written in a language that supports these features.
That said, I recommend that this author try programming something non-trivial in Java. I have. I've written about 30,000 lines of Java code, as part of a project that sits at about 120,000 lines of code. Java has made this project go several times faster than it would have had it been developed in C++. Some of this is due to the Java architecture. A lot of it has to do with the rich set of built-in packages. Porting is as simple as copying the post-compiled code from machine to machine (it didn't use to be that way, but Java has improved since then).
All I'm saying is that you shouldn't harsh on Java without giving it a chance. Otherwise, you're simply spreading FUD. This is no different than the Micros~1 weenies saying that Linux sucks, since Linux has no support.
--Be human.
Actually, I'm pretty sure there exist both Ada and Modula-3 frontends for gcc as well.
Also, I'm not totally sure of this, but I think the frontend just translates the input language into an intermediate language. That's then optimized, and passed to the backend, which generates the object code. That's why gcc can compile to so many different architectures.
Also, saying Java is a "cut down C++" is somewhat misleading. Java does, as first glance, look like C++ with all of the bad stuff taken out. It does have some significant differences though. The semantics are different, and garbage collection leads to a diffrent style of programming. Being able to dynamically load classes is nice too...
The number of times I've actually encountered the ClassCastException you describe would have to be less than 5. I don't tend to create a Vector (say) and pass it around to every class under the sun and just hope they don't add a Dog object to my Vector of Windows.
Yes, and that's the problem. There are a lot of situations where a Vector is the appropriate structure to use, but you use an array instead because you don't want to lose type safety (and obfuscate the code with a zillion casts). Proper generic containers would be a lot more useful. I often wish Java had them. (No, don't bother mentioning Pizza/GJ; they're unusable for me because they compile to bytecode, not standard Java, so I can't use my choice of compiler.)
Alan
who has written around 25k lines of Java, and has never used C++.
Nice idea, competition, but Sun's goal is write once, run anywhere. How well it works is open to dispute, but you can't have WORA if their are different versions. Why not let's have different versions of C, tcl/tk, perl, etc?
--
Infuriate left and right
I agree overloaded operators are easier to use, and it makes Java very verobose (as well as increasing the inelegant distinction between objects and primtive types).
The problem with operator overloading is that in long peices of code, it makes it hard to work out what is really going on - you cannot tell whether a + b is just an integer addition or some function call, and then you do not know whether it has the properties you would expect of +.
I remember one peice of C++ code that redefined + to perform some operation with a a side effect. You wouldn't believe how long it took me to find the bugs in that (someone else wrote it, I should stress).
Write Once Run Anywhere requires a platform for application development, and that requires a class library. With a compiler and a VM you can calculate fibonacci sequences or find GCDs, but thats no use at all without IO libraries. This is exactly the same philosophy that makes C portable.
Stroustrup criticised Java for lack of portability ? Now there is a man with a sense of humor.
I would prefer Java to support generics as well - all that casting makes my fingers ache - but I want them to do it properly. C++ templates have several problems - they do not perform up-front checks on the parameters, and there is no way to constrain the types of the parameters. This makes them a pain to use. There is also no way to use them as proper generic types (ie if T is a template you cannot say x is of type T without giving all the type parameters as well, and even then T does not include T).
I prefer the Java situation (whose worst consequence is sore fingers) to the situation with C++.
It's not quite there (no Java 1.1 support) but this is a huge step in the right direction. Once again I feel vindicated in forgetting all the C++ I ever learned.
I just hope that this doesn't lead to java forking. It's already started (CommAPI for instance) and architecture-dependent java variants could really screw up the big opportunity for architecture-independent programming.
Kudos to Cygnus!
Thanks to some changes that were made in Java 1.1, you can now do generic programming in Java reasonably well. Interested folks should check out the Java Generic Library, a "port" of the C++ Standard Template Library to Java.
One thing the author of the above article writes is that there is almost no performance penalty in using the C++ STL, but there is a considerable penalty in using the Java equivalent (all those downcasts from Object to whatever class you're using cost).
Netbeans is a very good IDE, itself 100% Java with Swing. But unless something's changed recently, it's only an entry-level IDE.. no versioning integration, no bundled javabeans for JDBC, no servlet debugging, etc. Some of these features are available in controlled betas.
Because of that, it only really competes with the $100 entry-level IDEs, but in that realm it stacks up very well. It's on par with the base versions of Visual Cafe 3 and JBuilder 2.x. Very nice two-way development, a damn fine form painter, Java 2 support, and so forth. Runs like a charm under Linux, too.
There's a high-end version with all the other bells and whistles supposedly on the way, but last time I checked it was vaporware and behind schedule. At least it looks like they made it easier to obtain the beta JDBC support for now.
It's commercialware, but free for personal noncommercial use AFAIK.
Not me. Getting read of pointers renders Java fairly useless as a systems programming language.
Have you actually used java? Java has references which for all intents and purposes are pointers, but without all of the potential to be abused.
Maybe lack of pointers limits java's usefulness if you are writing device drivers, but other than that, why do you need pointers?
(I've done plenty of C/C++ and Java, and I have yet to find myself thinking that I could do something better with a pointer than I can with a reference.)
--Rob
To a real OO programmer, multiple inheritance separates the Javas and ObjC's of the world from the C++'s of the
world. C++ is simply superior for this reason. =)
I found myself wishing that Java had multiple inheritance once... then I thought about the problem a little bit and realized that single inheritance + multiple interfaces was a much cleaner solution.
Plus, in some cases, you can actually do multiple inheritance of sorts... you can have an inner class the extends a class, while the outer class extends a different class. This usually results in better encapsulation... (Am I the only one who things inner classes are the best thing since sliced bread?)
--Rob
Because Sun knows that the best part about Java is that you can load classes into a running program. That cannot
be done with a compiled version of Java.
Yes it can... how do you think native methods get loaded.
Instead of compiling foo.bar.MyClass to foo/bar/MyClass.class, a native compiler could compile it to foo/bar/MyClass.{so/dll}, and let the runtime link it in as needed vi dlopen()/dlsym() (or whatever dll api the machine you are compiling for supports).
--Rob
For starters, they produce different outputs. Jikes compiles Java source into portable byte codes. Egcs apparently produces native byte codes.
- Sam Ruby
Last time I looked, gcj compiled from bytecode, rather than source, so I can't see that you loose any cross-platform compatability.
For example, I currently use a command-line network tool that was written in Java just so that it would "run everywhere". At the moment, I run it under the JDK, but if I could compile it to a native binary, I wouldn't need to have the JDK mapped in all the time.
-- Andrew
If I remember correctly, one of Bjarne Stroustrop's chief criticisms of Java was its initial inability to support generic programming (as well as its apparent portability problems).
I haven't kept up with "Java2". Can anyone tell me if Java has improved in this regard?
This is a clear advantage of C++ that Java needs to address.
The practice of explicitly making a method "virtual" isn't there just to make C++ hard. Its part of the theory of its design. You only incur the overhead of a vtable if you want one. Java forces one on you whether you want it or not.
The Jikes compiler (http://www.research.ibm.com/jikes/) blows away any other current compiler in terms of speed. How does Java for egcs match up? I will try to do some benchmarks, but I don't currently have any time.
--Ivan, weenie NT4 user, Jon Katz hater: bite me!
--weenie NT4 user: bite me!
"Computers are nothing but a perfect illusion of order" -- Iggy Pop
GTK+ bindings for Java are already in the works.
I can't remember where I came across it but I think it was some guy in france that was doing it.
********************************************
Superstition is a word the ignorant use to describe their ignorance. -Sifu
...does compile Java into windows binaries just fine. Including AWT and Swing classes. Big reason I keep booting NT is to use it. (Besides Illustrator)...
Linux needs not just a Java compiler, but also a good IDE like Visual Cafe..
<^>_<(ô ô)>_<^>
Actually, even in NT I prefer to use EMACS with JDE. Works great. Visualcafe is used for quick forms layout and initial code generation and for compiling.
<^>_<(ô ô)>_<^>
I actually found that for modelling a good code parser is better for me than going the other way around - modelling in IDL, drawing pretty boxes, and generating hard to read code. RR generated code is butt ugly.
Just do your inital design with placeholder for functions, than use something like Source Navigator (from Cygnus) to look how it looks like in terms of the structure... It draws pretty trees and diagrams for Java pretty well. And when linked to EMACS for an editor with JDE it is grreat. Though a built in editor is good enough.
- just $150 for developers version...
<^>_<(ô ô)>_<^>
Actually there are a number of F90 compilers under Linux. We've been using the Portland Group compiler for more than a year. There are several others. See the Linux Fortran Information Page for all the details.
Why are you using multiple VMs when one VM with many threads will suffice ?
Starting up many VMs to handle stuff will consume lots of memory and CPU, don't do that.
- sigs are for wimps.
They can have natively compiled binaries plus
java class files to achive dynamic loading.
Very nifty stuff, and very fast java performance (check out the latest reviews on javaworld).
http://www.towerj.com
- sigs are for wimps.
Nice to hear you have a good technical reason for it ;)
You're free to solve the problem any way you want but , sheez , it's not that complicated to make the thing just one VM with many threads running.
- sigs are for wimps.
To transform Java into a systems programming language as capable as C/Modula/Ada, it would be sufficient to add a "java.unsafe" module that adds support for reading, writing, and executing raw memory.
When you provide some credentials, I'll start accepting crap like "I can't possibly belive you
have any programming experience" without some good proof.
I object to the streams because they exist, not because they are forced on you. They provide some benefits, but they don't do things like set errno, they give you less information on file opening failures than their libc equivalents. The types of errors that you can catch are just fewer and less informative. That's my gripe with them. They're less powerfull. They do have some nice qualities, like easy overloading.
Speaking of which, overloading is a nice feature of C++.
My point, though, was that there are reasons to not like C++, and there are no great reasons that C++ is better than C. It has some niceties (the STL, operator overloading, declaring variables anywhere in a program, etc.), but none of them are necessities by any means.
So simple preference is a valid reason to choose a language when there are no clear significant advantages to either. obj1 = obj2 + obj3 is nicer than add(obj1, obj2, obj3), but not by all that much.
Btw, the word logical was probably a bad choice of words. I was trying to refer to the opposite of OO programming, which I guess might be better termed action oriented? What is a good way to describe a += b instead of a->add(b); (using a silly and never-going-to-be-used example).
Did someone just steel your girlfriend, btw? You sound awfully hot tempered for someone responding to a simple post on language choices that said that C++ is not the one true way.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Frankly, C++ has its drawbacks too, like being more complex and further removed from the computer. C++ has a different feel to it. Bloated and Anal come to mind, but that's probably just partially from the way that it was tought to me. Possibly the other part is that I don't really trust any language that has those awful stream object. cin & cout are pathetic compared to their equivalents of printf and scanf.
And those try{} catch{} blocks just feel way too much like some sort of basic. I want to program, not play a game of baseball.
Part of it is also that most of the C++ OO programming that I've seen has made anything that it could find an object, which is the wrong way to go about things. I like OO programming in C better than in C++, partly, I think, because people are more likely to write the code that does the job most elegantly and not the code that does the job most abstractly/OOedly.
Of course, that has nothing to do with the language, but I have tended to dislike the way that people attack problems to attack them with an OO frame of mind rather than a logical frame of mind. This is just a generalization, btw, and I haven't seen all that much C++ code.
But the major thing about C rather than C++ is that C just doesn't have the "designed by theory" feel to it. Everything in C feels like it's been designed from experience and logic. That's why, I think, that it's been called portable assembly. Assembly tends to be elegant, efficient, and logical. Especially some of the RISC assembly languages.
C has that sort of feel to it. It has a minimalist appeal. C is quite convenient, as long as you're comfortable with computers, and while it has its faults, it doesn't really get in your way to do anything.
C++, by contrast, feels like it was designed with OO theory in mind. It has all sorts of contructs that just don't feel right on a computer. Like the public/protected/private declarations. That just feels like something that should be in a classroom, not a real programming language. Of course, that's a feeling, but it has its validity. public/protected/private isn't part of how a problem gets solved, it isn't part of the code, and it isn't something that helps the compiler figure out what you mean.
On the other hand, classes do offer some convenience for having OO functions inherently know what data they are operating on. But it is just a convenience. It's not much of a hardship to do object->data instead of data.
Anyhow, I haven't seen any really good reasons for prefering one language over the other. I get more of a feeling of leaner, faster code from C, but that might be erroneous, it's possible that if you don't really use certain features of C++, they're not put in there because they theoretically belong in there. I haven't really looked through the various C++ compilers.
But please don't disparage C so much. There's nothing that you can do in C++ that you can't do in C (that isn't syntactical in nature), and setting up your own object model generally means a few extra pointers that would be handled for you in C++. For those who like the feel of C better, there aren't really any compelling reasons to switch to C++.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
I responded to the logical part in another post, but let me address that here, too. I didn't mean that OO programing wasn't logical, I was just trying to refer to the other paradigm of programing that isn't OO. Maybe it's action oriented programming? I used the silly example of a += b; rather than a->add(b); That was what I meant. I respect C++, btw, I didn't mean to imply otherwise. I just didn't phrase it well.
.c file. C++ seems like a good language, but it's not clearly better than C++.
:-)
> If E and Gnome were written in intellegent C++,
> they might actually work.
Just like Netscape?
Oh, and in what sense doesn't E work? I can't remember it crashing on me since the 13.3 days, and I use it exclusively. Gnome is just a massive project that's growing at an incredible rate. To expect a project of gnome's magnitude to go from nothing to perfect in a year by volunteer developers is insane.
I'm not saying that C++ might not be more appropriate for them, but they're doing quite well as they are. So is Linux. And the gimp.
I never meant to imply that C++ isn't good, just that it isn't simply all-around better. And saying that you can compile C with a C++ compiler isn't an argument for using C++, it's not an argument for much of anything than it's fine to invoke g++ instead of gcc on a
Lacking a real clear general superiority, there's no reason to condemn those who like C over C++, or to regard them as inferior. Frankly, while I like C, my favorite language is perl. C feels closer to the CPU, and in that way I like it better, but there's nothing like Perl for elegance of design.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
Thanks for the kind and informative reply.
You're right that I'm a student, and haven't really been a part of large corporate projects. My experience is mostly on the small things that I've written, and on the larger projects that I've looked into by other people (part of why I love open source).
As far as streaming goes, the idea itself probably isn't a bad one, but from your description of it (and my meager experience of it) it's more a syntactical convenience, like perl's default scalar, than a feature that's hard to do in C.
As far as try/catch blocks, my problem isn't really with them, though I'm a bit dubious about your claim that they're much better than error codes, is the way that they're handled. With the standard stream IO objects, especially the file stream objects, they didn't have nearly as many exceptions that can be thrown as they should have, their errors were largely generic. "couldn't open file" type errors, not "too many file descriptors open" type errors. This is more a matter of implementation, though.
But try/catch blocks aren't particularly different than error codes, you flag and error and someone down the road picks up on it. With error codes, you often have the benefit of printf("%s\n", strerror(errno));, which saves a lot of debugging work.
As far as public/private, I've never been able to gather much of a benefit from that feature of the language that isn't something that should be built in anyhow. wouldn't:
#define private public
just get wrid of the language barriers to using private members?
In C, you can stick the private functions in a header file that you don't even distribute, which is more private than giving them out.
But information hiding sounds more like a matter of programmer discipline. You should, having inelligent and responsible programmers, be able to make a header file with
/* These are the general functions, use them */
...
/* These are the private functions which may change at any time without warning, don't use them. */
...
And achieve the same effect. Sure, there's nothing forcing someone to pay attention, but what's forcing someone not to do a #define trick, or just to rewrite the header file (using a local copy), etc.
Anyhow, my point was that not using C++ for everything is not necessarily a sign of incompetance. C++ doesn't offer any tremendous, clear advantages that make C the choice of idiots only. That was my only point. Every supposed benefit of C++ that has been pointed out, I've seen to be a benefit, but not as a major benefit. That is, not as the sort of benefit that you'd be an idiot to ignore. I'm not trying to start a holy war, just defend C as a viable language choice for many applications.
Btw, I wasn't arguing about OO design. That's often the way to go. But you can do OO design reasonably well in C.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
I wasn't trying to disparrage C++. It's a good language, and has benefits over straight C. My argument was just that if someone likes C better, they're not an idiot for using it over C++, even if C++ had some benefits. It's quite possible that the benefits aren't significant enough to outweigh personal preference or personal circumstance. Essentially that there's no one true language. I never meant to disparrage C++ as something inferior to C.
Oh, and I'm not clueless. I didn't learn too much C++, we don't have the best CS teachers here, but I did learn some C++, enough to have some flavor of the language. I know C, I know perl while not being a master of it, I've done a little java programming, a touch of javascript, x86 and MIPS assembly, bash shell scripting (if that can really be counted as a language), and I'm probably forgetting something that I've tried. I plan to learn more languages, I'm interested in lisp, among others.
Anyhow, I don't mean to disparrage any language, as I said above. I just wanted to point out that there aren't any real grounds for saying that real programmers don't program in C, only throwbacks do. I think that we're essentially agreed.
They laughed at Einstein. They laughed at the Wright Brothers. But they also laughed at Bozo the Clown. -- C. Sagan
This means that Java is now a real language, just like Objective-C, Pascal, Fortran, or C. The FUD official stops now.
And I bet this means we'll be getting GTK+ and GNOME and ORBit bindings for Java/gjc soon... yes...
--jon. Postel is dead. May we all mourn his, and our, loss.
Metrowerks is making one. It will do C, C++, and Java. It is not open source though.
http://www.metrowerks.com/advert/001/
BTW, I think the Mac version will compile Java into binaries. The Win9x/NT version could also but I haven't messed around with it as much.
--karrots
It's a Java source to native binary compiler. To write any interesting binaries in Java, you need compiled versions of the Java libraries (I mean, at a minimum, you'd need java.lang.Object, right?). These are only sorta done. But it's a start! (And one more excuse for me not to learn C++.)
-- Some things are to be believed, though not susceptible to rational proof.
The Java language itself is very nice, and I prefer to use it over many other languages even without the lure of write once, run anywhere. On the other hand, I feel one of the strongest features of Java is that I no longer have to learn Motif to write the GUI for my Unix systems, Visual Basic for my Windows machines, who knows what for my Macs (if I had any) etc... Unfortunately, Java is STILL awful slow for this kind of thing, and the only stuff I see being optimized is the stuff I could do with straight C on any of these platforms anyway. Also, with native compilation I no longer need to have the VM installed on all of the target platforms, which would save a lot of headaches. Is anyone working on native compilation for AWT, Swing, etc?
See NetRexx from IBM and NetCobol from Fujitsu.
Also their are Basic compilers and Eiffel as well.
-- dIon Play: http://www.trongus.com Work: http://www.multitask.com.au
To a real OO programmer, multiple dispatch separates the Dylans and Cecils of the world from the C++s of the world.
;-)
I don't know why anyone would limit themselves to single dispatch with C++ especially since multimethods have several well known advantages like a simple solution to the "binary method" problem, cleaner implementations of the "visitor", "strategy", and similar design patterns, and a form of "open objects".
I'm serious in concept but joking in tone. C++ has its place, too. I think it's called a museum.
java isn't supposed to be C++.
the whole point of java is "write once, run anywhere".
compiling to native code does not advance that.
just-in-time compilation does.
Everything should be made as simple as possible, but not simpler. -- A.E.
This has the nice side-effect of keeping your namespaces clean; all these little utility classes are hidden away.
Once you've started using inner classes, it's hard to stop.
If Cygnus doesn't have inner class support done yet, I don't think their Java tools have any worth, IMHO.
-jon
Remember Amalek.
I think it's a damned shame how much Sun screwed this up. Java could have been genuinely useful years ago if they hadn't tried to maintain control so tightly, and hadn't tried to conflate so many completely different things (a language, an enormous class library, a virtual machine, and a security model) under one name.
With all due respect, I agree with your second reason but have doubts concerning your first. If If I'm not mistaken, their official line on why they maintained that tight control was twofold: first, they wanted to protect Java from sabotage,as Microsoft tried to pull, and second, that their initial license agreements with vendors made loosening their control legally tricky.
Could they have prevented Microsoft from discrediting Java's "Write once, run anywhere" claims if their control had been any looser? Possibly. Was it feasible for them to give up some ground any faster than they did, or to simply have released the product under a more open license to begin with? Maybe they could have done that, too.
In general, however, I feel that Sun deserves more credit than they've received so far. Vendors such as IBM, IBM/Lotus, Oracle, Apple - in short, pretty much everyone but Microsoft and Compaq/Digital have had enormous input on the class specifications, for example. Some important parts even originated at one of those other companies. And Sun has released preliminary specs for public review and criticism; they've been extremely receptive to outside influence, and I guess the fact that they've been reserving the final word for themselves just doesn't bother me as much as it seems to bother you.
It goes without saying that they're simply acting out of their best business interests; those interests seem quite compatible at the moment with almost everyone but Microsoft. Most of all, they are very compatible with the self-interests of developers. The Java community license is possibly the best compromise between the free and proprietary worlds that I've seen so far.
I realize that many people feel there can be no compromise: the Qt flame wars demonstrated that quite clearly. But for developers who want to make a living developing, without doing so as consultants, scrutinizing the middle ground is absolutely essential.
Of interface.
:)
What else do you need?
(C++, the PL/I of the 90s
-- Alastair
Getting [rid] of pointers renders Java fairly useless as a systems programming language.
ROTFL.
The operating systems for Burroughs large systems (B6700, etc), now Unisys A-series, are written in a variant of ALGOL utterly devoid of pointers.
(It does, however, have a predefined array called MEMORY. If you really need that level of access for your systems programming, add that to your JVM.)
-- Alastair
I think Bjarne's confused on this issue, if you're quoting him correctly.
Any language that supports inheritance supports generic programming, if you do it right. You don't need templates for it, either.
I started using C++ back in cfront 1.1 days, before templates or multiple inheritance were part of the language. We just created a bunch of basic classes to inherit from.
-- Alastair
A language should give the programmer as much power and flexibility as possible, and a programmer should know when not to use it.
In theory I agree, and that's fine for personal projects. In practise, however, I've seen (and occasionally had to maintain) far too much crappy C++ code (and other languages, certainly) written by programmers who weren't enough above average (and remember, 50% of programmers are below average) to use such features appropriately. On anything that needs to be reused, or maintained, its just not worth it. (The ultimate example of this is perhaps APL -- powerful, expressive language, wonderful for writing quick personal and powerful apps (I've even seen an email system written in APL), no fun to maintain.)
Having a programming language enforce what it considers good programming practice results in disasters like Ada, Pascal and Java.
Those "disasters" have proven spectacularly successful in the domain of large project development (well, Pascal less so, but it was designed as a teaching language) precisely because of that enforcement.
-- Alastair
It is the runtime library for egcs-COMPILED Java programs. It is, I'm assuming, somewhat analogous to a libgcc, which is where the compiler stores some of the functions needed for a GNU C environment on the target platform (things like strdup, possibly, where it doesn't exist in-system).
It will doubtless also provide the environment for Java programs to make calls to C runtime libraries and routines, and provide any scratch areas for stuff like exception handling.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
That's the subject of their contest. Hit their website for details.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
I do tend to agree with you, in that multiple inheritance is a very useful paradigm. However, where I find C++ lacking is in its inability to do interface inheritance. Having both concepts in a language cannot be impossible, surely.
/.ers...
Interface inheritance makes dynamic type loading a much easier proposition (without the need for factory methods and like cruft... ick...), while multiple inheritance can make a coherent family of objects sing. I like both concepts.
On to a couple other points raised here by other
Is multiple dispatch (mentioned by a Dylan guy) a sort of SIMD thing? If I have an array of Foo objects, and I want to call Bar() using each of them as an argument, is there a possibility for concurrency of execution innate in the language?
If so, I _really_ appreciate that.
Also, in the case of C++ on Unix, there needs to be a set of exceptions which map to the system's asynchronous signal model, and the use of signal() in C++ programs should be deprecated.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
There is an intermediate form targetted by the language front-end, which consists of a highly decorated syntax tree. This form is passed to the back end for optimization and production of assembly code.
AFAIK, anyway...
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
Have a look at the MudOS LPMud driver for proof of this concept. That language has, for years, mixed bytecode, interpreted, and natively-compiled objects, and is a fairly decent OO language in its own right (if somewhat dated).
ftp://ftp.imaginary.com/pub/LPC (I think)
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
Boy, if we could just convince IBM to port the Visual Age stuff to Linsux... :)
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
You might like XWPE, then. Its IDE is almost an exact copy of the Borland IDE, and it's free. It needs better integration with the rest of the dev tools, but the IDE is mostly there.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
If the majority of people don't know how to use overloaded operators, then their code sucks and their programming skills are atrocious. Don't however, take away a powerful tool like operator overloading just because there are idiots in the world.
:)
Clarity and cleanliness is so much easier to attain when code uses symbols to mean certain things.
One question:
string1 + string2 is a straightforward concept. How would you conceive string1 - string2, or string1 / string2? I can see string1 * int, but not string1 * string2.
Please email me with an answer to this, too.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
The only way to learn recursion is to learn recursion.
--Corey
Not only will they not deserve liberty or safety, Mr. Franklin, they will be DENIED both!
Anyone one know if this circumvents Java's array bounds checking? I suspect it doesn't. When using a good JIT, this is the biggest impediment to fast Java (at least with my code).
Compile with -fno-bounds-check.
Indeed. Every sentient being reading this should immediately snarf the paper written by Guy Steele for OOPSLA '98 entitled Growing a Language which makes this point so forcefully you will be dazzled.
The best place to find this on the net is apparently hanging off the web page of the soon-to-be-slashdotted Phil Wadler; download the postscript version this instant.
This is a bit of a red herring. Overloaded methods are at least as open to abuse (e.g., some clown could always define a "print" method that reads files instead...). What they don't do is invite the same expectations. But I think Java has a way out of this: you could have classes implement a standard interface that includes the operators you want to use in your class.
I've always found Java ironic that way; they come up with a truly cool idea like interfaces, then still use inheritance all over the place just to be OO, I suppose.
King Babar
Babar
You're a sick individual........
My current task at work is to translate Java code into C++ because the servers couldn't handle the load of starting up as many VMs as were needed. If this is ready for use (and you can bet I'm going to give it a try) it'll let me get back to interesting stuff.
I didn't write the thing. I just have to fix it. (And since I'm me, that means C++.)
I just hope that this doesn't lead to java forking. . .architecture-dependent java variants could really screw up the big opportunity for architecture-independent programming.
Agreed that losing sight of architecture-independance is bad.
But a faster Java that is developed as an open source project, rather than as Sun's main PR tool? That could be great indeed.
I agree that the lack of generic programming in Java is one of its biggest weaknesses.
Java2 has a new API that tries to rectify this though. The Collections Framework (or whatever the nom du jour is) provides some generic container classes, complete with algorithms ala STL.
The problem is it is Java still doesn't have templates. All the generic stuff is implemented with standard OO inheritance and polymorphism. That means that the nice compile time checking of C++ doesn't happen in Java; you have to make sure every Object you add to a List is really a Comparible Object or else Sort will choke at runtime.
Plus you can't have lists of anything except Objects. I know, I know, everything is an Object, but that means you can add a Thread to a list of Windows, for example. Unless you create a specialized class derived from List that only works with Windows.
In short, yes it has generic progamming of a sort. But it is still a lot less powerful than templates as implemented by C++.
You are right, the particular situation I described doesn't happen in real life that often.
My real point is that C++ with templates binds everything at compile-time. If a type won't work with a particular algorithm, or you try to put the wrong type of object into a container, the program won't compile.
Java binds everything at compile time, and throws exceptions if something goes wrong. It will compile, and it might even run 99% of the time.
From a software engineering perspective, the first is much better because it catches that entire class of errors 100% of the time. They can't be caught all the time in the second situation without exhaustive testing.
Small projects that use a Vector here and a List there aren't going to have problems. But large projects that use generic programming exstensively are much better off with the static typing.
The whole argument is really the same as the argument between statically typed languages (C++, Java, Pascal, etc.) and untyped or dynamically typed languages (Lisp, Smalltalk, TCL, etc.), except on a higher level.
-- A wealthy eccentric who marches to the beat of a different drum. But you may call me "Noodle Noggin."
Quando Omni Flunkus Moritati
yeah... I've been caught in the middle of trying to decide on a language to hitch my wagon to (besides C of course)...Perl ...Python ...Tcl ...C++ ...Java...hmmmm...This might boost java up to the front...
No AWT L&F, but gtk bindings are certainly possible. Personally, I think the Java language is very cool. Parts of the Java class library are also cool, but AWT/Swing/JFC are not worthwile (nor is any other GUI toolkit that isn't easily accessable from multiple programming languages efficiently).
Of course, your statement is perfectly correct from the point of view of writing client-side code. gcj Compiled Java isn't very useful for client-side code in the first place, since it is platform dependent. gcj does hold out the hope of a better application development language than C that's fairly portable and fairly efficient for many tasks, though. There are plans to support a JVM as well in the future, which would also boost performance for many client-side applets (esp. by compiling the Java class libraries, which requires that those get finished...) But IMO the cross-platform, JVM hoopla has overshadowed a language that is a perfectly good alternative to C in some situations. Better than C++ for sure. Still not appropriate for all tasks, of course, but nothing is.
Sumner
rage, rage against the dying of the light
Why isn't CLOS practical? There's a CLOS on just about every platform; Allegro Common Lisp can even target Nintendo 64 and Sony Playstation...
Objective C fits nicely for those who like real objects (a la Smalltalk) but need a compiled language. For those who don't, Squeak is spiffy.
There are choices, and some of them are superior to Java.
True, but I think the better reason a beginner should start first with C rather than C++ is the complexity of C++, and the fact that you really should be comfortable with C before embarking upon C++ (which is essentially C with additional features)
Take, for example, a string class in C++. Many beginners will build a string from characters by concatenating each character to the end of the string (thestring += thechar). This resizes the string on every character added, as a new array is created (1 char bigger), the old data is copied over, and the old char array is deleted - all internally and automatically by the string class. Sure, this is really easy, and that's the problem - the beginner doesn't realize how much inefficiency is going on behind his back.Any decent implementation will preallocate a small block of memory beyond the end of the string (or array) so that the string (or array) will not have to deallocate and reallocate with each additional character (or array element). Most implementations I've used also let you give the string object a hint about how long you want it to be.
So even though C++ is easier in many respects for beginners (the compiler automatically takes care of reference parameters, automatically determines the data types for outputting and inputting to/from the console, etc.), I still think it's a good idea to learn C first, to understand how things really work, and then to learn C++. Of course, most schools don't agree with me. Oh wellAre schools starting people out with C++? I came to my first Comp Sci class with C under my belt, but was forced to learn Pascal.
I've been hearing about the Cygnus project for ages, nice to see that its finally coming along. There are quite a few native compiler products for Java, but none that are open source. TowerJ (www.towerj.com) is available for linux, and compiles Java 1.1 non AWT apps using GCC. I believe it did very well in the recent VolanoMark benchmarks.
However, more exciting is the research into VMs going on at various places including IBM. Many people are predicting that dynamic compilation will soon eclipse static compilating in terms of tuning for actual use.
Agreed. C is easier to port than C++ and C compilers are more common on older systems that some companies can't afford to phase out.
Also (with the possible exception of BeOS) many operating systems and their APIs have a decided "C-bias".
Save the whales. Feed the hungry. Free the mallocs.
For syntax highlighting and other niceties, I'm pretty much hooked on NEdit ( http://fnpspa.fnal.gov/nirvana/nedit.html ). I haven't found an IDE I'm crazy about yet in either Windos or Linux. Anyone have any suggestions?
Save the whales. Feed the hungry. Free the mallocs.
I just started using Java (I'm a C++ programmer at heart) and I have to say that I'm very happy about the portability of the language. But there are two things that bug me. Getting rid of pointers... I can live with that. Getting rid of operator overloading??? That's dumb.
Why write c = a.add(b); when c = a + b; is SO much better?
Just because operator overloading has been abused doesn't mean that it should be removed from the toolbox!
a) If you really believe that Java is "so unappealing to everyone", I expect you haven't been paying attention.
b) The concept of a VM is what makes Java very appealing to _many_ people. Even though WORA is still largely a pipe dream for complicated apps, a lot of people are still working towards it.
- Old Man of the Mountain ---- "I want to disturb my neighbor"
In practice, pointers are only necessary for small
parts of an operating system, which (in Java)
could either be accomplished by small scraps
of unsafe code, VM-specific classes, or unsafe
extensions to Java. Go give Modula-3 a look;
it has an unsafe variant, and M-3 has been used
to write an operating system (SPIN) that compares
favorably (in terms of performance) with flavors
of Unix available on the same box (DEC Alpha).
Furthermore, adding pointers to Java (in an
unsafe, walled-off extension to the language)
does not give you the same language as C, and
certainly not C++. How do I know? Because
I've seen it done.
Casts don't cost much in a decent VM, and
because there's no preprocessor, you can write
(and I have seen it done) "generic" expanders
in perl. That is, I don't care whether "Java"
does generic programming, because I do generic
programming in something that looks like Java
(just as templates resemble C++), and I've got
(at least) two ways to do it, one compact and
somewhat slower, the other not compact and
somewhat quicker. Given the generally miserable
performance of C++ compilers and debuggers on
C++ templates, I don't miss them at all.
but you can't have WORA if there are different versions.
You can if the spec is tight enough (it might be,
it is certainly tighter than C's) and if the
different VMs conform to the spec. It would
help if Sun conformed to their own spec in the
area of JNI, and it would be nice if someone
could verify that Sun's JCT only checked for
those things defined in the spec (I've heard that
if you don't run it in the Pacific Time Zone,
you cannot pass), but such is life. It looks
like a huge step in the right direction, and
it is much easier to write portable code in
Java than it is to write it in C or C++.
"The nice thing about the streams library is that you can easily expand it to handle user defined types"
This is true, but IMO, one of the best things about the streams library is that the compiler determines at compile time which code to call to do the streaming. Used properly, this is vastly more efficient than run-time interpretation of arguments to the printf family of functions.
Another great thing is that the streams library is type safe. That means the compiler does the error checking for you, elminating a whole class of bugs common to printf where arguments are given that don't match the format specification.
--
Daniel Neades
www.araxis.com
-- Daniel Neades, Araxis Ltd (www.araxis.com)
I'm not too fond of Rexx or COBOL, but do you happen to know which Eiffel implementation can compile to Java bytecodes? That might be interesting.
You'd be surprised at how many companies still use straight C.