How C++ manage memory in event driven system ?
-
I am trying to improve my C++ skills and could use some advice. I am using event driven tool - I am not allowed to say the name here - and my basic question is if I create an instance of a class which uses a library should the library by instantiated in class constructor as a common to all class methods variable or be instantiated in each method ( as a local method variable ) as needed ? Process speed is immaterial, my question is about how is memory allocated / de-allocated ( managed by C++) during the events.
-
I am trying to improve my C++ skills and could use some advice. I am using event driven tool - I am not allowed to say the name here - and my basic question is if I create an instance of a class which uses a library should the library by instantiated in class constructor as a common to all class methods variable or be instantiated in each method ( as a local method variable ) as needed ? Process speed is immaterial, my question is about how is memory allocated / de-allocated ( managed by C++) during the events.
You do not normally instantiate a library. If the library contains classes then you would instantiate objects as you need them. If it only contains functions then there is nothing to instantiate. But without details of the actual library and how you want to use it, it is not possible to be clearer.
-
I am trying to improve my C++ skills and could use some advice. I am using event driven tool - I am not allowed to say the name here - and my basic question is if I create an instance of a class which uses a library should the library by instantiated in class constructor as a common to all class methods variable or be instantiated in each method ( as a local method variable ) as needed ? Process speed is immaterial, my question is about how is memory allocated / de-allocated ( managed by C++) during the events.
This is probably best answered by the provider of the library. Is the library smart enough to know it's been initialized, so repeated initializations don't leak resources? Does the library need to initialized per thread, per object created, or on some other scheme? Is finalization needed? If so, is that per thread/object/other? As Richard points out, without more detail, we'd just be guessing.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
This is probably best answered by the provider of the library. Is the library smart enough to know it's been initialized, so repeated initializations don't leak resources? Does the library need to initialized per thread, per object created, or on some other scheme? Is finalization needed? If so, is that per thread/object/other? As Richard points out, without more detail, we'd just be guessing.
"A little song, a little dance, a little seltzer down your pants" Chuckles the clown
Maybe the answer is in this approach create an instance of the object create primary method and create local instance of the library create secondary method and again create local instance of the library that way there are two instances of the library "in use " the compiler /linker may flag it or not I really think the issue is - these methods are events and "go away" when done - which is really confusing as far as actual C++ "deleting" unused stuff.
-
Maybe the answer is in this approach create an instance of the object create primary method and create local instance of the library create secondary method and again create local instance of the library that way there are two instances of the library "in use " the compiler /linker may flag it or not I really think the issue is - these methods are events and "go away" when done - which is really confusing as far as actual C++ "deleting" unused stuff.
Salvatore Terress wrote:
create primary method and create local instance of the library create secondary method and again create local instance of the library
As I said above, there is no "ceate an instance of a library". A library is linked into your application and appears (at the excution level) as if it is just part of your code. So please read my answer once again, or get yourself a good book on C++.
-
Maybe the answer is in this approach create an instance of the object create primary method and create local instance of the library create secondary method and again create local instance of the library that way there are two instances of the library "in use " the compiler /linker may flag it or not I really think the issue is - these methods are events and "go away" when done - which is really confusing as far as actual C++ "deleting" unused stuff.
When we talk about a library we generally mean a DLL (.so in linux world) or static library (.a in linux) that is linked in with your code. That being the case, there is only one instance of any given library during the execution of a single process1, even if its multi threaded. Either you don't understand this, or you're using the term
libraryto refer to something else. If the latter, you need to explain your concerns differently. The difference between a DLL and a static library, in case you don't know, is that the functions in a static library are linked in at compile time, while dynamic libraries are linked in at run time. That means that when a change is introduced in a library (bug fix, for example), a program that is linked against a static library needs to be relinked after the static library has been compiled and installed. A program that is linked against a DLL gets the benefit of the change the next time it is run, without the need to relink it. 1There is a way to get multiple copies of a shared library attached to a single process, but that involves usingdlopen()and friends, which I assume you're not doing here. Update: Just checked, multiple calls to dlopen() does not attach multiple instances of a library to a process, so ignore that bit."A little song, a little dance, a little seltzer down your pants" Chuckles the clown
-
When we talk about a library we generally mean a DLL (.so in linux world) or static library (.a in linux) that is linked in with your code. That being the case, there is only one instance of any given library during the execution of a single process1, even if its multi threaded. Either you don't understand this, or you're using the term
libraryto refer to something else. If the latter, you need to explain your concerns differently. The difference between a DLL and a static library, in case you don't know, is that the functions in a static library are linked in at compile time, while dynamic libraries are linked in at run time. That means that when a change is introduced in a library (bug fix, for example), a program that is linked against a static library needs to be relinked after the static library has been compiled and installed. A program that is linked against a DLL gets the benefit of the change the next time it is run, without the need to relink it. 1There is a way to get multiple copies of a shared library attached to a single process, but that involves usingdlopen()and friends, which I assume you're not doing here. Update: Just checked, multiple calls to dlopen() does not attach multiple instances of a library to a process, so ignore that bit."A little song, a little dance, a little seltzer down your pants" Chuckles the clown