«

jacob navia wrote:
> Ian Collins wrote:
>> jacob navia wrote:
> [snip]
>>> This is not true. Most C++ compilers support C and will allow C and
>>> C++ to coexist peacefully.
>>
>> They do, provided you use C linkage functions (extern "C" in the C++
>> world). Exceptions are alien to C, so you simply can't propagate
>> exceptions through a C function.
>>
>
> Yes you can. I have done this under gcc and msvc, and I think
> all C++ compilers will generate compatible code.
>
More by luck than anything else. The mechanics may work, but it's a
very dangerous thing to do because the C code will not be exception
aware, let alone safe.

Like all things undefined, the next compiler release could break your code.

>>> Problems arise when you mix different
>>> compilers and versions or you want to generate code dynamically.
>>>
>> A problem in C++, but in C? The C ABI is determined by the platform,
>> not the compiler (at least in the Linux/Unix world). If a compiler used
>> a different ABI, how could it link to system libraries?
>>
>
> If you use different compilers, the throw machinery ill be different
> and passing throws will just not work.
>
Double check my post, I said "The C ABI is determined by the platform".
C doesn't have throw machinery.

--
Ian Collins.

Ian Collins wrote:
> jacob navia wrote:
>> Ian Collins wrote:
>>> jacob navia wrote:
>> [snip]
>>>> This is not true. Most C++ compilers support C and will allow C and
>>>> C++ to coexist peacefully.
>>> They do, provided you use C linkage functions (extern "C" in the C++
>>> world). Exceptions are alien to C, so you simply can't propagate
>>> exceptions through a C function.
>>>
>> Yes you can. I have done this under gcc and msvc, and I think
>> all C++ compilers will generate compatible code.
>>
> More by luck than anything else. The mechanics may work, but it's a
> very dangerous thing to do because the C code will not be exception
> aware, let alone safe.
>


Who cares?

C doesn't have to know any exceptions!

The throw will pass through the C stack part until it finds a catch.
Most compilers generate a set of tables describing the stack layout
of each function so that the throw mechanism can walk the stack.

If you compile with the same compiler, those tables get generated for
the C code and you are in business.

> Like all things undefined, the next compiler release could break your code.
>

I said that explicitely in my FIRST message. You need to keep
compatible versions of everything:

o The tables generated by the compiler
o The throw run time mechanism


>>>> Problems arise when you mix different
>>>> compilers and versions or you want to generate code dynamically.
>>>>
>>> A problem in C++, but in C? The C ABI is determined by the platform,
>>> not the compiler (at least in the Linux/Unix world). If a compiler used
>>> a different ABI, how could it link to system libraries?
>>>
>> If you use different compilers, the throw machinery ill be different
>> and passing throws will just not work.
>>
> Double check my post, I said "The C ABI is determined by the platform".
> C doesn't have throw machinery.
>

You just do not know what the issue here is. Reread the OP
message, and my answers. Obviously C doesn't have and doesn't
need any throw machinery. That is not the issue here.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> Ian Collins wrote:
>> jacob navia wrote:
>>> Ian Collins wrote:
>>>> jacob navia wrote:
>>> [snip]
>>>>> This is not true. Most C++ compilers support C and will allow C and
>>>>> C++ to coexist peacefully.
>>>> They do, provided you use C linkage functions (extern "C" in the C++
>>>> world). Exceptions are alien to C, so you simply can't propagate
>>>> exceptions through a C function.
>>>>
>>> Yes you can. I have done this under gcc and msvc, and I think
>>> all C++ compilers will generate compatible code.
>>>
>> More by luck than anything else. The mechanics may work, but it's a
>> very dangerous thing to do because the C code will not be exception
>> aware, let alone safe.
>>
> Who cares?
>
Anyone who wants to write reliable, portable code.

> C doesn't have to know any exceptions!
>
Isn't that what I said?

