Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
General
GeneralPortable MacsHardwareNetworking
Applications
Mac ApplicationsEudoraFirefox / MozillaInternet ExplorerOutlook ExpressMS OfficeEntourageExcelPowerPointWordVirtual PCMedia PlayerOther MS Products
Programming
Mac ProgrammingCodeWarriorPerl
Country Specific
Australian Mac GroupUK Mac Group

Mac Forum / Programming / CodeWarrior / March 2004



Tip: Looking for answers? Try searching our database.

static globals and vector<bool>

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Michael McLaughlin - 02 Mar 2004 18:33 GMT
In PPx (CW 9.1), I have a class, to manage multiprocessing, instantiated
once as a static global object, theCMP.

This class has a static member

static vector<bool> Waiting;

The class ctor is automatically called prior to main() and, at that
time, Waiting is resized to the number of active processors.  Debugging
confirms this.

However, the first time theCMP is subsequently used the size of Waiting
has decreased to zero, having been cleared (somehow automatically).
Debugging shows the deleter being called deep within library code.  [I
do not call it.]

Note, all of the static members of this class that are scalars retain
their correct values -- e.g., numProcessors.  It is just this vector
that is cleared.

Is this the way the STL is supposed to behave or is this some kind of bug?

TIA.

--
Mike McLaughlin
Matthew Collett - 02 Mar 2004 20:00 GMT
> This class has a static member
>
[quoted text clipped - 8 lines]
> Debugging shows the deleter being called deep within library code.  [I
> do not call it.]

Having a static member of a unique global object is overegging it.  
Since you only have one object, Waiting can be a normal member variable
of it.  A static member will be initialised independently of the object,
and the implementation is free to do these two initialisations in either
order unless both variables (i.e. Waiting and theCMP) are defined in the
same translation unit.  In fact, unless the definitions are in the same
TU with theCMP after Waiting, your use of the static member in the class
constructor is undefined behaviour.  Your observations are consistent
with the static member initialisation being after that of the global
object.

(Also note that std::vector<bool> is 'wierd'; unless you really, really
need to save every last byte, you might be better off with deque<bool>.)

Best wishes,
Matthew Collett

Signature

Those who assert that the mathematical sciences have nothing to say
about the good or the beautiful are mistaken.          -- Aristotle

Michael McLaughlin - 02 Mar 2004 20:57 GMT
I tried making Waiting[] non-static but then I get an error:

"Illegal use of non-static member"

as soon as I try to modify it.  That is, the code will not compile.

Note: Much of the MP manager seems to require static members for various
things which is why I made everything static in the first place.  All
was working until I added this vector<bool>.

>>This class has a static member
>>
[quoted text clipped - 25 lines]
> Best wishes,
> Matthew Collett
Matthew Collett - 04 Mar 2004 07:38 GMT
> >>static vector<bool> Waiting;
> >
[quoted text clipped - 11 lines]
> things which is why I made everything static in the first place.  All
> was working until I added this vector<bool>.

That's odd:  static or not is a C++ distinction, not one that should
make any difference to the OSes MP manager.  It's difficult to say more
without seeing the (minimal) code that produces the error.

Best wishes,
Matthew Collett

Signature

Those who assert that the mathematical sciences have nothing to say
about the good or the beautiful are mistaken.          -- Aristotle

Scott Ribe - 04 Mar 2004 17:37 GMT
> "Illegal use of non-static member"

That would be because you're still trying to access it as though it were
static, rather than treating it as a "normal" class member.
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.