Static Method/stateless/statefull/how to :-)

[MaxMax]

Now... I have a problem... It's an engineering problem.
I have a function, we will call it MyBigFunc. It's a function that can be
easily built as a static method, because it is the only function that the
"user" will use and it is stateless.

So I wrote something like:
class MyClass
{
public:
static int MyBigFunc() { return 0;}
};

Clearly there are some private/protected methods that are called by
MyBigFunc. There is a storage (a sub-class) that is istantiated by MyBigFunc
and is destroyed at the end of MyBigFunc. It's quite big but it's life is
short (the life of MyBigFunc) The private/protected methods receive a
pointer to this subclass.

....
private:
class MyClassSomeData
{
};
....

Then I decided to make it easily expandible, so I built some overridable
functions that are called by MyBigFunc at various times. Clearly to be
called by a static function they are static :-) The problem is that the
"user" functions probably will need some private data that THEY will produce
(so, for example, if a1, a2 and a3 are methods called by MyBigFunc, a1 could
open a file that will be used by a2 and a3. The file must be closed in the
end). There is even the possibility (it is probable) that a derived class
will be stateful. So now I don't know what to do.

Oh... yes... I was forgetting something: at this time the base class is a
template class and it calls the methods through "template-virtual" calls

So it's more like:

template <class T>
class MyClass
{
public:
static int MyBigFunc()
{
MyClassSomeData SomeData;
T::OneFunc(&SomeData);
return 0;
}
static int OneFunc(MyClassSomeData *pSomeData) { // donothing }
};

[Greg]

MaxMax wrote:

Now... I have a problem... It's an engineering problem.
I have a function, we will call it MyBigFunc. It's a function that can be
easily built as a static method, because it is the only function that the
"user" will use and it is stateless.

So I wrote something like:
class MyClass
{
public:
static int MyBigFunc() { return 0;}
};

Clearly there are some private/protected methods that are called by
MyBigFunc. There is a storage (a sub-class) that is istantiated by MyBigFunc
and is destroyed at the end of MyBigFunc. It's quite big but it's life is
short (the life of MyBigFunc) The private/protected methods receive a
pointer to this subclass.

...
private:
class MyClassSomeData
{
};
...

Then I decided to make it easily expandible, so I built some overridable
functions that are called by MyBigFunc at various times. Clearly to be
called by a static function they are static :-) The problem is that the
"user" functions probably will need some private data that THEY will produce
(so, for example, if a1, a2 and a3 are methods called by MyBigFunc, a1 could
open a file that will be used by a2 and a3. The file must be closed in the
end). There is even the possibility (it is probable) that a derived class
will be stateful. So now I don't know what to do.

Oh... yes... I was forgetting something: at this time the base class is a
template class and it calls the methods through "template-virtual" calls

So it's more like:

template <class T>
class MyClass
{
public:
static int MyBigFunc()
{
MyClassSomeData SomeData;
T::OneFunc(&SomeData);
return 0;
}
static int OneFunc(MyClassSomeData *pSomeData) { // donothing }
};

I think your post got cut off before it got to the question. Assuming
that you are interested in alternative design ideas, I would recommend
looking into function objects instead of purely static functions:

struct MyBigFunctionObjectClass
{
int operator() const;
...
} BigFunction;

int main()
{
int x = BigFunction();
...

MyBigFunctionObjectClass can be subclassed, its function call operator
can be declared virtual - or be declared a member template - in short
there's quite a range of possible uses for function objects that one of
them might work well for your situation.

Greg

[MaxMax]

> I think your post got cut off before it got to the question. Assuming

that you are interested in alternative design ideas, I would recommend
looking into function objects instead of purely static functions: No no... the question was "how should I build the class"
struct MyBigFunctionObjectClass
{
int operator() const;
...
} BigFunction;

Mmmh... It seems a little strange... And I would need a .cpp file (because
if I include this in a .h file the linker will complain about multiple
BigFunction)... But then I'll need a .h file because I'm using templates
(and I'm not using Comeau)

--- bye

[Jonathan Mcdougall]

MaxMax wrote:

Now... I have a problem... It's an engineering problem.
Since this is not a precise question about a language feature, you
should have put more efforts in making the question simple. You
probably won't get many answers to this post.
I have a function, we will call it MyBigFunc. It's a function that can be
easily built as a static method, because it is the only function that the
"user" will use and it is stateless.
This is an invalid premise. You should use static member functions if
1) the class is stateless
2) creating several instances of the class is invalid semantically

The first point seems to be refuted below when you say "There is even
the possibility (it is probable) that a derived class will be
stateful". You never talked about the second point so I assume it is
not important.
So I wrote something like:
class MyClass
{
public:
static int MyBigFunc() { return 0;}
};

Clearly there are some private/protected methods that are called by
MyBigFunc.

There is a storage (a sub-class) that is istantiated by MyBigFunc
and is destroyed at the end of MyBigFunc. It's quite big but it's life is
short (the life of MyBigFunc) The private/protected methods receive a
pointer to this subclass.

...
private:
class MyClassSomeData
{
};
...

Then I decided to make it easily expandible, so I built some overridable
functions that are called by MyBigFunc at various times. Clearly to be
called by a static function they are static :-) The problem is that the
"user" functions probably will need some private data that THEY will produce
(so, for example, if a1, a2 and a3 are methods called by MyBigFunc, a1 could
open a file that will be used by a2 and a3. The file must be closed in the
end). There is even the possibility (it is probable) that a derived class
will be stateful. So now I don't know what to do.

Oh... yes... I was forgetting something: at this time the base class is a
template class and it calls the methods through "template-virtual" calls

So it's more like:

template <class T>
class MyClass
{
public:
static int MyBigFunc()
{
MyClassSomeData SomeData;
T::OneFunc(&SomeData);
return 0;
}
static int OneFunc(MyClassSomeData *pSomeData) { // donothing }
};

That's a weird design. You should use virtual functions instead.

class MyClass
{
public:
int MyBigFunc()
{
MyClassSomeData some_data;
one_fun(&some_data);
return 0;
}

virtual int one_fun(MyClassSomeData *sd)
{
// do nothing
}
};

class Derived : public MyClass
{
public:
virtual int one_fun(MyClassSomeData *sd)
{
// ..
}
};

You may make MyClass a singleton, though this is another matter
completly. If you don't really need MyClass to have only one instance,
you can forget static member functions for this design.
Jonathan

[MaxMax]

> This is an invalid premise. You should use static member functions if

1) the class is stateless The class IS stateless. A derived class could be stateless or could be
statefull. I'm building the class to be easily expandable. 2) creating several instances of the class is invalid semantically

This isn't my problem.

The main problem is that if I create a stateless class using static
functions it will be very difficult to derive it in a statefull class. I was
even thinking of using the preprocessor to make something like:

#define STATELESSCLASS static

so that the "user" can select if he want the class to be stateless or
statefull

and then
#ifdef STATELESSCLASS
class MyClassStateless
#else
class MyClassStatefull
#endif
STATELESSCLASS int MyBigFunction()
{
}

In this way the "user" can include twice the header, once with and once
without the STATELESSCLASS defined and have both, or he can include it once
and have only one of the two.

--- bye