Using objects without ever creating an instance - recommendable?

[lars.uffmann]

Hi everyone!

I am debugging a big piece of code on the search for memory leaks,
using g++ under suse 9.3.
Since I'm trying to eliminate ALL memory leaks, I now stumbled upon a
class foo that is not ever instantiated (thus no constructor or
destructor ever called), but instead, all of its member variables are
defined as static in the according .cpp file, and it's methods are
invoked by calling foo::bar(...) to invoke method "bar(...)".

foo.h:
----------------
class foo {
public:
foo() {};
~foo() {};
static void bar (const char *);

private:
static char * myString;
static int myInt;
}

foo.cpp:
-----------------
/* definition of static members */
char *foo::myString;
int foo::myInt;

void foo::bar (const char *someString) {
myString = (char *) someString;
myInt = 1;
}
------------------

main.cpp:
------------
#include "foo.h"

int main() {
foo::bar ("Hello World!");
}
--------------

From my understanding of C, the line

myString = (char *) someString;
stores a copy of the pointer to the parameter given to foo::bar in
myString, which can cause undefined behaviour, because the parameter
string is a (const char *) and loses validity after the function exits.

Question no. 1: Is that correct?
Question no. 2: Is the usage of classes without an instance excusable
under ANY circumstances? I totally disapprove of this style, but maybe
it's just my lack of understanding of how objects work?

What I see is that there is no defined point to free the memory pointed
to
by any member variables of class foo - the job normally done by a
destructor.

Question no. 3:
If - in order to solve this - I create an instance myFoo of class foo,
and remove the
declarations of static member variables in the foo.cpp, can I be sure
that
I will get an error at compile time, if I forget to change any access
to the
variables from foo::myString to myFoo->myString?
That last question seems obvious to answer, but I want a 2nd opinion

Regards,

Lars Uffmann

 

[Victor Bazarov]

I am debugging a big piece of code on the search for memory leaks,
using g++ under suse 9.3.
Since I'm trying to eliminate ALL memory leaks, I now stumbled upon a
class foo that is not ever instantiated (thus no constructor or
destructor ever called), but instead, all of its member variables are
defined as static in the according .cpp file, and it's methods are
invoked by calling foo::bar(...) to invoke method "bar(...)".

foo.h:
----------------
class foo {
public:
foo() {};
~foo() {};
static void bar (const char *);

private:
static char * myString;

Do the contents of this "string" ever change? No, I don't mean the
value of the pointer, I mean, do you ever change individual chars in
this "string"? If not, it should be declared a pointer to const char:

static char const* myString;

static int myInt;
}

foo.cpp:

And here too

char const* foo::myString;

int foo::myInt;

void foo::bar (const char *someString) {
myString = (char *) someString;

If 'myString' is a pointer to const char, there will be no need to
cast anything.

myInt = 1;
}
------------------

main.cpp:
------------
#include "foo.h"

int main() {
foo::bar ("Hello World!");
}

No. It "stores a copy of the pointer". Not "to the parameter".

given to foo::bar in
myString, which can cause undefined behaviour, because the parameter
string is a (const char *) and loses validity after the function
exits.

No, it does not. The value does not lose validity.

Question no. 1: Is that correct?
No.

Question no. 2: Is the usage of classes without an instance excusable
under ANY circumstances?
Sure.

I totally disapprove of this style, but maybe
it's just my lack of understanding of how objects work?

Static data members are singletons. If the program design calls for
a singleton, use it.

What I see is that there is no defined point to free the memory
pointed to
by any member variables of class foo - the job normally done by a
destructor.

There is no need - objects with static duration are created at the start
of the program and disposed of at the end of the program. If the type
of a static object has a constructor, it will be called, same for the
destructor. In your example, the static objects are of the built-in
types, no constructor or destructor exists.

Question no. 3:
If - in order to solve this - I create an instance myFoo of class foo,
and remove the
declarations of static member variables in the foo.cpp, can I be sure
that
I will get an error at compile time, if I forget to change any access
to the
variables from foo::myString to myFoo->myString?

WHY? What for? Does the program work? If it ain't broke, don't fix it.

That last question seems obvious to answer, but I want a 2nd opinion

Happy to provide one.

BTW, what book on C++ are you currently reading?

V

 

[lars.uffmann]

