Menu
▾
▴
classbuilder-news
|
From: joan c. \(ai4b\) <jc...@ai...> - 2003-07-03 07:56:42
|
When creating a relation between two clases in the generated code = appears one iterator class. But this class does not appear in any place = of the classbuilder desing and also is not documented anyware. How does it work, can i instantiate many cursors at the same time? = because there are some static variables.=20 If I'm not going to use them, can I avoid the code generation for it? There is any way to change the capital letter of generated methods. I = would like (for conding conventions) to have all methods is lower = letters, but the generated ones are in capitals. There is any way to = change it? Thanks.=20 Joan Codina p.d Thanks Craigh for the new version, I will download and test it ASAP |
|
From: Craig G. <CGu...@ex...> - 2003-07-03 13:05:58
|
Under "Project" and "Setting", you can set "Expand Macros" and then write the source file out again. You will find the iterator classes. Capitals are generated by default. To change it you have to do it manaully, sorry. Craig -----Original Message----- From: joan codina (ai4b) [mailto:jc...@ai...] Sent: Thursday, July 03, 2003 2:57 AM To: ClassBuilder Subject: iterators When creating a relation between two clases in the generated code appears one iterator class. But this class does not appear in any place of the classbuilder desing and also is not documented anyware. How does it work, can i instantiate many cursors at the same time? because there are some static variables. If I'm not going to use them, can I avoid the code generation for it? There is any way to change the capital letter of generated methods. I would like (for conding conventions) to have all methods is lower letters, but the generated ones are in capitals. There is any way to change it? Thanks. Joan Codina p.d Thanks Craigh for the new version, I will download and test it ASAP |
|
From: <jim...@ph...> - 2003-07-03 13:58:21
|
Although ClassBuilder is not documented very well, the iterator stuff is documented quite good, see 3.5 of the getting started document. It is allowed to have multiple cursors open at the same time and more important it is save to alter the list while iterating it. Unlike the STL stuff you can modify the list while you are iterating it, with the iterators. With most iterators there are certain modifications that are unsafe while you are iterating, with the ClassBuilder iterators it isn't. This is the reason of the static stuff. Internally a static list is kept of all open iterators per relation ship type. Thus a relation A <>-->> B is one static list while A <>-->> C is another. When for example an B object is removed or replaced from its relationship with A (see chapter 9 of the getting started document for more about object replacement), all open iterators A <>-->> B are verified, if their cursor is pointing to the B object. It their cursor is pointing to the B object then the cursor is updated. It is possible to keep the code out, just alter the CB...h files to make a few macro's empty and as a result no code will be inserted. But the iterator stuff, does not make the object sizes bigger and a good compiler/linker will remove unused code, so I do not know if it is worth to edit the include files. Personally I always use the iterators, because of there ease of use, especially with the Insert Iterators option with the ClassBuilder code editor and of its safety. Only in a few exceptional cases I go for direct use of GetFirst/GetNext to traverse a relation. It is not directly possible to alter the case, but perhaps a Add-in is possible, that traverse all classes and methods and alters the case of the methods. Jimmy Venema |
|
From: <jim...@ph...> - 2003-07-05 17:19:39
|
Although ClassBuilder is not documented very well, the iterator stuff is documented quite good, see 3.5 of the getting started document. It is allowed to have multiple cursors open at the same time and more important it is save to alter the list while iterating it. Unlike the STL stuff you can modify the list while you are iterating it, with the iterators. With most iterators there are certain modifications that are unsafe while you are iterating, with the ClassBuilder iterators it isn't. This is the reason of the static stuff. Internally a static list is kept of all open iterators per relation ship type. Thus a relation A <>-->> B is one static list while A <>-->> C is another. When for example an B object is removed or replaced from its relationship with A (see chapter 9 of the getting started document for more about object replacement), all open iterators A <>-->> B are verified, if their cursor is pointing to the B object. It their cursor is pointing to the B object then the cursor is updated. It is possible to keep the code out, just alter the CB...h files to make a few macro's empty and as a result no code will be inserted. But the iterator stuff, does not make the object sizes bigger and a good compiler/linker will remove unused code, so I do not know if it is worth to edit the include files. Personally I always use the iterators, because of there ease of use, especially with the Insert Iterators option with the ClassBuilder code editor and of its safety. Only in a few exceptional cases I go for direct use of GetFirst/GetNext to traverse a relation. It is not directly possible to alter the case, but perhaps a Add-in is possible, that traverse all classes and methods and alters the case of the methods. Jimmy Venema |
|
From: Val G. (TT) <Val...@tr...> - 2003-07-07 20:01:41
|
Statics are only related to deletion (support collection of iterators to
update in case an entry into a collection is being deleted that is being
pointed to by an existing iterator). If iterators are created and destroyed
often, and deletion can not happen when an iterator points to the entry of
the collection (which is the case in our current project, where all entries
are refcounted by user level pointers and iterators exposed to the users),
they are unnecessary. For this reason I #ifdef'ed them out. If anyone is
interested, I can send a zip with the modified directory.
Val Goldring
Trading Technologies
(312) 476-1036
[Sponsored by:]
_____________________________________________________________________________
The newest lyrics on the Net!
http://lyrics.astraweb.com
Click NOW!
|
|
From: <jim...@ph...> - 2003-07-08 07:27:13
|
It doesn't hurt to have a look at it. The situation that you delete an entry while iterating doesn't occur that often, but if it occurs it is a nasty bug to find. So it does make sense to have the possibility to ifdef it out. On the other hand the overhead introduced isn't that big, so for most applications you can easily take the extra overhead and the few placed I need the performance I normally use the low level GetFirst GetNext stuff. But it sound like your solution is a nice middle way, at least I'm interested to have a look at it. Perhaps we can make this set the default include set, we only have to see how to deal with the precompiled stuff, which is needed for expansion. Jimmy |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X