On Saturday, 21 July 2012 at 21:12:55 UTC, Namespace wrote:
> I'm not sure if it's a bug or my code is nonsense. ;)

While there are some bugs D, you have to realize that D is a garbage collected language, which means you should not rely on objects being destructed in a timely fashion (or at all). Furthermore, it discourages manipulating raw pointers.

While experimenting is fine and all (and I encourage it), you really need to embrace the language for what it is, rather than force a design on to it (scoped!).

I'd be willing to bet big money you are coming from C++? I had the same difficulties at first.

Yes, C++ was my previous language.

And no, nobody say anything about Ranges. But i doesn't like stuff who is deprecated as language feature and is rebuild as std.algorithm construct. It is that simple. :)

On Sunday, July 22, 2012 10:16:25 Namespace wrote:
> Yes, C++ was my previous language.
> 
> And no, nobody say anything about Ranges. But i doesn't like stuff who is deprecated as language feature and is rebuild as std.algorithm construct. It is that simple. :)

std.algorithm doesn't have anything like that. Are you talking about std.typecons.scoped?

Regardless, it was decided that it was  _bad_ language feature, which is why it was removed from the language (or will be anyway - I don't think that it's actually been deprecated yet like it's supposed to be). The same goes for delete. They're _not_ safe when dealing with GC memory, and their use should generally be strongly discouraged.

- Jonathan M Davis

Oh yes, i mean std.typecons, not std.algorithm, my bad.

If delete will be deprecated, how can i delete/call dtor of one of my objects manually?

On Sunday, July 22, 2012 10:46:51 Namespace wrote:
> Oh yes, i mean std.typecons, not std.algorithm, my bad.
> 
> If delete will be deprecated, how can i delete/call dtor of one of my objects manually?

You're _really_ not supposed to be doing that. If you're dealing with GC allocated memory, then it's the GC that should be freeing it, not you. It's unsafe for you to be doing it, and it's just asking for bugs. If you want to be manually managing memory, you should be using malloc and free (which admittedly is a bit of pain with objects right now - custom allocators should fix that once we get them).

But if you absolutely insist on trying to manage GC memory manually, then use the stuff in core.memory:

http://dlang.org/phobos/core_memory.html

But again, that's really only for when you _really_ need it. If you're doing much with it, then it's just about a guarantee that you're not using D as it's intended to be used. You're trying to program in C++ with D, which is just going to cause you trouble.

- Jonathan M Davis

The reason for my experiements is just to find a good solution for Not Null types. :)
As long as they are not implement in std.typecons. Maybe you take my solution, if i have some. ;)

On 07/22/2012 01:46 AM, Namespace wrote:
> Oh yes, i mean std.typecons, not std.algorithm, my bad.
>
> If delete will be deprecated, how can i delete/call dtor of one of my
> objects manually?

In C++, deleting involves two steps: call the destructor and release the memory.

It is different in D: releasing memory should be the responsibility of the GC; after all, GC is the one that runs some algorithm that fits its needs.

On the other hand, calling the destructor is still acceptable in D because it may be important for the programmer to run the contents earlier than GC would. clear() does that:

    auto t = new Test(f3);
    // ...
    clear(t);    // <-- Run the destructor

Unfortunately it has a bad name, which is going to be changed.

Ali

> On the other hand, calling the destructor is still acceptable in D because it may be important for the programmer to run the contents earlier than GC would. clear() does that:
>
>     auto t = new Test(f3);
>     // ...
>     clear(t);    // <-- Run the destructor
>
> Unfortunately it has a bad name, which is going to be changed.
>
> Ali

Really? I thought we have to stay with this name now. In my
opinion this name is quite bad, especially in the presence of
UFCS. What is going to be changed to? destroy()?

Mafi

Nice to know. A name like "destroy" or "delete " would be better i think.
But isn't a solution for the not null problem.

A other question:
How can i check if t is valid, after i call "clear"?

[code]
import std.stdio;

class Test {
public:
	this() {
		writeln("CTor");
	}

	~this() {
		writeln("DTor");
	}
}

void main() {
	Test t = new Test();

	clear(t);

	writeln("end main");
}
[/code]

If i write assert(t !is null); it fails, and if i write writeln(t); or assert(t); i get an access violation.