Thanks

Post #267,163 by broomberg 9/10/06 1:41:55 PM Reply	Thanks I actually did a bit of what you said already this morning. The usage for the function get_lock was because I hadn't fully started using exceptions yet, which in turn meant I wanted a local function to check that the object had created the lock file, and it did it by checking to see if the object's file descriptor was not -1. So, added a throw to the Lock_File object constructer, get rid of the front end code that checks the value, and get rid of the method that provides it. Lock_File -> LockFile - check. Assignment changed to initialization, overloaded added - check. \nLockFile(const LockFile&) {}\n This is a constructor that takes an argument of an address of a LockFile object. But what does it actually do? \nLockFile& operator=(const LockFile&) {}\n This is an override of an equals that returns is address of the LockFile object - right?
Post #267,175 by tuberculosis 9/10/06 10:26:41 PM Reply	2 of the "magic 4" methods Copy constructor: LockFile(const LockFile&) {} is generated by the compiler if you don't write it. The compiler version does a memberwise copy (calling copy ctors of all embedded objects). Consider this code: \nclass LockFile\n{\npublic: \n LockFile(int fileId) : _lock(primitiveCreateLockFileFunction(fileId)) {}\n ~LockFile() { primitiveReleaseLock(_lock); }\nprivate: \n int _lock;\n};\n\nfunc(LockFile lock) {}\n....\nLockFile lock(aFileId);\n\nfunc(lock); // object is copied via the copy constructor - at end of function it is destroyed - releasing the lock\n See the problem? A for the duration of func, there are two copies of the lock object - one passed to func, the other in the calling stack frame. They end up sharing the same lock and your lock gets free'd early. There are two fixes to this 1) Always pass lock by reference. 2) Make FileLock's copy ctor private so the compiler will prevent unintentional copying since you haven't made the object copy safe. The second method is similar, but used in assignment and once again, the compiler will generate it for you if you don't. You should always define the "big 4" methods and, if you can't make some of them safe, make them private so nothing can call them. [link\|http://www.blackbagops.net\|Black Bag Operations Log] [link\|http://www.objectiveclips.com\|Artificial Intelligence] [link\|http://www.badpage.info/seaside/html\|Scrutinizer]
Post #267,178 by broomberg 9/10/06 10:50:17 PM Reply	Ahh, thanks My original code used a new and passed the pointer around, but had a bunch of work for no reason. My new "simplified" code only did the single allocation, didn't copy anything around, so was bug free by accident. I would have noticed the accidental destroy since I was printing a message when called, trying to understand it. But again, pure luck. I've got the 3rd edition of the C++ Programming Language that I've been reading, but it is slow going. And 'ctor'? That took a bit of googling to figure out it was shorthand for constructor. You must be used to it.
Post #267,205 by tuberculosis 9/11/06 12:25:30 PM Reply	If you are going to continue on this path You really ought to get (and read) Scott Meyer's [link\|http://www.amazon.com/Effective-C%2b%2b-Addison-Wesley-Professional-Computing/dp/0321334876/sr=8-1/qid=1157991837/ref=pd_bbs_1/104-0140589-9124705?ie=UTF8&s=books\|Book] "Effective C++". It explains all this stuff in nice easy to read bite sized chunks. [link\|http://www.blackbagops.net\|Black Bag Operations Log] [link\|http://www.objectiveclips.com\|Artificial Intelligence] [link\|http://www.badpage.info/seaside/html\|Scrutinizer]
Post #267,243 by broomberg 9/11/06 5:09:10 PM Reply	Order request sent Thanks Note: One of my favorite Perl book is Effective Perl programming, which I believe is patterned after this book (or maybe the C one).
Post #267,352 by broomberg 9/12/06 3:39:15 PM Reply	Ordered from big river today.

Welcome to IWETHEY!