well, of course I didn't learn everything about c++, I'm even sure I didn't learn all the basics, but I
know enought to write this little application

I don't understand your signature, because I don't know what "echo" does in c++ ...
but can main return int? I thought it hast to be void...

rhican, why are you so focused on the speed of a language, which is just the side effect?
You are aware that too gain more speed, you need not only a faster processor but also a good algorithm, right?
In situations where speed is such a big concern, I'd say go for the machine language
Nevertheless, programming languages are created not to improve the execution time, but to reduce the effort needed in development, testing, bug fixing, security management, etc. (Feel free to compare those constraints )

the echo in fact is not c plus plus, that's just a wrapper, to make it do something on a linux shell, the real issue is

int call(){int a;2[&a]-=5;} int main(){return call();}

just compile that on a x86, and try to discover why it does what it does

@quang
i'm not focussed on the speed of a language. You appear to be focussed/frustrated more than I am.
Where as I replied on topic, You are the one that came with the ridiculous link to some ridiculous piece of research
which to all likelihood will never make it into our machines.
Other things I don't like about java
- the way they interpreted "generics"
- no operator overloading. if I make a vector a and a vector b. i want to be able to bloody write c=a+b; not some c=a.add(b); or c=a; c.add(b);
- the abundance of bad java coders.
- no multiple inheritance. If I have an Ipod class, and a Videoplayback class. I still can not make a videoIpod.
only an Ipod that reimplements the videplayback interface. or a videoplayback that reimplements the Ipod interface
-the fact that I can't do memory management even when I know the VM's will do it inefficiently and I have the time to
do it better.

However these are personal whereas speed is universially understood.

If you look closely I already said everything you are saying. Yes even the trade of. It's not a contest. I know pretty much all there is to
know about the differences. Conceptually, java has some interesting ideas. It might be faster if it learned to use runtime information
better. But right now It's basically the implementations that make the difference. which are slow. Not as slow as they were. But clearly
slow. I have heard all the arguments. From an software application point of view java makes plenty sence.
However that's not who we are. Is it?

c or c++ give you control over your machine. And correct me if I'm wrong but that's what most of the members here are interested in.
Learning about this brilliant technologies that connects people around the globe, plays movies, games, applications. Don't we all want
to know how it ticks? Until now it doesn't tick on java. And the virtual machines that run java, are written in c++. Yeah they are.

writing straight machine code, rarely ever is faster, than well compiled c code. But it's fun none the less.

c/c++ works, yes development cost is higher, yes it has certain security problems, which do not occur in a language like java. which
require that you don't make certain mistakes. eventhough DEP is on by default now, PIC, Stackgaurd/heapguard/.. And you only
have to worry about those when your application does something lowlevel or network related.

I know java is not that bad. I am just a realist and dare to recognize that it's rather slow now. Do you know c++ is not so bad either?

not to mention the elegance of a standalone executable.

If you are getting advice about programming languages here, then coding in assembly is the last place you should be looking to improve the performance of your code. First choose good algorithms for frequently executed code; then implement them in a reasonable choice of language; next comes profiling, cache optimization, etc.

Unless you think you can outperform good compilers at register allocation, instruction selection, scheduling, branch optimization, and other aspects of code generation, assembly is likely to just slow down your program development. If you choose this approach anyway, don't be surprised when your code runs slower than compiled C for no obvious reasons.

exactly what i ment with

"writing straight machine code, rarely ever is faster, than well compiled c code. But it's fun none the less."

tnx unime

Rhican:

We posted replies at around the same time. I hadn't seen yours when I sent mine in. Either way, you're welcome!

About your sig: I haven't checked other systems, but on my x86 computer, the program (q) returns promptly with code 0373 whether or not the assignment is made, and the shell command as a whole prints "Why isn't this printed?". The reason for this is that 2[&a] is still below the frame pointer (ebp), an so only affects the stack frame local to call. I expect that is not the behavior you intended. Should I compile this under Windows (with which version of gcc) to see what happens?

As for Java, well I don't mean to be an apologist, but from a language perspective it is actually pretty decent. Overloaded operators have their place, but user overloading is too often abused and, imho, not valuable enough to be worthy of inclusion. Automatic storage allocation and garbage collection can actually be faster than hand-optimized malloc and free, which can be very difficult to get right in real programs, though I can't say I know how much overhead there is in the Java memory system. I suspect there is more wasted effort in dynamic type checking and object-related overhead, though.

well actually most compilers will compile it in the way i expect .. but sure i'm doing nasties ..
on the multitude of gcc's/VC versions i tested it, it works.. you can assume that i intend
a to be allocate tos after entering the function. And no canaries/buffers/other stack protection
techniques other than randomize_vaspace are to be. used

i just tested it again with latest stable gentoo gcc.


Sure java is not all bad. There is something to be said for putting the programmer in this
white room with cushions all over the place. I just don't like it.

I do object to the fact that you say that operator overloading is abused too much. taking away the option of using it is just ridiculous.
operator overloading is done regardless it's a matter of syntax.
how much more iritating is it to check if it's .equals() .eq .smallerthan() .lessthan() , .lessthanorequal() .lessorequal() .smaller() .smallereq() .same() ...
when there are these excelent symbols like <= , < , = that even really dense people can understand
and operator() makes functors that more intuitive... no Comparer a(20); a.compare(); but Camparer a(20); a();
and ..., and ...
Fact is that operator overloading would have made the lexer/parser harder, which they probably didn't dare to do. and now you have to find you way
through the mess of verbose names. It has nothing to do with the fact that users of other languages "abuse" the feature.

