Global variables...

[Morpheus]

Hello,

Say I have a class with a member...

char mId;

Whenever an object is created, I want to assign an incrementing
character to this member, for instance the first would be A, then B, C,
D, E etc....

Unless I create a singleton class as a provider for this, the only way
I can think of tracking the last ID would be to use a global variable.
Is there a way to do this without either of the above?

Background: We are in the middle of renovating the entire structure of
our software. A customer needs the current build for other fixes
however at the moment I can not access the methods of a particular
class. A global would give me a temporary workaround to access the
member directly... This is probably not enough info to help out but...
(The actualy member is not a char, but for the purpose of this
question it will suffice.

 

[David Harmon]

On 22 Dec 2005 13:10:46 -0800 in comp.lang.c++, "Morpheus"

Whenever an object is created, I want to assign an incrementing
character to this member, for instance the first would be A, then B, C,
D, E etc....

Unless I create a singleton class as a provider for this, the only way
I can think of tracking the last ID would be to use a global variable.

I would guess that the last ID would ordinarily be a static member
variable.

 

[mlimber]

On 22 Dec 2005 13:10:46 -0800 in comp.lang.c++, "Morpheus"


I would guess that the last ID would ordinarily be a static member
variable.

Right. Something like:

class A
{
public:
A() : mID( sID++ ) {}
private:
char mID;
static char sID;
};

char A::sID=0;

Cheers! --M

 

[Victor Bazarov]

Say I have a class with a member...

char mId;

Whenever an object is created, I want to assign an incrementing
character to this member, for instance the first would be A, then B, C,
D, E etc....

Unless I create a singleton class as a provider for this, the only way
I can think of tracking the last ID would be to use a global variable.
Is there a way to do this without either of the above?

A static data member of a class is essentially a hidden global variable.
However, given that it has advantages over a global variable, I'd go that
route, probably.

[.."explanation" of "background" removed -- made no sense anyway..]

V

 

[Axter]

Hello,

Say I have a class with a member...

char mId;

Whenever an object is created, I want to assign an incrementing
character to this member, for instance the first would be A, then B, C,
D, E etc....

Unless I create a singleton class as a provider for this, the only way
I can think of tracking the last ID would be to use a global variable.
Is there a way to do this without either of the above?

Background: We are in the middle of renovating the entire structure of
our software. A customer needs the current build for other fixes
however at the moment I can not access the methods of a particular
class. A global would give me a temporary workaround to access the
member directly... This is probably not enough info to help out but...
(The actualy member is not a char, but for the purpose of this
question it will suffice.

The member type is more important then you may think.
If the type is NOT a POD type, and you have other global comlex types
trying to access them, you're going to run into problems in that the ID
types may or may not be initialized when called before main() starts.
That's because the C++ standard does not garantee the order of
construction for complex objects in multiple translation units.
Global POD types are garanteed to be initialized before global non-POD
types.
So if your ID type is an int type, and you have a global foo type that
tries to access the ID, then you should be safe. But if your ID is a
static std::string member, and you have a global foo type that tries to
access the ID (before main() starts), then you're going to run into
problems, because you have no garantee that the ID variable has been
initialized.

You also have a similar related problem when your application tries to
exit. You could have a static member variable (static std::string ID)
who's destructor has been called, and then have a global type try to
access it after it's been destroyed.

One easy safe workaround solution is to use a function that stores the
complex object as a local static variable.

std::string& GetID()
{
static std::string *strID = new std::string();
return *strID;
}

IAW C++ standard this would garantee that the object would be created
when fetching it from multiple translation (modules) units (via global
object).

You can also use a method MS used with it's CString class for default
emtpy CString's, but I'm not sure how portable that method would be.

 

[Jay Nabonne]

Right. Something like:

class A
{
public:
A() : mID( sID++ ) {}
private:
char mID;
static char sID;
};

char A::sID=0;

That works. Here's another similar way:

class A
{
public:
A() : mID( GetNextID() ) {}
private:

static char GetNextID()
{
static char sID = 0;
return SID++;
}

char mID;
};

- Jay

 

[Victor Bazarov]

[..]
static char GetNextID()
{
static char sID = 0;
return SID++;

return sID++;

}
[..]

 

[Morpheus]

Good... thanks for the help. I was originally thinking of a static
member but thought that setting it in one object would affect the
other... using a static variable within a method seems to do the trick,
at least as a workaround and does not "seem" to break any rules.

[.."explanation" of "background" removed -- made no sense anyway..]

Hence my disclaimer "This is probably not enough info to help out
but... "

 

[Jay Nabonne]

Good... thanks for the help. I was originally thinking of a static
member but thought that setting it in one object would affect the
other... using a static variable within a method seems to do the trick,
at least as a workaround and does not "seem" to break any rules.

[.."explanation" of "background" removed -- made no sense anyway..]

Hence my disclaimer "This is probably not enough info to help out
but... "

The *behavior* should be equivalent (class static vs. local static vs
global). It's just a question of where the persistent variable is (i.e.
it's a design question). The whole point of the persistent variable is
that it *does* affect other objects (every object of that class created,
in fact).

- Jay