 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic |
Last Thread Next Thread |
| Why Pluggable Factories Rock My Multiplayer World |
|
 |
BaelWrath Member since: 6/26/2001 From: England |
|||
 Posted - 6/26/2001 9:10:27 AM |
||||
| Excellent use of the object factory system! I have now not only decided to use the system for network message handling but am going to use a version of the system to handle WorldToken events, and expand my TokenFactory to allow the soft architecture to add new tokens to the enviroment. |
||||
|
||||
|
Anonymous Poster |
|||
 Posted - 6/3/2003 7:09:52 AM |
||||
| Why not use factory factories ? that would be fun. Having one class per message type is not necessary, it's just for the pleasure of writing lots of classes, lots of code, and being proud to use abstract classes when not necessary. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 5/9/2004 6:25:13 AM |
||||
| The problem is that if u never reference a static member of a class then linker simply gets rid of it so your map entry never becomes registered. I still didn't find solution to this problem. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 6/10/2004 2:31:43 PM |
||||
| If the map's find fails, a NULL pointer will be returned. Dereferencing a NULL pointer does NOT cause a C++ language exception as the article indicates. It is undefined behavior and will probably do something weird (or crash) and the exception handler will not be entered. You should probably check the result of the find operation before trying to use it. If your linker is removing static objects, it's busted. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 6/10/2004 2:35:09 PM |
||||
| Let me amend that last part. If your linker is removing static objects that are not referenced, but the static objects have non-default constructors, then I think it is busted. How does the linker know that omitting the constructor calls is okay? It can't, so it should leave those objects in the build. |
||||
|
||||
|
WizHarDx Member since: 9/16/2001 From: United Kingdom |
|||
 Posted - 3/29/2005 5:01:19 AM |
||||
| I like this aritcle very much, Ive implemented it into my network engine. It was all working fine till one day it crashed suddenly when I compiled it. Anyway the reason it crashed was that the static registry map was constructed after one of the makers, so when the maker called the base constructor to register it it caused an error as the map had not been created. The way round this is to make the map a static ptr to a map. Then whan you declare it in the cpp file set it to 0. Then on the base constructor check if its 0 and if so allocate it. Then register your maker. This raises the issue of deallocating the map. You can't put it in the destructor of the base object as it is a static member and you want it to deallocate when all the program ends. The solution to this is have an unregister function which takes the id and erases the entry in the map. Then in that function also check the size of the map if its 0 then all objects have unregistered so delete the map. Hope this helps Iain Fraser |
||||
|
||||
|
BradDaBug Member since: 5/2/2001 From: Cuba, MS, United States |
|||
 Posted - 4/1/2005 7:13:00 PM |
||||
Quote: I love you. I love you so much. |
||||
|
||||
|
Anonymous Poster |
|||
Posted - 9/26/2005 10:37:09 AM |
||||
| What about open-source/cross platform software. I imagine that building on different platforms/compilers could cause different id constructor mappings depending on the order the static variables get initialized. |
||||
|
||||
|
doynax Member since: 1/8/2004 From: Sweden |
|||
|
Posted - 9/26/2005 10:48:41 AM |
||||
Quote:We encountered this problem and all the others mentioned so far (out of order construction, dynamic list creation, the linker removing unreferenced modules). The linker part was solved by adding explicit references to the classes (dummy functions called somewhere within the program essentially). And the order of unique message IDs was handled by naming each message and sorting the list before using it. But really.. It caused an enormous amount of problems for no real gain, an enum of all messages and a simple switch case somewhere dispatching messages to the appropriate classes would've worked just as well. Having to recompile large parts of the project whenever the list of messages changed certainly wouldn't have been a problem in our case. Perhaps it could've savied time if the system had hundreds of messages or was to be extended by third parties. |
||||
|
||||
| All times are ET (US) |
Last Thread Next Thread |
|