> The throw will pass through the C stack part until it finds a catch.
> Most compilers generate a set of tables describing the stack layout
> of each function so that the throw mechanism can walk the stack.
>
Yes, so a C function calling a C++ function that throws will return at
the point of the call, bypassing any clean up and possibly leaving the
applications state in an undefined state. For example:

void f()
{
allocateSomething(); /* 1 */

callFunctionThatThrows(); /* 2 */

deallocateSomthing(); /* 3 */
}

The function will "return" at line 2, line 3 will never be called.

> If you compile with the same compiler, those tables get generated for
> the C code and you are in business.
>
That forces you to compile C as C++. C isn't C++.

>> Like all things undefined, the next compiler release could break your
>> code.
>>
>
> I said that explicitely in my FIRST message. You need to keep
> compatible versions of everything:
>
> o The tables generated by the compiler
> o The throw run time mechanism
>
You also appear to be implying that the C code be compiled as C++.
>
>>>>> Problems arise when you mix different
>>>>> compilers and versions or you want to generate code dynamically.
>>>>>
>>>> A problem in C++, but in C? The C ABI is determined by the platform,
>>>> not the compiler (at least in the Linux/Unix world). If a compiler
>>>> used
>>>> a different ABI, how could it link to system libraries?
>>>>
>>> If you use different compilers, the throw machinery ill be different
>>> and passing throws will just not work.
>>>
>> Double check my post, I said "The C ABI is determined by the platform".
>> C doesn't have throw machinery.
>>
> You just do not know what the issue here is. Reread the OP
> message, and my answers.
>
To quote from the OP:

framework::main() (C++)
--> plugin::Event() (C)
--> api::Sum() (C++)
throw X;

Which is exactly what the issue we should be discussing.

> Obviously C doesn't have and doesn't
> need any throw machinery. That is not the issue here.
>
Then why did you say mention throw machinery in response to a question
about the C ABI?

--
Ian Collins.

It seems to me a fair summary, then, to say it's unwise for us to go
this way. It might work under some conditions, but with no restrictions
on compiler or even language..., and especially given my inexperience in
this area. I guess we'll elect to use error codes instead, I can come to
terms with that.

Thanks, all, for your time and your helpful comments.

Ian Collins wrote:
[snip]

Mr Collins

1) The question here is if C and sit in the middle between a catch in
C++ and a throw in C++. My answer is YES.

2) If you leave objects without proper cleanup in your C code is
another problem. HINT: Do not do that in your C code. Just never
call a C++ function that can throw if you need to cleanup.

3) In the case of the original poster of this thread everything is
done at compile time. I have solved a more difficult case when
in the framework of a JIT (Just in time compiler) you generate
code dynamically. In the OP case there is no need to modify
the C code. Obviously if any throw happens, cleanup may never
happen. That is another problem. The question was if this is
at all possible.

I think your opinion and mine are well known. I stop this thread
then.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

jacob navia wrote:
> Ian Collins wrote:
> [snip]
>
> Mr Collins
>
> 1) The question here is if C and sit in the middle between a catch in
> C++ and a throw in C++. My answer is YES.
>
And mine is NO. The result is undefined.

My apologies to the c.l.c readers, but here's an example that
illustrates this:

x.cc:

extern "C" void f();
extern "C" void functionThatThrows() { throw 42; }

int main ()
{
try { f(); }
catch(...) {}

return 0;
}

x.c:

#include <stdio.h>

void functionThatThrows();

void f()
{
puts("allocateSomething");
functionThatThrows();
puts("deallocateSomthing");
}

With compiler A:

c99 -c -o xc.o /tmp/x.c
CC /tmp/x.cc xc.o

../a.out
allocateSomething

With compiler B:

gcc -c -o xc.o /tmp/x.c
g++ /tmp/x.cc xc.o

../a.out
allocateSomething
terminate called after throwing an instance of 'int'
Abort (core dumped)

