Best Way to Handle Instances

[e_barroga]

What would be a great way to handle object instances; like drawing each created instance, performing each instances' handle event, etc.

At the moment, I was thinking about creating a "instance list" and looping through the entire list, but I didn't think that was the best idea.

Code: [Select]

for (i=0; i<10001; i++) {
    i.draw();
}

[Wizzard]

Try to use a std::vector to do the dirty work for you.

Code: [Select]

#include <iostream>
#include <vector>

int main()
{
    // Create a vector container that contains data of type int
    std::vector<int> Container;

    // Create an iterator using partially the same syntax as above
    std::vector<int>::iterator Iterator;

    // Add some values to the end of the container
    Container.push_back(-2);
    Container.push_back(-4);
    Container.push_back(2);
    Container.push_back(4);

    // Remove the second value of the container
    Container.erase(Container.begin() + 1);

    // Iterate through the container from beginning to end
    for (Iterator = Container.begin(); Iterator < Container.end(); ++Iterator)
        // The * and -> operators are used to get the data iterators are at
        std::cout << *Iterator << ' ';
}

Vectors and almost all other STL containers can handle any standard or custom data types, but I decided to use an int for the example.

[MrQuizzles]

I'm making a shmup, and for this, I'm using a list of pointers to a base class with a virtual handle function.

A list isn't the fastest thing to iterate through, but I'll be adding and deleting random items from the list constantly. Lists handle random object deletion better than vectors do, and that is why I chose to use a list.

[Wizzard]

I'm pretty sure lists and vectors iterate in linear time, so it shouldn't be more than several nanoseconds wasted in iteration.

I use lists in my implementation of an entity manager because their iterators can be used as pointers, because lists' elements don't change their place in memory.

This way, I can store on an element the place where it is on the list, making it so I can delete the element from the list without searching through the list.

Regardless, I don't think people should stress too much on what STL container to use, but they should make an effort to learn the key differences of them.

[bullno1]

If you really care about memory management/fragment ... Just throw in a boost pool allocator and you're done. However, if you don't constantly create/delete entity, you will not notice any difference.

[e_barroga]

I've never heard of a "boost pool allocator". I'll be sure to check it out.

I need help with one more thing. I would like to create functions that manage specific things pertaining to a certain aspect of the game, which would be stored in seperate header files. I also haven't really used header files, but know what they are and also how to prevent multiple inclusions.

I would like to do something like so:

Code: [Select]



//Includes all the other headers
#include "Includes.h"

int main()
{
    GetInput();
    Events();
    ProcessObjects();
    Draw();
    return EXIT_SUCESS;
}

[Wizzard]

I have not tested this, but if I remember correctly, this is how you use header files in functional programming.

Includes.c

Code: [Select]

void GetInput()
{

}

void Events()
{

}

void ProcessObjects()
{

}

void Draw()
{

}


Includes.h

Code: [Select]

// This is to prevent multiple inclusions
#ifndef INCLUDES_H
#define INCLUDES_H

// Any include directives will be included in all files that include this file
#include <iostream>

// This makes the functions included by all files that include this file
extern void GetInput();
extern void Events();
extern void ProcessObjects();
extern void Draw();

#endif // INCLUDES_H


[e_barroga]

So something like this:

Get Input.h

Code: [Select]


//Prevent Multiple Inclusions
#ifndef GET_INPUT_H
#define GET_INPUT_H

extern void GetInput();

#endif GET_INPUT_H


Get Input.cpp

Code: [Select]


void GetInput()
{
}


main.cpp

Code: [Select]


#include "Get Input.h"

int main()
{
GetInput();
}

Would that work, or am I supposed to include the "Get Input.cpp" file as well? If so, I do not understand how it would know to compile the ".cpp" file.

[Wizzard]

It depends on what you're using to compile your files, but assuming you're using a graphical IDE, you just add both .cpp files to your project.

You can also put the function directly into Get Input.h and get rid of Get Input.cpp entirely:

Code: [Select]

#ifndef GET_INPUT_H
#define GET_INPUT_H

void GetInput()
{

}

#endif GET_INPUT_H


[e_barroga]

I did something like this:

main.cpp

Code: [Select]


#include "Includes.h"

int main()
{
    GetInput();
}

Includes.h

Code: [Select]


#include "Get Input.h"

It says that "GetInput()" is not in this scope.

[bullno1]

You should learn basic C++ first, learn STL, standard library then SFML . There are thick and boring books out there that teach you. Sorry to say that but it's the only way you can use a C++ library properly.

[Wizzard]

I agree with bullno1. Although it's great to dive into programming, you might want to make sure you can survive the drop into a small pool before jumping off a cliff and into the ocean.

[e_barroga]

I've gone through: www.cplusplus.com

I know stuff like pointers, classes, polymorphism, etc.

However, I think that the only way to truely know the language is by experience.... which you can't really get unless you dive into programming.

Also.... I understand the concepts of "scope" and the "scope operator> ::

[Wizzard]

Reading a tutorial is an excellent way to dive into C++, but creating applications to explore possibilities, reading articles, books, conversations, documentation, or source code, and asking or even debating with other programmers about the language, is how you can get to be fluent in C++. I'm simply recommending that you keep your pool small until you can easily and gracefully swim from one side to the other. Don't think that you should completely cease using SFML in all your projects, but you should really learn the rest of the fundamentals before you get into anything serious.