Re: Avoiding the anonymous variable declaration RAII error...
On Mar 13, 10:47 pm, "Eric J. Holtman" <e...@ericholtman.com> wrote:
Greg Herlihy <gre...@mac.com> wrote innews:bd2ea86e-eac1-418a-820a-f2b60540b475@e6g2000prf.googlegroups.com:
Actually there is a very simple technique to prevent an unnamed Locker
variable - just replace "Locker" in the variable's declaration with an
equivalent typedef:
typedef Locker StLocker;
void
process_threaded_data ()
{
StLocker (m_mutex); // Error
StLocker lk (m_mutex); // OK
// ...
At least on MS Visual Studio 2005, that does not
produce an error.
So, would you expect the Visual Studio 2005 C++ compiler to compile
this program successfully:
struct Mutex
{};
struct Locker
{
Locker(const Mutex&) {}
};
typedef Locker StLocker;
Mutex m_mutex;
int main()
{
StLocker (m_mutex); // ?? OK or Error?
}
In fact no version (6, 7, or 8) of the Visual Studio C++ compiler, nor
the gcc, Comeau, or EDG C++ compilers will successfully compile the
above program. And in each case, the C++ compiler reports the same
error:
Error: 'Locker' : no appropriate default constructor available
According to this error message, a C++ compiler interprets this
declaration:
StLocker (m_mutex)
as the equivalent to this declaration:
Locker m_mutex;
In both cases, the program is declaring (and default-constructing) a
Locker object named "m_mutex" - and in neither case is the program
initializing an unnamed Locker object with a Mutex variable named
"m_mutex". So the difference between using a typedef name and the
equivalent class name in this context - has a dramatic effect on the
declaration's meaning.
So, unless Locker's Mutex initializer is in fact optional, the fact
that your program allows Locker class to be default-constructed - is a
serious flaw in Locker's implementation; especially since a typedef
name can - as shown above - easily conceal the fact that a particular
Locker object is being default-constructed.
I wouldn't expect it to: a typedef doesn't introduce
a new type, it's just a synonym.
Your premise does not support your conclusion. The fact that a typedef
name does not name a type in its own right (like a class name does) -
is exactly the reason why a typedef name does not behave exactly like
a class name in every context.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]