Amigo, This is a mucho excelente site!!! GREAT RESOURCE! Sonork ID: 0.2

Oliver, I've checked up and down every resource I know and I've compiled several tests on VCC using multithreaded (to check the assembly output) and yes: Short Circuit and proper register re-loading are done everytime. So, you're right.. the short circuit would solve the (ptr==NULL&&ptr->member!=0) issue. However, even after aknowledging that the example was a bad one, I must insist on the fact that even when goto can be avoided every time, sometimes avoiding it causes you to write less efficient code. Also consider that, at the very end, your assembly output is nothing but a huge set of "gotos" all over the place.. and the closer you get to the machine's language, the more efficient you potentialy can get.. (and yes: the more unreadable your code can also get) Thanks for having taken your time on replying to this.. I will now start relying more heavily (shiver) on short circuit evaluation. Sonork ID: 0.2

Nice to see this forums does have a lot of life, and even better to see people that know their stuff. Rassman: Of course I agree with re-using other people's code .. hehe.. I'm not in the mood of re-writing a web-browser, and even less on re-writing the APIs! ;) I'm referring to my own code, and let me tell you why: I used to use STL every chance I had, then.. I looked at the dissasembly and found some pretty ugly code.. ok, I can deal with that.. but then.. if you look at the compiler's fixed bugs (buglist?) on SP2.. you'll see that hundreds of the fixes where related to the STL! omg: So, many of my bugs where caused by external code over which I had no control! all I could do was sit and wait till MS decided it was ok to launch the patch. This is, of course, unacceptable when you're running a commercial product where customers are all over you: You simply can't answer "er... the exception code was not done be me.. so you have to wait until 3rd-party releases a fix" An example: I do use exceptions in Sonork's integrated browser.. but I've made it a separate DLL so that I don't need to use exceptions in the main code.. this reduced the [main] code from 950Kb to almost 750Kb (a 21% reduction) Also, when I started porting to Linux (GCC), the GCC manual stated (at that time) that.. "exception handling is buggy" ::eek: That's the reason why I avoid (whenever possible) 3rd party code and compiler-dependency and always consider the possibility of re-inventing the wheel (based on 3rd part code) if that code is not too much/complex. But, as everyone has already stated... that is a personal choice... at the end, both ways will work, one'll give you less work, but more compiler-dependability, the other one more work, but more control. Just a matter of prios. Sonork ID: 0.2

Oliver,
You're assuming a compiler (VCC), which is fine (and undesrtandable in a MS-oriented forum) but, if you never indend your code to be compiled anywhere else, it is not alright
Are you sure BC does this? and what about GCC? how about Symantec's?
Where does the short circuit evaluation happen? in the compiler or in the optimizer? if in the second, which flag enables/disables this option? How about multithreaded applications? what if ptr is loaded into a register before entering the critical section but changed by another thread? See? too much relying on your compiler.. I don't buy that. I'm a C-programmer legacy which hates goto, but hates even more tool-dependency (reason for which I avoid as much as I can frameworks like MFC) VCC states it does that, ok.. but the C/C++ specs say that the compiler can evaluate expressions in ANY order the compiler thinks fit (as long as the result is the same)
Maybe my example doesn't apply well to VCC, but the idea still stands. Sonork ID: 0.2

Long, long time ago (when Win 3.11 was a toddler) .. I wrote (in assembly) a graphical O/S as my varsity project. It included disk, mouse, scanner, VGA and sound drivers and virtual memmory handling... I had the best time ever back then (well, maybe because I was in university so no worries back then mon)

So, with that humble varsity experience as my presentation card and if you allow, I'd LOVVVVE to help you with your project.. I don't have much time but I do have some little.. and lots of ideas and tips I learnt back then.
Given that you're going to re-invent the wheel, I'd suggest you REALLY re-invent it (why bother otherwise?) and take a looooong look and nano-kernels: The O/S is as small as it can be.. and I really mean small and all components (even the memory swapper, file system, etc..) are "mortal" processes (like VMS used to have). Furthermore.. these "components" have COM-like communication which means that you could be using memory located on ... another PC!
If someone had invented such an O/S (I think NeXT was trying to).. TCP/IP.. sockets and all that crap would've never been necesary! "Amoeba" was on such attempt. Anyway.. I could go on and on and on.. but I'll stop here with my help offer and a litte suggestion to get started: Read "Operating System Concepts" by A. Silberschatz, J.Peterson and P.Galvin (I think it is used in varsity) Sonork ID: 0.2

Maybe this'll help:
Compile with and without exceptions: compare code size and assembly output.
My preference: Never use exceptions nor anything over which I don't have absolute control of the code generated. Sonork ID: 0.2

