Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
0 user currently in Programming. | 3 guests
Acmlm's Board - I2 Archive - Programming - Easiest programming launguage to learn | |
Pages: 1 2 3Add to favorites | "RSS" Feed | Next newer thread | Next older thread
What launguage do you think is easiest, or one of the easiest to learn?
6502
 
56.2%, 9 votes
65816
 
12.5%, 2 votes
C++
 
18.8%, 3 votes
Java
 
12.5%, 2 votes
Multi-voting is enabled.

User Post
Dish

Spiny
Level: 38

Posts: 150/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 10-30-04 03:44 AM Link | Quote
Originally posted by Atma X
What does it mean when it says that "something" writes to the H Scroll value in $2005 range from 0 to 256. (what is $2005,... is it an address, and if so, why does the H Scroll value have to be at address $2005?)


Before you look into nestech... you should have the basic understanding of 6502. I'm going to assume you know the basic LDA and STA instructions... if you don't concentrate more on the 6502 end before you look into NES specific stuff (NEStech doesn't cover any 6502 stuff... it's all NES-specific hardware stuff).

A CPU 'read' is when the CPU reads a value from somewhere and does something with it. For example... the LDA instruction reads a value and puts it in the Accumulator. A CPU 'write' is just the opposite... it takes a value and writes it to somewhere in memory (or to a register). STA does just this... it takes whatever is in the Accumulator and writes it somewhere.

$2005 is an address, yes... but its the address of a PPU register. PPU registers are how your program interacts with the PPU (picture processing unit - graphics... basically you need to interact with PPU registers to do anything relating to video). $2005 is the Scroll register. So when you write a value to $2005, you're setting the horizontal/vertical scroll for the screen.

I wouldn't worry about scrolling just yet... since it's one of the harder areas.



Can you give me some instructions on that to help me get started?


Well... have you been able to assemble anything yet? Maybe just get anything assembled first... even garbage code. I might be able to help more, but it's awkward doing this on a message board

---EDIT---

http://www.geocities.com/disch_/demo.zip

