www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - D 1.076 Alpha for Windows 64 bits, works with VS 2010

reply Walter Bright <newshound2 digitalmars.com> writes:
http://ftp.digitalmars.com/dmd1beta.zip

Mainly for those daring folks who want to help develop it further:

         $(LI 80 bit reals are truncated to 64 bits when formatting.)
         $(LI Many math functions are not implemented.)
         $(LI No symbolic debug info is generated.)
         $(LI Cannot catch Win64 structured exception handling exceptions.)
         $(LI VS debugger cannot look at call stack.)
         $(LI No DLL support.)
         $(LI Only tested with VS 2010.)
         $(LI No installer.)

My plan going forward is to now switch to bringing D2 up to this state.

Help, of course, is appreciated in addressing the shortcomings above. The math 
problems are due to reliance on the C standard library, and VC is both missing 
many C99 functions, and of course has no 80 bit support.

We'll have to roll our own.

The call stack problem is because the VC 64 bit ABI does not use a standard 
stack layout, so it cannot walk the stack. dmd uses the stack layout used on 
every other D port, which VC doesn't recognize. Eventually, this will have to 
get fixed. Frankly, not being able to look at the call stack in the debugger is 
quite a nuisance.

DLL support is probably straightforward.

I haven't looked at the symbolic debug info format.

I've been folding the changes into the D2 compiler as I've gone along, so that 
will hopefully mostly work out of the box. I have only done some of the library 
work for D2. Essentially I gotta go through the commit history on Phobos1 and 
fold it all into Druntime/Phobos2.

D will probably not bother with the 64 bit SEH.
Sep 27 2012
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Walter Bright:


 http://ftp.digitalmars.com/dmd1beta.zip


How do I switch from producing a 32 bit to 64 binary? I am 
looking for a -b64 or -b32 or similar switch...

Bye,
bearophile
Sep 27 2012
next sibling parent reply Mike Wey <mike-wey example.com> writes:
On 09/27/2012 01:56 PM, bearophile wrote:

 Walter Bright:


 http://ftp.digitalmars.com/dmd1beta.zip


 How do I switch from producing a 32 bit to 64 binary? I am looking for a
 -b64 or -b32 or similar switch...

 Bye,
 bearophile


-m32 and -m64 ? i'ts what dmd uses on linux.

-- 
Mike Wey
Sep 27 2012
parent "bearophile" <bearophileHUGS lycos.com> writes:
Mike Wey:


 -m32 and -m64 ? i'ts what dmd uses on linux.


Are those usable on DMD-Windows64 too?

Bye,
bearophile
Sep 27 2012
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/27/2012 4:56 AM, bearophile wrote:

 How do I switch from producing a 32 bit to 64 binary?


-m64
Sep 27 2012
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/27/12, Walter Bright <newshound2 digitalmars.com> wrote:

 D will probably not bother with the 64 bit SEH.


How come, and what will be the consequences of this?

Anyway great work so far!
Sep 27 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-09-27 15:42, Andrej Mitrovic wrote:

 On 9/27/12, Walter Bright <newshound2 digitalmars.com> wrote:

 D will probably not bother with the 64 bit SEH.


 How come, and what will be the consequences of this?

 Anyway great work so far!


What he said. What about this:

http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx

Not SEH?

-- 
/Jacob Carlborg
Sep 27 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 27 September 2012 at 15:00:23 UTC, Jacob Carlborg 
wrote:

 On 2012-09-27 15:42, Andrej Mitrovic wrote:

 On 9/27/12, Walter Bright <newshound2 digitalmars.com> wrote:

 D will probably not bother with the 64 bit SEH.


 How come, and what will be the consequences of this?

 Anyway great work so far!


 What he said. What about this:

 http://msdn.microsoft.com/en-us/library/1eyas8tf.aspx

 Not SEH?


This _is_ the 64 bit SEH implementation (although it is 
table-based instead of relying on setup in the function 
prologues, like on 32 bit Windows).

Walter seems to imply that he will roll/port his own EH mechanism?

David
Sep 27 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/27/2012 8:27 AM, David Nadlinger wrote:

 Walter seems to imply that he will roll/port his own EH mechanism?


Well, I did. The EH mechanism in dmd Win64 is the same as that used for dmd 
Linux, OSX and FreeBSD, 32 and 64.
Sep 27 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-09-27 21:51, Walter Bright wrote:


 Well, I did. The EH mechanism in dmd Win64 is the same as that used for
 dmd Linux, OSX and FreeBSD, 32 and 64.


