Just found out what *my* problem was. I had a watch set on one of my vars: 'what.size()'. Removing this makes everything work just fine. Maybe a bug in the VC6 debugger(?) Something for you to try anyway.... ========================== i1.2sqrt(u).bcos(ur)sec(c) but b4.isqrt(u).ru/16 Navier ==========================

Sometimes even this doesn't work. I've just had a really bizarre one where stepping over 'xor ecx, ecx' in the disassembly of 'char u[10] = "1";' caused an access violation. Access Violation on a register????? Maybe I'm missing something but that's not supposed to happen as far as I know. I ended up having to re-create the .dsw from scratch. Dropping the same source in and setting the same proj options (as far as I know) made it work just fine. Strange but true. ========================== i1.2sqrt(u).bcos(ur)sec(c) but b4.isqrt(u).ru/16 Navier ==========================

I don't know how it's done but Foundstone have a free tool called FPort (in the Intrusion Detection section) that will do it for you. As far as I'm concerned actually doing this is deep voodoo. i1.2sqrt(u).bcos(ur)sec(c) but b4.isqrt(u).ru/16 Navier

How long is a piece of string? A really easy way to do it is just to take the raw text and XOR each byte with a constant byte value. That turns the text into garbage. Then you check the password. If it matches you XOR each byte of the garbage with the same constant byte and voila your original text is back. Example: Encryption - 101 xor 011 = 110 Decryption - 110 xor 011 = 101 This is really insecure but it's dead easy. It depends on what level of security you need. If you're just looking for something to stop casual observers then this will do the trick but if you expect someone to expend some effort in cracking your encrypted text and it's security is important then you need to look for something more significant than this. There are plenty of industrial strength algorithms about but I'm no expert on current practices. Just google for 'encryption' for details. The other potential problem with what you propose is that your security model is trivially broken if the password is revealed. Look for 'public key encryption' to avoid this. HTH i1.2sqrt(u).bcos(ur)sec(c) but b4.isqrt(u).ru/16 Navier

I'd say use VC++ as well. You'll be more in demand commercially and there's more help/samples/info about for it. Get a copy of Petzold (Programming Windows) as well and if you do go MFC later get Prosise (Programming Windows with MFC) i1.2sqrt(u).bcos(ur)sec(c) but b4.isqrt(u).ru/16 Navier

I'd agree with pretty well everyone. Do at least some SDK stuff first as a 'training' exercise. If you need heavy GUI support though go striaght to MFC. The effort it saves is worth the fact that you won't have much of a clue about what is going on under the hood. One caveat I'd add though is that MFC is a bit flaky in places (someone rightly mentioned WinSock which is absolute pants under MFC) and it's not nice wading through the src to find out whether it's you or Bill's little Elves that have cocked up. Especially if you don't really know what you're doing. i1.2sqrt(u).bcos(ur)sec(c) but b4.isqrt(u).ru/16

Seems to me like a Singleton pattern would do the job better. BTW the standard (well Nov96 draft at least) says a constructor can't have a static modifier (12.1 para 4) if you want official confirmation. i1.2sqrt(u).bcos(ur)sec(c) but b4.isqrt(u).ru/16

Jon's reply is spot on IMHO but maybe a bit of coding philosophy is in order. The distinction between .h and .cpp files is really all about information hiding. That's what he means by scope really. A .h file can be included pretty well anywhere so you can give access to the code it contains to pretty well anything you want just by using a #include. In other words what you really want in the .h file is the interface to whatever code it supports. A fundamental principle of software engineering is to minimise the interface. That means put as little as possible into the .h file and hide the rest in the .cpp file. To a large extent, users of your code only have to worry about what is in the .h file in this case. You're hiding the implementation details from the user (in this case I mean other programmers or you yourself in six months time when you've forgotten how your super duper widget class works). People can get really stuffy and prissy about using globals and functions that aren't class members. I find globals extremely useful sometimes. For example I nearly always have an instance of a CLog class that logs diagnostic data to disk from pretty well everywhere in everything I write. Making this a global means I don't have to worry about passing it around everywhere as a parameter. If you limit yourself to a few cases like this then I don't have a problem with globals. Non-member functions are often recommended by the gurus. Stroustrup uses them a lot in 'The C++ Programming Language', I think (my copy is at work so can't check it was him), as helper functions. His argument is solid (if a bit too advanced for details here) but it seems to go against the grain of conventional wisdom that says make your functions members of the class on which they operate. A good set of rules of thumb is only use globals where they really make life easier and implement them like Jon suggests, put your functions in a class as members of that class, and put your class interface in the .h file and it's implementation in the .cpp file. Like all rules these are made to be broken but knowing when you can break them safely only comes with pain and experience. The point really is that you need to strive towards coding correctly but if you make a few wrong decisions along the way nobody's going to shoot you. There aren't many coders out there who can honestly look at code they wrote six months ago and not find something they would do differently now. The good thing about C++ is you can write really really bad code and it will

You can also do: for (int i=0, int j=0; i<10 && j<10; ++i, ++j) Just wanted to blow that disgustingly UGLY bit of code out of the water. Three lines for a loop for God's sake. Talk about slack. When I were a lad we 'ad 2k and bloody grateful for it we were too. Eee, young 'uns. Anyway, what's so wrong with writing efficient code then? i1.2sqrt(u).bcos(ur)sec(c) but b4.isqrt(u).ru/16

That's definitely the way I'd do it (you need an ifstream though not an istream) you get all the flexibility in the world and code re-use goes up 'cos you're not having to talk MFC. You can always use .c_str() on it if you need to get down and dirty. Why does anybody use anything else? I hear The Prisoner and 7of9 aren't getting along too well these days.

I use it in both my day job and in my freelance work. It's fantastic. The new version is even better though I haven't tried it personally yet. I did have one problem with it grabbing resources for RAS. No doubt there are a few other funnies but there's no contest as far as I'm concerned. Re the machine spec issue. I run it at home on a 333 Celeron with 128MB. It's slow but still definitely useable for things like 95/98. Win2k can be a problem. On a 933 at work it's fine. Overall it's pretty well transparent apart from the speed issues. Have fun Nav.