A little demo I made which just cycles the background color every frame (may induce seizures! XD). One file has the source with very few comments. Another has every little thing commented and explained (with the exception of wait-for-vblank stuff... I didn't want to explain how that worked just yet... status flags and branching and whatnot are arguably the hardest part of 6502, so I figure get the basics first). A binary file which contains the needed iNES header, and a batch file to build the thing is included.

Hopefully it'll help. Lemme know if you have problems building the .nes file (although, the batch file should really take care of it) or if you have any other questions.



BTW: The only thing I saw on irc.esper.net was a "Parent Directory" page .


Well it's an IRC server, you'd need an IRC client. If you get mIRC, you can connect to irc.esper.net and join the chat channels on there.


(edited by Disch on 10-29-04 08:42 PM)
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 1885/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 10-30-04 10:35 AM Link | Quote
Out of those, 6502. 65816 = 6502 with more instructions. Java is quite a pain in the ass with all the libraries and such, and C++... *shudder* If #include and string handling don't get you, the API will.

Really, though, if you just want to learn any form of ASM, try Z80/Gameboy, and for general programming, VB6.


(edited by HyperHacker on 10-30-04 01:36 AM)
Dish

Spiny
Level: 38

Posts: 152/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 10-30-04 11:01 AM Link | Quote
Originally posted by HyperHacker
and C++... *shudder* If #include and string handling don't get you, the API will.


what's so hard about #include?

what do you mean by string handling? strings are the same as arrays. There are several easy ways to change/edit/manipulate strings in C that don't require much effort or are even difficult to learn.

And the API isn't part of the language... it's part of the OS. Granted... the Windows API isn't the easiest thing in the world to pick up, but once you get the idea it's not really that hard to work with. Anyway, the API is something every [decent] language is going to have to interact with.... unless the langauge is so high level that it doesn't really compile to executable code (Java), or unless the language goes out of its way to take functionality from the coder (VB)


Really, though, if you just want to learn any form of ASM, try Z80/Gameboy


I'd agree, that while the resources/tools for GB/Z80 aren't as common, Z80 is probably easier to pick up for a beginner.


and for general programming, VB6.


ew, ew, ew, ew, EEEEWWWWWW

VB is absolutely wretched in every aspect. Sluggish, dependancy heavy, Windows specific, with syntax that looks like absolute hell. VB is like the language for people that want to make programs... but don't really want to know how to program.

I'd even recommend Java over VB. They're both stupid in the same ways... but at least Java is cross platform.



(sorry HyperHacker... but I feel compelled to intervene whenever I see anyone actually recommending VB).
dan

Snap Dragon
Level: 43

Posts: 215/782
EXP: 534516
For next: 30530

Since: 03-15-04

Since last post: 20 hours
Last activity: 14 hours
Posted on 10-30-04 03:03 PM Link | Quote
Originally posted by Disch
(sorry HyperHacker... but I feel compelled to intervene whenever I see anyone actually recommending VB).


Disch, the world needs more people like you.

Personally, I'd recommend something like Python. Seems easy enough to learn, and it forces you into good programming practices (well, in regards to whitespace). Plus, you can create games, GUI based applications, or whatever you want with it.


(edited by dan on 10-30-04 06:04 AM)
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 1908/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 10-31-04 05:16 AM Link | Quote
Well sure, C > VB, but which do you think would be easier for someone just learning programming? As for what I meant by #include, it just drives me looney having to search through a coupla million header files to find a declaration, then include the entire file, sending my EXE's size skyrocketing with dozens of functions and variables I don't need, instead of just having each function and variable included as they're used. Plus, since every compiler uses a different set of library files, one person's code often won't work on another, or even the same compiler. Working with strings is just wretched, and whether it's the language's fault or not, Windoze's API SUCKS, and in VB you don't have to deal with it as much. (Not that I blame them, when your code is comprised of a zillion hacks and patches to something written 20 years ago, of course it's going to be buggy and completely devoid of standards. Still, they need to just delete the whole damn thing and start over.)
Dish

Spiny
Level: 38

Posts: 154/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 10-31-04 06:28 AM Link | Quote
Originally posted by HyperHacker
Well sure, C > VB, but which do you think would be easier for someone just learning programming?


Well... I guess that depends. Basic C syntax isn't hard to learn at ALL. In fact... there's way fewer keywords you have to be familiar with. From what I've seen of VB... it uses unnecessary keywords everywhere when a simple symbol would suffice. It's almost as though they tried to make the language as though you were talking to the computer (which doesn't make it any easier, because you still have to memorize the exact right way to "say" it)

"Dim MyVar As Int" <-- VB
"int MyVar;" <--- C

So while it may be harder to make a functional program with C... learning the C language isn't really that difficult at all.


As for what I meant by #include, it just drives me looney having to search through a coupla million header files to find a declaration, then include the entire file, sending my EXE's size skyrocketing with dozens of functions and variables I don't need, instead of just having each function and variable included as they're used.


Including files is the only logical way a compiler could know what you're doing. You can't use functions/variables that don't exist... and the compiler can't know they exist until it comes across them in code. You #include files which have the function declarations so the compiler knows "okay, SoAndSo is a function".

VB really just goes out of its way to hide the benefits of including files. Instead... it just automatically includes all the regular VB stuff... but all the stuff in the API isn't part of that VB stuff... so when you want to use API stuff (like BitBlt), you can't just #include the file that contains it... you have to redefine the function in your own code. I can't even phathom the logic behind that.

Declare Function GetLastError Lib "kernel32" Alias "GetLastError" () As Long <--- afaik, the VB version to re-declare a single function from the API so you can use it in your program. (again note the excessive and unnecessary use of keywords everywhere).

vs

#include <Windows.h> <--- In C, gives you nearly every function in the API.

And I don't know what you're talking about with that bloated EXE size. Have you looked at VB apps? They're enormous.... even if you ignore the hundreds of extra DLL files and OCX files you need to run them... I mean seriously... open one up in a hex editor. The function names and variable names are stored in the binary. There's no reason for that.

Plus... any decent C compiler (and every C compiler I'm aware of) drops unused functions from the code. If you include a file and don't use anything in it... there's no penalty to the program other than it taking a little longer to compile.



Plus, since every compiler uses a different set of library files, one person's code often won't work on another, or even the same compiler.


Properly written C will compile on any compiler. You'll have to adjust the library linkage when you build, but it's usually just a manner of minor changes (often times, just a matter of changing the file extension of the libraries you're linking to).


Working with strings is just wretched,


strcpy( strA, strB ); // <--- copy strB to strA
strcat( strA, strB ); // <-- append strB to the end of strA
strlen( strA ); // <-- retreive the length of strA
strcmp( strA, strB ); // <-- compare 2 strings to see if they match (case sensitive)
strcmpi( strA, strB ); // <--- ditto, case insensitive

I don't really see what the big deal is. And as a special bonus... C gives you direct access to the memory which holds the string, which makes it MUCH easier to do string maniupulation you can't easily do in VB.


and whether it's the language's fault or not, Windoze's API SUCKS,


The short answer: "If you don't like it, then don't code for Windows"

The long(er) answer:
The API is a necessary evil even in VB. Any VB program that does any kind of serious work uses the API... because the VB methods just don't cut it.

And really... the API isn't all that bad. It's a little hard to learn because there's so many parts to it, but once you get the concept down, it's really simple and straightforward (a few oddities aside).


and in VB you don't have to deal with it as much.


VB automates a lot of aspects of coding... which is why it appears easier to learn. But ultimately, you end up thinking VB's methods are how things are actually happening. It's like a false truth. Anyone that wants to move from VB to something else (which you will HAVE to do if you're at all serious about programming) will have to 'unlearn' a lot of the crap VB got them used to.

Actually...from your comments, I'm going to use you as an example ;D. You seem to have some weird idea that #includes and strings are overly complex... when they're really VERY simple once you understand what they are and how they work. But since you're used to VB, you don't [seem to] really understand what the purpose of including is... or why strings have to be handled a little differently from vanilla ints. VB just makes up its own unique crazy way of doing things that are so far beyond abstract... that languages that do things the right way quickly become unfamiliar.

Which brings me back to my earlier comment: "VB is like the language for people that want to make programs... but don't really want to know how to program." Using VB to program is one step above using RPGMaker to 'program'... unless you do your work in the API... in which case you'd be better off (and have a much easier time) with a different language.

So yeah... VB is a terrible bane to many aspiring programmers. It ultimately just makes the process of learning to program that much longer (learn the wrong way first... before unlearning it to learn the right way). Which is why I butt in whenever I see it being recommended. Telling people to start with VB is doing them a disservice... it'll just make things much much harder for them further down the road.


(edited by Disch on 10-31-04 01:39 AM)
(edited by Disch on 10-31-04 10:33 AM)
neotransotaku

Baby Mario
戻れたら、
誰も気が付く
Level: 87

Posts: 1593/4016
EXP: 6220548
For next: 172226

Since: 03-15-04
From: Outside of Time/Space

Since last post: 11 hours
Last activity: 1 hour
Posted on 11-01-04 09:14 AM Link | Quote
Originally posted by HyperHacker
Still, they need to just delete the whole damn thing and start over.)
Problem with that is the alienation of a bunch of windows programmers who have taken the pain of learning the API. Also, lost of backwards compatibility because in essence, a program written in Windows 1 should run in Windows XP.

But anyways, VB has its merits but doesn't do anything for helping Atma get to his goal. How will learning to program in VB help him in coding assembly? The concept of memory and pointers is totally devoid in VB plus there is no need to learn how to write a GUI interface since the idea of a GUI interface is non-existent at the assembly level. Also, most entry-level programming classes start at the command line level, not GUI.

Anyways, since it seems he wants to get used to the basic concepts of programming, there is a online book that will teach it to him--this book is used as the introductory programming classes at Berkeley, MIT, and a few other institutions: Structure and Interpretations of Computer Programs

Hmm...maybe that is a little too high?
sloat

Level: 16

Posts: 6/85
EXP: 18044
For next: 2212

Since: 05-21-04
From: South Central Delaware

Since last post: 19 days
Last activity: 5 hours
Posted on 11-01-04 11:52 PM Link | Quote
It doesn't really matter which language you learn first. All that matters is that you learn how to program. There's a big difference between knowing how to program and knowing a programming language. In my opinion, if you know how to program, then you can solve a particular problem with just about any language if given enough time and effort.

If you learn one language and can't apply any of it to another language, then maybe you should think about a different career or hobby. The world needs more pottery makers.
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 1930/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 11-02-04 01:09 AM Link | Quote
Filesize? 24K for a VB program that creates a window, or 380K for a C program that does it? Just #include <windows.h> sends the filesize skyrocketing. It makes more sense to me to just tell it what functions you want, instead of including 850 useless ones just for the one you want. (You're right about the idea of storing the variable names in the binary being really stupid though. ) True, I love the basics C's syntax, but having to do everything manually can be a pain. If I'm going to do it that way, I want to do it with ASM, so that I don't have to deal with stupid limitations and pointers to pointers to integers and all that BS. After a few lines of 'someThing->WTF += bhCms(*&&otherThing.cooCoo,*$variable)' I just want to throw up. (Which is another problem, people write such horribly messy code in C, sometimes deliberately. Being able to write everything on one semi-colon-separated line, and crazy things like '#define function1(x) function2(x)' doesn't help. And before you say it, in the real world sometimes you have to edit other peoples' code.)


(edited by HyperHacker on 11-01-04 04:10 PM)
Dish

Spiny
Level: 38

Posts: 155/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 11-02-04 02:20 AM Link | Quote
Originally posted by HyperHacker
Filesize? 24K for a VB program that creates a window, or 380K for a C program that does it?


What are you smoking? I wrote a Full Game in 80k -- and about 40k of that is due to graphics (there's a 40k non-compressed bitmap built into the exe)



Just #include <windows.h> sends the filesize skyrocketing.


You must have missed a paragraph I said earlier, so I'll restate it:

Plus... any decent C compiler (and every C compiler I'm aware of) drops unused functions from the code. If you include a file and don't use anything in it... there's no penalty to the program other than it taking a little longer to compile.

When you #include files, you're typically just including a bunch of declarations. The function bodies themselves lie in libraries on the computer (like in the Kernel) and are NOT built into the exe.

#including does not increase your exe size.


It makes more sense to me to just tell it what functions you want,


That's basically exactly what #including does. There's a list of functions you can use in your code spanned out in several header files. You #include the files you want so that you can have access to all the functions contained in those files.

The extra functions that you don't use in your app get dropped as soon as the compiler finishes parsing your file. They do not affect your exe's file size.


True, I love the basics C's syntax, but having to do everything manually can be a pain.


I'm a little unsure of what you mean by this. The only thing I'm aware of that VB automates that C doesn't is window creation... which takes a total of about 22 lines of code (which you can write once and copy/paste to other apps if you want).

Well that and oddball things... like strings. If VB makes something super-easy that I'm unaware of lemme know.


If I'm going to do it that way, I want to do it with ASM, so that I don't have to deal with stupid limitations and pointers to pointers to integers and all that BS.


What stupid limitations? Anything you can do in asm you can do in C. Although code will typically be faster if written in assembly. And you can even put chunks of asm inside your C code if you want.

Assembly has to deal with pointers just like C does. In fact... lack of decent pointers is one of VB's fatal flaws. Proper use of pointers makes things SO much easier to code. Sure, coming from VB, pointers might seem a little strange... but that kind of is my point. Pointers are a simple, basic, fundamental, and manditory part of programming. The fact that VB doesn't make an effort to teach them is another reason why it's a poor language to start with (or even use).



After a few lines of 'someThing->WTF += bhCms(*&&otherThing.cooCoo,*$variable)' I just want to throw up. (Which is another problem, people write such horribly messy code in C, sometimes deliberately. Being able to write everything on one semi-colon-separated line, and crazy things like '#define function1(x) function2(x)' doesn't help. And before you say it, in the real world sometimes you have to edit other peoples' code.)


Writing sloppy VB is no harder/less common that writing sloppy C. That's hardly a fault of the language. I've seen some pretty hellish VB in my time... but that's up to the programmer... not the language.

And macros (your #define example thing) are an excellent part of the C language. Macros exist in most assemblers as well... and several other languages. If VB doesn't have them... it's just one more reason why it isn't up to par.


(edited by Disch on 11-01-04 05:45 PM)
DahrkDaiz

Red Super Koopa

Acmlm's Mosts 2005
Best ROM Hacker

Level: 45

Posts: 370/885
EXP: 643520
For next: 16644

Since: 03-15-04
From: K-Town

Since last post: 4 hours
Last activity: 4 hours
Posted on 11-02-04 02:39 AM Link | Quote
Also, I'd like to mention the joy of LIBRARIES. A nice set of functions written that can make the hard things EASY. It would be a bitch if you had to write a memory allocation routine everytime you wanted memory in your program, but good ole stdio.h will let you use malloc, or set up a connection to another computer, or create a window.

Your little rant just shows your own ignorance. Anyone who claims VB has any advantage over C besides production speed is just plain retarded.
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 1940/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 11-02-04 06:59 AM Link | Quote
Well, if you find making a window so easy in C, why don't you explain it? I can't make any sense of it. That's really the only reason I still use VB.
BTW, from what you're saying, I'm forced to concluce that Dev-C++ sucks a lot. Time to delete it. It apparently does not remove unused code or resources, and its header declarations are horrible.

There's really no point in arguing, but I feel I should mention that anything you can do in C, you can do in VB (as long as Windoze is running while you do it). Each language has their own advantages. VB is easier and has an easier-to-read syntax, whereas C is faster and is more powerful than VB without the API. The only thing I really have against C is its lack of standards. How often can you just take someone else's code and get it to compile in a different compiler? I even tend to have problems with the same compiler. Someone needs to just lay down a set of standards for them all. (And of course, it's always a lot nicer to get an error like 'overflow' and have the problem area highlighted, than 'this program caused an illegal operation' and have NO idea WTF is wrong. Aren't there any C compilers that can do that?)

Also, what I meant about ASM is that you don't need to deal with weird limitations like having to declare all the functions separately, not being able to do things like grabbing two 16-bit variables with a 32-bit read, etc. Hell, in ASM you can make them whatever size you want. There are no overflows, variables just go from $FFFF to 0. Really, if x86 ASM wasn't so painful, I'd use it.)

BTW: VB has libraries, they're called modules.


(edited by HyperHacker on 11-01-04 10:00 PM)
Dish

Spiny
Level: 38

Posts: 156/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 11-02-04 08:11 AM Link | Quote
Originally posted by HyperHacker
Well, if you find making a window so easy in C, why don't you explain it? I can't make any sense of it. That's really the only reason I still use VB.


I would absolutly love to. Right off I can point you to this excellent tutorial which is actually how I learned. It covers making simple SDI windows (similar style to paint... or notepad). I'd also recommend you look up the CreateWindowEx() function on MSDN for a detailed explaination of all the params (specifically all the available window styles).

If you want to work with Dialogs with pushbuttons and the like (or Forms, or whatever they're called)... I can write up something real quick that explains it. Just lemme know.

As for your Dev-C++ problems... it might be adding debugging info to the build. Debug builds are usually bloated. You usually have to reconfig the compiler for a release build to optimize it. I have no experience with Dev-C++ so I can't really be specific, but I'm sure you could get those exe sizes down.

As for which langauge is easier to learn/read... I'm still convinced C is the simplest... but neither of us are going to convince the other one... so let's just agree to disagree.

And yeah... VB can do most of what C can (I'm still not quite sure about all.... can you do DLL builds in VB? Can you read from the commandline? Have direct access to the message pump?)

I can understand the frustration with getting someone else's code to compile. And I must admit I'm pretty ignorant when it comes to this area -- my experience is pretty much solely with Visual Studio. From what I know... code (if written properly) will compile on any compiler (provided the needed headers/libraries are available), but getting the compiler and linker actually set up to complete the build can be funky. I think makefiles are made to take care of this, but I'm totally clueless about them. I really need to dive into some new compilers .

I'm still not quite sure what you mean by being less limited with asm. But I'll concede that you are less limited (the lower level you go, the more control you have).
sloat

Level: 16

Posts: 7/85
EXP: 18044
For next: 2212

Since: 05-21-04
From: South Central Delaware

Since last post: 19 days
Last activity: 5 hours
Posted on 11-02-04 10:43 AM Link | Quote
VB can't make standard DLL files -- only ActiveX -- and thus can't venture in to the fun fun realm of global and cross-thread message hooks without the assistance of a 3rd party control.

VB can't do variable argument functions.

VB cannot execute multiple threads concurrently. (VB6 anyway. Multithreading is part of the .Net Crapwork)

VB cannot static link anything.

And like Disch said, you can't have direct access to the message pump, unless you create the window from scratch.

I know there's something weird about the stack and GDI. Every GDI intense project I've worked on in VB had frequent stack overflows.

Those are the only reasons I can remember that I hated VB for.
dan

Snap Dragon
Level: 43

Posts: 223/782
EXP: 534516
For next: 30530

Since: 03-15-04

Since last post: 20 hours
Last activity: 14 hours
Posted on 11-02-04 11:29 PM Link | Quote
Dev-C++ isn't a compiler. It's an IDE for Mingw.
Dish

Spiny
Level: 38

Posts: 160/596
EXP: 355646
For next: 14801

Since: 03-15-04
From: Disch

Since last post: 18 days
Last activity: 18 days
Posted on 11-02-04 11:41 PM Link | Quote
I thought Mingw was an IDE for gcc/g++

bah... shows what I know about different compilers lol
neotransotaku

Baby Mario
戻れたら、
誰も気が付く
Level: 87

Posts: 1603/4016
EXP: 6220548
For next: 172226

Since: 03-15-04
From: Outside of Time/Space

Since last post: 11 hours
Last activity: 1 hour
Posted on 11-03-04 03:59 AM Link | Quote
i find it interesting that the gcc that is available for windows relies on MingGW to run... so you were right in thinking there is a relationship between the two...
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 1948/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 11-03-04 04:26 AM Link | Quote
IDE, compiler, either way it's a buggy piece of crap. Anyone recommend a better one? I have Visual Studio, but their C++ IDE isn't the most stable thing in the world either. (Once crashed just when I hit a scrollbar. )

Yes, I'm convinced that I'm not going to convince you that VB > C, and you're not going to convince me that C (entirely) > VB. (Mostly, yes, but VB has it ups. ) No point in arguing over it anyway.

As for what I meant about limitations, here's some ASM stuff that I don't think you can do (at least not easily, if at all) in C:

somefunction:
[some instructions here]
.subfunction:
[more instructions here]
ret

call somefunction.subfunction

Thus skipping some of the instructions in somefunction instead of having to write a duplicate function without them.

somefunction:
[some instructions here]
ret

otherfunction:
[some instructions here]
jp somefunction


Thus going directly from otherfunction to somefunction, which saves an instruction (don't need to do 'ret' after otherfunction) and some stack space (don't need to store the address it came from).

As far as VB goes...
-You can make ActiveX DLLs. I dunno exactly what you mean by DLL builds.
-If by 'read from the commandline' you mean using command line parameters, then yes. Check command$.
-Message pump meaning window messages? You can use subclassing to have a specific function process each one, but it's somewhat risky.

Sloat:
-It can't?
-It is possible, using optional instructions or arrays. Or of course you can do it the ASM way and declare variables to hold your parameters.
-Er, yeah, I forgot about that. You can do multithreading, but it's VERY unstable. (VB5 didn't have a problem with it, IIRC. )
-What specifically do you mean by static link?
-If you're talking about window messages, like I said, subclass.
-I've never had overflow problems using the GDI. Only when I accidentally created a function that called itself in a loop.

BTW, thanks for the tutorial. Maybe I'll be able to understand this one.
neotransotaku

Baby Mario
戻れたら、
誰も気が付く
Level: 87

Posts: 1607/4016
EXP: 6220548
For next: 172226

Since: 03-15-04
From: Outside of Time/Space

Since last post: 11 hours
Last activity: 1 hour
Posted on 11-03-04 04:48 AM Link | Quote
Originally posted by HyperHacker
somefunction:
[some instructions here]
.subfunction:
[more instructions here]
ret

call somefunction.subfunction

Thus skipping some of the instructions in somefunction instead of having to write a duplicate function without them.

somefunction:
[some instructions here]
ret

otherfunction:
[some instructions here]
jp somefunction


Thus going directly from otherfunction to somefunction, which saves an instruction (don't need to do 'ret' after otherfunction) and some stack space (don't need to store the address it came from).
Here is the example in C that almost does that:
  void foo() // somefunction
{
//some work part1
bar();
}

void bar() // .subfunction
{
//some work part2
}

// global variables to simulate registers


but anyways, a good compiler should see that is the case and will optimize the resulting C code to do the ASM you have described.


(edited by neotransotaku on 11-02-04 07:50 PM)
HyperLamer
<||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people

Sesshomaru
Tamaranian

Level: 118

Posts: 1949/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 11-03-04 05:12 AM Link | Quote
Hey, that's not a bad idea. I didn't think they'd optimize it like that.
Pages: 1 2 3Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Programming - Easiest programming launguage to learn | |


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.103 seconds.