[xsd-users] Re: argument mismatch in the generated code

[Wahid]

Hi Boris,
Very True,
when I got your answer to my question, I had already felt sorry for asking it. I should have paid more attention.
It doesn't make sense to supply a return type for post_* method and expect to receive nothing(void) when catching it as an argument.

Thank you
vahid

--- On Tue, 3/20/12, Boris Kolpackov <boris at codesynthesis.com> wrote:

From: Boris Kolpackov <boris at codesynthesis.com>
Subject: Re: argument mismatch in the generated code
To: "Wahid" <hamishagi at yahoo.com>
Cc: xsd-users at codesynthesis.com, boris at codesynthesis.com
Date: Tuesday, March 20, 2012, 6:05 PM

Hi Wahid,

Wahid <hamishagi at yahoo.com> writes:

> I define a type map file as :
> 
> Link void sim_mob::Link*;
> 
> 
> this means that the ONLY desirable modification in the generated code 
> is RoadNetwork_t::Links() to get One argument: 
> RoadNetwork_t::Links(sim_mob::Link*)
> before i continue, is this a valid expectation at all? or I have a wrong
> assumption!?)

The above map file fragment doesn't make much sense. The two C++ types
that you specify are the return type from the *_post() callback and the 
argument type to the element/attribute callback. XSD/e "connects" the
two by first calling the *_post() callback and then passing the returned
value to the element/attribute callback. In your case it will be something
along these lines:

ret_type r = Links_parser_->Links_post ();
RoadNetwork_t_parser_->Links (r);

I think from this it should be clear that you cannot have the return type
void while the argument type void. They either both have to be void or both
non-void. If they are both void, then XSD/e generated the following calls
instead:

Links_parser_->Links_post ();
RoadNetwork_t_parser_->Links ();

Boris