09 Aug, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
As my project moves along I've really enjoyed adding c++ features to the mud. Although so far there hasn't been any real changes besides aesthetics:

send_to_char("Hello World",ch); 

VS.

ch->send("Hello New World");


I am getting to a point to where I want to start designing the implementation for a Quest system. As discussed on other threads, I really want to do it "right" moving forward. As far as containers for things i design moving forward, what real benefit is there to using an std::list than a doubly linked list? Am I ok in using the linked lists the same way the mud currently does? Will there be clashes with the fact that I'm using classes instead of structs? I know the main difference in c++ is that members are implicitly public in structs.
09 Aug, 2009, Kline wrote in the 2nd comment:
Votes: 0
If you use a class just be sure to denote things appropriately as private/public/etc, or they will all end up private. Other than that zero different from the existing structs afaik.

If you're going to need random access to items in your list, look into using vectors. If you just plan to loop through them in order, a list should be fine. Personally I prefer using lists over the "roll your own" system in Dikus of prev/next/is_free values in each class/struct because they're more general, and I don't have to add extra fields into a class/struct just to make a list out of them. Lists also have the convenience of list.remove(thing) or list.erase(positon) depending on how you want to remove items. You can also safely call remove/erase on things that may not even be in your list.
09 Aug, 2009, David Haley wrote in the 3rd comment:
Votes: 0
For almost all intents and purposes here, there is no reason to implement the linked list instead of using the STL's list implementation. The question is whether a list is the appropriate data structure in general; as Kline pointed out if you want random access you should consider a vector. If you want to index by something (perhaps the quest name, or quest type, or quest location, …) a map might be more appropriate.
09 Aug, 2009, Runter wrote in the 4th comment:
Votes: 0
David Haley said:
For almost all intents and purposes here, there is no reason to implement the linked list instead of using the STL's list implementation.


Truth.

Also before someone disputes it with some niche intent or purpose notice the "almost" qualifier.
10 Aug, 2009, JohnnyStarr wrote in the 5th comment:
Votes: 0
Thanks for the replies. I have a separate question, but i didnt want to start a similar thread:
I am thrilled that I can start migrating existing routines in the codebase into class specific implementation files.
I started out by adding character.cpp which is where i store all my new character routines.

Although the game system will still work "as is", is it a good thing to leave it that way? The reason I ask is because with all the newer features such as the STL lists, vectors, maps, and things like 'new' vs. 'malloc'. My main concern is designing everything c++ style and having compatibility issues down the road.

So, to clarify, this is why I asked about the std::list vs linked list question. I just dont want to shoot myself in the foot.
10 Aug, 2009, David Haley wrote in the 6th comment:
Votes: 0
We've kind of talked about this before, really. There's no point in changing things just for the sake of changing them. My recommendation would be to not waste your time changing things until it actually gives you practical benefit to do so. Refactor code as you work on it; don't waste time refactoring things without practical benefit, unless you have nothing else to do for your code at the moment.
10 Aug, 2009, JohnnyStarr wrote in the 7th comment:
Votes: 0
my main concern is with confilcting design. for instance ROM's memory system uses calloc. Is this going to work with objects created with the c++ "new" keyword? Anyway, sorry if it came accross as repetitive, but i want to cover all bases before i go and start creating stuff.
10 Aug, 2009, Runter wrote in the 8th comment:
Votes: 0
staryavsky said:
my main concern is with confilcting design. for instance ROM's memory system uses calloc. Is this going to work with objects created with the c++ "new" keyword? Anyway, sorry if it came across as repetitive, but i want to cover all bases before i go and start creating stuff.


calloc() is basically a wrapper for malloc(). new is an alternative to using malloc(). So if you are using new you simply aren't using malloc() any longer.

If conflicting means you may not mix and match new/malloc with free/delete then yes. They conflict. But I'm not totally sure that is what you mean here. The implementation of memory management depends greatly upon operating system and architecture. Some operating systems supply an allocator for malloc, while others supply functions to control certain regions of data. The same dynamic memory allocator is often used to implement both malloc and operator new in C++.

So if you can clarify exactly what you mean by compatible perhaps I can better answer your question.
11 Aug, 2009, David Haley wrote in the 9th comment:
Votes: 0
To expand a bit on what Runter said, you don't want to use malloc (& friends) and free on objects with constructors and destructors. The reason is that malloc/free are not aware of constructors and destructors and therefore objects will not be correctly allocated or destroyed (assuming the object has something interesting in its destructor).

That said, this doesn't really have much to do with std::list, other than any data structure that contains a std::list must be created and destroyed using new and delete.
11 Aug, 2009, JohnnyStarr wrote in the 10th comment:
Votes: 0
thanks for the clarification.
i am still uncertain about the ROM mem system. For example, it recycles mem with realloc if i'm not mistaken. which isnt something you can do with new and delete.
am i safe in leaving the existing system and implementing my own for the new additions that i make?
11 Aug, 2009, David Haley wrote in the 11th comment:
Votes: 0
You are correct that you can't just realloc memory if that memory is an object. You would need to reinitialize it, perhaps by calling the constructor again.

You can, of course, implement your own stuff alongside it in parallel as well.
11 Aug, 2009, Kline wrote in the 12th comment:
Votes: 0
As DH and Runter said, just work at it as you need to, just don't mix malloc/free with new/delete lest Bad Things ™ happen. AckFUSS was originally 100% C (as ACK!MUD) but has a fair bit of C++ in it now, right alongside (or sometimes in place of) the old stuff. The old system used a lot of FREE_LIST items, where it would malloc an object of a type, use it, then push it off into a list when it was killed/destroyed/whatever and re-use that chunk of memory later when you needed another new similar object. Most of that is now gone, except in a few fringe cases where it hasn't been worth my time yet. I replaced it all with actual new/delete calls as needed – freeing memory as I no longer need it and re-allocating it when I do, rather than leaving it "floating", and things are working great.

Hopefully this gives you some insight to what you're about to head down, and that it's not all that bad :)
11 Aug, 2009, Davion wrote in the 13th comment:
Votes: 0
staryavsky said:
thanks for the clarification.
i am still uncertain about the ROM mem system. For example, it recycles mem with realloc if i'm not mistaken. which isnt something you can do with new and delete.
am i safe in leaving the existing system and implementing my own for the new additions that i make?


You are mistaken! Rom does not use realloc() to recycle information. If it does use realloc, it's likely to expand the space of the current chunk it's taken for its own memory (but that has more to do with strings, than object instances). Once ROM allocates something, it never goes away (hence the name, alloc_perm). Even after you call free_blah(), all it does is add that node to a list (the free_* lists) and keep it there. When alloc_perm is called again, and the free list isn't empty, it returns one of the nodes from that list and reinitializes it.
11 Aug, 2009, JohnnyStarr wrote in the 14th comment:
Votes: 0
very helpful one and all :biggrin:
0.0/14