Re: warnings when using directors with multiple throw specifiers

Doesn't SWIG emit a warning about not having a throws typemap? This problem 
doesn't seem to be director specific. You can either define a throws typemap for 
each of the different types in your exception specification or define a generic 
SWIGTYPE& typemap for all of them. You could base it off the SWIGTYPE throws 
typemap in python.swg (SWIG-1.3.21).

William

Oren Miller wrote:
> I have some virtual classes with throw specifiers that indicate multiple 
> possible exceptions, such as this one:
>
> virtual void fromAdmin( const Message&, const SessionID& )
>   throw( FieldNotFound&, IncorrectDataFormat&, IncorrectTagValue&, 
> RejectLogon& ) = 0;
>
> The code that is generated looks like this (for python):
>
>             try {
>                 (arg1)->fromAdmin((FIX::Message const 
> &)*arg2,(FIX::SessionID const &)*arg3);
>             }
>             catch(...) {
>                 throw;
>             }
>             catch(...) {
>                 throw;
>             }
>             catch(...) {
>                 throw;
>             }
>             catch(...) {
>                 throw;
>             }
>
> Now this does not cause any errors (at least not in gcc 3.2, I can't 
> speak for other compilers), but it does cause several warnings (since 
> ... should be the last thing to be caught, and three of them are not 
> last).  With multiple directors which can have several methods like 
> this, the warnings can add up.  Of course this can make errors more 
> difficult to spot.  I would suggest that the generated code either look 
> like so:
>
>             try {
>                 (arg1)->fromAdmin((FIX::Message const 
> &)*arg2,(FIX::SessionID const &)*arg3);
>             }
>             catch(FieldNotFound&) {
>                 throw;
>             }
>             catch(IncorrectDataFormat&) {
>                 throw;
>             }
>             catch(IncorrectTagValue&) {
>                 throw;
>             }
>             catch(RejectLogon&) {
>                 throw;
>             }
>
> or just simply consolidated into:
>
>             try {
>                 (arg1)->fromAdmin((FIX::Message const 
> &)*arg2,(FIX::SessionID const &)*arg3);
>             }
>             catch(...) {
>                 throw;
>             }
>
> On May 28, 2004, at 12:21 PM, David Beazley wrote:
>
> > Marcelo Matus writes:
> >
> > > Ok, the thing is that "C arrays mapping" is a strange case.
> > >
> > > The problem with C arrays is that the have a known size, and
> > > the '\0' ending char is just a coincidence, ie you can define
> > >
> > >   char hi_a [] = {'h','e','l','l','o'};
> > >   char hi_b [] = "hello";
> > >
> > > and both will be different
> > >
> > >   sizeof(hi_a) -> 5
> > >   sizeof(hi_b) -> 6
> > >   strlen(hi_a) -> undefined
> > >   strlen(hi_b) -> 5
> > >
> > > and in the python side you will get
> > >
> > >   hi_a -> 'hello'
> > >   hi_b -> 'hello\0'
> > >
> > > note that you can also put '0' char in between
> > >
> > >   char hi_a [] = {'h','e',0,'l','o'};
> > >
> > >   sizeof(hi_a) -> 5
> > >   strlen(hi_a) -> 2
> > >
> > > So, in your case, maybe is better to use
> > >
> > >   const char* const BeginString_FIX44 = "FIX.4.4";
> > >
> > > since that will be properly understood in C,C++ and in the python side
> > > (and you don't need the std::string). In that case the use of 'strlen'
> > > is explicit, and in the python side you will not see the '\0' ending
> > > character.
> >
> > Any definitions of the form
> >
> >    char foo[N] = "whatever";
> >    char bar[] = "whatever";
> >
> > should *always* be treated as NULL-terminated strings by default in
> > SWIG.    If someone wants different behavior than that, they should
> > write their own typemap to do it.
> >
> > Why is this suddenly broken?  I thought issues concerning C character
> > arrays were resolved long ago.
> >
> > -- Dave
>
> _______________________________________________
> Swig maillist  -  Swig@xxxxxxxxxxxxxxx
> http://mailman.cs.uchicago.edu/mailman/listinfo/swig


_______________________________________________
Swig maillist  -  Swig@xxxxxxxxxxxxxxx
http://mailman.cs.uchicago.edu/mailman/listinfo/swig