How should C++ methods that manipulate static data members be defined?

tags:

c++
static

views:

203

answers:

+1 Q:

How should C++ methods that manipulate static data members be defined?

I have a C++ class which contains only static data members. I noticed the compiler is OK if I define the access methods as const, as static, or as "regular" - so all seem to work.

My question is what is the correct/better practice in this case?

Thanks!

+2 A:

Static accessors for static data members.

Seth Illgard 2009-11-11 06:53:23

My compiler does not seem to allow having a method both static and const. I believe that once a method is defined static, then by design it cannot modify the class non-static members - since this method does not "belong" to a specific instance of the class.

Mym 2009-11-11 06:55:45

You are right, my fault.

Seth Illgard 2009-11-11 07:01:51

Thank you. This makes sense to me.

Mym 2009-11-11 07:03:53

@Mym: In your question you state that the class contains only static data members. If the class also contains non-static data, please edit the question. This answer is correct to your question: If you only have static data members, the most appropriate solution is using only static methods on them.

David Rodríguez - dribeas 2009-11-11 07:10:06

For now there are only static data members. The thing is that I want to maintain the flexibility to enhance the class in the future (potentially using local data members) without the need to update any calling code.This is why I want the calling code to create an instance of this class and use the methods via this instance. This is why I was thinking not to define them as static.

Mym 2009-11-11 07:14:56

If it is just statics now, it should not be a class now. If you want to change that later, you can always refactor later. If you force users to create objects even thought they don't hold any state, then that's just confusing.

sbi 2009-11-11 09:26:22

At this point you have a design (whether explicit or just thought of) of your system. When you bind operations together you are assigning a name to it, and that name has a meaning for you and for others to read. At this point you should be able to discuss whether X (whatever your name is) is instantiable.

David Rodríguez - dribeas 2009-11-11 10:48:34

Don't forget about thread safety in case you need to use your static data members in a multi threaded environment.

fritzone 2009-11-11 14:55:04

+2 A:

If your class contains only static members, you should probably be using the singleton pattern.

Alex Deem 2009-11-11 06:53:36

I agree, such a class is effectively a singleton.But what is the problem if I keep it like this?

Mym 2009-11-11 06:58:07

But... be careful. The singleton pattern is often overused.

rlbond 2009-11-11 06:59:27

Actually, there are very few "real" cases where you need the singleton patter, I believe that a class with only static functions is perfectly ok.

Seth Illgard 2009-11-11 07:01:15

@Mym: The problem is that you cannot control the order or initialization of static data members. With a singleton you can use different approaches that guarantee the proper initialization (before use) in all scenarios, while with your solution if another static object (global or static data member of other class) access this class' static members during construction then there is no guarantee that this class members have been properly initialized.

David Rodríguez - dribeas 2009-11-11 07:12:08

Thanks for this data!

Mym 2009-11-11 07:17:05

@dribeas: another static object in a different compilation unit, that is.

Steve Jessop 2009-11-11 16:39:22

Consider the "Borg" pattern: http://code.activestate.com/recipes/66531/ (that article is Python-based, but the pattern is not. The C++ equivalent would be to have non-static member functions which act on static member variables). Alex Martelli points out that the important thing is usually the uniqueness of the state. But Singleton is defined by the uniqueness of the object, which usually is irrelevant. I think of Borg like handles - a handle on a kernel object is not unique, whether the resource it represents is unique or not. Making the handle a singleton would be an unnecessary constraint.

Steve Jessop 2009-11-11 16:48:06

If all methods are static then there is no point in creating an instance of the class. So I suggest to make all methods static so that you can use those methods without creating the object of the class. Basically, you will be able to call the methods using the namespace syntax.

Naveen 2009-11-11 06:53:49

True, so calling code can either create an instance of the class (no penalty, empty c'tor, no non-static data members), or by directly accessing the static methods without creating an instance.

Mym 2009-11-11 07:06:20

Yes..but creating an object directly looks a bit odd for all static variable class.

Naveen 2009-11-11 07:12:17

@Mym: If the class is not meant to be instantiated, you should hide the constructors. Your interface should offer only those operations that make sense for your design. If there are only static data and methods, the constructor should be private (and unimplemented).

David Rodríguez - dribeas 2009-11-11 07:14:25

+2 A:

I have a C++ class which contains only static data members.

Then that probably shouldn't be a class, but either free functions in a namespace or a singleton.

sbi 2009-11-11 06:54:43

I still find it easier to encapsulate them in a designated class since it has a specific role and I have quite a few methods which manipulate these static data members (three different maps).

Mym 2009-11-11 06:59:27

+1 concur! You only need a header wich declares some functions. These functions will mutate whatever static storage variable you desire. No need to declare them in a class and make other translation units depend on this class declaration.

sellibitze 2009-11-11 08:09:36

So, a translation unit should be your "abstraction" (not a class) and a header file would be the interface that doesn't contain any implementation details.

sellibitze 2009-11-11 08:11:35

@Mym: A class is the template for objects. Objects combine state (i.e. data) with behavior (methods). If you have a class that doesn't have state and that isn't there for instantiating objects, then you do _not_ have a class, but a collection of algorithms. Some newer OO languages force you to assemble those in classes, but in C++ you don't need to. You might want to read this article: http://www.idinews.com/quasiClass.pdf

sbi 2009-11-11 09:24:39

Copying the comment I've written in another answer:For now there are only static data members. The thing is that I want to maintain the flexibility to enhance the class in the future (potentially using local data members) without the need to update any calling code. This is why I want the calling code to create an instance of this class and use the methods via this instance. This is why I was thinking not to define them as static.This is why I still want to maintain a class here.

Mym 2009-11-12 09:24:38

@Mym: Why do you copy your comment from there to here? Shall I now copy my answer from there to here, too?

sbi 2009-11-12 23:26:48

ansaurus

tags:

views:

answers:

How should C++ methods that manipulate static data members be defined?

related questions