Re: Using delegate for WindowProc - possible ?
On Thursday, 29 December 2011 at 20:08:45 UTC, bls wrote:
import std.stdio;
import std.functional;
int main(string[] argv)
{
extern(Windows) int delegate( int i) dg;
alias dg callback;
callback = toDelegate(&test);
writeln( callback( 1 ) );
readln();
return 0;
}
extern(Windows) int test(int i) { return 41 +i;}
hth, bjoern
Wow! This is actually pretty cool! I needed something similar,
but it was to call a member function from the Windows procedure,
and I had to use some thunking though assembly.
Maybe I can adapt my code to use a delegate like this instead.
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thu, Dec 29, 2011 at 7:16 PM, Jonathan M Davis wrote:
>
> A D exit function would have to do essentially the same thing as throw an
> exception and catch it in main anyway. The only way that the stack is going to
> be unwound properly is if you actually unwind it. The only way in the language
> to do that without actually returning from each and every function on the
> stack is to throw an exception.
>
> How many modern languages do you know of with an exit function that cleans
> everything up properly? C++ won't for the same reasons that D won't. Java gets
> away with it because it doesn't have destructors or scope statements or
> anything else that would actually require unwinding the stack.
>
> All a D exit function _could_ do would be to throw an exception and then have
> the runtime catch it - which still wouldn't work if the programmer was foolish
> enough to do something like
>
> catch(Exception) {}
>
> in their code. So, throwing an exception and catching it _is_ the way to do
> it, and it really makes more sense if you're doing it yourself, since then
> you're less likely to make that mistake and catch all Exceptions somewhere in
> your code and eat the one which is supposed to exit the program.
>
> - Jonathan M Davis
Hm...embarassingly, it didn't occur to me that C++ didn't clean up
either; but sure enough, the following code shows that exit() breaks
C++ RAII.
#include
#include
struct SafeExit {
~SafeExit() {
std::cout << "Safely exit with destructor." << std::endl;
}
};
int main(int argc, char** argv)
{
SafeExit safeExit;
std::cout << "Test if std.c.stdlib.exit() breaks RAII." << std::endl;
std::cout << "Pre-exit!" << std::endl;
exit(0);
std::cout << "Post-exit! Should not get here!" << std::endl;
return 0;
}
On the other hand, ruby happily *does* unwind the stack properly on exit().
def safe_exit
begin
yield
ensure
puts "Safely exit with ensure."
end
end
safe_exit do
puts "Test if std.c.stdlib.exit() breaks RAII."
puts "Pre-exit!"
exit(0);
puts "Post-exit! Should not get here!"
end
Honestly, I would rather have the latter robustness. While I have
always thought of abort() as being a dirty exit, I had, until now,
always thought of exit() as being very safe. Violating RAII on a
safely-intended exit() is a really Bad Thing, I would think. Since D
could conceivably implement a very safe exit() without an explicit use
of Exceptions to get around the "catch Exception() {}" problem you
mentioned above, does it make sense to request a safer exit() feature
for D?
Ashish
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thursday, December 29, 2011 13:43:36 Ashish Myles wrote:
> On Thu, Dec 29, 2011 at 1:26 PM, Andrej Mitrovic
>
> wrote:
> > Probably the easiest thing to do is to throw a custom exception and
> > catch it somewhere in main() to return your status code. Unlike
> > exit(), throwing will take care of RAII stuff.
>
> Thanks, Andrej. That option had occurred to me, but I figured that
> shouldn't be the way to do things given that most other languages have
> a native exit function. Given that this code transformation isn't
> particularly difficult (put main in a try/catch, have a custom
> exception storing exit code, return the exit code in the catch block),
> would it be reasonable to do a feature request for a
> D-language-supported exit()?
A D exit function would have to do essentially the same thing as throw an
exception and catch it in main anyway. The only way that the stack is going to
be unwound properly is if you actually unwind it. The only way in the language
to do that without actually returning from each and every function on the
stack is to throw an exception.
How many modern languages do you know of with an exit function that cleans
everything up properly? C++ won't for the same reasons that D won't. Java gets
away with it because it doesn't have destructors or scope statements or
anything else that would actually require unwinding the stack.
All a D exit function _could_ do would be to throw an exception and then have
the runtime catch it - which still wouldn't work if the programmer was foolish
enough to do something like
catch(Exception) {}
in their code. So, throwing an exception and catching it _is_ the way to do
it, and it really makes more sense if you're doing it yourself, since then
you're less likely to make that mistake and catch all Exceptions somewhere in
your code and eat the one which is supposed to exit the program.
- Jonathan M Davis
Re: Using delegate for WindowProc - Is possible and fun!
On 12/28/2011 03:45 PM, Tal wrote:
Can I do something like this :
__
extern (Windows) LRESULT delegate (HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam) MyWinProcDelegate;
this() {
MyWinProcDelegate =&Events;
}
extern (Windows) LRESULT Events (HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam) {
MessageBoxA(null , "Success!!!" , null ,0);
return DefWindowProcA(hWnd, message, wParam, lParam);
}
__
The Events() doesn't seem to fire... am I missing something ?
Hi Tal.
I have added an other example using array of delegates. I guess I know
what you want to do... so do not miss the end of the document. Enjoy.
import std.stdio;
import std.functional;
int main(string[] argv)
{
// array of delegates
extern(Windows) int delegate( int i)[] dg;
alias dg callback;
// function to delegate
callback ~= toDelegate( &test ); // std.functional
writeln( callback[0]( 1 ) );
callback ~= toDelegate( &inc );
writeln( callback[1] (0) );
writeln (callback[0]( 1 ) );
readln();
return 0;
}
extern(Windows) int test(int i) { return 41 +i;}
extern(Windows) int inc(int i) { return ++i;}
// Now an associative array of delegates indexed by (of course) HWND ;)
extern (Windows)
LRESULT delegate (HWND hWnd, UINT message, WPARAM wParam,LPARAM
lParam)[HWND] dg;
alias dg MyWinProcDelegate;
bjoern
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On 12/29/2011 12:43 PM, Ashish Myles wrote: On Thu, Dec 29, 2011 at 1:26 PM, Andrej Mitrovic wrote: Probably the easiest thing to do is to throw a custom exception and catch it somewhere in main() to return your status code. Unlike exit(), throwing will take care of RAII stuff. Thanks, Andrej. That option had occurred to me, but I figured that shouldn't be the way to do things given that most other languages have a native exit function. Given that this code transformation isn't particularly difficult (put main in a try/catch, have a custom exception storing exit code, return the exit code in the catch block), would it be reasonable to do a feature request for a D-language-supported exit()? Yeah, really. I'd been using the C exit() as well. Seems like a pretty fundamental feature. :O
Re: Are D classes always garbage collected?
On 12/21/2011 10:20 PM, Froglegs wrote:
>
>>> Which returned me a nice fat null pointer.. wth? Perhaps that should
>>> be a compile time error if you aren't supposed to use classes..
>>
>> Strange... I'm not sure what the deal is with that overload. I meant
>> the last one on the page (that takes a void[]).
>
>
> Hum I've tried the array version but I believe it contains a rather
> serious bug...
>
> T emplace(T, Args...)(void[] chunk, Args args) if (is(T == class))
> {
> enforce(chunk.length >= __traits(classInstanceSize, T),
> new ConvException("emplace: chunk size too small"));
> ...
>
> This fails whenever the size is greater or equal to the amount of memory
> required :(
That bug has recently been fixed:
http://d.puremagic.com/issues/show_bug.cgi?id=6204
> Anyway I need the pointer version for what I was hoping to do, unless
> there is some way to convert a pointer into an array?
emplace() with classes is a little more involved compared to structs; I
think because the type of the class variable need not be the same type
as the instance.
> Is there any way to do something like this..
>
> void* pData = some_c_function();
> void [] fakeArray = pData, size;
Yes, as Andrew Wiley has shown:
void[] fakeArray = pData[0..size];
Ali
P.S. I have all of this in my Turkish book but that chapter hasn't been
translated to English yet:
http://ddili.org/ders/d/bellek_yonetimi.html
Re: cas function issue
On Thu, 29 Dec 2011 08:01:51 +, Adrian Mercieca wrote:
> Hi folks,
>
> I've got this very simple program, for which I keep getting compiler
> errors at the 'cas' function call.
>
> import
> std.stdio,
> core.atomic;
>
> class Int
> {
> public:
> this(int v) {
> this._v = v;
> }
>
> private:
> int _v;
> }
>
>
> void main()
> {
> shared(Int) a = new shared(Int)(10);
> shared(Int) b = new shared(Int)(20);
> shared(Int*) p = &a;
>
> if ( cas(p, a, b) ) {
> writeln("Swap OK");
> }
> }
>
> The errors are:
>
> Error: template core.atomic.cas(T,V1,V2) if
> (__traits(compiles,mixin("*here = writeThis"))) does not match any
> function template declaration
>
> Error: template core.atomic.cas(T,V1,V2) if
> (__traits(compiles,mixin("*here = writeThis"))) cannot deduce template
> function from argument types !()(shared(Int*),shared(Int),shared(Int))
>
> Is it not possible to compare and swap object references in the cas
> function call? Would someone kindly tell me as to what I am doing wrong?
>
> Thanks.
> - Adrian.
Hi,
I think I got it; the class (Int) needs to be declared as shared.
Thanks.
Re: Using delegate for WindowProc - possible ?
On 12/28/2011 03:45 PM, Tal wrote:
Can I do something like this :
__
extern (Windows) LRESULT delegate (HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam) MyWinProcDelegate;
this() {
MyWinProcDelegate =&Events;
}
extern (Windows) LRESULT Events (HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam) {
MessageBoxA(null , "Success!!!" , null ,0);
return DefWindowProcA(hWnd, message, wParam, lParam);
}
__
The Events() doesn't seem to fire... am I missing something ?
ok next try, this works for me.
import std.stdio;
import std.functional;
int main(string[] argv)
{
extern(Windows) int delegate( int i) dg;
alias dg callback;
callback = toDelegate(&test);
writeln( callback( 1 ) );
readln();
return 0;
}
extern(Windows) int test(int i) { return 41 +i;}
hth, bjoern
Re: Using delegate for WindowProc - possible ?
On 12/28/2011 03:45 PM, Tal wrote:
Can I do something like this :
__
extern (Windows) LRESULT delegate (HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam) MyWinProcDelegate;
this() {
MyWinProcDelegate =&Events;
}
extern (Windows) LRESULT Events (HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam) {
MessageBoxA(null , "Success!!!" , null ,0);
return DefWindowProcA(hWnd, message, wParam, lParam);
}
__
The Events() doesn't seem to fire... am I missing something ?
ok next try : At least it compiles ..
import std.functional;
int main(string[] argv)
{
extern(Windows) int delegate() dg;
alias dg callback;
callback = toDelegate(&test);
return 0;
}
extern(Windows) int test() { return 42;}
hth, bjoern
Re: Using delegate for WindowProc - possible ?
On 12/28/2011 03:45 PM, Tal wrote:
Can I do something like this :
__
extern (Windows) LRESULT delegate (HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam) MyWinProcDelegate;
this() {
MyWinProcDelegate =&Events;
}
extern (Windows) LRESULT Events (HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam) {
MessageBoxA(null , "Success!!!" , null ,0);
return DefWindowProcA(hWnd, message, wParam, lParam);
}
__
The Events() doesn't seem to fire... am I missing something ?
Maybe std.functional toDelegate() ?
auto DelegateToUse = toDelegate(&Events);
Not sure how much sense this makes...
If I recall correctly I have used
alias extern windows LRESULT delegate() callback;
callback = &cbfunc;
As said I am not sure, hth Bjoern
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On 2011-12-29 18:22, Jakob Ovrum wrote:
On Thursday, 29 December 2011 at 16:27:33 UTC, Ashish Myles wrote:
std.c.stdlib.exit() seems to break RAII. The code below tests this
both using a struct destructor and an explicit scope(exit) {}. Is
this an intentional feature or a bug?
import std.stdio;
import std.c.stdlib;
void main()
{
struct SafeExit {
~this() {
writeln("Safely exit with destructor.");
}
}
SafeExit safeExit;
scope(exit) { writeln("Safely exit with scope(exit)."); }
scope(failure) { writeln("Safely exit with scope(failure)."); }
writeln("Test if std.c.stdlib.exit() breaks RAII.");
writeln("Pre-exit!");
std.c.stdlib.exit(0);
writeln("Post-exit! Should not get here!");
}
The C runtime is beyond D's immediate control. You would have to replace
C's exit function with a custom one or make the compiler recognize calls
to it.
Calling 'exit' doesn't properly shut down the D runtime either, it's not
just constructors.
It's neither a bug or a feature. The bug is arguably in your program.
Could druntime hook up on the atexit function to run destructors and
similar when the program exits?
--
/Jacob Carlborg
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thu, Dec 29, 2011 at 1:26 PM, Andrej Mitrovic wrote: > Probably the easiest thing to do is to throw a custom exception and > catch it somewhere in main() to return your status code. Unlike > exit(), throwing will take care of RAII stuff. Thanks, Andrej. That option had occurred to me, but I figured that shouldn't be the way to do things given that most other languages have a native exit function. Given that this code transformation isn't particularly difficult (put main in a try/catch, have a custom exception storing exit code, return the exit code in the catch block), would it be reasonable to do a feature request for a D-language-supported exit()?
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
Probably the easiest thing to do is to throw a custom exception and catch it somewhere in main() to return your status code. Unlike exit(), throwing will take care of RAII stuff.
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thu, Dec 29, 2011 at 12:22 PM, Jakob Ovrum wrote:
> On Thursday, 29 December 2011 at 16:27:33 UTC, Ashish Myles wrote:
>>
>> std.c.stdlib.exit() seems to break RAII. The code below tests this
>> both using a struct destructor and an explicit scope(exit) {}. Is
>> this an intentional feature or a bug?
>>
>> import std.stdio;
>> import std.c.stdlib;
>>
>> void main()
>> {
>> struct SafeExit {
>> ~this() {
>> writeln("Safely exit with destructor.");
>> }
>> }
>> SafeExit safeExit;
>>
>> scope(exit) { writeln("Safely exit with scope(exit)."); }
>> scope(failure) { writeln("Safely exit with scope(failure)."); }
>>
>> writeln("Test if std.c.stdlib.exit() breaks RAII.");
>> writeln("Pre-exit!");
>> std.c.stdlib.exit(0);
>> writeln("Post-exit! Should not get here!");
>> }
>
>
> The C runtime is beyond D's immediate control. You would have to replace C's
> exit function with a custom one or make the compiler recognize calls to it.
>
> Calling 'exit' doesn't properly shut down the D runtime either, it's not
> just constructors.
>
> It's neither a bug or a feature. The bug is arguably in your program.
In that case, what is the recommended way to exit a program from a
deeply nested level and also possibly specify a return value?
Ashish
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thursday, 29 December 2011 at 17:22:33 UTC, Jakob Ovrum wrote: Calling 'exit' doesn't properly shut down the D runtime either, it's not just constructors. I mean destructors*.
Re: Bug or feature? std.c.stdlib.exit() breaks RAII
On Thursday, 29 December 2011 at 16:27:33 UTC, Ashish Myles wrote:
std.c.stdlib.exit() seems to break RAII. The code below tests
this
both using a struct destructor and an explicit scope(exit) {}.
Is
this an intentional feature or a bug?
import std.stdio;
import std.c.stdlib;
void main()
{
struct SafeExit {
~this() {
writeln("Safely exit with destructor.");
}
}
SafeExit safeExit;
scope(exit) { writeln("Safely exit with scope(exit)."); }
scope(failure) { writeln("Safely exit with scope(failure).");
}
writeln("Test if std.c.stdlib.exit() breaks RAII.");
writeln("Pre-exit!");
std.c.stdlib.exit(0);
writeln("Post-exit! Should not get here!");
}
The C runtime is beyond D's immediate control. You would have to
replace C's exit function with a custom one or make the compiler
recognize calls to it.
Calling 'exit' doesn't properly shut down the D runtime either,
it's not just constructors.
It's neither a bug or a feature. The bug is arguably in your
program.
Bug or feature? std.c.stdlib.exit() breaks RAII
std.c.stdlib.exit() seems to break RAII. The code below tests this
both using a struct destructor and an explicit scope(exit) {}. Is
this an intentional feature or a bug?
import std.stdio;
import std.c.stdlib;
void main()
{
struct SafeExit {
~this() {
writeln("Safely exit with destructor.");
}
}
SafeExit safeExit;
scope(exit) { writeln("Safely exit with scope(exit)."); }
scope(failure) { writeln("Safely exit with scope(failure)."); }
writeln("Test if std.c.stdlib.exit() breaks RAII.");
writeln("Pre-exit!");
std.c.stdlib.exit(0);
writeln("Post-exit! Should not get here!");
}
Re: Reading about D: few questions
On 25.12.2011 11:28, Denis Shelomovskij wrote:
OK. As I wrote: "Yes, this allocation sometimes can be optimized out but
not always.". Consider this:
---
void main()
{
int[] a = new int[5];
void f(int[] b)
{
// Here we assume that b is unchanged a.
// As these array differ we need a copy.
assert(b[0] == 0);
assert(a[0] == 1);
}
f(a[]++); // Note: compilation error now
}
---
Why not to rewrite `f(a[]++);` as `f(a); ++a[];`? Because postincrement
is expected to increment its argument when it is executed. It just
returns an unchanged copy. Analogous D code with integers illustrates this:
---
void main()
{
int a;
void f(int b)
{
assert(b == 0);
assert(a == 1);
}
f(a++);
}
---
I wasn't familiar with this postincrement behavior. I would expect both
a and b to be 0 inside f().
Anyway, what do you suggest? To leave it not compilable?
My original point was to just allow:
a[]++;
More complicated scenarios like the one above is beyond my knowledge, as
I'm only learning the language, but I think they have to be addressed as
well.
cas function issue
Hi folks,
I've got this very simple program, for which I keep getting compiler errors at
the 'cas' function call.
import
std.stdio,
core.atomic;
class Int
{
public:
this(int v) {
this._v = v;
}
private:
int _v;
}
void main()
{
shared(Int) a = new shared(Int)(10);
shared(Int) b = new shared(Int)(20);
shared(Int*) p = &a;
if ( cas(p, a, b) ) {
writeln("Swap OK");
}
}
The errors are:
Error: template core.atomic.cas(T,V1,V2) if (__traits(compiles,mixin("*here =
writeThis"))) does not match any
function template declaration
Error: template core.atomic.cas(T,V1,V2) if (__traits(compiles,mixin("*here =
writeThis"))) cannot deduce template
function from argument types !()(shared(Int*),shared(Int),shared(Int))
Is it not possible to compare and swap object references in the cas function
call?
Would someone kindly tell me as to what I am doing wrong?
Thanks.
- Adrian.
