Re: C++ / multiple instances / iostreams

[Hans Aberg]

At 11:51 +0200 2004/07/23, Detlef Vollmann wrote:
>> I sense though we are getting a little off topic here;
>Ok, I'll stop as soon as anyone complains.

It could be that some C++ questions are appropriate here, if we don't stray
too far, as a C++ parser is certainly on the Bison todo list.

>> But
>> all exception implementations, I am told, induce some overhead; also the so
>> called no-overhead exception handling.
>Exceptions are a bit problematic as examples: it is not clear
>to what you should compare the "overhead".
>If you don't care about errors, yes, then exceptions have an
>overhead.
>But if you compare the C-style return value checking to C++ exceptions,
>it turns out that the C-style has higher "overhead" than
>C++ exceptions on some implementations.

OK. I was under the impression that this C error return style would always
be faster. So it is probably that compiler writers have to learn these new
techniques. Exceptions are very important from the semantic point of view,
as they ensure that the code cannot be broken. Therefore this style will be
very important in the future from the point of view of code safety.

>For other alternatives to C++ exceptions see e.g.
>  http://www.vollmann.ch/de/pubs/cpp-excpt-alt.html
>
>I don't really know to what you refer with "no-overhead exception
>handling".

It was a term on the C++ ball a few years ago. I do not know what it means,
either. :-)

>  The table approach has no overhead in term of run-time
>(as long as no exception is thrown), but in program text size
>(they use a table that is typically left on disk as long as it
>is not used).

But I have a memory of that some experts said that also such approaches
actually had an time overhead.

>So, any approach to handle exceptional cases has its "overhead",
>be it C-style return value checking, C++ exceptions or something
>else.  And each of them has advantages and disadvantages.

Right. But the point is that the new C++ high level approaches (like
exceptions) are not required to be as efficient as the corresponding C low
level features (such as error returns).

If I should take an example which is directly to the implementation of the
Bison C and C++ parsers, a question that pops up in this list from time to
time, then it the question of a dynamic parser stack:

Under C, all struct data is POD, so it needs not to invoke any copy
constructors, so the whole stack can be re-copied in one go. If the code is
C++, then there is in general no way to know whether the semantic values is
POD or not, so one is forced to use a proper C++ stack which does invoke
the copy-constructors. This then creates an overhead, which can only be
removed if one somehow knows that the data is POD (which happens, for
example, when one is using the Bison %union feature) and then uses the
C-stack recopying method.

  Hans Aberg