Mother-Class to controll objects, inheritance problem.

I want to ask for "rightness" of some idea. Actualy I already used it. While learning SDL I made set of methods, and vector to ensure at any point I can delete all textures without remembering their addresses. Now I am adding session to game and when I started implementing it I recognized, that I'm writing same code again, so now I want to create class, to inherite from, so I won't write 2 times same thing, but I'm not sure if it is right idea (ofc all ideas are right, but is it reasonable?), and I have some problem, but that can be off-topic. The example code of mother-class is below and now note to my problem :
//a bit off-topic
(probably I just miss some data from inheritance) : I am making 'control_list'. Can I even make it so children have all separate static vectors, and still they will know how to use parent function, for their own?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
#ifndef Control_h
#define Control_h
#include <vector>
class Controlable {
public:
    Controlable () {
        control_list.push_back(this);
    }
    void del () {   //  <- could be ~Controlable(), but than while del_all it would run through vector many timesfor no reason.
        for (unsigned int i=0;i<control_list.size();i++)
        {
            if (control_list[i] = this)
            {
                control_list[i] = 0;
                control_list.erase (control_list.begin()+i);
                delete this;
            }
        }
    }
    static void del_all () {
        for (unsigned int i=0;i<control_list.size();i++)
        {
            delete control_list[i];
        }
        control_list.clear();
    }
protected:
    static std::vector <Controlable*> control_list;
    ~Controlable();
private:
};
#endif // Control_h

/*now, my off-topic problem :
class session : Controlable
{
    static std::vector <Controlable*> control_list;
};

std::vector <Controlable*> session::control_list;
         ^
        /|\
         |
It create vector inaccesable for parent, don't know how to plan it so it works.

*/ 

Last edited on
Hopefully someone else will have more in-depth feedback, but let me just say that a design that involves deleting yourself is bad design unless in some very weird, unique circumstance.

I'm talking about this
delete this;
I'm not sure why you think you need this.

Your code as a whole doesn't make much sense to me. You're doing very weird operations in your del() function that don't make any sense together.

if (control_list[i] = this)
This is assigning this to control_list[i], not testing for equality. Equality is ==.

1
2
control_list[i] = 0;
control_list.erase (control_list.begin()+i);

You're trying to assign the list element (a pointer) the value of 0. You should be using the constant NULL or nullptr.
But then you try to erase every element from 0 to i, inside the for loop. You're going to end up erasing out of bounds, causing undefined behavior and possibly crashing your program, because you're going to run out of elements to erase.

So overall, no I don't think your code is right. But I don't know enough about your situation to really suggest a fluent "fix". Perhaps if you showed the actual use cases you want with an example, someone might have a more concrete suggestion.

1
2
3
4
class session : Controlable
{
    static std::vector <Controlable*> control_list;
};

If that even compiles, it means you're shadowing your base class's control_list. Not sure if that is what you want.
https://stackoverflow.com/questions/998247/are-static-fields-inherited
Last edited on
Oh, yea, I messed it up severely.

I thought erase delete only selected item.

I made this 0 NULL at first, but NULL is undefined in clear c++ and I didn't wanted to add any library only to have NULL, yet asigning it have no point if i want to erase element : /

My overall idea was, to delete all objects witch pointers I can't even remember. But I don't know if it's right. Now I think OS anyway delete it at end of program, and nowhere inside I don't need to do this...
Yeah, that's nonsence. My bad. Thanks for answer anyway, and actualy that was all this question was about. Does it make any sence at all.
Last edited on
My mistake, it is only deleting the one element. I'm just so use to seeing (begin, end) iteration that I assumed it was deleting every one. But that is also prone to error because that mutates your size, which can mess up your for loop.

NULL is undefined in clear c++
No it's not. It's part of the standard. NULL is simply what you should assign a pointer to make it a null pointer. Modern C++ should use type-safe nullptr instead of NULL, though.

Feel free to post more questions if you want or updated code if you want more feedback from others.
Last edited on
But (...) which can mess up your for loop.

Oh yea, missed that. Thank you for spotting that, so at future I might be more aware of that. I'm ussualy writing just 'random stuff' and than repair everything, but that is bad habit as if I will someday work with databases it can cost me a lot.

At first I wrote NULL, but it created error message `NULL' was not declared in this scope. Maybe it is included and with almost all libraries, but I'm almost entirely sure in pure c++ it is not defined. Even on stack overflow they adviced to add #include <stddef.h>

https://stackoverflow.com/questions/924664/why-is-null-undeclared


NULL is not a built-in constant in the C or C++ languages. In fact, in C++ it's more or less obsolete, just use a plain literal 0 instead, the compiler will do the right thing depending on the context.

In newer C++ (C++11 and higher), use nullptr (as pointed out in a comment, thanks).

Otherwise, add

#include <stddef.h>

to get the NULL definition.

But there also I learned about nullptr, witch is good.
Last edited on
Oh, I see. Didn't realize the thing about <cstddef>. But I am still on the side of preferring NULL over 0, even if only for a semantic difference, because it demonstrates that you are in fact working with pointers instead of integers. But I guess it's not the end of the world, either way.
Topic archived. No new replies allowed.