Re: Singleton Review: GCC compiler errors
Tobias Schwinger wrote:
Jason Hise wrote:
Sorry about the duplicate messages, thunderbird seemed to be having a problem. Hoping it's fixed now.
Jason Hise wrote:
Tom Brinkman wrote:
Was the "singleton" library tested on GCC. I'm getting many compiler errors on 3.34.
It was a while back, but many changes have been made since then. I'll see if I can track down a copy of gcc to try compiling with it myself.
Actually, now that I'm looking into it it appears that Dev C++ uses a port of GCC by default, and I have successfully tested the latest version with Dev C++, getting no warnings or errors. What error messages are you getting?
Are you sure you had all warnings enabled (-Wall) ?
It was rather loud on my system. However, I could successfully build tests and example with both 3.2 and 3.4 (both MinGW32).
I'll send the output to you in private mail.
Thanks for the heads up that I needed to use the -Wall option (I'm not used to working with gcc). I am now getting the same warnings that you sent to me, and am working to correct them. In many cases I am getting the warning that specific classes have virtual functions, but non virtual destructors. This is intentional, because they only have virtual functions in debug mode (pure virtual, to make the singleton uncreatable by client code) and will never be destroyed through a pointer to base. I wanted to avoid the overhead of a vtable in release mode. Is there a way to disable this specific warning while compiling with gcc? -Jason
"Jason Hise" wrote:
In many cases I am getting the warning that specific classes have virtual functions, but non virtual destructors. This is intentional, because they only have virtual functions in debug mode (pure virtual, to make the singleton uncreatable by client code) and will never be destroyed through a pointer to base. I wanted to avoid the overhead of a vtable in release mode. Is there a way to disable this specific warning while compiling with gcc?
No, there's no way to disable this or that warning using pragma in GCC (though I read somewhere they will finally add such feature). Perhaps you may use a kludge with conditional macros. /Pavel
Pavel Vozenilek wrote:
"Jason Hise" wrote:
In many cases I am getting the warning that specific classes have virtual functions, but non virtual destructors. This is intentional, because they only have virtual functions in debug mode (pure virtual, to make the singleton uncreatable by client code) and will never be destroyed through a pointer to base. I wanted to avoid the overhead of a vtable in release mode. Is there a way to disable this specific warning while compiling with gcc?
No, there's no way to disable this or that warning using pragma in GCC (though I read somewhere they will finally add such feature).
Perhaps you may use a kludge with conditional macros.
Wouldn't making the destructor virtual in debug mode serve as a satisfactory solution? Andrei
"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
Pavel Vozenilek wrote:
"Jason Hise" wrote:
In many cases I am getting the warning that specific classes have virtual functions, but non virtual destructors. This is intentional, because they only have virtual functions in debug mode (pure virtual, to make the singleton uncreatable by client code) and will never be destroyed through a pointer to base. I wanted to avoid the overhead of a vtable in release mode. Is there a way to disable this specific warning while compiling with gcc?
No, there's no way to disable this or that warning using pragma in GCC (though I read somewhere they will finally add such feature). Perhaps you may use a kludge with conditional macros.
Wouldn't making the destructor virtual in debug mode serve as a satisfactory solution?
Or I guess you could pick one of the many other mechanisms used to make a class abstract (?) -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
Pavel Vozenilek wrote:
"Jason Hise" wrote:
In many cases I am getting the warning that specific classes have virtual functions, but non virtual destructors. This is intentional, because they only have virtual functions in debug mode (pure virtual, to make the singleton uncreatable by client code) and will never be destroyed through a pointer to base. I wanted to avoid the overhead of a vtable in release mode. Is there a way to disable this specific warning while compiling with gcc?
No, there's no way to disable this or that warning using pragma in GCC (though I read somewhere they will finally add such feature). Perhaps you may use a kludge with conditional macros.
Wouldn't making the destructor virtual in debug mode serve as a satisfactory solution?
I suppose this would work. The only problem is that client code must remember to do this as well if they choose for their singleton to
David Abrahams wrote: provide a destructor.
Or I guess you could pick one of the many other mechanisms used to make a class abstract (?)
To which mechanisms are you referring? AFAIK, a pure virtual function is the only way to automatically make any derived classes un-instantiable. -Jason
From: Jason Hise <chaos@ezequal.com>
"Andrei Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@moderncppdesign.com> writes:
Pavel Vozenilek wrote:
"Jason Hise" wrote:
In many cases I am getting the warning that specific classes have virtual functions, but non virtual destructors. This is intentional, because they only have virtual functions in debug mode (pure virtual, to make the singleton uncreatable by client code) and will never be destroyed through a pointer to base. I wanted to avoid the overhead of a vtable in release mode. Is there a way to disable this specific warning while compiling with gcc?
No, there's no way to disable this or that warning using pragma in GCC (though I read somewhere they will finally add such feature). Perhaps you may use a kludge with conditional macros.
Wouldn't making the destructor virtual in debug mode serve as a satisfactory solution?
I suppose this would work. The only problem is that client code must remember to do this as well if they choose for their singleton to
David Abrahams wrote: provide a destructor.
Nope. The derived class dtor would be virtual automatically. (12.4/7) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Jason Hise wrote:
AFAIK, a pure virtual function is the only way to automatically make any derived classes un-instantiable.
Have you considered a protected (or even private if you want complete uninstantiability) constructor ? Regards, Tobias
Tobias Schwinger wrote:
Jason Hise wrote:
AFAIK, a pure virtual function is the only way to automatically make any derived classes un-instantiable.
Have you considered a protected (or even private if you want complete uninstantiability) constructor?
This will not automatically make derived classes uninstantiable. Client code should not be forced to provide a protected constructor if they wouldn't naturally need one... the uninstantiability, if that's a word, should be inherited automatically. A protected constructor would allow a public client default constructor to be generated automatically. Rob Stewart wrote:
Nope. The derived class dtor would be virtual automatically. (12.4/7)
In that case I'll apply the changes and get the new version online as soon as possible. -Jason
Jason, This is part of the rat-hole I was hoping to direct you away from in the thread discussing your Singleton design in late March: http://aspn.activestate.com/ASPN/Mail/Message/2531666 I am still of the opinion that the mechanism you're trying to develop to protect against unwanted multiple instantiations of the singleton object is orthogonal to the design of the singleton, and is clunky besides. My two cents. dr On 5/9/05, Jason Hise <chaos@ezequal.com> wrote:
Tobias Schwinger wrote:
Jason Hise wrote:
AFAIK, a pure virtual function is the only way to automatically make any derived classes un-instantiable.
Have you considered a protected (or even private if you want complete uninstantiability) constructor?
This will not automatically make derived classes uninstantiable. Client code should not be forced to provide a protected constructor if they wouldn't naturally need one... the uninstantiability, if that's a word, should be inherited automatically. A protected constructor would allow a public client default constructor to be generated automatically.
Rob Stewart wrote:
Nope. The derived class dtor would be virtual automatically. (12.4/7)
In that case I'll apply the changes and get the new version online as soon as possible.
-Jason
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, May 06, 2005 at 10:10:04PM -0400, Jason Hise wrote:
In many cases I am getting the warning that specific classes have virtual functions, but non virtual destructors. This is intentional, because they only have virtual functions in debug mode (pure virtual, to make the singleton uncreatable by client code) and will never be destroyed through a pointer to base. I wanted to avoid the overhead of a vtable in release mode. Is there a way to disable this specific warning while compiling with gcc?
-Wno-non-virtual-dtor jon
From: Jonathan Wakely <cow@compsoc.man.ac.uk>
On Fri, May 06, 2005 at 10:10:04PM -0400, Jason Hise wrote:
In many cases I am getting the warning that specific classes have virtual functions, but non virtual destructors. This is intentional, because they only have virtual functions in debug mode (pure virtual, to make the singleton uncreatable by client code) and will never be destroyed through a pointer to base. I wanted to avoid the overhead of a vtable in release mode. Is there a way to disable this specific warning while compiling with gcc?
-Wno-non-virtual-dtor
That would apply to all code using singleton, not just to singleton itself. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
participants (2)
-
Andrei Alexandrescu (See Website For Email) -
Dan Rosen -
David Abrahams -
Jason Hise -
Jonathan Wakely -
Pavel Vozenilek -
Rob Stewart -
Tobias Schwinger