Yeah, since @trusted is checked manually, it's sort of a problem,
if you don't know, how to check it.
On Friday, 13 February 2015 at 09:28:30 UTC, Kagamin wrote:
On Friday, 13 February 2015 at 09:11:26 UTC, Foo wrote:
And I wouldn't say indiscriminately. Every function I marked
with @trusted was checked by me so far.
What did you check them for? :)
Just first example: make and destruct, being
On Friday, 13 February 2015 at 09:11:26 UTC, Foo wrote:
And I wouldn't say indiscriminately. Every function I marked
with @trusted was checked by me so far.
What did you check them for? :)
Just first example: make and destruct, being marked as @trusted,
don't prevent caller from UAF and double
On Friday, 13 February 2015 at 08:00:43 UTC, Kagamin wrote:
On Thursday, 12 February 2015 at 17:29:34 UTC, Foo wrote:
And since today it is @safe wherever possible.
Well, you marked functions @trusted rather indiscriminately :)
Such approach doesn't really improve safety, and the code could
w
On Thursday, 12 February 2015 at 17:29:34 UTC, Foo wrote:
And since today it is @safe wherever possible.
Well, you marked functions @trusted rather indiscriminately :)
Such approach doesn't really improve safety, and the code could
work as well being @system. It's not like @system is inherentl
On Thursday, 12 February 2015 at 14:44:07 UTC, Kagamin wrote:
On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin
wrote:
If we can't relay on GC wholly, there is no need for GC.
All of the objects, that I can create, I can destroy manually
by myself, without any doubtful GC destroyi
On Thursday, 12 February 2015 at 11:10:35 UTC, ponce wrote:
On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote:
On Thu, 12 Feb 2015 09:04:27 +, ponce wrote:
http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
I've also made one for "D can't do real-time because it
On Thursday, 12 February 2015 at 12:52:03 UTC, Andrey Derzhavin
wrote:
If we can't relay on GC wholly, there is no need for GC.
All of the objects, that I can create, I can destroy manually
by myself, without any doubtful GC destroying attempts.
Manual memory management should be possible in D
On Thu, 12 Feb 2015 13:55:20 +, Andrey Derzhavin wrote:
> On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote:
>> sure. but when it comes, for example, for big data structures with
>> complex cross-references, you'll inevitably found that you either
>> leaking memory, or writing your o
On Thu, 12 Feb 2015 13:21:07 +, Paulo Pinto wrote:
> On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote:
>> On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote:
>>
>>> That's a repetition of C++ atavism, that resource management == memory
>>> management. IStream is a traditional exampl
On Thursday, 12 February 2015 at 13:11:48 UTC, ketmar wrote:
sure. but when it comes, for example, for big data structures
with
complex cross-references, you'll inevitably found that you
either leaking
memory, or writing your own half-backed semi-working GC
realization.
ah, good luck doing ef
On Thursday, 12 February 2015 at 09:41:50 UTC, ketmar wrote:
On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote:
That's a repetition of C++ atavism, that resource management
== memory
management. IStream is a traditional example of a GC-managed
object,
which needs deterministic destruction, and
On Thu, 12 Feb 2015 12:52:02 +, Andrey Derzhavin wrote:
> If we can't relay on GC wholly, there is no need for GC.
> All of the objects, that I can create, I can destroy manually by myself,
> without any doubtful GC destroying attempts.
sure. but when it comes, for example, for big data struc
On Thursday, 12 February 2015 at 12:29:47 UTC, Marc Schütz wrote:
Exactly. That's why it's wrong to rely on the GC if you need
deterministic resource management. It's simply the wrong tool
for that.
Unfortunately, the "right" tools are a bit awkward to use, for
the time being. I still have h
On Thu, 12 Feb 2015 12:10:21 +, Andrey Derzhavin wrote:
> if GC does not guarantee the calling of dtor we can't be sure that some
> textures will be destroyed.
> It will be followed by overflowing of the video memory.
> And it is obvious, becouse we have no way to detect when the objects are
>
On Thursday, 12 February 2015 at 12:10:22 UTC, Andrey Derzhavin
wrote:
OK. there is some example:
// we're using an OpenGL
class A
{
protected int m_tex;
this()
{
// texture has been created in video memory. there is no GC
resource.
glGenTexture(1, &m_
On Thursday, 12 February 2015 at 11:11:53 UTC, ponce wrote:
On Thursday, 12 February 2015 at 10:24:38 UTC, Mike Parker
wrote:
On 2/12/2015 6:09 PM, weaselcat wrote:
On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
Truth be told, D has no guideline for deterministic
destruction of
OK. there is some example:
// we're using an OpenGL
class A
{
protected int m_tex;
this()
{
// texture has been created in video memory. there is no GC
resource.
glGenTexture(1, &m_tex);
glTexImage2D(); // texture in video memory
On Thu, 12 Feb 2015 11:10:34 +, ponce wrote:
> On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote:
>> On Thu, 12 Feb 2015 09:04:27 +, ponce wrote:
>>
>>> http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
>>>
>>> I've also made one for "D can't do real-time becau
On Thursday, 12 February 2015 at 10:24:38 UTC, Mike Parker wrote:
On 2/12/2015 6:09 PM, weaselcat wrote:
On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
Truth be told, D has no guideline for deterministic
destruction of
managed resources.
+1
don't complain about people wonderi
On Thursday, 12 February 2015 at 09:50:39 UTC, ketmar wrote:
On Thu, 12 Feb 2015 09:04:27 +, ponce wrote:
http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
I've also made one for "D can't do real-time because it has a
stop-the-world GC"
http://p0nce.github.io/d-idioms/#Th
On 2/12/2015 6:09 PM, weaselcat wrote:
On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
Truth be told, D has no guideline for deterministic destruction of
managed resources.
+1
don't complain about people wondering why class destructors don't work
when there's no _real_ way to do
On Thu, 12 Feb 2015 09:04:27 +, ponce wrote:
> http://p0nce.github.io/d-idioms/#The-trouble-with-class-destructors
>
> I've also made one for "D can't do real-time because it has a
> stop-the-world GC"
> http://p0nce.github.io/d-idioms/#The-impossible-real-time-thread
>
> And one for "D does
On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote:
> That's a repetition of C++ atavism, that resource management == memory
> management. IStream is a traditional example of a GC-managed object,
> which needs deterministic destruction, and not because it consumes
> memory, but because it encapsula
On Thu, 12 Feb 2015 09:26:12 +, Kagamin wrote:
> That's a repetition of C++ atavism, that resource management == memory
> management. IStream is a traditional example of a GC-managed object,
> which needs deterministic destruction, and not because it consumes
> memory, but because it encapsula
On Thursday, 12 February 2015 at 08:55:43 UTC, Jonathan M Davis
wrote:
On Thursday, February 12, 2015 08:33:34 Kagamin via
Digitalmars-d-learn wrote:
Truth be told, D has no guideline for deterministic destruction
of managed resources.
Really what it comes down to is that if you want determini
On Thursday, 12 February 2015 at 08:33:35 UTC, Kagamin wrote:
Truth be told, D has no guideline for deterministic destruction
of managed resources.
+1
don't complain about people wondering why class destructors don't
work when there's no _real_ way to do it in D beyond 'drop down
to C level
On Thursday, 12 February 2015 at 08:14:49 UTC, Mike Parker wrote:
On 2/12/2015 6:42 AM, ketmar wrote:
this problem has very easy solition: we should stop calling
class dtors
"destructors", and rename them to "finalizers".
Absolutely. So many people coming from C++ see "destructor" and
wa
On Thursday, February 12, 2015 08:33:34 Kagamin via Digitalmars-d-learn wrote:
> Truth be told, D has no guideline for deterministic destruction
> of managed resources.
Really what it comes down to is that if you want deterministic destruction,
you _don't_ use managed resources. You use malloc and
Truth be told, D has no guideline for deterministic destruction
of managed resources.
On 2/12/2015 6:42 AM, ketmar wrote:
this problem has very easy solition: we should stop calling class dtors
"destructors", and rename them to "finalizers".
Absolutely. So many people coming from C++ see "destructor" and want to
use them as they did in C++. How often do we see people coming
On Wednesday, February 11, 2015 21:40:30 Orvid King via Digitalmars-d-learn
wrote:
> On Wednesday, 11 February 2015 at 21:34:00 UTC, Andrey Derzhavin
> wrote:
> >If we are using a DMD realization of destroying of
> > objects, happens the following: at the calling the «destroy»
> > method t
On Wednesday, 11 February 2015 at 21:34:00 UTC, Andrey Derzhavin
wrote:
If we are using a DMD realization of destroying of
objects, happens the following: at the calling the «destroy»
method the calling of dtor takes place always, and then the
object which is being destroyed is initializ
On Wed, 11 Feb 2015 21:33:59 +, Andrey Derzhavin wrote:
> If we are using a DMD realization of destroying of objects, happens the
> following: at the calling the «destroy» method the calling of dtor takes
> place always, and then the object which is being destroyed is
> initialized by the de
If we are using a DMD realization of destroying of
objects, happens the following: at the calling the «destroy»
method the calling of dtor takes place always, and then the
object which is being destroyed is initialized by the default
state. In other words, after calling «destroy» method,
35 matches
Mail list logo