What does that practically mean from the users point of view?

-- 
/Jacob Carlborg
Sep 27 2012
next sibling parent Brad Roberts <braddr puremagic.com> writes:
On 9/27/2012 11:01 PM, Jacob Carlborg wrote:

 On 2012-09-27 21:51, Walter Bright wrote:
 

 Well, I did. The EH mechanism in dmd Win64 is the same as that used for
 dmd Linux, OSX and FreeBSD, 32 and 64.


 
 What does that practically mean from the users point of view?


It's another interoperability problem.  It means that when mixing c++/d that
stackframe unwinding during exception
handling doesn't work as expected.  It'll be one more thing that eventually
needs to be fixed.
Sep 27 2012
prev sibling next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/28/12, Brad Roberts <braddr puremagic.com> wrote:

 It's another interoperability problem.  It means that when mixing c++/d that
 stackframe unwinding during exception
 handling doesn't work as expected.  It'll be one more thing that eventually
 needs to be fixed.


I thought the whole COFF work was entirely about interoperability
(well, that and 64bit). Oh well..
Sep 28 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2012 10:43 AM, Andrej Mitrovic wrote:

 I thought the whole COFF work was entirely about interoperability
 (well, that and 64bit). Oh well..



COFF is just a file format, nothing more. It is not an ABI specification.
Sep 28 2012
prev sibling next sibling parent Brad Roberts <braddr puremagic.com> writes:
On Fri, 28 Sep 2012, Andrej Mitrovic wrote:


 On 9/28/12, Brad Roberts <braddr puremagic.com> wrote:

 It's another interoperability problem.  It means that when mixing c++/d that
 stackframe unwinding during exception
 handling doesn't work as expected.  It'll be one more thing that eventually
 needs to be fixed.


 
 I thought the whole COFF work was entirely about interoperability
 (well, that and 64bit). Oh well..


Interoperability isn't a single attribute.  It's an accumulation of tons 
of attributes.  Much like .so/.dll support.  So, 2 steps forward, but 20 
left (obviously making up those numbers).
Sep 28 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/27/2012 11:01 PM, Jacob Carlborg wrote:

 On 2012-09-27 21:51, Walter Bright wrote:


 Well, I did. The EH mechanism in dmd Win64 is the same as that used for
 dmd Linux, OSX and FreeBSD, 32 and 64.


 What does that practically mean from the users point of view?


It means D cannot throw or catch VC exceptions, and VC code cannot throw or 
catch D exceptions.

Pretty much just like on Linux/OSX/FreeBSD, which doesn't seem to be a problem.
Sep 28 2012
parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Fri, 28 Sep 2012, Walter Bright wrote:


 On 9/27/2012 11:01 PM, Jacob Carlborg wrote:

 On 2012-09-27 21:51, Walter Bright wrote:
 

 Well, I did. The EH mechanism in dmd Win64 is the same as that used for
 dmd Linux, OSX and FreeBSD, 32 and 64.


 
 What does that practically mean from the users point of view?


 
 It means D cannot throw or catch VC exceptions, and VC code cannot throw or
 catch D exceptions.
 
 Pretty much just like on Linux/OSX/FreeBSD, which doesn't seem to be a
 problem.


It's more than just catching.  That's a relatively minor issue.  The 
bigger one is stack unwinding and related cleanups.  Consider: c++ 
function with local variables that have dtors that calls a D function that 
throws.  Those c++ locals will never have their dtors called.

It's not a huge problem, but the sum of the problems add up to pain and 
will need to be fixed at some point.  The lack of pain today is that it's 
barely feasible to mix languages where more than one has any exception 
handling right now.  Something of a catch-22 of issues, imho.
Sep 28 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/28/2012 12:39 PM, Brad Roberts wrote:

 It's more than just catching.  That's a relatively minor issue.  The
 bigger one is stack unwinding and related cleanups.  Consider: c++
 function with local variables that have dtors that calls a D function that
 throws.  Those c++ locals will never have their dtors called.

 It's not a huge problem, but the sum of the problems add up to pain and
 will need to be fixed at some point.  The lack of pain today is that it's
 barely feasible to mix languages where more than one has any exception
 handling right now.  Something of a catch-22 of issues, imho.



