By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,837 Members | 1,637 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,837 IT Pros & Developers. It's quick & easy.

About static member variable

P: n/a
I'd like to write all code of a class in only header file. But when
there is any static member varia ble, I have to define it in cpp file,
not the header file. Otherwise, the static member variable may be
duplicated because two or more cpp files may include the header.
How can I solve this without the cpp file, which used to define the
static member variable?
Thanks!

Sep 29 '07 #1
Share this Question
Share on Google+
13 Replies


P: n/a
ya*********@gmail.com wrote:
I'd like to write all code of a class in only header file. But when
there is any static member varia ble, I have to define it in cpp file,
not the header file. Otherwise, the static member variable may be
duplicated because two or more cpp files may include the header.
How can I solve this without the cpp file, which used to define the
static member variable?
Simple. Don't use any static variables.

If you can asnwer the following questions, you can answer your own:

"I like walking outside when it's raining, and stay dry, but I
don't want to wear any rain gear or carry an umbrella. How to
accomplish my goal?"

"I want to live a long life and be healthy, but I don't want to
give up smoking or alcohol or drugs. How can I do that?"

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Sep 29 '07 #2

P: n/a
Thanks for all your funny answers! :D

It sounds that I have asked for way to an unreachable thing. But I
have found such requirements in real life indeed, while I also have
some "wacky" habit (such as writing class implement in header file
only).

There is a example in Microsoft's ATL. I found class CWindow has a
static member rcDefault. Microsoft use its own keyword
"_declspec(selectany)" to slove this problem. I am curious if there is
a common solution via C++ language itself.

Sep 29 '07 #3

P: n/a
On Sep 29, 7:10 pm, yanlinli...@gmail.com wrote:
I'd like to write all code of a class in only header file.
Why? The header file is visible by all users; the more you put
in it, the more coupling you get, and the harder it is to
maintain the program.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Oct 1 '07 #4

P: n/a
James Kanze <james.ka...@gmail.comwrote:
On Sep 29, 7:10 pm, yanlinli...@gmail.com wrote:
I'd like to write all code of a class in only header file.

Why? The header file is visible by all users; the more you put
in it, the more coupling you get, and the harder it is to
maintain the program.
I don't think that putting all code in header file would increase the
coupling. Since the implementation code is private in class, users can
ignore them usually.

The reason I do this is from the occasion that I publish my code to
others in Windows platform. There are many compiling types for library
(such as multi-threading, multi-threading DLL), and every type can
build as both Debug and Release (as well as ANSI or Unicode, etc.). As
a result, I have to give so many different .lib files. If I publish
my .h and .cpp files, troubles also can be met. Target projects always
need to be changed, to add my .cpp file as one compiling unit. So, I
publish only header files finally, they can only use #include to use
my code now.

Oct 1 '07 #5

