I have an issue that might be related to my code, to Windows or to wxWidgets. I'm coding on Win7 64bit HP with Code::Blocks 12.13 using MinGW 32bit 4.8.1 and wxWidgets 3.0.0 (I'm planning to update when time is available). Here is my issue:
The following code "works" but will lead to irradic (and hard to reproduce) crashes:
wxString *items = new wxString[2];
items[0] = "Item 1";
items[1] = "Item 2";
wxChoice *ch = new wxChoice(SomeParent, SomeId, wxDefaultPosition, wxDefaultSize, 2, items);
delete items;
I've also tried to keep the items pointer until no longer used:
MyPanel::MyPanel() {
m_PrivateItemPtr = new wxString[2];
m_PrivateItemPtr[0] = "Item 1";
m_PrivateItemPtr[1] = "Item 2";
wxChoice *ch = new wxChoice(SomeParent, SomeId, wxDefaultPosition, wxDefaultSize, 2, m_PrivateItemPtr);
}
MyPanel::~MyPanel() {
delete m_PrivateItemPtr;
}
And this leads to the same behaviour of irradic crashes. If the destruction of the items ("delete items;") is commented out the crashes stops but this then leads to a minor memory leakage.
I've tried to look into the wxWidgets source and not found anything that suggests that the pointer containing the items should be released by wx. I've looked into the "MSWInsertOrAppendItem" method and the CB_ADDSTRING / CB_INSERTSTRING and not found any conclusive as to whether or not they take ownership of the string data - but it does seem like it.
Can anyone tell my if this is normal behaviour and/or if there is a workaround?
Irradic AppCrash with wxChoice
Re: Irradic AppCrash with wxChoice
Advice #1: Do not use raw pointers in C++ code, in your case using wxStringArray allocated on stack (i.e. a local variable) would be probably for the best.
Advice #2: If you allocate an array (i.e. using new ...[]), you must delete it with "delete[]", please notice the brackets following the operator, otherwise you are treading into the dreaded "undefined" territory.
Advice #2: If you allocate an array (i.e. using new ...[]), you must delete it with "delete[]", please notice the brackets following the operator, otherwise you are treading into the dreaded "undefined" territory.
Re: Irradic AppCrash with wxChoice
Thank you for your suggestions! I will experiment with those and reply back!
Re: Irradic AppCrash with wxChoice
So I've adjusted my code and given the application some testing time and it seems like the missing [] was the culprit, dunno how I could have slipped those
wxString *s = new wxString();
wxString *a = new wxString[5];
//..
delete s;
delete a;
Different constructors but equal destructors and since "a" is an array of wxString and not an instance of a *wxString it bugs out. Thanks for reminding me of good coding practice, PB!
wxString *s = new wxString();
wxString *a = new wxString[5];
//..
delete s;
delete a;
Different constructors but equal destructors and since "a" is an array of wxString and not an instance of a *wxString it bugs out. Thanks for reminding me of good coding practice, PB!
I have a bad habbit of not testing the code I post
Re: Irradic AppCrash with wxChoice
BTW: There is really no need to create the strings on the heap. The wxChoice ctor will copy them anyway. Using wxArrayString is the easiest way:
Code: Select all
wxArrayString my_choices;
my_choices.Add( "Item 1");
my_choices.Add( "Item 2");
my_choices.Add( "Item 3");
// and so on
Use the source, Luke!
Re: Irradic AppCrash with wxChoice
It is not possible completely to avoid (string) pointers since my application uses them as client data for list items etc. which again can be used as items for choices. I could use a wxArrayString *sl = new wxArrayString() as item data instead but this would in the end being "same soup different cup"
Thanks for you suggestions
Thanks for you suggestions
I have a bad habbit of not testing the code I post