Re: how to catch D Throwables (or exceptions) from C++?
On Friday, 2 December 2016 at 08:13:51 UTC, Jacob Carlborg wrote:
On 2016-12-01 02:58, Timothee Cour via Digitalmars-d-learn
wrote:
eg:
```
dlib.d:
extern(C) void dfun(){assert(0, "some_msg");}
clib.cpp:
extern "C" void dfun();
void fun(){
try{
dfun();
}
catch(...){
// works but how do i get "some_msg" thrown from D?
}
}
```
At least for a C++ exception it's possible to get the current
exception with __cxxabiv1::__cxa_current_primary_exception(). I
verified and it works for C++ exceptions. I would think that
the following works for D exceptions, but I cannot even catch
the D exception in C++. Maybe it's not working properly on
macOS.
// c++
void foo();
const char* getExceptionMessage(void*);
void bar()
{
try
{
foo();
}
catch(...)
{
void* e = __cxxabiv1::__cxa_current_primary_exception();
if (e)
{
const char* msg = getExceptionMessage(e);
if (msg)
printf("%s\n", msg);
else
printf("no message\n");
}
else
{
printf("no exception\n");
}
}
}
// d
extern(C++) void foo()
{
throw new Exception("foo");
}
extern(C++) immutable(char)* getExceptionMessage(void* e)
{
if (e)
{
auto t = cast(Throwable) e;
return t.msg.ptr;
}
return null;
}
I'm compiling the C++ code with clang++ and I need to link with
libc++abi.
Exceptions thrown from D set a different exception class in the
header, and the C++ personality routine (i.e the function that
gets called for each catch block) only handles exceptions which
displays the C++ exception class, so let D exceptions slip
through.
To catch exceptions thrown by D code in C++ I think this would
have to be done by throwing a C++ exception (eventually wrapping
a D class), but this is yet to be implemented.
Re: Operator overloading through UFCS doesn't work
On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote: The difference is that it's impossible to do 10.opBinary!"+"(15), so if you're forced to do foo.opBinary!"+"(bar) to get around a symbol conflict, it won't work with built-in types. Obviously operator overloading should be limited to class and struct types, so that's not really relevant. UFCS does not have that problem, because you're dealing with free functions and can choose to not use UFCS and provide the full import path or to alias the function, which you can't do with operators - particularly built-in operators. I still don't understand what you're getting at, unfortunately. D was designed to be much cleaner with operator overloading than C++ is. It restricts what the definitions of the operators are so that you don't have to define as many of them to get the basic operations (e.g. opCmp for most of the comparison operators or op!"++" for both pre-increment and post-increment) and so that they aren't easily overloaded to do stuff that does not correspond to what that operator does for built-in types. D doesn't even use + for string concatenation, because Walter thought that that was operator abuse. Allowing arbitrary code to add overloaded operators to an existing type is not at all in line with that philosophy. Regardless, there really isn't much point in arguing this. If you want things to change, you're going to need to convince Walter, which I very much doubt is going to happen. - Jonathan M Davis Thanks for taking the time to explain, although I still fail to see a good justification for disabling UFCS for operators. I will look for more discussions on the topic and if still no opposing argument seems valid I might push the issue forward.
Re: Operator overloading through UFCS doesn't work
On Wednesday, 25 May 2016 at 21:50:06 UTC, Jonathan M Davis wrote:
It's not an overloaded operator anymore at that point, and that
definitely fails to work for generic code, since not all
operators are overloaded operators. Free functions don't have
that problem.
Sorry to reiterate the previous post but is that really the case?
void FuncTemplate(...)(...) {
X.FreeFunc(Y);
}
import ModuleA; // contains FreeFunc
import ModuleB; // contains a conflicting FreeFunc overload
FuncTemplate!()(); // fails
Where is the difference with writing generic code with operators
(overloaded or not)?
Re: Operator overloading through UFCS doesn't work
On Tuesday, 24 May 2016 at 23:43:46 UTC, Jonathan M Davis wrote: On Tuesday, May 24, 2016 23:19:32 Elie Morisse via Digitalmars-d-learn wrote: On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote: > Afaik free-function operator overloads (but not in the > context of UFCS) were considered and turned down because D > did not want to get amidst discussions about adding Koenig > lookup. UFCS does not do Koenig lookup. I don't get it, aren't the current symbol lookup rules enough to make free function operator overloads useful? To me it looks like they are. Sorry for digging up this thread, just getting irritated by a restriction that seems pointless and arbitrary. Overloaded operators would suffer from the same potential abuses other methods are subjected to if UFCS was enabled, nothing more as far as I can see. If UFCS doesn't work, because there are two free functions with the same name which take the same arguments, then you can differentiate between them by not using UFCS and using their full import paths, or you can alias them so that they don't have the same name. Neither of those would be possible with operator overloading. If overloaded operators were allowed as free functions, then if there were ever a symbol conflict, you'd be screwed. - Jonathan M Davis X.FreeFunc(Y); // multiple matches error ModuleA.FreeFunc(X, Y); // ok X * Y; // multiple matches error ModuleA.opBinary!'*'(X, Y); // ok Is there much of a difference between the two?
Re: Operator overloading through UFCS doesn't work
On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote: Afaik free-function operator overloads (but not in the context of UFCS) were considered and turned down because D did not want to get amidst discussions about adding Koenig lookup. UFCS does not do Koenig lookup. I don't get it, aren't the current symbol lookup rules enough to make free function operator overloads useful? To me it looks like they are. Sorry for digging up this thread, just getting irritated by a restriction that seems pointless and arbitrary. Overloaded operators would suffer from the same potential abuses other methods are subjected to if UFCS was enabled, nothing more as far as I can see.