P: n/a
On Oct 1, 3:06 pm, yanlinli...@gmail.com wrote:
James Kanze <james.ka...@gmail.comwrote:
On Sep 29, 7:10 pm, yanlinli...@gmail.com wrote:
I'd like to write all code of a class in only header file.
Why? The header file is visible by all users; the more you put
in it, the more coupling you get, and the harder it is to
maintain the program.
I don't think that putting all code in header file would increase the
coupling. Since the implementation code is private in class, users can
ignore them usually.
Never the less, the granularity of the build system is usually
the file; modify the header, and you trigger the recompilation
of the client code; modify a separate source, and you don't. Or
wourse, if for some reason you don't recompile part of the code,
you get inconsistancies.
The reason I do this is from the occasion that I publish my code to
others in Windows platform. There are many compiling types for library
(such as multi-threading, multi-threading DLL), and every type can
build as both Debug and Release (as well as ANSI or Unicode, etc.). As
a result, I have to give so many different .lib files. If I publish
my .h and .cpp files, troubles also can be met. Target projects always
need to be changed, to add my .cpp file as one compiling unit. So, I
publish only header files finally, they can only use #include to use
my code now.
If you want to offer all of the options, you almost have to
provide source, and let the user build the library. Most
libraries I know don't, however. They provide a single .so or
..a, depending on whether they are designed to be linked
dynamically or statically, and the necessary headers.
Typically, you won't have debugging information in the library,
but this is not a problem, because you won't have to debug it.
(What you deliver to the customer is always a "release" build.
By definition.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Oct 2 '07 #6

P: n/a
Alf P. Steinbach wrote:
Constants are not problematic, just use 'const':

const int x = 42;
He was talking about *member* variable (well, a static "member"
variable would technically not be a member variable but a class
variable, but I assume that with "member variable" he meant "class
variable", ie. a static variable inside the scope of a class).

You can't write that for member variables (well, at least not until
the next C++ standard). You can, however, write this:

static const int x = 42;

I'm wondering though: What does the standard say about such static
const variables? Do they need an actual instance or not?

AFAIK not having an actual instance of such a variable can be
problematic if someone takes a pointer to it. A pointer requires that
the variable has an actual physical instance. Moreover, IIRC all
pointers which reference the same variable should be identical (ie. it's
not ok for the compiler to simply instantiate the variable in the
current compilation unit if the code creates a pointer to the variable,
because all such pointers in different compilation units must point to
the same memory location, if I'm not completely mistaken).
Oct 2 '07 #7

P: n/a
Juha Nieminen wrote:
Alf P. Steinbach wrote:
>Constants are not problematic, just use 'const':

const int x = 42;

He was talking about *member* variable (well, a static "member"
variable would technically not be a member variable but a class
variable, but I assume that with "member variable" he meant "class
variable", ie. a static variable inside the scope of a class).

You can't write that for member variables (well, at least not until
the next C++ standard). You can, however, write this:

static const int x = 42;

I'm wondering though: What does the standard say about such static
const variables? Do they need an actual instance or not?

AFAIK not having an actual instance of such a variable can be
problematic if someone takes a pointer to it.
I belive you mean "obtains its address". The actual wording I think
I've seen is "uses it in the context that treats it as an l-value",
which could mean taking its address, initialising a reference with
it, etc. (although I am not sure what's in 'etc')
A pointer requires that
the variable has an actual physical instance. Moreover, IIRC all
pointers which reference the same variable should be identical (ie.
it's not ok for the compiler to simply instantiate the variable in the
current compilation unit if the code creates a pointer to the
variable, because all such pointers in different compilation units
must point to the same memory location, if I'm not completely
mistaken).
I believe you're bringing up the ODR, which should hold for the program
to be a standard C++ program.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 2 '07 #8

P: n/a
On 2007-10-02 07:10:13 -1000, Juha Nieminen <no****@thanks.invalidsaid:
Alf P. Steinbach wrote:
>Constants are not problematic, just use 'const':

const int x = 42;

He was talking about *member* variable (well, a static "member"
variable would technically not be a member variable but a class
variable, but I assume that with "member variable" he meant "class
variable", ie. a static variable inside the scope of a class).
The language definition uses the term "static members" to refer to,
well, static members. They are static and they are members. C++ does
not have the formal notion of "class variable", and using that term
leads to confusion.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Oct 2 '07 #9

P: n/a
Pete Becker wrote:
The language definition uses the term "static members" to refer to,
well, static members. They are static and they are members. C++ does not
have the formal notion of "class variable", and using that term leads to
confusion.
Well, I believe that the distinction between "member functions" and
"class functions" is quite common. Why shouldn't the same distinction be
made with variables?
Oct 2 '07 #10

P: n/a
Juha Nieminen wrote:
Pete Becker wrote:
>The language definition uses the term "static members" to refer to,
well, static members. They are static and they are members. C++ does
not have the formal notion of "class variable", and using that term
leads to confusion.

Well, I believe that the distinction between "member functions" and
"class functions" is quite common. Why shouldn't the same distinction
be made with variables?
I've not seen "class functions" up until your post. What does it mean?

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
Oct 2 '07 #11

P: n/a
On 2007-10-02 09:11:38 -1000, Juha Nieminen <no****@thanks.invalidsaid:
Pete Becker wrote:
>The language definition uses the term "static members" to refer to,
well, static members. They are static and they are members. C++ does not
have the formal notion of "class variable", and using that term leads to
confusion.

Well, I believe that the distinction between "member functions" and
"class functions" is quite common. Why shouldn't the same distinction be
made with variables?
It's not about making the distinction, but about what you call it. The
language definition uses the term "static member" to refer to static
members, both functions (as in "static member function") and data (as
in "static member data"). Don't invent new terms.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Oct 3 '07 #12

P: n/a
On Sep 29, 7:10 pm, yanlinli...@gmail.com wrote:
I'd like to write all code of a class in only header file. But when
there is any static member varia ble, I have to define it in cpp file,
not the header file. Otherwise, the static member variable may be
duplicated because two or more cpp files may include the header.
How can I solve this without the cpp file, which used to define the
static member variable?
Thanks!
I agree with most of what everyone has said, therefore <thissolution
to your problem is not worth much I deem, but it may be considered:

template <class T, class U>
struct HasStaticVar
{
static U get;
};

template <class T,class U>
U HasStaticVar<T,U>::get = U();

struct X : HasStaticVar<X,int>
{
};

int main()
{
X::get = 20;
return 0;
}

Of course, you could make the static member protected
so as to only allow change via derived. If the member
is something other than builtin, you would have to use
interesting schemes to initialize it to something other
than its default. etc. Nevertheless, X has its static
variable.

Kind regards,

Werner

Oct 3 '07 #13

P: n/a
On Oct 2, 7:10 pm, Juha Nieminen <nos...@thanks.invalidwrote:
Alf P. Steinbach wrote:
Constants are not problematic, just use 'const':
const int x = 42;
He was talking about *member* variable (well, a static "member"
variable would technically not be a member variable but a class
variable, but I assume that with "member variable" he meant "class
variable", ie. a static variable inside the scope of a class).
You can't write that for member variables (well, at least not until
the next C++ standard). You can, however, write this:
static const int x = 42;
I'm wondering though: What does the standard say about such static
const variables? Do they need an actual instance or not?
According to the current standard, you need an actual instance
if the variable is ever used. According to the latest draft,
you need an actual instance if the variable is ever used in a
context where it is not immediately subject to an lvalue to
rvalue conversion.

In practice, if you want to be sure that your code will work,
you have to provide an instance.
AFAIK not having an actual instance of such a variable can be
problematic if someone takes a pointer to it. A pointer requires that
the variable has an actual physical instance. Moreover, IIRC all
pointers which reference the same variable should be identical (ie. it's
not ok for the compiler to simply instantiate the variable in the
current compilation unit if the code creates a pointer to the variable,
because all such pointers in different compilation units must point to
the same memory location, if I'm not completely mistaken).
That's exact. The compiler cannot generate more than one
instance of the variable, and still be conform. For all the
compilers I know, if the compiler needs an instance, you must
provide a definition somewhere.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Oct 3 '07 #14

This discussion thread is closed

Replies have been disabled for this discussion.