> 2) If you leave objects without proper cleanup in your C code is
> another problem. HINT: Do not do that in your C code. Just never
> call a C++ function that can throw if you need to cleanup.
>
That assumes you know you are calling a C++ function.

>
> I think your opinion and mine are well known. I stop this thread
> then.
>
Indeed. One of us understands the meaning of undefined behaviour and
how to write portable code.

--
Ian Collins.

On Jun 14, 1:57 am, Ian Collins <ian-n...@hotmail.com> wrote:
> jacob navia wrote:
> > Ian Collins wrote:
> > [snip]

> > Mr Collins

> > 1) The question here is if C and sit in the middle between a
> > catch in C++ and a throw in C++. My answer is YES.

> And mine is NO. The result is undefined.

According to the standard. One thing an implementation can do
with undefined behavior is define it; all of the C++ compilers I
know do define it.

Not that it's much use, of course. As you correctly pointed
out, code written in C will not be exception safe; it counts on
the guarantee (valid in C) that if you call a function, it
either returns, or the process is aborted in some way.

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

In comp.lang.c, James Kanze wrote:
[snip]
> Not that it's much use, of course. As you correctly pointed
> out, code written in C will not be exception safe; it counts on
> the guarantee (valid in C) that if you call a function, it
> either returns, or the process is aborted in some way.

Hmmm....... So, what does longjmp() do? If you call a function that calls
longjmp(), does the called function return? Or does longjmp() abort the
process? (assuming that setjmp() was properly invoked prior to the call to
the function)

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

James Kanze wrote:
> On Jun 14, 1:57 am, Ian Collins <ian-n...@hotmail.com> wrote:
>> jacob navia wrote:
>>> Ian Collins wrote:
>>> [snip]
>
>>> Mr Collins
>
>>> 1) The question here is if C and sit in the middle between a
>>> catch in C++ and a throw in C++. My answer is YES.
>
>> And mine is NO. The result is undefined.
>
> According to the standard. One thing an implementation can do
> with undefined behavior is define it; all of the C++ compilers I
> know do define it.
>
True, but we were talking portable solutions here, so no is the only
safe answer.

Every compiler I use has its own exception propagation mechanism,
ranging from the elegant to the gross. As an internal implementation
detail, this is likely to change between releases. Thus even code built
and "working" with the same tool chain is likely to break if the tools
are upgraded.

--
Ian Collins.

On Jun 15, 1:16 am, Ian Collins <ian-n...@hotmail.com> wrote:
> James Kanze wrote:
> > On Jun 14, 1:57 am, Ian Collins <ian-n...@hotmail.com> wrote:
> >> jacob navia wrote:
> >>> Ian Collins wrote:
> >>> [snip]

> >>> Mr Collins

> >>> 1) The question here is if C and sit in the middle between a
> >>> catch in C++ and a throw in C++. My answer is YES.

> >> And mine is NO. The result is undefined.

> > According to the standard. One thing an implementation can do
> > with undefined behavior is define it; all of the C++ compilers I
> > know do define it.

> True, but we were talking portable solutions here, so no is the only
> safe answer.

> Every compiler I use has its own exception propagation
> mechanism, ranging from the elegant to the gross. As an
> internal implementation detail, this is likely to change
> between releases. Thus even code built and "working" with the
> same tool chain is likely to break if the tools are upgraded.

Yes. It's clear that all of the code must have been compiled
with the same compiler (same version, and possibly even with the
same options).

If all the code is your application, you should have no trouble
mastering this, and I wouldn't worry too much about portability.
For things like plugins, of course, it's totally a different
matter, and if your plugin uses a C ABI, you certainly cannot
count on exceptions propagating through it (and if it uses a C++
ABI, of course, the suppliers of the plugin will have to compile
with the same compiler---including version and options enought
to ensure binary compatibility---or the plugin won't work).

--
James Kanze (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34