Printable View
That should be typedef int bool; or whatever way round it goes :pQuote:
Originally posted by filburt1
This is my favorite macro definition set:
No more including bool.h for older C++ libraries! :)Code:#define bool int
#define true 1
#define false 0
And just get a new compiler if it doesn't support bool :D
That's actually a very complicated qwestion to answer. With current available compilers C++ is leading, but as a matter of fact the language forms the programmer as well as the programmer forms the code, so C++ has it's unique advantages. The very statements provide much more flexibility, in vb you either use the integrated calls ones or do simple lefthanded assignment. C++ is partly lowlevel partly OOP language, and besides all that there's templates (ooh, I love those) so while having the ability to maintain extreemly reusable (and I mean Vb or even Java has nothing comparable) interfaces the language supports detailed refinements and optimizations, if that's not enough, the compilers supports inline asembly as well. The operators and methods in C++ all return values, including unary operators, almost all operators can be overloaded and used for user specific purposes with user specific types, the statements are mainly operator/function tree's which evaluate and assigns as the the operators/functions executes, that provides the flexibility that C++ is so popular for. Although most C++ users have a RAD instinct, C++ really most powerful when used for OOP, those who've realized that power must know why, and there's probably no other way to understand it but learn it by yourself.
typedef's are aliases, not macros ;) and macro's aren't evil if they are used correct, M$ inlining can't be trusted
I know they're aliases :p
I never trust anything, although occasionally it gets something right (I checked the listing on a few things but never worked out just WHY it wouldn't inline certain things).
vb strings suck up 10 bytes + 2 bytes per character
the later since Vb default strings are unicode
byte strings suck up 22 bytes + 1 byte per character, but I don't see many vb users actually use them
did you use the 3 pragmas? I haven't tried on looking at listings, i think i need a hexeditor that disassebles but I haven't had time to get one
I think WinHex does disassembly - haven't tried it out yet.
I played with the pragmas but didn't have the time or the inclination at that moment.
WinHex, I'll check it out some time
In addition to pointers, structs, unions, and classes, your new language should support hashes and anonymous variables.
Oh, wait, that's Perl. :) Guess we don't need a new language. ;)
I'm complaining because I'm using VBScript in ASPs (at the client's request, not mine) and the only data structure I can use is MULTI-DEMENSIONAL ARRAYS!!! That sucks so much.
It can't get worse than that :p
Hey CiberThug, hashes and the other stuff I know, but what are anonymous variables. By the way, I havent given you the full specification for Ciyana yet, thats why you underestimate it.There are things in Ciyana that no other programming language has. I am on research for now but soon, things will get hot. i am sure Perl is cool but you wait......gotta go.
They are just that, variables that you don't know the name of. But how do you reffer to them? Well, somone knows their name. :)
Here is a bit of Perl code to demonstrate.
Now that is very simple code, and I've left out a lot. Let's say you have a Resource with the name MyResource and an ID of 001. There will be a key/value pair in the hash of 001/MyResource. And now there will be an array with the variable name MyResource that contains all of the response times for MyResource.Code:
// We are going to raid a DB and get a list of resources
// and their UIDs. Then we are going to build an array of their
// response times.
my %Resources;
my $RS = FuncToReturnRecordSet(myDB);
foreach my $record ($RS) {
// We will step through each record in the record set and
// put the UIDs and Resource Names in a hash
$Resources{$record->{UID}} = $record->{Name};
// This creates a UID/Resource Name key/value pair.
}
foreach my $currUID (keys(%Resources)) {
// We are now going to step through our list of IDs in our
// hash and do a DB look up. Now we could just use pointers,
// but we are going to create an anonymous array of the values
$RS = FuncToReturnRecordSet(myDB, $currUID);
my @$Records{$currUID};
foreach $record ($RS) {
push(@$Records{$currUID}, $record);
}
}
The variable's name is "@MyResource", but you don't explicitly know that when you write the code. Everytime you call that variable, you call another one which gives you that one's name.
So if I want to find the second response time fo MyResource I would ask "$MyResource[1]". 'Course, in the code, something had to trigger that, and whatever triggered that will hopefully supply resource name (in say a $ResourceName variable) or the UID (again in a $UID variable).
Now I ask for "$$ResourceName[1]" or "$$Resources{$UID}[1]".
Again, you can use pointers to accomplish this. In Perl "->" is the dereference operator for pointers. You see where I have "$$". That is analogous to dereferencing my anonymous variables.
'Course, I've been working in VB/VBScript for the last six months, so my Perl may be rusty. But hopefully you get the idea.
You hopefully don't need to know Perl to understand what I've just done.
Oh I see what you mean. A bit like PHP? Probably nicked from Perl ;)That sort of thing?PHP Code:$n = "myvar";
$myvar = 5;
$$n = 10;
# $myvar is now 10
Exactly Parksie.
A lot of PHP is nicked from Perl.
And I can see why, they're bloody useful some of those things :) Plus it makes it dead easy for Perl programmers to use.
When I started in computers I didn't have C, I didn't even have assembly. I started with machine code. Wow - those were the days. Wiring your own cpu's. Lot's of fun.
When considering languages you always end up with the big dilemma ... you want a language that is low-level to be fast, but it should be built to be portable. These two things force you to compromise.
Some platforms use segmented memory, some use linear, and some even use banking. This can make pointer arithmetic a non-issue. Perhaps there is some merit to dereferencing variables after all! However, this is a huge topic.
ericmuttta asked if it's the language or the compiler that make efficiency. My first answer is, the compiler. However, the language itself may contain aspects that make it difficult to be efficient. So both play a role in the potential of efficient binary code.
(By the way, all you people who say C is the most powerful and there is no need for readability. I propose you write in Machine. After all, it is the MOST powerful and the least readable (some say). The point here is that blasting VB because of it's readability is not logical. It is possible to have a readible language that is every bit as powerful as C - although, that is NOT VB.)
So why should we care about readability? Well, it sure makes troubleshooting easier. If I were to write in shorthand, my mistakes would not be so obvious - after all, one mistaken letter changes the entire word it's meant to encode. On the other hand, a long word is in context with the other letters around it, and, therefore, it is easier to catch something out of place.
.....
I could always develop MUCH quicker than those using C. Don't get me wrong, I love C. C is power and efficiency.
I have read people say VB sucks. LOL. This is not true. VB is quite useful. However, it's just like a road trip. I love nice fast looking sports cars as much as the next guy, but, you would rather take a 4x4 into the mountains. This is my point. Each has it's own use. If your gonna write a device driver or an OS, you pretty much MUST write it in C.
VB can produce programs quickly. I have written many market programs in VB. However, I have found that only-VB programmers (because they started here and do not really understand the machine) cannot write powerful VB programs (this is an important statement).
I HAVE been able to write powerful VB programs. (Even in Basic days, I was doing stuff that others could not. However, note, that I did have to write my own assembly library. Some things in Basic were just too slow.) Even in C do we not sometimes put inline assembly in?
As some have said here, and I agree, getting 'low' in the frame of things gives you an better understanding of the machine - C is closer than VB, no doubt. I think learning assembly would be wise for every programmer to start with. I also think playing with the electronics is very empowering too. For, no matter what language I have used in my life (even some mainframe ones) - understanding the machine reduces your learning curve A LOT.
Someone here said that before you embark on a new language, you should learn C. I strongly agree. I have also heard a lot of people wanting to write an OS. They too should study other OS's to know what the long-term issues are. DDE, OLE, COM, DCOM, Automation ... they all came about because of need. This need would also exist in any new OS. Perhaps with a different implementation, but still the need.
.....
This next comment is to make us think. What is more efficient?
So, lets all ask ourselves a question. We go to make a new language. We want strings, of course. How would you choose to implement the string philosophy?
In Basic, strings have a length and may contain binary 0. So, if I am manipulating large sets of strings, obtaining the lengths IS EFFICIENT.
In C, strings do not contain a length and may not contain a binary 0 - indeed this 0 tells you it's length. If I am manipulating large sets of strings, obtaining lengths IS NOT EFFICIENT (at least compared to Basic).
(YES, Basic is MORE EFFICIENT HERE. Don't believe me. Run the tests.)
.....
Remember that ultimately VB uses pointers just as much as C. It simply hides most of this from you. For those unaware, pointers are quite exposed and accessible in VB now.
I was interested that others were discussing platform issues here. Generally, extensibility is becoming the important thing, not low-level efficiency. Our computers are running faster and faster everyday. Perhaps we should just have a variable and let the platform-specific compiler do the dirty work. This does tend to be the direction OS's are going. COM and DCOM. In the end, perhaps, that variable might actually be on another computer altogether, thus having no local pointer to speak of.
Good point, but I suppose if you wanted something like that then you could just have a struct containing a pointer and a length. Or just prepend the length - I did that a couple of times, leading to such lovely code as:Quote:
In Basic, strings have a length and may contain binary 0. So, if I am manipulating large sets of strings, obtaining the lengths IS EFFICIENT.
In C, strings do not contain a length and may not contain a binary 0 - indeed this 0 tells you it's length. If I am manipulating large sets of strings, obtaining lengths IS NOT EFFICIENT (at least compared to Basic).
(YES, Basic is MORE EFFICIENT HERE. Don't believe me. Run the tests.)
Add a few choice functions to that and you can use binary zeros. I haven't ever really found much need for NULL in a C string, so I use it as-is.Code:printf("%s\n", ptr+4);
Exactly parksie. Hmmm. We even have to do 'dirty' tricks in C somethimes too.
If you were going to manipulate binary data in C, you would probably allocate a chunk of memory from the heap and use the returned pointer. The exact way I do it in VB.
I agree, strings are not really the place for byte 0 and they rarely show up there. The interesting point of discussion is the length aspect.
This is what VB does. :-)Quote:
Good point, but I suppose if you wanted something like that then you could just have a struct containing pointer and a length.
Yep. Although it does it with the aid of a huge runtime DLL... ;)Quote:
Originally posted by Jay Rogozinsky
This is what VB does. :-)
I don't bash languages for the sake of it (except for Pascal because I hate it), and there are a lot of places where I wouldn't use C++. For example, databases. I'd much rather use VB and ADO than C++ (considering VC++ can't even compile the MS ADO sample projects I gave up on learning that). And Perl has its place for a lot of things (such as my VB->HTML converter).
Yes, let us not forget that C also utilizes a runtime DLL.
VB has always been a great place to slap off a conversion utility or such.
Does it? I only use the runtime DLL for C when I can control the target environment - normally I make them self-contained.
Msvcrt.dll contains calls such as strlen, printf, malloc, puts, etc. Msvcrt.dll has been succeeded by Msvcrt20.dll, Msvcrt40.dll, etc.
If you use those calls, you are using Msvcrtxx.dll. This dll, and likely some of the successors, will exist on ALL Windows systems. This is why you don't have to worry about them being there and your code always seems to work.
Only if you write very simple programs will no DLL calls be made. For instance, a simple variable increment in C requires NO outside calls - it can simply be an INC instruction on the processor.
Now, is it possible to have a compiler extract (some or all) of this code from the DLL and put it into a stand alone EXE? Yes. Does C let you do this - I don't know.
Even if it does, it does not negate the point. Both VB and C give you access to standard calls and those calls are not your code - they exist in a support DLL.
So your 'self-contained' program still relies on C library code - no matter if it's stripped into your EXE or not.Quote:
Does it? I only use the runtime DLL for C when I can control the target environment - normally I make them self-contained.
If you can, and do, put this code into your own EXE you are defeating the purpose of DLL's and also you are disallowing your end-users from upgrading a potentially buggy DLL call (i.e. even if they upgrade their Msvcrtxx.dll - your program will still exhibit the bug).
VB has the Dll due to the compiler, I heard of compiler that compile VB into standalone exe's so runtime's shouldn't be part of when considering languages, but part of compilers.
I use C++ not C, because C doesn't have the power of OOP. I'd say most programmers, quite close to 100% around here use RAD-style programming mainly, that's of course how a simple one purpose application could be programmed most effectively in time perspective, the available API's just need to be called in the correct order and that's that, hardly you do any real OOP work. These API makes your application dependent and unportable.
OOP work should be platform independent, and so C++ does perfectly, there's no need for strllen's or printf's but in RAD style projects. The main point with OOP applications is reusability, a base to derive other projects from, much the style you need for developing API's. Such interfaces where other programmers derive your work has to be as flexible as possible, well encapsulated to avoid unintended misuse, easy to use and not to forget with best possible performance. Of course you need to do compromises between these but with a poweful OOP language as C++ the performance losses are quite minimal. VB, C and ASM are far from useful in this style of programming.
The clients of enough powerful interfaces shouldn't consider about what language is most efficient in the first place but the usefullness, since if the base interface does all time critical jobs any language could be used to put them together into a interface for the end user.
Im half way reading through this post and i am having fun. But who ever said {} brackets or braces (what ever you want to call them) are mainly for scope. Not for tidying up your code.
Has anyone ever programed using Lisp, Python, or Ada?
And if so what are the strong points for each language. I heard Lisp is mainly used for AI. And Python for server stuff. Is that true?
I don't know LISP but it's short for 'list processing' which tells you a fair bit about what the language is good for. It's certainly used for a lot of AI stuff. Has too many parenthesis for my comfort though.
Python is a fully object oriented, platform independant scripting language, and I use it a lot. It's very flexible and easy to use and read (especially if you are familiar with C syntax), although it's not compiled to native machine code, so it can be slower than some languages. Still, it's fast enough for me and it's easily extensible with C/C++ modules if you want some more speed. It's mostly used for CGI apps at the moment, and in the scientific community.
Ada is more or less an even stricter version of Pascal (yikes!), which is great if you're writing code to run an ejector seat but pretty tedious if you're writing non-critical code. It's one of those must-be-bug-free kind of languages; the military use it quite a bit.
"Operator Overloading, probably the best beer in the world"
td.
VC++ has linker options. You can either link with the DLL stub library, or use the ACTUAL static library. The default is in fact to use the static library so if you use the normal settings you don't need any DLLs other than the system ones. And yes, it needs library code, but you can strip a lot of that out by writing your own _mainCRTStartup function and being careful (you also need to rewrite a few of the library functions but you can get them from the source if necessary). This makes stupidly small executables with no external dependencies (other than the system).Quote:
Originally posted by Jay Rogozinsky
Msvcrt.dll contains calls such as strlen, printf, malloc, puts, etc. Msvcrt.dll has been succeeded by Msvcrt20.dll, Msvcrt40.dll, etc.
If you use those calls, you are using Msvcrtxx.dll. This dll, and likely some of the successors, will exist on ALL Windows systems. This is why you don't have to worry about them being there and your code always seems to work.
Only if you write very simple programs will no DLL calls be made. For instance, a simple variable increment in C requires NO outside calls - it can simply be an INC instruction on the processor.
Now, is it possible to have a compiler extract (some or all) of this code from the DLL and put it into a stand alone EXE? Yes. Does C let you do this - I don't know.
Even if it does, it does not negate the point. Both VB and C give you access to standard calls and those calls are not your code - they exist in a support DLL.
So your 'self-contained' program still relies on C library code - no matter if it's stripped into your EXE or not.
If you can, and do, put this code into your own EXE you are defeating the purpose of DLL's and also you are disallowing your end-users from upgrading a potentially buggy DLL call (i.e. even if they upgrade their Msvcrtxx.dll - your program will still exhibit the bug).
Dont forget all these banks, financial companies, insurance co.s, etc... that use VB. It is useful for internal database apps. As I have said many times though, when it comes to mainstream commercial apps, i challenge you to find a successful, decent one made in VB.Quote:
Originally posted by Jay Rogozinsky
Yes, let us not forget that C also utilizes a runtime DLL.
VB has always been a great place to slap off a conversion utility or such.
Heh :p
Wow this has just got to be the thread in town....lets keep talking.
Hooray Jay, thanks for your enlightenment. Gosh you had to write in machine code?!!???, that must have been fun huh? Well I am the moment am learning assembly language. I will need it for systems programming later on (early anouncement of the death of Windows and the birth of....I dunno but its coming no more crashes and BSOD's LOL.) Also this compiler that I am making for Ciyana will need the stuff.
You know you guys are right. Learning VB as a first language is fun but thats until you become proficient and start asking questions. I have been using VB for some time now and I wanted to know what on earth goes on within the chunks of silicon on my desk. You ask VB what Form.Visible=False means it tells you its gonna hide your form nnnnnnnnnnhhhhhhhhggggg!!!!! wrong answer its SendMessage(hWnd,SW_HIDE,0&,0&) (hope i got that right). Well those are the kind of answers I was looking for but good ol Vb just hides them. NOT FUN WHEN YOU REALLY WANNA KNOW WHATS UP. So I started learning windows programming. I have a windows skeleton program written using the API and a couple of BAS modules.Its about 400 lines long and all it does is register a window, show it,have two little menus and an empty About box .....HELLELUJAH FOR VB SOMETIMES.....you'd be surprised how much it really does for you. So anyway the point is I wanna go low level and know the real truth and C++, ASM all take the cake. Now i know why its never a good idea to use Goto statements (leads to flushing the prefetch queue on some pcs meaning data has to be fetched all over again) or how you can call a function give it a couple of bit values and have it work out what ORing/ANDing etc those bit values would produce without ever writing the expression. (boolean algebra..you gotta love the stuff). Plus theres more but hey thats for another day.
DONT ANYBODY STOP TALKING THIS DISCUSION IS FOR THE AGES I GOTTA GO BUT I WILL BE BACK. And yeah thanks for answering my efficiency question. Oh so does this mean the C++ compiler writers at microsoft are better than the VB ones??? HERE IS A SECRET EVERYONE, YOU KNOW THE VB COMPILER AND THE C++ COMPILER................SSHHHHHHHSSHHH THEY ARE THE SAME THING!!!!!!Tell you more later.(eric is taken away by a horde of guards from the secret Gates society nooooooooooo.....)
Now
You sure sound excited :p
A lot of people here know more about C and VB than I do, but thanks. I know exactly how things work, just not the specifics in some cases.Quote:
Hooray Jay, thanks for your enlightenment
Ya. OMG. Hundreds of hand written pages containing OP CODES (1F, A9, ADC, MOV, etc). Everytime a serious correction was made, many of those pages were re-written. The code was entered with dip-switches. HeHe. I built a significant amount of the electronics too. I worked on the same stuff Bill Gates started on. S100 bus type systems (the name IMSAI rings a bell, or something like that). 8080 and 80x88 processors (the pre 80x86 stuff) - then some Z80 processors too were used. The only sound we had was turning on a standard radio and listening to the loops execute (by the system generated electrical noise). Memories! :-) And yes, it was a blast.Quote:
Gosh you had to write in machine code?!!???
It was around this period that we made the rocket sled (playing with science and physics) - but thats another story.
I can see the Linker being the same ... but the compiler? Neat.Quote:
HERE IS A SECRET EVERYONE, YOU KNOW THE VB COMPILER AND THE C++ COMPILER................SSHHHHHHHSSHHH THEY ARE THE SAME THING!!!!!!
Then why aren't you a billionaire?Quote:
Originally posted by Jay Rogozinsky
I worked on the same stuff Bill Gates started on.
What makes you presume I'm not. :-)
blah compile blah blah boot sector... 1:23 and Im drunk........
:p
Cuz I ain't seen yer name in Forbes.Quote:
Originally posted by Jay Rogozinsky
What makes you presume I'm not. :-)
Ha!
Hello people, I have returned. So what have I missed?
Well Ciyana is going on well and I had some insipiration today on thoughts about the execution and debugging of programs. Does anybody know where I can get material on debuggers and intepreters? I need to know how they work so I can use them for Ciyana.
So far about the intepreter I have the following ideas.
Variables and the likes will be stored in files during the intepretation of code.
When the code refers to a variable,using some specialised routines,I can read the values as they are in the files, work on them and store the results back in the files.
Built in functions will be implemented as follows.Say the code reads: a = Sqrt(b). What I would do is the following. From the file, I would read the current value of b into a vb variable say an integer. I would then call the Sqrt function (which I would write myself) to get what the result is. Then the value would be saved to file where "a" has its space.
My current code library contains over 3000 lines of code (about 81 string functions ,rougly 30 mathematical functions, 10 logical functions and 4 sort and search functions) Yep I have been writing this library for the past 6 months and everyday it continues to grow. I intend to include it as part of the Ciyana runtime libraries. Ciyana by the way is going to be very powerful when it comes to text processing.Why? what do compilers,word processors, browsers, intepreters etc work with? TEXT TEXT TEXT. The more functions there are to deal with text the better.I have functions to select individual words,swap them, move them, replace them,expand them,encrypt them, analyse facts about them etc. All this is to be used for the Ciyana compiler itself.
If anyone wants any of it, as soon as I can get it into a DLL ,I can mail you a copy(let me know at: [email protected])
So then people lets share our ideas about how compilers and intepreters work. I will return and we can start right with VB itself.Meanwhile keep chatting and see ya. Eric.
cuz gates didnt do jack $hi7. He just bought the rite stuff at the rite timeQuote:
Originally posted by aknisely
Then why aren't you a billionaire?