Check out the (very simple) multiplayer (via serial port) pacman game I had to write for a module last semester, and see for yourself.

http://www.bigblah.net/upload/wspg.asm

Isn't the whole point of high-level languages that you let the compiler generate all the Assembly? What's the point of using low-level code in the middle of C/C++?

Optimization, it is an incredibly common thing to have C code call external functions written in asm.

Because even some of the best compilers do things you don't want it to. They do make mistakes fairly often and the only way to resolve the issue is to edit the generated assembly by hand.

By "low-level" I refer even to thing like Pointers - to even use the damned things you must compile your code with the "unsafe" option. A fundamental concept to be sure, and not all that low-level, but one that C# doesn't like.

http://www.c-sharpcorner.com/Code/20...UnsafeCode.asp

Argh. I sorry. I didn't mean best API... Ew. That was a rather sad mistake. Er... Best IDE. This is why acronyms are evil. I like VS's interface, not the library. Sorry for the misunderstanding. :/

The VS IDE is.... OK. Still can't touch vim+make in my book. Or Eclipse if you truly need an honest-to-god IDE.

But vim+make isn't an IDE, so that doesn't really count.

Eclipse came out near the end of my college career, so I didn't really get into it, being set in my ways, but a few of my student teachers turned me on to it. Had I stuck with programming and Java, I would have made the switch to it eventually.

I've had some time with C and C++ last semester, and now dealing with assembly this semester. It's more of a bitch to do things that would be considered "simple" in C/C++ in assembly. What could take like 3-4 lines of code in C/C++ would take 2-3 times more (occassionally even more) code in assembly.

But then again, if you saw Blah's example, you'd now this by now.

Oh yeah, forgot to mention the original post. I've compiled C/C++ programs (although all were run in a DOS window) and they worked fine in Windows XP.

Using assembly you can make a program run faster than using program written in C/C++. Especially local variables, which can be removed, by using only registers (which cannot be accessed in high level language).

Most basic functions in C/C++ are written in assembly for the purpose of speed like the function strcpy, strlen. Which are written in assembly (as of the libraries of VC++). In tracing the function, you will see assembly immediately.

There are some software that fit using assembly, like hardware communication. Which includes software driver, etc. and some program that are fit using high level like C/C++, business software since maintenance is also part of the cost of developing software.

Nowadays, when CPU time is cheap and coding time isn't, writing assembly is just plain stupid. Your code isn't portable, is more painful to debug and read, and the speed benefit is very negligible.

There are many applications where any improvement is worth it. Consider a program which is run billions of time every day versus the time it takes to code a function once.

Operating system and system software like anti-virus and firewall must be written in such low level so that they will execute much quicker.

As the computer grows faster, we users install and use more software. And programmers tend to use the potential of the faster computer (Game is a good example).(I think it’s proportional: more speed = more software = more memory usage :) .)

Even using such low-level or high level, if the algorithm of the software is slow, any implementation will not make it faster.

Isn't it stupid when one pays about 2x the price of a processor for a faster model, then happily wastes CPU cycles because the software isn't properly optimized?
ASM, used wisely, is used to optimize concrete areas of an application, not to develop entire applications (that's just overkill, and one could end up reinventing the square wheel if not careful).
As for portability, it's ok when an application is portable between OSes, but most times you aren't going outta the x86 architecture so it's not much of a deal.

Exactly. When you have a program where 1% of your code accounts for 50% of your runtime (which is VERY common) then why the hell would you not recode that 1% in Assembly?

And this is precisely why it takes 256MB of RAM and a 700+Mhz CPU to run a spreadsheet today. When spreadsheets did the same shit on a 486. The same reason why an itty-bitty VB database frontend takes 30MB of RAM to run a simple query.

Usually, such high requirements aren't due to high language coding but because of inadequate data structures and/or bloatware.

First off, x86 hit your complaints on the head.

Second, who DOESN'T have 256MB of RAM and 700Mhz? I have 6 machines meeting those qualifications in my house (0 that don't), a stack of 550-700Mhz Pentium III chips sitting on my desk that I have nothing to do with, and a bag of 128MB PC100 and PC133 RAM sticks that I have nothing to do with. You can find better hardware at Goodwill.

And I guess "Third" would be stop using MS Office 2003. I've ran OpenOffice 2.0 on Pentium-75s with 128MB of RAM.

Even though ASM is useful in cases, I'd much rather avoid it when possible. Just let the compiler do its job.

Personally, I dig Python a lot more than C/C++, and Python is an interpretted language, so it's even slower than C. But really, it makes up for the slowness with awesome. I'm sure some of you hate it because it doesn't have strict variable typing and indentation rules and whatnot, but I love it. The library, the simplicity, the forced convention of spacing, generator functions, lists, tuples, dictionaries, not having to use confusing templates... <3.

Even I am using Java, which I considered the slowest language that I have used, since it is both compiled and interpretted.

More program especially business program doesn't need to run very efficient that it must be written in assembly. It's the logic and algorithm that count. Even you use assembly but the logic takes n * n to finish(I don't know how to write n square). It will be defeated by a logic that takes log n, n or even n * log n written in latest language.

Programmers tends to choose language which they can work/compatible with so that they can create software much faster.

The compilers are also being develop/upgrade so that it can be more efficient and have more options to give.

The main slowdown of Java is the horrendous VMs out there today. If someone could write a good, efficient VM, it'd become the complete industry standard overnight. But that giant level of overhead is what keeps other stuff like C++ and C# going. Heck, I haven't even bothered learning Java yet. I suppose eventually I should.

I'll believe that when I see it. Java is a proprietary dead end. It's C++ with all the good bits stripped out and replaced with junk.

=o

You, sir, have my respect.

Double Post:
There exists free (as in free-beer) ports, the most famous one being gcj, but I think it is still incomplete.

Java is pretty strong today, with a *lot* of business-critical applications. I'm not expecting it to disappear quickly.

(I say that, and I just hate Java)

However, you can be sure Microsoft will try to kill it with its C#

OK. How many hours did it take to simply boot the application?.:edgartpg:

You're right that a good algorithm is the most important factor in a runtime, but you don't have to write a whole program in ASM. You can write small functions in ASM that your code in a higher-level language calls to get around compiler imperfections.

C++ has no good "bits". That's what people like about it, it is basically nothing, allowing users to do whatever they want with no protection whatsoever.

Java is very important, I think the 3rd most used language (outside of C and C++). Sun, as a caretaker, has gone to vast lengths to improve it, there is one single body to make changes to the language and they never make poor decisions. I think it is still the easiest language to learn (not just the language itself, but it is easy to learn concepts in), so it definitely has its educational purposes.