gmane.comp.lang.d.general

Re: Pointer semantics in CTFE

Walter Bright — 2012-05-26T03:35:34

If q is unrelated to the array, which you can tell because q, pstart, and pend 
must all refer to the same object that CTFE knows about, then you can have CTFE 
refuse to execute it.



I still don't think you need to make a special case for it. If upon 
initialization of q, pstart, and pend, CTFE makes a note of what memory object 
they are initialized from, then you can unambiguously tell if they still point 
within the same object or not.

Re: Pointer semantics in CTFE

Don — 2012-05-26T03:24:48

That is exactly how it works right now.

The problem is, if pstart and pend point to the beginning and end of an 
array, then given another pointer q, there is AFAIK no defined way in C 
for checking if q is between pstart and pend, even though I'm sure 
everyone does it. (eg, I don't know how to implement memcpy otherwise).
If q is part of that array, (q >= pstart && q <= pend) is well-defined, 
and returns true.
But if it isn't part of that array, q >= pstart is undefined.

In reality of course, if q is unrelated to the array then EITHER q < 
pstart, OR q > pend. So (q >= pstart && q <= pend) is ALWAYS false, and 
the result is completely predictable.

ie, the full expression can be well-defined even though its two 
subexpressions are not.

This can be implemented.
Given an expression like q >= pstart, where p and q are unrelated, it's 
possible to make it have the value 'false_or_undefined'. If it is anded 
with another expression that is also false_or_undefined, and goes the 
other direction ( q <= pend

Re: clear() and UFCS

Mehrdad — 2012-05-26T03:21:30

Why not just call it 'destroy()'?

Re: clear() and UFCS

Mehrdad — 2012-05-26T03:20:50



Ahh, that was what confused me, thanks... I thought you were 
referring to member /Object/s.

Re: clear() and UFCS

Joshua Niehus — 2012-05-26T03:01:42

disembowel?

Re: clear() and UFCS

Andrei Alexandrescu — 2012-05-26T02:47:40

delete also deallocates.

Andrei

Re: Pointer semantics in CTFE

Don — 2012-05-26T02:43:51

Actually it isn't well-defined in C. You can compare unrelated pointers 
for equality, but can't compare their ordering.
(I think this is because of the segmented architecture in 16 bit DOS).

Re: clear() and UFCS

Jonathan M Davis — 2012-05-26T02:46:43

Yes, though it calls rt_finalize on classes rather than dtor directly, so that 
may do some extra stuff beyond strictly calling __dtor and zeroing out the 
vtable.


Normally when an object is destroyed, all of its member variables' destructors 
would be called as well (at least for member variables which are structs or 
arrays of structs - member variables which are classes aren't finalized). But 
the destructor itself doesn't call all of the member variables' destructors, 
so calling __dtor doesn't call them. You have to do something else to get the 
member variables destroyed as well (something with typeid I think, but I don't 
remember the details).

- Jonathan M Davis

Re: clear() and UFCS

Mehrdad — 2012-05-26T02:34:30

Okay, thanks for the explanation.


So basically, clear() just calls __dtor(), and then zeros out the 
vtable?

I don't understand what you mean by "I don't believe that it 
destroys what the object references"... why should clear() ever 
destroy anything except the object that it's destroying?

Re: XOMB operating system

tim krimm — 2012-05-26T02:33:13

I tried contacting them almost a week ago and I have not heard 
back.

Re: clear() and UFCS

Jonathan M Davis — 2012-05-26T02:27:15

clear destroys the object (by calling its finalizer or destructor) and then in 
the case of classes, it zeroes out its vtable so that if you accidentally the 
object after clearing it, it'll blow up rather than getting weird, non-
deterministic behavior. In the case of structs, I think that it puts the 
object in its init state, but I'm not sure.

clear does _not_ free the object's memory. It merely destroys the object so 
that whatever other resources it references can be released (or just 
unreferenced in the case of GC heap allocated objects that it references).

delete does what it does in C++. It destroys the object and then frees the 
memory. It was decided that having a language construct which freed memory on 
the GC heap was too dangerous and error-prone and shouldn't be encouraged, so 
it's being removed. It's still quite possible however, to create a function 
which destroys and object and then tells the GC to free that object's memory 
using the stuff in core.memory.

__dtor is simply the object

Re: clear() and UFCS

Mehrdad — 2012-05-26T02:04:51

Would you mind explaining the difference between clear(), delete, 
and __dtor/etc? I think it's a little confusing for me.

Re: Pointer semantics in CTFE

Mehrdad — 2012-05-26T01:39:49

Wait, what?

Pointer semantics are well-defined... what's wrong with comparing 
two unrelated pointers?

Re: dget - getting code from github

Walter Bright — 2012-05-26T01:35:13

How about slapping a Boost license on it and creating a pull request for:


https://github.com/D-Programming-Language/tools

?

Re: clear() and UFCS

Jonathan M Davis — 2012-05-26T01:38:03

clear and delete are very different things. It was definitely decided that we'd 
be better off without delete. It's going for good. Renaming clear to something 
that doesn't conflict so easily with more benign functions is completely 
different from bringing back delete. Bringing back delete isn't even on the 
table at this point.

- Jonathan M Davis

Re: Nimrod language

Araq — 2012-05-26T01:00:02


Indeed this is a nice feature to copy. It is, however, possible 
to implement as a macro.

Re: dget - getting code from github

Walter Bright — 2012-05-26T00:46:35

Holy Mackerel! I'm going to give it a try.

Re: clear() and UFCS

Mehrdad — 2012-05-26T00:30:57

or we could just, uh, bring back delete...

Re: Nimrod language

Araq — 2012-05-25T23:20:18

Thank you. Let's see how long I will stay. ;-)

Re: Pointer semantics in CTFE

Walter Bright — 2012-05-25T23:09:32


My experience with such special cases is that users lose the ability to reason 
about what code will work in CTFE and what will not. Its operation will become a 
magical, unknowable black box. Meanwhile, you'll be endlessly chasing more 
special cases and rainbows.

I suggest not supporting it unless it can be done in the general case.

One solution might be to attach to each CTFE pointer a reference to the object 
it is pointing into. Then, pointer comparisons within the same object can work, 
and comparing pointers from different objects can explicitly and predictably be 
not supported.

Re: GitHub for Windows

Nick Sabalausky — 2012-05-25T22:29:50

"Steven Schveighoffer" <schveiguy< at >yahoo.com> wrote in message 
news:op.wevud50reav7ka< at >steves-laptop...

Well, realistically 128MB for XP, and even that was back around 2000 or so. 
I'm not really sure what the heck exactly happened (Just web sites? Or 
something more?), but these days, even on XP, 1GB is really bare minimum.


Yea, I knew about that. But I thought the whole system was consdered to be 
more efficient, too? (While I've used Win7, I've never compared it with XP 
on the same physical system. So that's one point I can't really say.)


I'd be surprised if it were very many, but at this point I think we're both 
reduced to hand-waving. :/