Re: cyclic dependency in throw declaration
On May 5, 4:35 pm, Michael Doubez <michael.dou...@gmail.com> wrote:
On 5 mai, 12:05, sgurukr...@gmail.com wrote:
I am trying to solve a weird problem because of the
following design that I want to implement.
I have an 'exception' class that no other function must be
able to throw except a select group of functions. I want the
compiler to prohibit people who use my code the capability
of throwing instances of my exception class.
The solution that works 99.99% of the time it to tell it in
your comments.
Agreed. And even then: I can't think of the slightest valid
reason for not allowing the client code to create instances, if
it wants. It can't really hurt your code in any way.
However they will still be able catch objects of the
exception class. Why do I want to do this ? This brings
clarity to the working of the code - the source of all
instances of my exception class is only one - my code. I
could have easily acheived this in Java by making the
constructor of my exception class package- private ( which I
acheive by not specifying any access modifier for the
constructor ) .
Except that that doesn't work in Java. Unless your class is
also final, anyone can access the package access elements just
by deriving from it.
I would then put the exception class inside the package
where my code will be making new instances of the exception
class. But C++ lacks this kind of access modifier. Now how
should I design my exception class to achieve this in C++ ?
Make the constructor private and declare one class as friend
which will be used in your code to generate your exception.
Don't publicly expose the detail of the friend class.
I resorted to making the constructor of my exception class as private
and making all the functions of my code which will be allowed to throw
instances of this exception class, as 'friend's of the class.
A representative piece of code of this design is given here:
struct m
{
private:
m ( )
{ }
friend void myFunc ( ) throw ( m ) ;
Exception specifications are useless in c++ except to specify a
nothrow guarantee.
Agreed. (Although I'm willing to admit that there might be
exceptions, I've yet to see one.) Note that any time you'd use
an exception specification in Java (i.e. anytime it actually
means anything), you're better off using a return value in
C++ -- and usually in Java as well. (Sometimes, you'll use an
exception in Java because emulating out or inout parameters is
even more invasive. This isn't a problem in C++.)
} ;
void myFunc ( ) throw ( m )
{
}
int main ( )
{
return 0 ;
}
The problem is that the above code doesn't compile in g++ (
GNU version of c++ compiler ). It throws the following
errors:
structure.cpp:8: error: invalid use of undefined type =BFstruct m=BF
structure.cpp:3: error: forward declaration of =BFstruct m=BF
Even more surprising fact is that the above code won't compile even if
I change the line 'friend void myFunc ( ) throw ( m )' to :
friend void myFunc ( ) throw ( m * )
and also make the corresponding change in the function definition of
'myFunc' !
However, it does compile only when I change this line to :
friend void myFunc ( ) throw ( m * * )
Here's the complete code:
struct m
{
private:
m ( )
{ }
friend void myFunc ( ) throw ( m * * ) ;
} ;
void myFunc ( ) throw ( m * * )
{
}
int main ( )
{
return 0 ;
}
Why does g++ allow me throw a pointer to a pointer of type
'struct m' but not a pointer of type 'struct m' ?
Because the standard specifies it =A715.4/2:
"[...]A type denoted in an exception-specification shall not denote an
incomplete type. A type
denoted in an exception-specification shall not denote a pointer or
reference to an incomplete type, other than void*, const void*,
volatile void*, or const volatile void*.[...]"
One does sort of wonder why this restriction. It's important
that the type be complete when the function is either called or
defined (so that the compiler can set up the necessary code to
catch violations), but certainly not when the function is
declared.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34