True, but I would never write code that tried to throw an exception across 
language boundaries, anyway. It's just asking for trouble.
Sep 28 2012
next sibling parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
On Fri, 28 Sep 2012, Walter Bright wrote:


 On 9/28/2012 12:39 PM, Brad Roberts wrote:

 It's more than just catching.  That's a relatively minor issue.  The
 bigger one is stack unwinding and related cleanups.  Consider: c++
 function with local variables that have dtors that calls a D function that
 throws.  Those c++ locals will never have their dtors called.
 
 It's not a huge problem, but the sum of the problems add up to pain and
 will need to be fixed at some point.  The lack of pain today is that it's
 barely feasible to mix languages where more than one has any exception
 handling right now.  Something of a catch-22 of issues, imho.


 
 
 True, but I would never write code that tried to throw an exception across
 language boundaries, anyway. It's just asking for trouble.


And that's fine for your code, but if you want D and DMD to be a system 
that people use for larger systems, then cutting down the sheer number of 
things that don't work when pushed is kinda important.
Sep 28 2012
next sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Fri, 28 Sep 2012 18:20:12 -0700
Brad Roberts <braddr slice-2.puremagic.com> wrote:


 On Fri, 28 Sep 2012, Walter Bright wrote:
 

 True, but I would never write code that tried to throw an exception
 across language boundaries, anyway. It's just asking for trouble.


 
 And that's fine for your code, but if you want D and DMD to be a
 system that people use for larger systems, then cutting down the
 sheer number of things that don't work when pushed is kinda important.



Especially since one of D's big selling points is linking with C/C++
code.

If such linking causes trouble with exceptions then people are
going to think twice about trying it (which reduces a major inroad for
D), or discover by surprise that it doesn't work and get
frustrated/annoyed.
Sep 29 2012
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, September 29, 2012 06:41:01 Nick Sabalausky wrote:

 On Fri, 28 Sep 2012 18:20:12 -0700
 
 Brad Roberts <braddr slice-2.puremagic.com> wrote:

 On Fri, 28 Sep 2012, Walter Bright wrote:

 True, but I would never write code that tried to throw an exception
 across language boundaries, anyway. It's just asking for trouble.


 
 And that's fine for your code, but if you want D and DMD to be a
 system that people use for larger systems, then cutting down the
 sheer number of things that don't work when pushed is kinda important.


 
 Especially since one of D's big selling points is linking with C/C++
 code.
 
 If such linking causes trouble with exceptions then people are
 going to think twice about trying it (which reduces a major inroad for
 D), or discover by surprise that it doesn't work and get
 frustrated/annoyed.



for one of our programs. A .NET bug with regards to C++ exceptions being 
thrown from C++ code resulted in destructors not being run when they were 

Mutexes weren't being unlocked as a result, and it wasn't pretty. Making sure 
that exceptions didn't escape the normal C++ code would have fixed it, but we 
shouldn't have had to do that. It may be a relatively rare issue, but it _is_ 
something that can cause bugs.

That being said, it probably _is_ better practice to make sure that you catch 
all exceptions at language barriers, even if they both use exceptions, but 
still, you know that some people are going to try and have exceptions cross 
those barriers, and if it doesn't work, they'll have bugs (and bugs which 
could be very hard to find depending). So, in the long run at least, it would 
be very desirable to have this compatability issue resolved.

- Jonathan M Davis
Sep 29 2012
prev sibling parent Rory McGuire <rjmcguire gmail.com> writes:
I think the original intent behind D's c++ support was just to make it
easier to work with c++. In other words your c++ come shouldn't throw
exceptions to D anyway.
So with golang you have to write a C wrapper. With D you can use c++.
Sep 29 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-09-29 03:20, Brad Roberts wrote:


 And that's fine for your code, but if you want D and DMD to be a system
 that people use for larger systems, then cutting down the sheer number of
 things that don't work when pushed is kinda important.


Exactly, I completely agree.

-- 
/Jacob Carlborg
Sep 29 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-09-29 03:01, Walter Bright wrote:


 True, but I would never write code that tried to throw an exception
 across language boundaries, anyway. It's just asking for trouble.


If everything is working correctly and is compatible it shouldn't be any 
problems.

-- 
/Jacob Carlborg
Sep 29 2012
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/29/12, Jacob Carlborg <doob me.com> wrote:

 On 2012-09-29 03:01, Walter Bright wrote:


 True, but I would never write code that tried to throw an exception
 across language boundaries, anyway. It's just asking for trouble.


 If everything is working correctly and is compatible it shouldn't be any
 problems.


