|
Calin Negru wrote: do I need to delete the vector once the work is done?
for(int i=0;i<3;i++)
{
vector<thing*> * Nodes = new vector <thing*>();
thing * Athing = new thing();
Nodes->push_back(Athing);
//do stuff
Nodes->clear();
delete Nodes;
}
Yes, you do.
Since you created it (vector) with new then you need to delete the vector once the work is done
|
|
|
|
|
What happens if I don’t delete the vector, will that cause a memory leak or it’s just allocated memory that is not used and takes extra space. The program doesn’t break with an error when I do source code version No 1
I have unexpected behavior somewhere else in my program and I was wondering if this could be the cause of it.
modified 9-May-24 10:43am.
|
|
|
|
|
With a memory leak, the memory footprint of the running process increases over time. If the conditions that lead to the leak are encountered often enough, the process will eventually run out of available memory, usually causing an exception of some sort. Unless you're in a very specialized environment, the memory associated with the process gets released when it exits. That means that the overall memory on the system doesn't get incrementally consumed over time. So you really only run the risk of the one process running out of memory, not the system as a whole. I hope I've explained that clearly enough.
Some system calls (and some user written functions!) use this to their advantage. On the first call they will allocate some memory, and then reuse it on successive calls. With no cleanup routine, they just rely on the program exit to do the memory release. That's why you might get notice of memory in use at exit when running a program under a memory diagnostic tool like Valgrind. When you trace back to where the memory was allocated, it might be inside something like fopen().
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
Thanks k5054 I think I understand. What I described in the first example is a memory leak but probably is not causing problems elsewhere.
|
|
|
|
|
If by "not causing problems elsewhere" you mean it's not affecting other processes, that's mostly true. You can, of course, run into an Out Of Memory (OOM) situation, where all the RAM and swap is marked as "in use", and Bad Things start happening. Assuming you've got a 64 bit OS with lots of RAM and swap configured, (heck, even a 32 bit OS with good Virtual Memory), that's only likely to happen if you've got a lot of memory allocated.
As a rule of thumb, you should clean up memory when it's no longer needed. Think of it like craftsmanship. A piece of Faberge jewelry shows attention to detail from both the back and the front. Freeing up unused memory is part of the attention to detail, just like closing files after use, for example.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
On top of what Victor said, look into using std::unique_ptr instead of "naked" pointers. Something like this:
auto Nodes = new std::vector< < std::unique_ptr<Thing> >;
Nodes->push_back( std::make_unique<Thing>() );
delete []Nodes;
Edit:
It is a bit unusual to "new" vectors. Given they can grow dynamically, in most cases you would write something like:
std::vector<<std::unique_ptr <Thing> >nodes;
nodes.push_back (std::make_unique<Thing>( ) );
When nodes goes out of scope all Things get deleted automatically.
Mircea
modified 9-May-24 9:41am.
|
|
|
|
|
Yes, you have to explicitly delete the vectors you allocated using new.
But that's not enough.
Try running the following code
#include <iostream>
#include <vector>
using namespace std;
class thing
{
public:
thing(){cout << "thing ctor\n";}
~thing(){cout << "thing dtor\n";}
};
int main()
{
for(int i=0;i<3;i++)
{
vector<thing*> * Nodes = new vector <thing*>();
thing * Athing = new thing();
Nodes->push_back(Athing);
Nodes->clear();
delete Nodes;
}
}
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Thank you guys for your feedback. I think I understand what a memory leak is now.
|
|
|
|
|
You are welcome.
As suggested, have a look at smart pointers, they could make your coding life easier.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Ah memory leaks (and small buffer overruns).
I would point out that your example is fairly obvious. If you have a long running task, and this code is in some sort of processing loop, you'll see it quickly. What will really bite you in the a$$ are the small leaks. A byte here, a byte there. I live in the embedded world where customers forget our equipment was installed under their production line 10 years ago. The engineer responsible either died, retired or moved on to another company. I'm not being morbid, I have stories I could tell you 
The group I work in is a decent group of smart people. Sadly, they never let us into the field to see how the product is actually used. The few times I've seen examples, they always shock me with "I didn't see that coming" sort of response. What amazes me is that if your customer never turns off your machine, why not set up an area where a test unit runs forever? I guess it falls under diminishing returns.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
Hi,
I have considerable work with mfc but not quite familiar with controlling USB power through windows resources programmatically. Any codes or material available?.
|
|
|
|
|
etechX2 wrote: I am beginner
A beginner programmer should not attempt that. You would need to learn quite a bit of just programming in C++ and then programming for windows and then programming to the device interface.
|
|
|
|
|
|
yeah, you are going to be down into device drivers and what not. I'm sure Microsoft has an API somewhere, but it'll change.
Charlie Gilley
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
Has never been more appropriate.
|
|
|
|
|
I am asking for code assistance, I am NOT asking for opinions, to implement
"foreach" to be able to write something likes
"action-> trigger this code "
I am asking for code help to rewrite this to recursively go thru the object hierarchy until "textMatch" is found
<pre>
QString textMatch = test; QList<QAction*> pTEST = parent->findChildren<QAction *>();
foreach( auto *action, pTEST)
{
text = action->objectName();
qDebug().noquote() << text;
if(text.contains(textMatch))
{
#ifdef RETILE
text = "match found parent ";
text += parent->objectName();
text += "\n action ";
text += action->objectName();
qDebug().noquote() << text;
#endif
action->trigger();
text += " foreach match ";
qDebug().noquote() << text;
return 0;
break;
}
}
The code abiove works fine "in single stage",
I need it to iterate , using foreach preferred, but not mandatory, thru the entire tree.
PLEASE NOTE
This is an "under construction code " and will be deleted AFTER solution is found.
"actionTile_subwindows" QAction
Locals
event @0x7fffffffca20 QCloseEvent
mdiParent @0x7ffff4ea5453 QMdiSubWindow
pActions <not accessible> QList<QAction*>
pL <not accessible> QList<QObject*>
pLParent <not accessible> QList<QObject*>
pLParent_Action <not accessible> QList<QAction*>
pOBJECT 0x5d0000006e QWidget*
pTEST @0x7fffffffc550 QWidget
this "SettingsDialog" SettingsDialog
[QDialog] "SettingsDialog" QDialog
[d] @0x555555d923e0 QDialogPrivate
[parent] @0x555555de3310 QMdiSubWindow
[QWidget] @0x555555de3310 QWidget
[d] @0x5555556d1000 QMdiSubWindowPrivate
[parent] @0x555555c30e80 QWidget
[QObject] @0x555555c30e80 QObject
[QPaintDevice] @0x555555c30e90 QPaintDevice
[d] @0x555555c30ec0 QWidgetPrivate
[parent] @0x555555c64250 QMdiArea
[QAbstractScrollArea] @0x555555c64250 QAbstractScrollArea
[d] @0x5555559ff1a0 QMdiAreaPrivate
[parent] "MainWindow_Bluetooth" MainWindow_Bluetooth
[QMainWindow] "MainWindow_Bluetooth" QMainWindow
[d] @0x555555c2ed00 QMainWindowPrivate
[parent] @0x555555ccf290 QMdiSubWindow
[children] <35 items> QList<QObject*>
[0] "_layout" QMainWindowLayout
[1] @0x555555c64250 QMdiArea
[2] "SettingsDialog" SettingsDialog
[3] @0x555555cdddc0 QSerialPort
[4] "actionAbout" QAction
[5] "actionAboutQt" QAction
[6] "actionConnect" QAction
[7] "actionDisconnect" QAction
[8] "actionConfigure" QAction
[9] "actionClear" QAction
[10] "actionQuit" QAction
[11] "actionVirtual_serial_port" QAction
[12] "actionBluetooth_virtual_port" QAction
[13] "actionBluetooth" QAction
[14] "actionBluetooith_virtiual_port" QAction
[15] "actionBluetooth_service_enable" QAction
[16] "actionWinsow_control" QAction
[17] "actionWindoiw_control" QAction
[18] "actionTEST_tile" QAction
[19] "actionTEST_resize" QAction
[20] "actionTile_subwindows" QAction
[21] "actionCascade_subwindows" QAction
[22] "actionMaximize_current_subwindow" QAction
[23] "actionTEST" QAction
[24] "actionSubmenu_1" QAction
[25] "actionSubmenuy_2" QAction
[26] "actionClear_all_windoiws" QAction
[27] "actionClear_all_windiws" QAction
[28] "actionSerial_test" QAction
[29] "actionSerial_test_2" QAction
[30] "actionC_code_scan" QAction
[31] "actionSelect_MDI_subwindow_MDI_window_control" QAction
[32] "menuBar" QMenuBar
[33] "mainToolBar" QToolBar
[34] "statusBar" QStatusBar
[properties] <at least 0 items>
[methods] <20 items>
[extra]
Menu_Index 0 int
command 0x0 char*
index 8 int
index_sub 0 int
list_array @0x555555bd2370 QStringList[10]
m_TAB_CommonDebug "A_BT_TAB_DIALOG" A_BT_TAB_DIALOG
m_TAB_Connect 0x0 A_BT_TAB_DIALOG*
m_TAB_Ext 0x0 A_BT_TAB_DIALOG_EXT*
m_console @0x555555c314f0 Console
m_mdiarea @0x555555c64250 QMdiArea
m_serial @0x555555cdddc0 QSerialPort
m_settings "SettingsDialog" SettingsDialog
m_settings_RFcomm 0x0 SettingsDialog_RFcomm*
m_status @0x555555c64370 QLabel
m_ui @0x5555556735a0 Ui::MainWindow_Bluetooth
mainAction @0x555555bd24c8 QAction*[16]
result "" QString
subAction @0x555555bd23c8 QAction*[16]
subMenu @0x555555bd2448 QMenu*[16]
text " Parent console (case 7) " QString
verify @0x555555bd2570 QStringList[16]
[children] <3 items> QList<QObject*>
[0] "qt_scrollarea_hcontainer" QAbstractScrollAreaScrollBarContainer
[1] "qt_scrollarea_vcontainer" QAbstractScrollAreaScrollBarContainer
[2] @0x555555c30e80 QWidget
[properties] <at least 8 items>
[methods] <14 items>
[extra]
[children] <6 items> QList<QObject*>
[properties] <at least 59 items>
[methods] <27 items>
[0] windowTitleChanged
[nameindex] 1
[type] signal
[argc] 1
[parameter] 149
[tag] 2
[flags] 6
[localindex] 0
[globalindex] 5
[1] windowIconChanged
[nameindex] 4
[type] signal
[argc] 1
[parameter] 152
[tag] 2
[flags] 6
[localindex] 1
[globalindex] 6
[2] windowIconTextChanged
[nameindex] 6
[type] signal
[argc] 1
[parameter] 155
[tag] 2
[flags] 6
[localindex] 2
[globalindex] 7
[3] customContextMenuRequested
[nameindex] 8
[type] signal
[argc] 1
[parameter] 158
[tag] 2
[flags] 6
[localindex] 3
[globalindex] 8
[4] setEnabled
[nameindex] 10
[type] slot
[argc] 1
[parameter] 161
[tag] 2
[flags] 10
[localindex] 4
[globalindex] 9
[5] setDisabled
[nameindex] 11
[type] slot
[argc] 1
[parameter] 164
[tag] 2
[flags] 10
[localindex] 5
[globalindex] 10
[6] setWindowModified
[nameindex] 12
[type] slot
[argc] 1
[parameter] 167
[tag] 2
[flags] 10
[localindex] 6
[globalindex] 11
[7] setWindowTitle
[nameindex] 13
[type] slot
[argc] 1
[parameter] 170
[tag] 2
[flags] 10
[localindex] 7
[globalindex] 12
[8] setStyleSheet
[nameindex] 14
[type] slot
[argc] 1
[parameter] 173
[tag] 2
[flags] 10
[localindex] 8
[globalindex] 13
[9] setFocus
[nameindex] 16
[type] slot
[argc] 0
[parameter] 176
[tag] 2
[flags] 10
[localindex] 9
[globalindex] 14
[10] update
[nameindex] 17
[type] slot
[argc] 0
[parameter] 177
[tag] 2
[flags] 10
[localindex] 10
[globalindex] 15
[11] repaint
[nameindex] 18
[type] slot
[argc] 0
[parameter] 178
[tag] 2
[flags] 10
[localindex] 11
[globalindex] 16
[12] setVisible
[nameindex] 19
[type] slot
[argc] 1
[parameter] 179
[tag] 2
[flags] 10
[localindex] 12
[globalindex] 17
[13] setHidden
[nameindex] 21
[type] slot
[argc] 1
[parameter] 182
[tag] 2
[flags] 10
[localindex] 13
[globalindex] 18
[14] show
[nameindex] 23
[type] slot
[argc] 0
[parameter] 185
[tag] 2
[flags] 10
[localindex] 14
[globalindex] 19
[15] hide
[nameindex] 24
[type] slot
[argc] 0
[parameter] 186
[tag] 2
[flags] 10
[localindex] 15
[globalindex] 20
[16] showMinimized
[nameindex] 25
[type] slot
[argc] 0
[parameter] 187
[tag] 2
[flags] 10
[localindex] 16
[globalindex] 21
[17] showMaximized
[nameindex] 26
[type] slot
[argc] 0
[parameter] 188
[tag] 2
[flags] 10
[localindex] 17
[globalindex] 22
[18] showFullScreen
[nameindex] 27
[type] slot
[argc] 0
[parameter] 189
[tag] 2
[flags] 10
[localindex] 18
[globalindex] 23
[19] showNormal
[nameindex] 28
[type] slot
[argc] 0
[parameter] 190
[tag] 2
[flags] 10
[localindex] 19
[globalindex] 24
[20] close
[nameindex] 29
[type] slot
[argc] 0
[parameter] 191
[tag] 2
[flags] 10
[localindex] 20
[globalindex] 25
[21] raise
[nameindex] 30
[type] slot
[argc] 0
[parameter] 192
[tag] 2
[flags] 10
[localindex] 21
[globalindex] 26
[22] lower
[nameindex] 31
[type] slot
[argc] 0
[parameter] 193
[tag] 2
[flags] 10
[localindex] 22
[globalindex] 27
[23] updateMicroFocus
[nameindex] 32
[type] <unknown>
[argc] 0
[parameter] 194
[tag] 2
[flags] 9
[localindex] 23
[globalindex] 28
[24] _q_showIfNotHidden
[nameindex] 33
[type] <unknown>
[argc] 0
[parameter] 195
[tag] 2
[flags] 8
[localindex] 24
[globalindex] 29
[25] grab
[nameindex] 34
[type] <unknown>
[argc] 1
[parameter] 196
[tag] 2
[flags] 2
[localindex] 25
[globalindex] 30
[26] grab
[nameindex] 34
[type] <unknown>
[argc] 0
[parameter] 199
[tag] 2
[flags] 34
[localindex] 26
[globalindex] 31
[extra]
data @0x555555c30fe0 QWidgetData
[children] <4 items> QList<QObject*>
[properties] <at least 2 items>
[methods] <7 items>
[extra]
[children] <8 items> QList<QObject*>
[properties] <at least 0 items>
[methods] <8 items>
[extra]
ConnectIndex 1 int
ConnectParent "MainWindow_Bluetooth" MainWindow_Bluetooth
ConnectText " TEST SettingsDialog Constructor (emit index 1 ) " QString
m_TAB_CommonDebug 0x0 A_BT_TAB_DIALOG*
m_TAB_Connect "A_BT_TAB_DIALOG" A_BT_TAB_DIALOG
m_TAB_Ext "A_BT_TAB_DIALOG_EXT" A_BT_TAB_DIALOG_EXT
m_currentSettings @0x555555d86c88 SettingsDialog::Settings
m_intValidator @0x555555dc61c0 QIntValidator
m_status @0x555555dc5af0 QLabel
m_ui @0x555555cb7d90 Ui::SettingsDialog
pTAB "A_BT_TAB_DIALOG" A_BT_TAB_DIALOG
staticMetaObject @0x7ffff7f03560 QMetaObject
statusBar @0x555555dd75f0 QStatusBar
text " this->parent()->objectName() " QString
Inspector
Expressions
"(?<=\thci0 <no such value>
// subMenu[index] = subMenu[index]
// ->addMenu(list[index] +
SERIAL_SETUP
SetupRun
endif
// //subtempmenu = new QMenu();
//
m_ui->actionConnect
processAction
qDebug().noquote() << text;
Return Value
Tooltip
|
|
|
|
|
There's probably a nice template way to do this. But if I understand you're problem, here's a simple C++ program with multi-level tree that you may be able to adapt to your situation:
#include <vector>
#include <iostream>
class Tree {
public:
int datum;
std::vector<Tree> children;
Tree(int d) :datum(d) {}
};
void walk(Tree& t, size_t n, void fn(const Tree& t, size_t n) )
{
fn(t, n);
for(auto child: t.children)
walk(child, n+1, fn);
}
int main()
{
Tree t(0);
for(int x = 1; x < 3; ++x)
{
Tree tmp(x);
t.children.push_back(tmp);
}
for(int y = 100; y < 500; y += 100 )
{
Tree tmp(y);
t.children[0].children.push_back(tmp);
}
walk(t, 0, [](const Tree& t, size_t indent) { std::cout << std::string(indent*3, ' ') << t.datum << '\n'; });
} This processes the parent before the children, but you can reverse the lines of the walk function to do the children first, if preferred. foreach is not part of the C++ standard, but the ranged for loop has been since C++-11, so your compiler almost certainly supports it. Whether QT containers will work with ranged for loops is not known to me. Still, the idea is the same. Create a recursive function that processes the parent, then calls itself on each of the children.
I'm sure there's a more generic way to do this using templates, that parameterizes the function, which would mean you don't have to write a separate walk function for every distinct function prototype on fn. Maybe that's an exercise you could undertake to help improve your understanding of templates, and other C++ facilities.
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
modified 8-May-24 13:32pm.
|
|
|
|
|
Thank you.
I was hoping to build on my current knowledge and working code , regardless if it is standard or not.
I am looking into this
QTreeWidgetItemIterator<QAction*> it(parent<QAction*>(this));
and have two issues with it
I still cannot access the object "parent" and it looks as this class expects
tree widget to iterate.
Moore RTFM.
|
|
|
|
|
Salvatore Terress wrote: Moore RTFM
Correct
"A little song, a little dance, a little seltzer down your pants"
Chuckles the clown
|
|
|
|
|
It worked...
I did save you a time to write FOUR letters...
Maybe I should end my post instead of
Cheers
( I hope you take this post as a joke ...good night from Huston )
|
|
|
|
|
Well, I am getting few "try it this way".
I believe there are many ways to "skin a cat" , but these well meaning alternative suggestion are
distraction from the task at hand.
Actually I have to "back-paddle " in my "foreach"' approach.
Before I can iterate I have to have a list and it better be of compatible type...
That also applies if I use any of the Qt ways to iterate...
Cheers
|
|
|
|
|
POST voluntarily removed - no response
modified 9-May-24 10:43am.
|
|
|
|
|
1. This has nothing to do with templates.
2. If you change the word pTEST in the first example to actionList, you will see that they are both exactly the same. Barring, of course the line:
text += " match ";
which is not present in the second sample.
And since the findChildren function returns a list of QAction* items, it matters not whether you specify it explicitly, or leave the compiler to infer it from the context.
|
|
|
|
|
Please do not do this. I posted a response which explained the situation. Now anyone who reads my response will have no idea what your question was even about.
|
|
|
|
|
VOLUNTARILY REMOVED
modified 6-May-24 16:22pm.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
