Problem with a deque object with embedded deques

This could be as simple as what's wrong with the following line of code :-

wc_children[i].wcc_chld_adlt_nmlabel.push_back(NULL);

However, this works first time around, but when it is used again, after erasing the deque member (and it's containing deque) I think I get into an ever memory hungry loop (i.e. I get the dreaded ???.exe has encountered a problem and needs to close, and then have to close the console, which takes a lot longer than normal 10/20 seconds).

Here's the class that I'm using :-

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
class wc_chldrn {
    public:
        HWND wcc_chld_nmlabel;
        HWND wcc_chld_nm;
        HWND wcc_chld_agelabel;
        HWND wcc_chld_age;
        deque<HWND> wcc_chld_adlt_nmlabel;
        deque<HWND> wcc_chld_adlt_rlt;
        deque<HWND> wcc_chld_adlt_carelabel;
        deque<HWND> wcc_chld_adlt_care;
        wc_chldrn();
        ~wc_chldrn();
};
wc_chldrn::wc_chldrn() {
    wcc_chld_nmlabel = NULL;
    wcc_chld_nm = NULL;
    wcc_chld_agelabel = NULL;
    wcc_chld_age = NULL;
}
wc_chldrn::~wc_chldrn() {
}


Here's the code that works first time around, that's in a function (and wcchildren is a deque of the class above [some repetitive stuff removed e.g. for the other HWND deque members]) :-
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
    for (int i=0; i < children.size(); i++) {
        cname="Child ";
        cname.append(NumberToString(i + 1));
        AddItemLabel(hwnd, wcchildren[i].wcc_chld_nmlabel,cname,vp,30,60);
        AddItemEditTXT(hwnd, wcchildren[i].wcc_chld_nm,children[i].getcname(),vp,95,100);
        AddItemLabel(hwnd, wcchildren[i].wcc_chld_agelabel,(string)"13+",vp,205,30);
        AddItemChkBox(hwnd, wcchildren[i].wcc_chld_age,children[i].isteen(),vp,240);
        vp=vp+vpa;
        for (int j=0; j < adults.size();j++) {
            aname = adults[j].getaname();
            wcchildren[i].wcc_chld_adlt_nmlabel.push_back(NULL);
            AddItemLabel(hwnd, wcchildren[i].wcc_chld_adlt_nmlabel[j],aname,vp,50,100);

            vp=vp+vpa;
        }
    }


Here's the code I use to erase the members (basically in an attempt to redisplay all the windows controls) (I'm not sure if this is at all relevant, but may be) (note that wcc equates to wcchildren, in both cases they are passed by reference to the function)(note all done in reverse order to the build) (again repetitive code for members removed):-

1
2
3
4
5
6
7
8
9
10
11
12
13
14
    for (int i=wcc.size()-1;i >= 0;i--) {
        for (int j=(wcc[i].wcc_chld_adlt_nmlabel.size()-1);j >= 0; j--) {
            DestroyWindow(wcc[i].wcc_chld_adlt_nmlabel[j]);
        }
        
        wcc[i].wcc_chld_adlt_nmlabel.erase(wcc[i].wcc_chld_adlt_nmlabel.begin(),wcc[i].wcc_chld_adlt_nmlabel.end());

        DestroyWindow(wcc[i].wcc_chld_nmlabel);
    }
    wcc.erase(wcc.begin(),wcc.end());
    DestroyWindow(wccab);
    wccab=NULL;
    DestroyWindow(wccl);
    wccl=NULL;