Also how are we supposed to control when a C++ library throws? We
could wrap every single function wrapper with a try/catch, but won't
this create a massive slowdown?

What needs to be taken into account is that D will inevitably be able
to link with many C++ libraries, some of which will have exceptions
turned on. We now have SWIG with good but limited support of C++
wrapping, dstep will probably get C++ support, and my own (unreleased)
dgen is a C++ wrapper generator too (it's starting to show signs of
life, so far 2 C++ libraries were successfully automatically wrapped,
pugixml and taglib).
Sep 29 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-09-29 18:08, Andrej Mitrovic wrote:


 Also how are we supposed to control when a C++ library throws? We
 could wrap every single function wrapper with a try/catch, but won't
 this create a massive slowdown?


I'm not sure but I don't think so. As I understand it, DWARF on Posix 
and SEH on Windows are zero-cost exception handling systems. This means 
that there will be no performance loss at runtime as long as no 
exception is thrown. setjmp/longjmp on the other do have performance 
impacts at runtime.

-- 
/Jacob Carlborg
Sep 29 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 9/29/12, Jacob Carlborg <doob me.com> wrote:

 I'm not sure but I don't think so. As I understand it, DWARF on Posix
 and SEH on Windows are zero-cost exception handling systems. This means
 that there will be no performance loss at runtime as long as no
 exception is thrown. setjmp/longjmp on the other do have performance
 impacts at runtime.


I see. Ok it's prime time for me to finally read the SEH chapter in
Windows via C++. :)
Sep 29 2012
prev sibling parent reply "David Nadlinger" <see klickverbot.at> writes:
On Saturday, 29 September 2012 at 19:21:59 UTC, Jacob Carlborg 
wrote:

 I'm not sure but I don't think so. As I understand it, DWARF on 
 Posix and SEH on Windows are zero-cost exception handling 
 systems.


Only the x64 variant of SEH is "zero-cost". On x86, exception 
handlers must be installed into a linked list in the function 
prologue, which takes a few pushes/movs and popped off again in 
the epilogue.

David
Sep 29 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-09-29 23:26, David Nadlinger wrote:


 Only the x64 variant of SEH is "zero-cost". On x86, exception handlers
 must be installed into a linked list in the function prologue, which
 takes a few pushes/movs and popped off again in the epilogue.

 David


Ok, I see.

-- 
/Jacob Carlborg
Sep 30 2012
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
On 9/29/2012 9:08 AM, Andrej Mitrovic wrote:

 What needs to be taken into account is that D will inevitably be able
 to link with many C++ libraries, some of which will have exceptions
 turned on. We now have SWIG with good but limited support of C++
 wrapping, dstep will probably get C++ support, and my own (unreleased)
 dgen is a C++ wrapper generator too (it's starting to show signs of
 life, so far 2 C++ libraries were successfully automatically wrapped,
 pugixml and taglib).


Also, consider that in C++ you can throw any type, such as an int. There 
is no credible way to make this work reasonably in D, as exceptions are 
all derived from Exception.
Sep 30 2012
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 10/1/12, Walter Bright <newshound1 digitalmars.com> wrote:

 Also, consider that in C++ you can throw any type, such as an int. There
 is no credible way to make this work reasonably in D, as exceptions are
 all derived from Exception.


Is that a bug or a feature? :)
Sep 30 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-01 06:35, Andrej Mitrovic wrote:


 Is that a bug or a feature? :)


Actually you can do the same thin in Ruby, at least with strings. This 
is can be kind of nice, no need to create a new exception type. But in 
Ruby the string is wrapped in an instance of RuntimeError, so that might 
not be comparable.

raise "foo"

Is the same as:

raise RuntimeError.new("foo")

-- 
/Jacob Carlborg
Sep 30 2012
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 01 Oct 2012 08:16:13 +0200
Jacob Carlborg <doob me.com> wrote:


 On 2012-10-01 06:35, Andrej Mitrovic wrote:
 

 Is that a bug or a feature? :)


 
 Actually you can do the same thin in Ruby, at least with strings.
 This is can be kind of nice, no need to create a new exception type.
 But in Ruby the string is wrapped in an instance of RuntimeError, so
 that might not be comparable.
 
 raise "foo"
 
 Is the same as:
 
 raise RuntimeError.new("foo")
 


Haxe can throw anything, too. I've always found it borderline useless,
and frequently a pain.
Oct 01 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-01 14:30, Nick Sabalausky wrote:


 Haxe can throw anything, too. I've always found it borderline useless,
 and frequently a pain.