I guess you would say multiple inheritance is not worth the bother of the VM, because it's difficult to implement, and creates a lot of
special cases. that the java standard rather wouldn't deal with. and now force the user to solve it.

and them i'm not even repeating the other features I don't like in java But i understand that features that have been proven to work
are either used to much for java, or to little... java is sounding like a self for filling prophecy...


There are instances where you know you can do memory management better, because you have runtime information the compiler
hasn't got, and the VM is too stupid to use yet.

In c++ you have the option of using a garbage collection. Like the one in the boost library. subtle differences.

so lets just say, I don't like java that much. I recognize it for what it is. It's good for putting a programmer in this nice jail, with
regular meals, no freedom to make mistakes. The rest of the society has no trouble with you. and they love wearing the
mittens you knit everyday day. But from the moment you want to do something serious you discover that all the doors are locked.
And people are going: "why are you trying to get out anyway? there's crime, drugs, heartbreak out there..*points*?"

to conlcude this post I'll leave you with the names of the java frameworks which i hate an love the most.
most hated: JINI
most adored: JNI
one letter, but a world of difference I already had the pleasure of building a project on top of jini, bah.

The reason your trick fails for me is that my gcc is optimizing for a different architecture than yours. It may be because my gcc was built using -with-tune=prescott. In any case, I get the expected behavior when I limit stack alignment using -mpreferred-stack-boundary=2.

Hey, I'm just spouting my own opinion about programming languages. I don't mean to say your reasons are invalid, just that there are other points of view on the matter. For what it's worth, I've been programming in fairly verbose languages for a long time, and I have used variants of ML with and without overloading extensively. OCAML has no overloading at all (write "+" for integer addition, "+." for float, and "Int64.add" for long), SML/NJ allows operator overloading. For me, the slight annoyance of writing long names doesn't seem to affect the time it takes to write, debug, and maintain a program. Since you brought up the notion of using "=" for equivalence I'll point out that I have accidentally written "=" where I meant "==" more often than I should probably admit when coding in C.

Parsing overloaded operators in no big deal, as long as the syntax is sufficiently restricted (having worked on the SML/NJ compiler, I feel qualified to make this statement). But I'll throw out an issue I can't see a solution for: How do you determine associativity and precedence for operators in a dynamically typed language? The problem is actually worse than that: Which class does a binary operator belong to: its left operand or right?

There is only one case where I really miss overloading: Code with complicated numerical expressions. But Java provides overloading for these cases, so it handles the important case. For me at least.

Multiple inheritance is something I have never really wanted to use, so I probably should not argue the point but what the hell. The biggest problem with adding MI to a language is that you hide which methods are being invoked in the very common case where multiple parents define the same method. Java does the useful part in my opinion: Multiple inheritance for interfaces. I don't have a problem picking a single parent and importing other methods explicitly in an implementation, though you might argue there is more maintenance when an interface changes.

Last, you can certainly do your own memory management in Java. Just create a big array and allocate blocks within it. If the Java GC is like the multi-generation collectors I am familiar with, such arrays are kept in a large object space and never (or at least extremely rarely) moved. It is not pretty, but it works and you can use whatever allocation algorithm you like best.

My apologies if I am drifting off-topic, or have fallen into the trap of trying to prove myself, rather than a useful point. I hope what I write is interesting. If anyone thinks I've overstepped some line, send me a PM and I'll try to learn from it.

Your language elitist,
unime

Right.
My proposal of using 0s and 1s only applies when all the optimization technique failed to give you the speed you desired. Of course we need a guru for this. If, in some weird case, using machine language results in an even worse performance, I believe it's the programmer's fault - he surely lacks skills, he shouldn't have tried it

Java doesn't give you much control over the machine. Why? Because that's kinda low-level. You know, most human don't understand machine language, and only a few try to understand. Programming languages are created to reduce the programmer's effort. Computers were first created to simplify the jobs for human. If, say, when your mom wants to read some news from the Internet, and the computer asks her to input some 0s, some 1s, some more 0s..., she'll surely throw it away

Although Java provides auto garbage collection, it also provides a quite good mechanism for controlling GC. Quite complicated stuff, but very powerful.

Oh and I'd like to tell you why I didn't like C/C++. It lacks standard. Mostly due to the domination of M$ and its Windows platform. If you write programs only to run on your computer, there's no problem. But when you bring the compiled program to another comp, it might stop working. Maybe the other comp is using another OS, or you're missing some libraries, blah blah... Right, you may want to recompile it from source. Not so easy. You might be lucky to have all the needed libs, but still the compilation will take, say, 10 minutes for a decent program. I'm not that patient

Oh well, not to mention the fact that each compiler compiles its programs differently

Simply put you like that highlevel jail. you fear options and freedoms. I don't but i can see where you are coming from.many things c++
has options for, are not "lowlevel". just a bit more difficult, to implement in the VM, or just a risk with the unkowledgable userbase.


I ddin't know this i'll research it.


Binary compatibility is a linux bug. other os's have perfect binary compatibility. Cross platform incompatibility is a feature. but on linux you can have
perfect staticly linked apps that work everywhere. like the binary flash player, ...
But ok I understand that this is an extra step, and you are free to not willing to deal with this.
c++ is also fairly compiler dependant too. it's evil but the freedoms .. njam
Java doesn't work perfectly cross platform either.
If you look at the multitude of opensource projects in c++ that are available cross platform .. like firefox, openoffice, codeblocks, ...
you see that achieving this i not a problem. puts a bit more effort on the development side, but the result is quite nice.

But clearly you like the jail and i respect that. I really want the full freedom of the machine and prepared to make some sacrifices.

So I believe we have clearly outlined several differences between the languages.