On Thursday, 29 March 2018 at 04:16:55 UTC, Adam D. Ruppe wrote:
On Thursday, 29 March 2018 at 04:12:38 UTC, Norm wrote:
Is there a way to do this in D, or does it require special
"create" functions for every struct that has a RAII-like
struct as a member?
You'll have to do it all
On Thursday, 29 March 2018 at 04:12:38 UTC, Norm wrote:
Is there a way to do this in D, or does it require special
"create" functions for every struct that has a RAII-like struct
as a member?
You'll have to do it all the way up (unless you can use a
constructor with an argumen
it with that static make function.
OK, that got me over the first hurdle but I still cannot use RAII
with struct member vars. E.g.
---
struct Resource {
this() {allocate_something();}
~this() {release_something();}
}
struct S {
Resource resource;
}
---
Is there a way to do this in D, or does
On Tuesday, 27 March 2018 at 02:43:15 UTC, Adam D. Ruppe wrote:
On Tuesday, 27 March 2018 at 02:35:23 UTC, Norm wrote:
What's the best way to do this in D?
I'd also add `@disable this();` and then a `static O make() {
return O(theAllocator.make!int(99)); }`
than you construct it with that
On Tuesday, 27 March 2018 at 02:35:23 UTC, Norm wrote:
What's the best way to do this in D?
I'd also add `@disable this();` and then a `static O make() {
return O(theAllocator.make!int(99)); }`
than you construct it with that static make function.
Hi All,
What's the best way to do this in D?
E.g.
---
struct O
{
int* value;
@disable this(this);
/+
this()
{
this.value = theAllocator.make!int(99);
}
+/
~this()
{
theAllocator.dispose(this.value);
}
}
O obj = O(); // Ideally this would be allocated but it simply run
On Monday, 19 June 2017 at 06:34:49 UTC, Ali Çehreli wrote:
It's unreliable because structs are value types in D, which
means that they can be moved around freely. This is why
self-referencing structs are illegal in D.
I guess it's more like the spec states, that they can be moved
vithout
On 06/18/2017 06:22 PM, Boris-Barboris wrote:
> https://dpaste.dzfl.pl/d77c72198095
>
> 1). line 47 and 76 together mean, that there is basically no reliable
> way to write uniqueptr method wich returns WeakPointer, registered by
> the correct pointer in it's constructor. Or is there? Is usage
Hello, I was trying to write some templated unique pointers.
Idea was simple: struct UniquePointer that handles underlying
pointer in RAII-style and WeakPointer struct that is spawned by
UniquePointer. Weak pointer is handled differently in my
collections, wich subscribe to the event
On Saturday, 3 June 2017 at 21:46:45 UTC, Stanislav Blinov wrote:
On Saturday, 3 June 2017 at 21:39:54 UTC, Moritz Maxeiner wrote:
It's always true, because I explicitly wrote *might*, not
*will*, to indicate that it depends on your use case. Your
example is a common use case where you can't
On Saturday, 3 June 2017 at 21:39:54 UTC, Moritz Maxeiner wrote:
On Saturday, 3 June 2017 at 21:16:08 UTC, Stanislav Blinov
wrote:
On Saturday, 3 June 2017 at 20:53:05 UTC, Moritz Maxeiner
wrote:
Quite, but if you backtrack to my initial statement, it was
about ptr not being/becoming null
On Saturday, 3 June 2017 at 21:16:08 UTC, Stanislav Blinov wrote:
On Saturday, 3 June 2017 at 20:53:05 UTC, Moritz Maxeiner wrote:
Quite, but if you backtrack to my initial statement, it was
about ptr not being/becoming null (implicitly) in the first
place, which *might* allow you to skip
On Saturday, 3 June 2017 at 20:53:05 UTC, Moritz Maxeiner wrote:
On Saturday, 3 June 2017 at 20:25:22 UTC, Stanislav Blinov
wrote:
On Saturday, 3 June 2017 at 20:13:30 UTC, Moritz Maxeiner
wrote:
Calling std.algorithm.move is explicit programmer intent, I
consider that about as accidental as
On Saturday, 3 June 2017 at 20:25:22 UTC, Stanislav Blinov wrote:
On Saturday, 3 June 2017 at 20:13:30 UTC, Moritz Maxeiner wrote:
Calling std.algorithm.move is explicit programmer intent, I
consider that about as accidental as calling memcpy with a
source full of zeroes.
In any case, having
On Saturday, 3 June 2017 at 20:13:30 UTC, Moritz Maxeiner wrote:
Calling std.algorithm.move is explicit programmer intent, I
consider that about as accidental as calling memcpy with a
source full of zeroes.
In any case, having that check in the destructor is fairly
cheap, so better safe than
On Saturday, 3 June 2017 at 19:55:30 UTC, ag0aep6g wrote:
On 06/03/2017 09:37 PM, Moritz Maxeiner wrote:
Of course, but AFAIK you'd need to explicitly assign it to an
object, so `ptr` won't null by accident, but only by explicit
programmer intent (same as overwriting the memory the object
On Saturday, 3 June 2017 at 19:55:30 UTC, ag0aep6g wrote:
On 06/03/2017 09:37 PM, Moritz Maxeiner wrote:
Of course, but AFAIK you'd need to explicitly assign it to an
object, so `ptr` won't null by accident, but only by explicit
programmer intent (same as overwriting the memory the object
On 06/03/2017 09:37 PM, Moritz Maxeiner wrote:
Of course, but AFAIK you'd need to explicitly assign it to an object, so
`ptr` won't null by accident, but only by explicit programmer intent
(same as overwriting the memory the object lives in via things like
`memcpy`); and you can always screw
On Saturday, 3 June 2017 at 19:21:58 UTC, ag0aep6g wrote:
On 06/03/2017 09:06 PM, Moritz Maxeiner wrote:
- null check in destructor: That's just because I forgot to
add it. If you add `@disable(this)` (disable the default
constructor), all elaborate constructors ensure it is not
null, and no
On 06/03/2017 09:06 PM, Moritz Maxeiner wrote:
- null check in destructor: That's just because I forgot to add it. If
you add `@disable(this)` (disable the default constructor), all
elaborate constructors ensure it is not null, and no members can set it
to null, you might be able to skip the
On Saturday, 3 June 2017 at 17:40:32 UTC, Russel Winder wrote:
Would one be considered more idiomatic D, or is it a
question of different circumstances different approaches. The
differences are mainly in construction I believe.
Well, the differences I spot are:
- null check in destructor:
Thanks to Moritz and Stanislav for their examples, most useful. There
are similarities (which I have just taken :-) but also some
differences. Would one be considered more idiomatic D, or is it a
question of different circumstances different approaches. The
differences are mainly in construction I
On Monday, 29 May 2017 at 23:39:17 UTC, Russel Winder wrote:
C++ allows one to create types that are pointer types but wrap
a primitive pointer to give RAII handling of resources. For
example:
class Dvb::FrontendParameters_Ptr {
private:
dvb_v5_fe_parms * ptr;
public
On Monday, 29 May 2017 at 23:39:17 UTC, Russel Winder wrote:
C++ allows one to create types that are pointer types but wrap
a primitive pointer to give RAII handling of resources. For
example:
class Dvb::FrontendParameters_Ptr {
private:
dvb_v5_fe_parms * ptr;
public
On Monday, 29 May 2017 at 23:39:17 UTC, Russel Winder wrote:
C++ allows one to create types that are pointer types but wrap
a primitive pointer to give RAII handling of resources. For
example:
[...]
std.stdio.File does basically the same thing with C's FILE*
C++ allows one to create types that are pointer types but wrap a
primitive pointer to give RAII handling of resources. For example:
class Dvb::FrontendParameters_Ptr {
private:
dvb_v5_fe_parms * ptr;
public:
FrontendParameters_Ptr(FrontendId const &
Arun Chandrasekaran wrote:
On Thursday, 23 February 2017 at 09:57:09 UTC, ketmar wrote:
Thanks for your help. NRVO looks interesting. However this may not be
RAII after all. Or may be too much of C++ has spoiled me. I am not
familiar enough with D to appreciate/question the language design
On Thursday, 23 February 2017 at 21:05:48 UTC, cym13 wrote:
It reminds me of
https://w0rp.com/blog/post/an-raii-constructor-by-another-name-is-just-as-sweet/ which isn't what you want but may be interesting anyway.
It is interesting, indeed, thanks.
On Thursday, 23 February 2017 at 09:57:09 UTC, ketmar wrote:
Arun Chandrasekaran wrote:
I'm trying to write an RAII wrapper on Linux.
I understand struct in D doesn't have default constructor (for
.init reasons).
I don't want to use `scope`.
Is there an elegant way to achieve this in D
On Thursday, 23 February 2017 at 09:52:26 UTC, Arun
Chandrasekaran wrote:
I'm trying to write an RAII wrapper on Linux.
I understand struct in D doesn't have default constructor (for
.init reasons).
I don't want to use `scope`.
Is there an elegant way to achieve this in D?
```
import
On Thursday, 23 February 2017 at 18:46:58 UTC, kinke wrote:
A constructor is just a factory function with a special name...
Wrt. the special name, that's obviously extremely useful for
generic templates (containers etc.).
...
it is almost equal amount of work.
Sorry but this is just completely wrong. RAII is all about me NOT
having to call special functions all over the place.
struct S
{
this() { /* initialize */ }
}
S[123] myArray; // hooray, no need to invoke a factory in a loop
struct Container
{
S s
On Thursday, 23 February 2017 at 10:48:38 UTC, kinke wrote:
That's not elegant. You need a factory function for each type
containing one of these structs then.
A constructor is just a factory function with a special name...
it is almost equal amount of work.
On Thursday, 23 February 2017 at 09:52:26 UTC, Arun
Chandrasekaran wrote:
I'm trying to write an RAII wrapper on Linux.
I understand struct in D doesn't have default constructor (for
.init reasons).
I don't want to use `scope`.
Is there an elegant way to achieve this in D?
static opCall
On Thursday, 23 February 2017 at 09:57:09 UTC, ketmar wrote:
Arun Chandrasekaran wrote:
Is there an elegant way to achieve this in D?
why not static method or free function that returns struct? due
to NRVO[0] it won't even be copied.
That's not elegant. You need a factory function for each
Arun Chandrasekaran wrote:
I'm trying to write an RAII wrapper on Linux.
I understand struct in D doesn't have default constructor (for .init
reasons).
I don't want to use `scope`.
Is there an elegant way to achieve this in D?
why not static method or free function that returns struct? due
I'm trying to write an RAII wrapper on Linux.
I understand struct in D doesn't have default constructor (for
.init reasons).
I don't want to use `scope`.
Is there an elegant way to achieve this in D?
```
import core.sys.posix.pthread;
import core.sys.posix.sys.types;
/// Makes
On Wednesday, 9 March 2016 at 10:48:30 UTC, cym13 wrote:
On Wednesday, 9 March 2016 at 10:28:06 UTC, John Colvin wrote:
Potential for leaking references from alias this aside, is
there some reason that I shouldn't do this for all my C++-like
RAII needs:
class A
{
~this(){ import
On Wednesday, 9 March 2016 at 10:28:06 UTC, John Colvin wrote:
Potential for leaking references from alias this aside, is
there some reason that I shouldn't do this for all my C++-like
RAII needs:
class A
{
~this(){ import std.stdio; writeln("hello"); }
}
auto RAII(T)(
Potential for leaking references from alias this aside, is there
some reason that I shouldn't do this for all my C++-like RAII
needs:
class A
{
~this(){ import std.stdio; writeln("hello"); }
}
auto RAII(T)()
if (is(T == class))
{
struct Inner
{
I have the following code in attempt to create an RAII object
wrapper, but it seems that it might be impossible. The problem
here is that FT_Init_FreeType is a static which is set at some
previous time to a function entry point in the FreeType library.
I could use a scope block, but would
On 11/20/2015 02:56 PM, Spacen Jasset wrote:
> FT_Init_FreeType is a static which is set at some previous time to a
> function entry point in the FreeType library.
> text.d(143,15): Error: static variable FT_Init_FreeType cannot be read
> at compile time
The compiler seems to think that
On 20.11.2015 23:56, Spacen Jasset wrote:
The ideal would be to have a struct that can be placed inside a function
scope, or perhaps as a module global variable. Why does Ft_Init_FreeType
have to be read at compile time?
text.d(143,15): Error: static variable FT_Init_FreeType cannot be read
at
On Friday, 20 November 2015 at 23:21:03 UTC, anonymous wrote:
[...]
FT_Init_FreeType must be read at compile time, because freeType
is a module level variable, and initializers for module
variables must be static values. The initializer is run through
CTFE (Compile Time Function Evaluation).
On Friday, 20 November 2015 at 23:35:50 UTC, Spacen Jasset wrote:
On Friday, 20 November 2015 at 23:21:03 UTC, anonymous wrote:
[...]
FT_Init_FreeType must be read at compile time, because
freeType is a module level variable, and initializers for
module variables must be static values. The
Thanks for the thorough response. I'm aware of some of what you
explained. Maybe I should have asked differently. Rather than asking
what RAII facilities do exist, I guess I was looking for the answer,
Here's what you typically do in C++ RAII that you can't do in D. I
could probably find out
Thanks. I had not looked at some of those yet.
Jim
Thanks for all the info. It's a good comparison of structs and classes
to keep handy. Actually, I'm fine with the GC. I don't mean to avoid it.
I just would like some way to also have non-memory resources
automatically released in a timely, predictable way.
One common thing to do in C++ is to
A serious bug affecting RAII is
https://issues.dlang.org/show_bug.cgi?id=14903, but apparently
its importance hasn't been properly acknowledged yet. Improving
the performance of binaries produced by dmd's backend is
obviously way more important than fixing serious bugs or
commenting
On Tuesday, 25 August 2015 at 22:35:57 UTC, Jim Hewes wrote:
Although C++ can be ugly, one reason I keep going back to it
rather then commit more time to reference-based languages like
C# is because I like deterministic destruction so much. My
question is whether D can REALLY handle this or
just going to come out and finally ask.
I know about this RAII section in the documentation:
http://dlang.org/cpptod.html#raii
But I don't believe that handles all cases, such as having classes as
member variables of other classes. (Do the members get destructors
called too
this or not. I've not
been sure about this for some time so now I'm just going to
come out and finally ask.
I know about this RAII section in the documentation:
http://dlang.org/cpptod.html#raii
But I don't believe that handles all cases, such as having
classes as member variables of other classes. (Do
destruction so much. My
question is whether D can REALLY handle this or not. I've not
been sure about this for some time so now I'm just going to
come out and finally ask.
I know about this RAII section in the documentation:
http://dlang.org/cpptod.html#raii
But I don't believe that handles all cases
this or not. I've not
been sure about this for some time so now I'm just going to
come out and finally ask.
I know about this RAII section in the documentation:
http://dlang.org/cpptod.html#raii
But I don't believe that handles all cases, such as having
classes as member variables of other classes. (Do
this or not. I've not
been sure about this for some time so now I'm just going to
come out and finally ask.
I know about this RAII section in the documentation:
http://dlang.org/cpptod.html#raii
But I don't believe that handles all cases, such as having
classes as member variables of other classes. (Do
-based languages
like C# is because I like deterministic destruction so much.
My question is whether D can REALLY handle this or not. I've
not been sure about this for some time so now I'm just going
to come out and finally ask.
I know about this RAII section in the documentation:
http
On Thu, 2014-08-21 at 19:22 -0700, Timothee Cour via Digitalmars-d-learn
wrote:
What would be a good answer to this article?
http://swiftcoder.wordpress.com/2009/02/18/raii-why-is-it-unique-to-c/
Especially the part mentioning D:{
D’s scope keyword, Python’s with statement and C#’s using
What would be a good answer to this article?
http://swiftcoder.wordpress.com/2009/02/18/raii-why-is-it-unique-to-c/
Especially the part mentioning D:{
D’s scope keyword, Python’s with statement and C#’s using declaration all
provide limited RAII, by allowing resources to have a scoped lifetime
http://dlang.org/phobos/std_typecons.html#.RefCounted
On Friday, 22 August 2014 at 02:22:16 UTC, Timothee Cour via
Digitalmars-d-learn wrote:
What would be a good answer to this article?
It's own publication date: Feb 2009. The D struct has changed a
lot since then, getting new features (@disable, postblit, more
reliable destructor) and bugs
in
http://dlang.org/cpptod.html#raii)
; is there any way to get
a ref
counted class?
(and btw RefCounted should definitely appear in
http://dlang.org/cpptod.html#raii)
It can be made to work with classes and probably should be.
There's no fundamental reason why it can't. It's probably just
more complicated.
- Jonathan M Davis
On Friday, 22 August 2014 at 02:22:16 UTC, Timothee Cour via
Digitalmars-d-learn wrote:
Especially the part mentioning D:{
D’s scope keyword, Python’s with statement and C#’s using
declaration all
provide limited RAII, by allowing resources to have a scoped
lifetime, but
none of them readily
On Monday, 7 July 2014 at 21:49:22 UTC, Justin Whear wrote:
On Mon, 07 Jul 2014 21:34:05 +, Nordlöw wrote:
However using this function through UFCS
auto cx = new C().set!x(11);
fails as
algorithm_ex.d(1257,17): Error: template algorithm_ex.set
cannot deduce
function from argument
Because D currently doesn't support RAII using named parameters
like in Python I tried the following.
Say I have an aggregate
class C { int x,y,z,w; }
or similarly
struct C { int x,y,z,w; }
I know define a generic _free_ function
ref T set(string member, T, U)(ref T a, in U value
On Mon, 07 Jul 2014 21:34:05 +, Nordlöw wrote:
However using this function through UFCS
auto cx = new C().set!x(11);
fails as
algorithm_ex.d(1257,17): Error: template algorithm_ex.set cannot deduce
function from argument types !(x)(C, int), candidates are:
On Mon, 07 Jul 2014 21:49:22 +, Justin Whear wrote:
On Mon, 07 Jul 2014 21:34:05 +, Nordlöw wrote:
However using this function through UFCS
auto cx = new C().set!x(11);
fails as
algorithm_ex.d(1257,17): Error: template algorithm_ex.set cannot deduce
function from
On Monday, 7 July 2014 at 21:50:22 UTC, Justin Whear wrote:
Copy and paste gone astray; should be this link:
http://dpaste.dzfl.pl/3c33ad70040f
Thx!
to call scope guards and RAII, it would need to
unwind the call stack, which could get complicated if you're trying to do it from within a
function.
It's much simpler not to use exit() and throw a custom exception instead.
Stewart.
That should have been int main.
On Thursday, December 29, 2011 23:03:23 Ashish Myles wrote:
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?
And how
On Fri, Dec 30, 2011 at 5:43 AM, Jonathan M Davis jmdavisp...@gmx.com wrote:
On Thursday, December 29, 2011 23:03:23 Ashish Myles wrote:
Since D
could conceivably implement a very safe exit() without an explicit use
of Exceptions to get around the catch Exception() {} problem you
mentioned
to shutdown cleanly. So,
the only means generally available to terminate a thread is to forcibly kill
it (as C's exit does), making automatic cleanup impossible.
_Some_ cleanup can be done when exit is called using atexit and on_exit, but
the stack won't be unwound properly, so RAII, scope statements
.
_Some_ cleanup can be done when exit is called using atexit and on_exit, but
the stack won't be unwound properly, so RAII, scope statements, and finally
blocks aren't going to be run properly. So, critical, global stuff can be
potentially cleaned up, but you can't get a fully clean shutdown
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
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.
On Thu, Dec 29, 2011 at 1:26 PM, Andrej Mitrovic
andrej.mitrov...@gmail.com 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
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
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*.
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
(), 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
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 iostream
#include cstdlib
struct SafeExit {
~SafeExit() {
std::cout Safely exit
On 2011-01-23 00:03, Sean Eskapp wrote:
It was recommended to me to use structs for RAII instead of scope classes,
since scope is being removed (?). However, since default-constructors for
structs can't exist, how does one do this?
You can use a static opCall, like this:
struct Foo
On 2011-01-23 01:14, Andrej Mitrovic wrote:
A workaround:
import std.stdio;
import std.exception;
struct A
{
int x;
this(void* none)
{
if (none !is null)
{
enforce(0, Tried to pass a parameter to A's constructor);
}
writeln(in
Ah, I keep forgetting about opCall. Nice tips there.
It was recommended to me to use structs for RAII instead of scope classes,
since scope is being removed (?). However, since default-constructors for
structs can't exist, how does one do this?
Sean Eskapp:
It was recommended to me to use structs for RAII instead of scope classes,
since scope is being removed (?). However, since default-constructors for
structs can't exist, how does one do this?
Inside the ~this() you may put code, to deallocate resources you have allocated
== Quote from bearophile (bearophileh...@lycos.com)'s article
Sean Eskapp:
It was recommended to me to use structs for RAII instead of scope classes,
since scope is being removed (?). However, since default-constructors for
structs can't exist, how does one do this?
Inside the ~this() you
A workaround:
import std.stdio;
import std.exception;
struct A
{
int x;
this(void* none)
{
if (none !is null)
{
enforce(0, Tried to pass a parameter to A's constructor);
}
writeln(in constructor);
// construction from here..
Actually this becomes rather annoying, since I can't use any closures on the
object. Stupidly, I can still use closures with an object which is deleted at
the
end of the function.
when the object
is
created and disappears when the object is destroyed (so all you have to do is
declare the object it at the beggining of the function and it automatically is
displayed and then disappears). This is classic RAII.
Obviously, because classes are reference types with infinite
for a mutex. Another would be the hourglass in MFC - it's
displayed when the object is created and disappears when the object is
destroyed (so all you have to do is declare the object it at the
beggining of the function and it automatically is displayed and then
disappears). This is classic RAII
). This is classic RAII.
Obviously, because classes are reference types with infinite lifetime
while
structs are value types with their lifetime restricted to their scope,
structs
would be the better choice for RAII. I have noticed a bit of a snag
however:
structs can't have default
On Monday 12 July 2010 00:27:11 Rory McGuire wrote:
Do you know about the scope storage class, or about scope classes?
{
scope tmp = new A();
// use tmp;
tmp destructor is called.
}
scope classes are similar:
http://www.digitalmars.com/d/2.0/class.html
Except
stuff with resource here
}
-Lars
Except that that's two statements and it's no longer RAII. The beauty of doing
it entirely in the constructor and destructor is that you only need one
statement and the whole thing takes care of itself. With scope, you have to
worry about remembering
be the hourglass in MFC - it's displayed when the object is
created and disappears when the object is destroyed (so all you have to do is
declare the object it at the beggining of the function and it automatically is
displayed and then disappears). This is classic RAII.
Obviously, because classes
Jonathan M Davis jmdavisp...@gmail.com wrote:
Except that that's two statements and it's no longer RAII. The beauty of
doing
it entirely in the constructor and destructor is that you only need one
statement and the whole thing takes care of itself. With scope, you have
to
worry about
be the hourglass in MFC - it's displayed when the object is
created and disappears when the object is destroyed (so all you have to do is
declare the object it at the beggining of the function and it automatically is
displayed and then disappears). This is classic RAII.
Obviously, because classes
is a class, so you'd have to do basically the same
thing. But if you only need a local mutex, you'd probably use a
synchronized statement instead.
It's not the mutex but an autolock for a mutex which would use RAII. It would
lock the mutex when it was declared and unlock when it left scope
Jonathan M Davis:
There are lots of cases where using scope(exit) makes sense, and it's a great
construct. But there are also plenty of cases where using plain old RAII with
a
single declaration is better. It works fine in D as long as the struct in
question doesn't need a default
1 - 100 of 107 matches
Mail list logo