Finally here's the code where I encounter the problem, the offending line in bold (I found this by progressively uncommenting code that had been commented out) :-

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
    for (int i=0; i < children.size(); i++) {
        cname="Child ";
        cname.append(NumberToString(i + 1));
        AddItemLabel(hwnd, wc_children[i].wcc_chld_nmlabel,cname,vpos,30,60);
        AddItemEditTXT(hwnd, wc_children[i].wcc_chld_nm,children[i].getcname(),vpos,95,100);
        AddItemLabel(hwnd, wc_children[i].wcc_chld_agelabel,(string)"13+",vpos,205,30);
        AddItemChkBox(hwnd, wc_children[i].wcc_chld_age,children[i].isteen(),vpos,240);
        vpos=vpos+vposadd;

        for (int j=0; j < adults.size();j++) {
            aname = adults[j].getaname();
            wc_children[i].wcc_chld_adlt_nmlabel.push_back(NULL);
            //wcchildren[i].wcc_chld_adlt_rlt.push_back(NULL);
            //AddItemLabel(hwnd, wcchildren[i].wcc_chld_adlt_nmlabel[j],aname,vp,50,100
            //AddRltDropDown(hwnd, wcchildren[i].wcc_chld_adlt_rlt[j],0,vp,155,140);
            //AddItemLabel(hwnd, wcchildren[i].wcc_chld_adlt_carelabel[j],(string)"Nights Care",vp,305,80);
            //AddItemEditNMB(hwnd, wcchildren[i].wcc_chld_adlt_care[j],0,vp,390,30);
            vpos=vpos+vposadd;
        }

    }


I think, in my weird way, that it might be something to do with reusing the same memory, but surely not.

Perhaps the answer is that I should manage this within the object calling methods to do the push_back and then to populate the properties.

I assume that it's not a windows API/control issue.

Lastly apologies for any misuse of terminology, I blame the saying that you can't teach an old mikedog new tricks. :)
Last edited on
One thing I notice is that i counts the number of elements in "children" but is then used to index into a different
variable (wc_children). Is this correct? Does wc_children have the same number of elements as children always
(or at least as many elements as children)?
jsmith,
children and wc_children should match in regards to the number of elements. There is a loop prior to this that builds wc_children from children. I could of have used the children class to store this info, but I wanted to keep the data used for the calculation (Child Support), separate from the windows management stuff.

The same technique is used to determine how many elements there are in the embedded deques, that is j is the number of adults. Basically there has to be a relationship(sic) between every child and every adult and the rlt dropdown allows this to be selected (relationships are Parent, Other (no relationship), Non-parent carer, parent abroad and deceased parent). There is also another component to a relationship, the amount of care the adult has of the child, add prompts and that's four separate deques embedded in the owning deque.

So what I am trying to do is prepare/pre-define the elements of the deque in readiness to store the windows handle, thus allowing flexible use of the functions (in my way of looking at things) that add the windows controls (although AddRltDropDown is very specific).

I've just tried adding a method to the wc_chlrdn class :-
1
2
3
4
5
6
void wc_chldrn::InitEmbedSet() {
    wcc_chld_adlt_nmlabel.push_back(NULL);
    wcc_chld_adlt_rlt.push_back(NULL);
    wcc_chld_adlt_carelabel.push_back(NULL);
    wcc_chld_adlt_care.push_back(NULL);
}


and using this method, the results are the same (as far as I can tell).
Ha, that MikeT's an idiot.

The issue (the idiot hopes, only basic checking done) is that after removing all the deque elements from the wcc (was wcchildren) that they mismatch what is in the children deque. The solution is to include a loop, (if there is a mismatch between wcc and children), to add (push_back) deque elements to equalise and difference.

e.g. :-

1
2
3
4
5
    if (wcc.size()< children.size()) {
        for (unsigned int i=0; i < (children.size()- wcc.size()); i++) {
            wcc.push_back(wc_chldrn());
        }
    }


JSmith, you were on the ball, shame I wasn't. :)


Ooops I got the above fix wrong. The subtraction in line 2 (to find out how many elements left to add) is done for each iteration of the loop, thus not all the deque elements get created (similar problem happens). So the final solution is more like :-
1
2
3
4
5
6
    if (wcc.size() < children.size()) {
        unsigned int diff = (children.size() - wcc.size());
        for (unsigned int i=0; i < diff; i++) {
            wcc.push_back(wc_chldrn());
        }
    }
Last edited on
Topic archived. No new replies allowed.