I find it quite annoying to have to create new classes for exceptions 
all the time. And since D constructors aren't inherited I need to also 
create a constructor that just forwards to the base class. Just useless 
boilerplate code.

-- 
/Jacob Carlborg
Oct 01 2012
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 19:14:45 Jacob Carlborg wrote:

 On 2012-10-01 14:30, Nick Sabalausky wrote:

 Haxe can throw anything, too. I've always found it borderline useless,
 and frequently a pain.


 
 I find it quite annoying to have to create new classes for exceptions
 all the time. And since D constructors aren't inherited I need to also
 create a constructor that just forwards to the base class. Just useless
 boilerplate code.


If you really need to declare new exception types all that often, I'd be 
inclined to think that you're creating a lot of needless exception types. But 
even if that's not the case and you really need many, new exception types with 
no extra member variables, it's trivial to create a mixin for doing that, 
though you don't get any ddoc if you do that.

- Jonathan M Davis
Oct 01 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-01 19:23, Jonathan M Davis wrote:


 If you really need to declare new exception types all that often, I'd be
 inclined to think that you're creating a lot of needless exception types. But
 even if that's not the case and you really need many, new exception types with
 no extra member variables, it's trivial to create a mixin for doing that,
 though you don't get any ddoc if you do that.


It's not that many in a single project but I have projects and I prefer 
to have at least one exception base class in each.

Yeah, mixins and ddoc does not go hand in hand.

-- 
/Jacob Carlborg
Oct 01 2012
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Mon, 01 Oct 2012 19:14:45 +0200
Jacob Carlborg <doob me.com> wrote:


 On 2012-10-01 14:30, Nick Sabalausky wrote:
 

 Haxe can throw anything, too. I've always found it borderline
 useless, and frequently a pain.


 
 I find it quite annoying to have to create new classes for exceptions 
 all the time. And since D constructors aren't inherited I need to
 also create a constructor that just forwards to the base class. Just
 useless boilerplate code.
 


If I'm being lazy, I'll just throw a normal Exception:
	throw new Exception("Whatever happened");

So it's almost as convenient as throwing a string (just a little more
typing), but unlike throwing strings or other non-Exceptions, you still
get the benefits of:

1. Always having the benefits of Exception, such as a stack trace.

2. Never having to deal with, or even consider the possibility of,
"What if some stupid lib or callback decides to throw something
nonsensical like an int or a Widget?" And a "catch(Exception e)" (or
rather "catch(Error e)") will always catch everything. Some languages
have a "catch all, from any unspecified type", but then you can't
have have any way to access whatever was thrown (unless it's a dynamic
language).

But, what you said about Ruby is an interesting idea. Ie, that throwing
a string is really just sugar for throwing a normal exception. I didn't
know that about Ruby. It would be kinda neat if we could do:

	throw "Shit happened";

And instead of actually throwing a string, it was just sugar for:

	throw new Exception("Shit happened");

That'd be pretty cool.

On a related, but goofier, note:
http://semitwist.com/articles/article/view/stupid-coder-tricks-debugging-exception-handlers
Oct 01 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-10-01 22:00, Nick Sabalausky wrote:


 But, what you said about Ruby is an interesting idea. Ie, that throwing
 a string is really just sugar for throwing a normal exception. I didn't
 know that about Ruby. It would be kinda neat if we could do:

 	throw "Shit happened";

 And instead of actually throwing a string, it was just sugar for:

 	throw new Exception("Shit happened");

 That'd be pretty cool.


Yeah, I wouldn't want this to become a regular String at the catch site, 
that would be pretty bad.


 On a related, but goofier, note:
 http://semitwist.com/articles/article/view/stupid-coder-tricks-debugging-exception-handlers


That's interesting. But that's also just like creating a function 
"error" which throws an exception. Which I end up doing sometimes.

-- 
/Jacob Carlborg
Oct 01 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/30/2012 9:35 PM, Andrej Mitrovic wrote:

 On 10/1/12, Walter Bright <newshound1 digitalmars.com> wrote:

 Also, consider that in C++ you can throw any type, such as an int. There
 is no credible way to make this work reasonably in D, as exceptions are
 all derived from Exception.


 Is that a bug or a feature? :)



It's a feature, and I'm not joking.