Do the contents of this "string" ever change? No, I don't mean the
value of the pointer, I mean, do you ever change individual chars in
this "string"? If not, it should be declared a pointer to const char:

Don't change, but it's pretty irrelevant because I was simplifying for
the example. The real code here uses lots of pointers to changing data
as member variables of class "foo".

No. It "stores a copy of the pointer". Not "to the parameter".

Still unclear. Given someString points to memory address X, then
after the assignment of myString, myString also points to memory
address X, right? That's what I meant.

No, it does not. The value does not lose validity.

Oh okay - I didn't know that. So if you store a pointer to a
const char passed to a function, the memory reserved for the
string during the function call stays untouched?

Mkay...

Static data members are singletons. If the program design calls for
a singleton, use it.

Thanks for the keyword...
http://en.wikipedia.org/wiki/Singleton_pattern
cleared up a few of my questions about how it is designed in this code
here. According to wiki, the constructor should be made either private
or protected, is NO constructor achieving the same effect? This class
has none.
For debugging purposes, I made it a normal class now and am using only
1 instance of it.

There is no need - objects with static duration are created at the start
of the program and disposed of at the end of the program. If the type
of a static object has a constructor, it will be called, same for the
destructor. In your example, the static objects are of the built-in
types, no constructor or destructor exists.

Hmm... so that means when the program exits - using exit (0); -
mtrace would NOT detect a memory leak unless there is some bug in the
code?

WHY? What for? Does the program work? If it ain't broke, don't fix it.

Nope - program has some huge memory leaks - over 200 megabytes of log
file from mtrace(). I am trying to fix them one by one, so I'm changing
everything that mtrace identifies as memory leak when I do a chain of
return; - at any point in the program to exit to the main routine and
then exit the
application.

The memory leaks make the code behave unpredictable and the behaviour
changes even on introduction of cerr-statements.

BTW, what book on C++ are you currently reading?

None, I just used the "foo" term because I saw it in lots of examples
and one name is as good as any *g*

Am working on my diploma thesis and in order to implement my code into
this big project, it seems I need to debug the whole project

Regards,

Lars

 

[Victor Bazarov]

Don't change, but it's pretty irrelevant because I was simplifying for
the example. The real code here uses lots of pointers to changing data
as member variables of class "foo".


Still unclear. Given someString points to memory address X, then
after the assignment of myString, myString also points to memory
address X, right? That's what I meant.

Then you're correct. The copy of the pointer value is created.

Oh okay - I didn't know that. So if you store a pointer to a
const char passed to a function, the memory reserved for the
string during the function call stays untouched?

Well, it's so with a literal. Generally speaking (to complicate things)
it is possible that the memory will go away. Inside the function we
don't know how the address passed to the function was obtained. But
it definitely does not lose validity (in your case) until the end of
the function, and if it's the address of the literal, it stays OK.

Thanks for the keyword...
http://en.wikipedia.org/wiki/Singleton_pattern
cleared up a few of my questions about how it is designed in this code
here. According to wiki, the constructor should be made either private
or protected, is NO constructor achieving the same effect? This class
has none.

But this class is not a singleton. Each of the static data members is.
And then, again, don't look at the pattern (yet). If you need some kind
of a C string and it has its designated purpose, and there is no need to
have many of them, then a static data member of some class will do.

For debugging purposes, I made it a normal class now and am using only
1 instance of it.

That's up to you, of course. I was using the word 'singleton' to mean
that there is only one of something, not to refer to the pattern.

Hmm... so that means when the program exits - using exit (0); -
mtrace would NOT detect a memory leak unless there is some bug in the
code?

I don't know what you're talking about.

Nope - program has some huge memory leaks - over 200 megabytes of log
file from mtrace(). I am trying to fix them one by one, so I'm
changing everything that mtrace identifies as memory leak when I do a
chain of return; - at any point in the program to exit to the main
routine and then exit the
application.

That's a good approach. I didn't see any memory leaks in the code you
posted, though.

The memory leaks make the code behave unpredictable and the behaviour
changes even on introduction of cerr-statements.

That can be also due to malformed code produced by the optimizing
compiler.

None, I just used the "foo" term because I saw it in lots of examples
and one name is as good as any *g*

Am working on my diploma thesis and in order to implement my code into
this big project, it seems I need to debug the whole project

Well, good luck with it! Ask more questions as you need. We're here to
help.

V