Quote:
Originally Posted by paxemuman
Talk still with peoples about how bad its vb6, how nice is c, c++. Maybe you all should code in ASM its fater than c++ then i am sure you will make huge progress with your emulator(talking instead coding its what Merlin do many years already, and look at his progress ).
Btw.
Better is write whole emu in vb6, and later just rewrite in c++ for performance than start coding in c++ and never finish it. C++ gives you more control on your code but its needs more precision and time from you.Thats why i think most of you have not enought time for finish real emulator(not programmers skills but time its biggest problem in this case).
|
It'd be nice if you knew anything about what you're talking about. You clearly don't know the history of any languages and you clearly don't know any of the languages you're talking about.
1. VB6 is bad. It is the successor to BASIC. BASIC wasn't bad, but it was an ancient language and its predecessors were very difficult to use languages, and it was very ASM like. As VB progressed it became more and more high level, culminating with today's VB.NET which is sitting atop one of the largest SDKs in the history of programming languages, the .NET framework.
Visual basic was originally a modified form of BASIC that allowed you to easily edit and create Windows components. This language was designed by Microsoft and they provided the VB IDE to do the visual editing. The last stable release made by Microsoft of their Visual Basic IDE and compiler was VB6, which was released in 1998. VB6 hit EOL in 2005 and for extended support in 2008. It was declared deprecated and unsupported in 2008. The runtime library, however, to allow legacy applications to continue running, is still supported.
VB6 was never highly popular. Its only strength was making and editing windows which was a feature highly embedded into the language. It removed a lot of previous notions of BASIC and was wholly a different language. It had been designed around the concept of forms and OOP at a very abstract level. At first it implemented this in P-code which was similar to intermediate code today, but less efficient as it was interpreted. In VB5+ binary compilation was introduced but it depended wholly on the runtime, including even basic operations in the code.
For instance:
This code would result in a call to some method to update a variable. It would pass the type of the value along with the value as a parameter. As you can imagine, this is unbelievably inefficient, but this was long before the notions of customized intermediate languages with virtual machines executing a higher-level binary code at high speeds -- see: MSIL, Java bytecode.
It was unbearably slow, even on fast systems. It hogged memory because every variable was wrapped in an ugly inefficient and large wrapper. It was just plain bad. But it was VERY easy to set up a window and manipulate it, so it gained ground in corporate software design for the front-end on applications. You'd import DLL functions to do the real work and just present the user with this nice, separately developed interface which, since it didn't really do any work other than displaying, didn't slow down the application much. Also, it was quite popular with the hacking crowd, esp. writing AOL and AIM proggies and punters/phaders/phishers/etc. in, as you could easily make a window interface and hook up with the DLL api that let you do the "fun stuff."
It was never hugely popular nor successful like VB.NET has been. It was taught in academia to demonstrate windows, since windowing API in C/C++ was still horribly scary to work with. Though there was Visual C++ which featured "almost" the standard C++ language coupled with an IDE to transparently use MFC to easily create windows from within C++, but the MFC sucks so nobody liked it. What has been far more successful is Microsoft's VBScript which is commonly used in systems administration to accomplish simple scripting tasks but even that is being phased out in favor of things like PowerShell, Python, and even PHP or Javascript.
2. C was designed by ASM programmers at Bell Labs who were working on UNIX in PDP-11 assembly in 1972. It was designed to be highly efficient being very close to the hardware and was designed to be simple, and specifically to excel at systems programming. To this day, C is very simple. It therefore leaves all control of memory management to the programmer. It is predictably converted to ASM allowing you to highly optimize your code with knowledge of your target platform's hardware, and in fact by design it allowed you to insert assembly inline with a special language keyword. This makes it superb as a systems programming language. This speed, level of control, and simplicity have made it one of the most popular programming languages ever conceived and still one of the most popular in use TODAY, almost 40 years after its creation. It has by far the largest library base available to any language. A lot of the oddities of the original version have been removed by standards, the latest of which is the C99 which almost no compiler completely supports, though lots support a large portion of it. MSVC++ does not support even a tiny fraction of it, GNU's C compiler implements most of it.
3. C++ was designed as an improved C with OOP support, ie. classes, by Bjarne Stroustrup in from 1979 to 1983. Since then it has been continually improved and is currently undergoing its next major upgrade to the "C++0x" standard, outlined in the TR1, which is now probably just called the C++1x standard. C++ isn't considered a high level language because it supports both high level language concepts and extremely low level ones. It contains as a subset almost all of standard C outside of oddities in the syntax that make compilation more difficult. Similarly, it implements OOP abstracts that are even higher than those in Java in many respects, and as of C++0x includes new features like variadic templates, lambda functions or closures, and rvalue references. While doing so, it is extremely fast, and most of its features are still implementable in C but in some cases require a large amount of code to replicate the same features. Its ability to redefine operators cannot be done in C without preprocessor programming and toolchaining that would frighten anyone but Linus Torvalds. Due to its rich feature set, C++ is incredibly complex. As a result, it is one of the hardest languages to master that exists. Java borrowed almost all of its syntax from C++, and it was meant to be a simpler C++ focusing mainly on the OOP side, removing most of the low level features, and a lot of the complexities that make C++ so difficult to master.
C++ has become nearly as popular presently as C, and its compatibility with C and ability through standard calling conventions to use C libraries (as well as for C code to use C++ libraries) have made the two largely interchangeable within a project, leaving us with 'C/C++' as a common term referring to the mixture of both, or coding in a C-like subset of C++.
Now.
Coding in C++ is much faster than coding in VB6. This is because C++ has much more features for prototyping than does VB6. Your argument claiming that C++ would be "slower" is ignorant. Most languages aren't faster for development than C++ except at specific tasks or at a very high abstraction level which results in a tremendous drop in performance. VB6 isn't one of them. Many rapid prototyping languages would excel in a toolchain to develop an emulator, including Javascript, Lua, Python, Lisp, and some others. VB6 isn't even close to being on that list.
Your comment about coding it in ASM is a common "if you want it to be fast, just go with the lowest level language!" argument. It's naive and ignorant. ASM can be faster if you code it specifically for a subset of CPUs and take advantage of features that are highly unportable and don't follow standard ABI practices that higher level languages do when constructing machine code, such as what's passed around in registers, etc. This level of optimization in hand code leads to highly unportable, impossible to maintain, and messy ASM code. Further, most C/C++ compilers on their most aggressive optimization levels can easily produce more efficient ASM than even good ASM programmers may. As a result, it's generally a waste of time to program something in ASM unless the capability simply isn't available in C/C++ or a higher level language. See a project of mine that needed to do this:
I'm still not done with it but the jDetours there needs ASM to do what it does. And I'll be adding an x86-64 assembler & disassembler in the future to that project to do it on the fly instead of hard-coding opcodes.
Your comment about me tells me that you are highly uninformed. Let's compare, shall we? I have a college degree. I own my own home. I own my own car. I have a full time job. And I've had various female friends over the past few years. These have all been combined over the last 5 years which has left almost no time for recreational software development. Couple that with the fact that I stopped development on SREmu for most of it and went on to work on various other projects and there you have it. SREmu isn't done because C++ was slow and it's taken me 5 years to write it. SREmu isn't done because I've just now started working on it again. Before I stopped, I had a highly efficient back-end system working and tested, but before I finished that, the other coders in my team left the project. Just so everyone knows, as always, your analysis is highly flawed and completely ignorant of the facts. You don't bother learning anything before you make a wild assumption.
There are projects that are 1000x bigger than any emulator anyone on this board will ever write that were started in C++ and finished in C++ on time. The size of the project doesn't matter. It's the programmers involved. Experienced C++ experts can easily finish a project they start in C++ without much hassle. Noobs cannot. Anyone who thinks C++ requires "more time" to get the performance it offers has never worked much with it. Yes, it is extremely complex. No, if you know the language, it doesn't require tons of time to do something well.
Please put some thought into your posts in the future. I don't need to continue destroying you with these posts that point out that everything in your entire post is completely incorrect and the result of highly flawed logic.
