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
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
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,
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 s
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 not
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 of
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 of
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 sk
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 (im
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 the
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 t
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 s
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
live
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
live
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 th
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 m
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 ch
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: That
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 ac
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
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.).
name...
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
{
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?
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 ty
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 retu
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.ty
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(){ i
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 RAI
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
{
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 ini
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).
P
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 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 FT_Init
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
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
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
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
com
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 not
-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 documentat
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 oth
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 oth
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 ha
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 oth
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 the members get destructors
called too?)
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 sta
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
sses though; 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
initely appear in
http://dlang.org/cpptod.html#raii)
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 not
http://dlang.org/phobos/std_typecons.html#.RefCounted
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
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 argumen
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!
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
>> f
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:
> algorit
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 valu
On 06/01/2012 14:44, Andrej Mitrovic wrote:
Just implement your own exception type, e.g. ExitException, and then use:
That's more or less what people have already said. What's more, Ashish has already
suggested a further improvement whereby the custom exception carries an exit code.
void m
That should have been int main.
Just implement your own exception type, e.g. ExitException, and then use:
void main() { try { realMain(); } catch (ExitException e) { return 0; }
void exit() { throw ExitException(); }
where realMain is the actual main function. Then just call exit()
whenever you want to.
s 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.
; them do it cleanly (which is what you'd need for a clean shutdown). You could
> use std.concurrency to inform them to shutdown or have a shared flag which
> indicates that it's time for all threads to shutdown, but you couldn't use
> pthreads or the Windows equivalent to tell
r have a shared flag which
indicates that it's time for all threads to shutdown, but you couldn't use
pthreads or the Windows equivalent to tell a thread to shutdown cleanly. So,
the only means generally available to terminate a thread is to forcibly kill
it (as C's exit does), maki
On Fri, Dec 30, 2011 at 5:43 AM, Jonathan M Davis 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 above, does
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 h
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() b
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
> particular
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
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
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
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 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
>>
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*.
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
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("S
Ah, I keep forgetting about opCall. Nice tips there.
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
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:
struc
On Saturday 22 January 2011 15:09:29 bearophile wrote:
> 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 t
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.
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..
== 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
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
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?
On Monday, July 12, 2010 18:15:04 Nick Sabalausky wrote:
> "torhu" wrote in message
> news:i1ft84$2h4...@digitalmars.com...
>
> > I think the conclusion is that RAII is less important in D than in C++.
> > In D you use scope (exit), or even finally, like in Java
"torhu" wrote in message
news:i1ft84$2h4...@digitalmars.com...
>
> I think the conclusion is that RAII is less important in D than in C++. In
> D you use scope (exit), or even finally, like in Java or Python. The other
> use of scope, as a storage class, is supposed to
torhu:
> I think that's supposed to go away, but I'm not 100% sure. Would make
> sense, since it was added as a sort of stopgap measure when there were
> no struct literals.
Well, if you have found a use case for static opCall then it needs to be shown
to the people that want to deprecate the
On Monday, July 12, 2010 15:40:24 torhu wrote:
> On 13.07.2010 00:09, bearophile wrote:
> > 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 pl
On 13.07.2010 00:09, bearophile wrote:
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 stru
1 - 100 of 117 matches
Mail list logo
