Re: class variables: scoping
From: Siemel Naran (SiemelNaran_at_REMOVE.att.net)
Date: 04/07/04
- Next message: P.J. Plauger: "Re: STL-container used with references"
- Previous message: Christopher Benson-Manica: "Re: Invalid conversion from 'char' tp 'char*'"
- In reply to: Neil Zanella: "Re: class variables: scoping"
- Next in thread: Alf P. Steinbach: "Re: class variables: scoping"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 07 Apr 2004 20:59:23 GMT
"Neil Zanella" <nzanella@cs.mun.ca> wrote in message
> "Siemel Naran" <SiemelNaran@REMOVE.att.net> wrote in message
news:<7Orcc.25911
> > /*mutable*/ std::set<std::string> d_constructed;
> >
> > and in your functions use the __FUNCTION__ macro to indicate that the
> > variables of this function are constructed. Note that __FUNCTION__ is
not
> > standard, though there are variations you can try.
> Is the __FUNCTION__ macro specific to the gcc compiler suite or does it
work
> with other compilers as well. In any case standard behavior could be
attained
> by using an enumeration with something similar to function names in it.
Borland 6 does not support __FUNCTION__. I think Microsoft does, but ask on
a Microsoft group to be sure, or try it on the compiler.
Instead of maintaining an enum, I was thinking of converting the address of
a function to a string, like this,
void * ptr = static_cast<void *>(&X::function);
std::cout << ptr;
But you can't convert a pointer to member function into a void*, even
through reinterpret_cast, because they usually have different sizes. And
typeid(&X::function).name() prints the type of the function, so if
X::function1 and X::function2 have the same signature, typeid.name() prints
the same thing.
To avoid cluttering the header file, why not just use the pointer to
implementation idea where you declare the struct in the cpp file? You get
insulation for free, can use reference counted smart pointers if so desired
(though they have multi-threading problems/challenges too), etc.
> > The static variables idea in your previous post works could easily cause
> > trouble in multi-threaded environments.
>
> Perhaps you are referring to the fact that in a multithreaded applications
> two objects may have the same virtual address, hence it is not possible to
> identify an object on the basis of its virtual address and be certain that
> the application will work. Is this what you are referring to when you
mention
> that problems may arise in multithreaded applications.
It's the standard one. Two threads call your function X::f(). Both see
that the static variable is not constructed. Then both go ahead and
construct it.
The solution is when one thread sees it is not constructed it blocks the
function memory so the other thread cannot do anything, the the first thread
constructs the object and releases the block, and the other thread then sees
the static variable is constructed. There is no native support for this in
C++. You have to use OS functions like critical section and mutexes. Even
if it works, the use of these OS functions is quite expensive. I'm not an
expert on multi-threading (still learning it myself), but those are the
basics.
- Next message: P.J. Plauger: "Re: STL-container used with references"
- Previous message: Christopher Benson-Manica: "Re: Invalid conversion from 'char' tp 'char*'"
- In reply to: Neil Zanella: "Re: class variables: scoping"
- Next in thread: Alf P. Steinbach: "Re: class variables: scoping"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
