Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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 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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Sat, 06 Oct 2012 11:38:43 -0700 Walter Bright wrote: > On 9/30/2012 9:35 PM, Andrej Mitrovic wrote: > > On 10/1/12, 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. > > > > 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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 9/30/2012 9:35 PM, Andrej Mitrovic wrote: On 10/1/12, 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. 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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Mon, 01 Oct 2012 19:14:45 +0200
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 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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Mon, 01 Oct 2012 08:16:13 +0200
Jacob Carlborg 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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 27/09/12 15:42, Andrej Mitrovic wrote: On 9/27/12, Walter Bright 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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 10/1/12, 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. Is that a bug or a feature? :)
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 9/29/12, 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. 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++. :)
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 9/29/12, Jacob Carlborg 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).
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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++.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Saturday, September 29, 2012 06:41:01 Nick Sabalausky wrote: > On Fri, 28 Sep 2012 18:20:12 -0700 > > Brad Roberts 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. It's a problem that I've run into at work between C++ and the C# interop layer 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 caught in the managed C++ code (and that's the _managed C++_, not even C#). 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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Fri, 28 Sep 2012 18:20:12 -0700 Brad Roberts 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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On Fri, 28 Sep 2012, Andrej Mitrovic wrote: > On 9/28/12, Brad Roberts 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).
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 9/28/12, Brad Roberts 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..
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 9/27/2012 4:56 AM, bearophile wrote: How do I switch from producing a 32 bit to 64 binary? -m64
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
Mike Wey: -m32 and -m64 ? i'ts what dmd uses on linux. Are those usable on DMD-Windows64 too? Bye, bearophile
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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.
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
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 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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 2012-09-27 15:42, Andrej Mitrovic wrote: On 9/27/12, Walter Bright 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
Re: D 1.076 Alpha for Windows 64 bits, works with VS 2010
On 9/27/12, Walter Bright 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!
