C/C++

Originally Posted by www.sega.co.jp

How much harder is it to program in assemly than it is in C/C++?

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

Originally Posted by Arainach

On C# - I'm no expert (I've just been learning it for a couple of weeks myself), but the entire point of C# is that it's strongly typed and prevents a lot of low-level activities that C and C++ allowed to that end. MS calls it a "security feature"; the rest of us call it "a pain in the ass".

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.

Originally Posted by Magic

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++?

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.

Originally Posted by Magic

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++?

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.

Originally Posted by Arainach

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.

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.

Originally Posted by BlueMikey

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.

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?

Originally Posted by Arainach

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.

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.

Originally Posted by PUG1911

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.

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