The intent is for a project that is intended for education and practice. So I want to utilize as much stuff as possible into a project that uses each of the things I implement the best ways I can.

The maximum amount of enemies on screen will be somewhere around 20, but no greater, I think. Only one enemy can die at a time; it is not possible to kill two at once. They are first flagged dead, then deleted, and it happens with a "death freeze frame", as in, all action freezes to let the enemy's dying animation play out, so computing time will probably not be noticably affected by moving data around. There is nothing graphics-intensive, as it is all run in command prompt and all sprites are character-based. I have no graphics to worry about. I will never have to worry about randomly accessing them because they're moved in sequence.

I made another thread about my enemies' data management and the people in the thread told me that I should not just flag the enemies dead, which is what I did before, and that I should delete enemies when they've been killed. So I've been working with that intent in mind. If you can convince me to do otherwise, then I'll change my method.

If for education purposes as you say, it sounds like a good plan.

You probably don't need to mark and delete enemies, you can just delete them without marking them in a list (unless you need them marked for unrelated reasons).
If using vectors, you can mark them without deleting them, or using the "swap to end" trick if element ordering is insignificant.

I am late to the game, but I wanted to mention that the first few times I read a description of what objects are, I was as confused as the OP. "An entity that encapsulates data and the code that acts on it together", or something like that is a horrible description. An object is just the data. Then we provide a bunch of functions that act on the data, and we put that in the same block as a way of mentally organizing things, but when you compute the size of an object, you only get the size of the data, not the code. When you write an object to a file, only the data is written. It would be good to be clear about this when introducing someone to objects.

Well, maybe I said my intentions wrong. This is for self-education, but it's going to be a finished product I distribute to people, and I don't only want to know how to do things like this, but have them used in my programs appropriately. So really what I'm kind of asking is what the best thing would be to do for something like this problem. I'm leaning more towards a vector now, because as I see it, its qualities really only shine through when there is a large amount of data being used, and the objects I'm using definitely don't approach a kilobyte.

The way I see it is that std::vector<> is the default container type one should go to. It'll be the best solution in the majority of circumstances. Only when someone needs specialization for different purposes do you reach for another container type (whether it be a linked list like std::list, or a quadtree or something of that nature).

However, it is of very significant benefit to roll your own containers for learning experience - so don't let me discourage you from that! But at the same time, you have to be willing to discard your own containers and go back to the tried and true, heavily optimized, heavily debugged standard containers after you practice with your own. This is hard for alot of people, because they want to use their own after all the work they put into it ("And why not, after I spent two weeks on it?"), and sometimes, overtime, they get caught into NIH and YAGNI - both which leads to not actually finishing projects, and instead just working on the sub-projects without actually releasing anything real - of which programming culture is far too filled with.

That is my personal opinion - other people's opinion will vary. You are intelligent enough to analyze the data yourself (now that you know there is data to analyze) and then decide what, in your personal and unique circumstances, is the best option at the present situation, and the best option for future situations. My (and everyone's) armchair guesses at what's best for your current project should always be taken as counsel but not law, as it may be flawed from us not having all the details that you alone possess.

To clarify:

An object is just the data. Then we provide a bunch of functions that act on the data, and we put that in the same block as a way of mentally organizing things, but when you compute the size of an object, you only get the size of the data, not the code. It would be good to be clear about this when introducing someone to objects.

Not quite. If you have a C++ object that has virtual functions, the size of the object is more than just the data. It isn't that the code is included in the object, but typical implementations include an indirect reference to the code (usually via a VTable pointer).

When you write an object to a file, only the data is written.
[/quote]
You cannot, in general, sensibly write non-POD types to a file directly.
[/quote]

I seem to have a problem lately when I try to keep things simple: Someone will come and pick my statements apart, instead of trying to understand what I am saying.

There is a common way to introduce objects out there as something comprising both data and code. At the same level of detail of that statement, I propose an alternative ("Objects are only data, but we write the code that manipulates the data in the same block to keep things neatly organized") to help beginners have some intuition as to what's going on.

When talking to a beginner that is confused enough to think that you store code in a linked list, I think your clarifications hurt more than they help. But yes, they are correct.

If you make your own container (such as list) for learning purposes, I'd suggest building it with the exact same interface as the standard library's corresponding container (or actually, its subset which only contains the critical features you need).

Then, if you have some separate project of your own, you can normally use the standard library container (which will be faster and more reliable than your own), but you can swap in your own container for testing purposes or for the hell of it. You'll increase your understanding of the standard interface, and good interface design, at the same time.

Just typedef it somewhere in your project and you can switch between your own container and standard container with ease.