|
> From: Barbara Morris > > It's even faster, and just as easy, to compare two handles to > structures. The service can communicate with its consumers by say an > integer that's an index into an array of pointers. You still have the > quick comparison without the consumer having the ability to look inside > (or worse, change) the private structure. (A real handle would probably > be an encoding of some unique value plus an array index, to prevent > accidental reuse.) Faster on compare, slower on use. Especially with the added encoding. A tradeoff, to be sure. > No argument there. But as a rule of thumb, giving out a pointer to a > module's private storage can lead to hard-to-solve problems, like the > one that started this thread. No argument here, either. But that's why we used void pointers to structures whose definitions weren't even available to the application programmer. Yes, they COULD break things, but they'd have to work pretty hard to do so. A programmer would have to actively recast the pointer, and anybody caught doing that in MY shop would have a lot of explaining to do. And of course, somebody could just as easily mangle a handle as recast a pointer, couldn't they? My technique was designed to prevent accidental misuse, not aggressive stupidity. > By the way, speaking of "thread", two modules having stored pointers to > one module's static storage is one of the thread-safety issues that > RPG's THREAD(*SERIALIZE) doesn't protect you against In a thread-safe > application, you would have to add your own serialization to access that > shared storage. Interesting point. Then again, if you're going to program threads, you should probably understand serialization techniques anyway, but that's just my opinion. Joe
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.