Re: [gobo-eiffel-develop] YY_SCANNER_SKELETON.yy_content_area could be ABSTRACT_SPECIAL ?

[Eric B. <er...@go...>]

Berend de Boer wrote:
>>>>>> "Emmanuel" == Emmanuel Stapf [ES] <ma...@ei...> writes:
> 
>     >> So the goal is to run the scanner/parser straight from a malloc
>     >> buffer, which used to work.
> 
>     Emmanuel> Having done many C/Eiffel interfaces I consider this as
>     Emmanuel> being dangerous to do. And why when using SPECIAL do you
>     Emmanuel> want to pass this to the C side? Is the C code doing to
>     Emmanuel> do some processing over the data?
> 
> Nah, it's just the other way around. The data is in a malloc buffer,
> and needs to be parsed by YY_PARSER. Previously one could write a
> wrapper where data was picked up from such buffer. Now Gobo requires
> that it is in a SPECIAL or descendant.

In my mind, it has always been clear that we should use SPECIAL
for efficency reason. The reason why this could be bypassed is
that at the time of writing some of the supported Eiffel compilers
did not support SPECIAL. Using ABSTRACT_SPECIAL is not really
a solution because it introduces polymorphism, hence reducing
the performance that we want to gain by using SPECIAL directly.

YY_SCANNER_SKELETON has been changed in such as way because during
the current migration to void-safety KI_CHARACTER_BUFFER.as_special
has been turned to return a non-void SPECIAL. I think that the problem
comes from here. Your version of class buffer is now likely to
violate this new postcondition in `as_special'.

I'll see what I can do to revert this change. I must say that I'm
not a fan of all this void-safety thing. For code that was well
equipped with assertions like the Gobo libraries, converting to
void-safety makes the code more convoluted, hence harder to read
and maintain.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com