Flubby: It depends on what you're doing.
If you're ok with depending on MFC, then VC is, of course, better. But for straight API programming I find BC's code better, much better. (except for multithreaded apps where there is a problem with the memory allocation libraries and you've gotta work extra)

Too bad Borland is no longer providing support for BC and I'm forced to consider moving to VC: VC's resource editor sucks big time and precompiled header handling is also very bad.
And what's with this stupid message "file XXX.cpp has changed.. do you want to recompile?"
you feel like answering "Nooooo.. just ignore the 50,000 extra lines I've just typed.. OF COURSE I want you, a compiler, to compile!.. haven't I payed for that???"
What VC does kick BC's ass is in project-file handling: In BC, sending a project to someone else is shitty because the project files keep references to your computer's paths.. while in VC, the paths are relative.
MAN! I wish Borland would keep enhancing BC.. but, too bad: I'll probably have to cope with VC's creepy auto-generated code. Sonork ID: 0.2

Colin:
The OOP extremists say: goto is NEVER to be used, it is as sinfull as cutting your pasta with a knife: It will make your code less understandable.
So, strictly speaking, there is NO way of using goto "efficiently".
In practice, I try to respect the NON use of goto as much as possible, but when I reach a situation where avoiding the goto statement makes me either:
a) Write a more complex code. c) Write a more inneficient code
I use it and shut my ears to purists ripping their cloths.
A clear example is: if a structure "PTR" is null or its "MEMBER" is 0, we do "B", else we do "A":
If CANNOT be written as: if(ptr!=NULL && ptr->member != 0) { // do stuff A } else { // do stuff B } Because the C/C++ compiler defs state CLEARLY that the compiler can choose the resolution order it thinks best. (testing ptr->member when ptr == NULL would kill our app).. so, we must write it this way:
if(ptr!=NULL) { if(ptr->member!=0) { // do stuff A } else { // do stuff B } } else { // do stuff B } See? unless I use GOTO, I'll have to write "stuff B" twice (larger code) or make stuff "B" a call to a function (slower code).
This could be re-written in a "holy" way like this:
for( ; ; ) { if(ptr != NULL ) { if( ptr->member!=0 ) { // do stuff A break; } } // do stuff B break; } This way, I've avoided the use of goto.. but is this code REALLY more understandable? break is very much a goto without a label.

My rule of thumb:
a) Use goto ONLY when there's no other choice.(*1) b) try to fit the goto and its matching label in one screen c) Use goto ONLY when there's no other choice.(*1) d) NEVER cross-over 2 or more goto labels (at a given point, there should only be one goto "active"). e) Use goto ONLY when there's no other choice.(*1) f) Don't "goto" backwards: You probably could've written that better. (*1) Avoiding the use would make code fatter or slower in a meaningfull way. Sonork ID: 0.2

Stooopid (and new) me.. sorry, I got the link.. thanx and disregard my "suggestion".
goto jobs;

(don't use goto) Sonork ID: 0.2

This forum is the best and I'd like to throw this on the table for whenever you need it:

I'm now looking for good programmers/apprentices (that's how you write it?) to hire/collaborate.. and given than 99.99% of the people in these forums are programmers.. first thing that came to my mind is.. hey!, try "The Code Project"..

So.. there's a suggestion: a "Jobs" forum because, even if you're not interested right now, chances are that in the future you will be needing such a forum, be that for getting hired or for hiring...

That's all.. Codlet: Try this on Linux while(true)fork(); hehehe Sonork ID: 0.2

HiYall, I'm new to this forum.. lovely! (2nd post.. 1st post did not appear?) Colin, thanks for giving Sonork a try ;) I *agree* with you in the sense that the NEW version should NOT be released along with a "TO-DO" list that includes bugs... When I release a new version of Sonork, I test it, bend it, break it, fix it, hit it, until I'm sure there aren't any bugs.. but then.. some user runs Sonork on WinME in a Linux emulator inside an Excel cell embedded in a Word document inside a webpage and kaboom!.. he finds a new bug. The to-do list then, comes AFTER the product version is on the air and BEFORE the fix is available.. in other words: Its only intention is to: a) Tell the others: "Please stop reporting this bug.. I know about it and I'm fixing it" b) Tell yourself: "This bug has X priority" AND MOST IMPORTANTLY: c) You _MUST_ attach the "bug report" to the _OLDER_ version of the source code - so when you (or your team members) re-use the code or revert to a backup, you/them are aware of the bug on that version. That's all.. where do I get coffee around here? Sonork ID: 0.2

HiYall, I'm new to this forum.. lovely! Colin, thanks for giving Sonork a try ;) I *agree* with you in the sense that the NEW version should NOT be released along with a "TO-DO" list that includes bugs... When I release a new version of Sonork, I test it, bend it, break it, fix it, hit it, until I'm sure there aren't any bugs.. but then.. some user runs Sonork on WinME in a Linux emulator inside an Excel cell embedded in a Word document inside a webpage and kaboom!.. he finds a new bug. The to-do list then, comes AFTER the product version is on the air and BEFORE the fix is available.. in other words: Its only intention is to: a) Tell the others: "Please stop reporting this bug.. I know about it and I'm fixing it" b) Tell yourself: "This bug has X priority" AND MOST IMPORTANTLY: c) You _MUST_ attach the "bug report" to the _OLDER_ version of the source code - so when you (or your team members) re-use the code or revert to a backup, you/them are aware of the bug on that version. That's all.. where do I get cofee around here? Sonork ID: 0.2