What is the compelling use case for throwing an int? How could that possibly
fit 
into some encapsulation model? What if library A throws an int, and library B 
does? Now you catch an int - which did it come from? You've got no clue. It's 
indistinguishable from garbage.
Oct 06 2012
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On Sat, 06 Oct 2012 11:38:43 -0700
Walter Bright <newshound2 digitalmars.com> wrote:


 On 9/30/2012 9:35 PM, Andrej Mitrovic wrote:

 On 10/1/12, Walter Bright <newshound1 digitalmars.com> wrote:

 Also, consider that in C++ you can throw any type, such as an int.
 There is no credible way to make this work reasonably in D, as
 exceptions are all derived from Exception.


 Is that a bug or a feature? :)


 
 
 It's a feature, and I'm not joking.
 
 What is the compelling use case for throwing an int? How could that
 possibly fit into some encapsulation model? What if library A throws
 an int, and library B does? Now you catch an int - which did it come
 from? You've got no clue. It's indistinguishable from garbage.
 


And it's not just int's either. Having to deal with code possibly, or
actually, throwing any type that isn't a proper Exception type is a
pain in the ass.
Oct 06 2012
prev sibling parent Don Clugston <dac nospam.com> writes:
On 06/10/12 20:38, Walter Bright wrote:

 On 9/30/2012 9:35 PM, Andrej Mitrovic wrote:

 On 10/1/12, Walter Bright <newshound1 digitalmars.com> wrote:

 Also, consider that in C++ you can throw any type, such as an int. There
 is no credible way to make this work reasonably in D, as exceptions are
 all derived from Exception.


 Is that a bug or a feature? :)



 It's a feature, and I'm not joking.

 What is the compelling use case for throwing an int? How could that
 possibly fit into some encapsulation model? What if library A throws an
 int, and library B does? Now you catch an int - which did it come from?
 You've got no clue. It's indistinguishable from garbage.


Just imagine how much fun could be had, if D let you throw sqrt(17.0) + 
37.919i.
Oct 09 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-10-01 06:19, Walter Bright wrote:


 Also, consider that in C++ you can throw any type, such as an int. There
 is no credible way to make this work reasonably in D, as exceptions are
 all derived from Exception.


Really, I had not idea that was possible. A workaround could be to 
convert to a string, wrap it in an exception class and pass to D.

-- 
/Jacob Carlborg
Sep 30 2012
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, October 01, 2012 08:14:03 Jacob Carlborg wrote:

 On 2012-10-01 06:19, Walter Bright wrote:

 Also, consider that in C++ you can throw any type, such as an int. There
 is no credible way to make this work reasonably in D, as exceptions are
 all derived from Exception.


 
 Really, I had not idea that was possible. A workaround could be to
 convert to a string, wrap it in an exception class and pass to D.


Which would make the exception handling that much mor expensive.

I would think that making it so that proper exception types are handled 
appropriately is plenty. There are limits to what can be reasonably done (just 
like at the limits that we have already when dealing with C++ from D). It's 
already arguably rather stupid to throw anything other than a proper exception 
type even if the language will let you. At some point, it _will_ be up to the 
programmer to do the right thing regardless of what level of compatibility we 
provide.

- Jonathan M Davis
Sep 30 2012
prev sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Monday, 1 October 2012 at 04:18:52 UTC, Walter Bright wrote:

 Also, consider that in C++ you can throw any type, such as an 
 int. There is no credible way to make this work reasonably in 
 D, as exceptions are all derived from Exception.


You could just detect C++ exceptions in the SEH handler and wrap 
them in a "ForeignLanguageException" or "CppException" class with 
a "Variant"-type member.

Not saying that this is necessarily an essential feature, though.

David
Oct 01 2012
prev sibling parent Don Clugston <dac nospam.com> writes:
On 27/09/12 15:42, Andrej Mitrovic wrote:

 On 9/27/12, Walter Bright <newshound2 digitalmars.com> wrote:

 D will probably not bother with the 64 bit SEH.


 How come, and what will be the consequences of this?


I don't see much of a reason for this. When I implemented exception 
chaining, I went to quite a bit of work to understand the 32bit SEH, 
mostly by reading the 64bit SEH which is a lot nicer and *far* better 
documented. In most respects it's the same as 32bit SEH but with a lot 
more restrictions on function calling conventions. The thing I don't 
know about is how nested functions mesh into the ABI requirements.

Also worth noting that the reason the ABI restrictions exist, is to 
allow exceptions to cross language barriers.

We should play nice.
Oct 01 2012