Re: Are D classes always garbage collected?
On Thu, 22 Dec 2011 00:01:53 -0500, Vladimir Panteleev
wrote:
On Thursday, 22 December 2011 at 04:15:25 UTC, Froglegs wrote:
You can allocate classes anywhere, if you're OK with forfeiting
safety guarantees. For example, see emplace in std.conv:
http://dlang.org/phobos/std_conv.html#emplace
Hum calling emplace ending up calling this bit of code..
T* emplace(T)(T* chunk)
if (is(T == class))
{
*chunk = null;
return chunk;
}
Which returned me a nice fat null pointer.. wth? Perhaps that should be
a compile time error if you aren't supposed to use classes..
Strange... I'm not sure what the deal is with that overload. I meant the
last one on the page (that takes a void[]).
I see it, you are emplacing a class reference *pointer*, not a class
reference.
Just so you know, classes are references already, you don't need to use
pointers.
-Steve
Re: Are D classes always garbage collected?
On 12/21/2011 10:20 PM, Froglegs wrote:
>
>>> Which returned me a nice fat null pointer.. wth? Perhaps that should
>>> be a compile time error if you aren't supposed to use classes..
>>
>> Strange... I'm not sure what the deal is with that overload. I meant
>> the last one on the page (that takes a void[]).
>
>
> Hum I've tried the array version but I believe it contains a rather
> serious bug...
>
> T emplace(T, Args...)(void[] chunk, Args args) if (is(T == class))
> {
> enforce(chunk.length >= __traits(classInstanceSize, T),
> new ConvException("emplace: chunk size too small"));
> ...
>
> This fails whenever the size is greater or equal to the amount of memory
> required :(
That bug has recently been fixed:
http://d.puremagic.com/issues/show_bug.cgi?id=6204
> Anyway I need the pointer version for what I was hoping to do, unless
> there is some way to convert a pointer into an array?
emplace() with classes is a little more involved compared to structs; I
think because the type of the class variable need not be the same type
as the instance.
> Is there any way to do something like this..
>
> void* pData = some_c_function();
> void [] fakeArray = pData, size;
Yes, as Andrew Wiley has shown:
void[] fakeArray = pData[0..size];
Ali
P.S. I have all of this in my Turkish book but that chapter hasn't been
translated to English yet:
http://ddili.org/ders/d/bellek_yonetimi.html
Re: Are D classes always garbage collected?
On Wed, Dec 21, 2011 at 10:20 PM, Froglegs wrote:
>
>>> Which returned me a nice fat null pointer.. wth? Perhaps that should be a
>>> compile time error if you aren't supposed to use classes..
>>
>>
>> Strange... I'm not sure what the deal is with that overload. I meant the
>> last one on the page (that takes a void[]).
>
>
>
> Hum I've tried the array version but I believe it contains a rather serious
> bug...
>
> T emplace(T, Args...)(void[] chunk, Args args) if (is(T == class))
> {
> enforce(chunk.length >= __traits(classInstanceSize, T),
> new ConvException("emplace: chunk size too small"));
> ...
>
> This fails whenever the size is greater or equal to the amount of memory
> required :(
>
>
> Anyway I need the pointer version for what I was hoping to do, unless there
> is some way to convert a pointer into an array?
>
> Is there any way to do something like this..
>
> void* pData = some_c_function();
> void [] fakeArray = pData, size;
>
>
Yes:
void* pData = some_c_function();
void[] fakeArray = pData[0..size];
Although Vladimir's solution is safer.
Re: Are D classes always garbage collected?
On Thursday, 22 December 2011 at 06:43:33 UTC, Froglegs wrote:
T emplace(T, Args...)(void[] chunk, Args args) if (is(T ==
class))
{
enforce(chunk.length >= __traits(classInstanceSize, T),
new ConvException("emplace: chunk size too small"));
...
This fails whenever the size is greater or equal to the amount
of memory required :(
Hum nevermind that, got confused by the IDE behavior. Anway
this emplace function crashes when I call it with a very
meaningless callstack.
This works for me:
import std.conv;
class C {
int i;
this() { i = 42; }
}
unittest {
void[__traits(classInstanceSize, C)] data = void;
auto c = emplace!C(data[]);
assert(c.i == 42);
}
Re: Are D classes always garbage collected?
T emplace(T, Args...)(void[] chunk, Args args) if (is(T ==
class))
{
enforce(chunk.length >= __traits(classInstanceSize, T),
new ConvException("emplace: chunk size too small"));
...
This fails whenever the size is greater or equal to the amount
of memory required :(
Hum nevermind that, got confused by the IDE behavior. Anway
this emplace function crashes when I call it with a very
meaningless callstack.
Re: Are D classes always garbage collected?
Which returned me a nice fat null pointer.. wth? Perhaps that
should be a compile time error if you aren't supposed to use
classes..
Strange... I'm not sure what the deal is with that overload. I
meant the last one on the page (that takes a void[]).
Hum I've tried the array version but I believe it contains a
rather serious bug...
T emplace(T, Args...)(void[] chunk, Args args) if (is(T == class))
{
enforce(chunk.length >= __traits(classInstanceSize, T),
new ConvException("emplace: chunk size too small"));
...
This fails whenever the size is greater or equal to the amount of
memory required :(
Anyway I need the pointer version for what I was hoping to do,
unless there is some way to convert a pointer into an array?
Is there any way to do something like this..
void* pData = some_c_function();
void [] fakeArray = pData, size;
Re: Are D classes always garbage collected?
On Thursday, 22 December 2011 at 04:15:25 UTC, Froglegs wrote:
You can allocate classes anywhere, if you're OK with
forfeiting safety guarantees. For example, see emplace in
std.conv:
http://dlang.org/phobos/std_conv.html#emplace
Hum calling emplace ending up calling this bit of code..
T* emplace(T)(T* chunk)
if (is(T == class))
{
*chunk = null;
return chunk;
}
Which returned me a nice fat null pointer.. wth? Perhaps that
should be a compile time error if you aren't supposed to use
classes..
Strange... I'm not sure what the deal is with that overload. I
meant the last one on the page (that takes a void[]).
I tried placement new syntax but this tells me I need an
allocator, whatever that means..
http://www.d-programming-language.org/memory.html#newdelete
Note that this feature is on its way to be deprecated. emplace
and clear are the future-proof method.
Re: Are D classes always garbage collected?
You can allocate classes anywhere, if you're OK with
forfeiting safety guarantees. For example, see emplace in
std.conv:
http://dlang.org/phobos/std_conv.html#emplace
Hum calling emplace ending up calling this bit of code..
T* emplace(T)(T* chunk)
if (is(T == class))
{
*chunk = null;
return chunk;
}
Which returned me a nice fat null pointer.. wth? Perhaps that
should be a compile time error if you aren't supposed to use
classes..
I tried placement new syntax but this tells me I need an
allocator, whatever that means..
I swear D is google proof sigh
Re: Are D classes always garbage collected?
You can allocate classes anywhere, if you're OK with forfeiting safety guarantees. For example, see emplace in std.conv: http://dlang.org/phobos/std_conv.html#emplace Ah thanks Value type polymorphism has shown to be problematic. One notable problem is object slicing: http://en.wikipedia.org/wiki/Object_slicing I see... seems like a pretty weak reason, I've never found that to be an issue in C++ as it is exactly what I'd expect to happen if I did something like that. I *think* the language allows implementing something akin to value type polymorphism (sans syntax sugar), but currently the required compiler features (alias this, compile-time symbol/address evaluation) are not implemented well-enough to test my idea. Ah, faking it, hopefully that works out someday :)
Re: Are D classes always garbage collected?
On Thursday, 22 December 2011 at 02:29:10 UTC, Froglegs wrote: From what I understand D classes are reference types, which would imply to me that they are either always garbage collected or rather less likely, reference counting. They are garbage-collected. Which is fine and all, but since structs don't support virtual functions, doesn't this pretty much force you to use classes and therefor GC if you want virtual functions? You can allocate classes anywhere, if you're OK with forfeiting safety guarantees. For example, see emplace in std.conv: http://dlang.org/phobos/std_conv.html#emplace So why don't structs support virtual funtions? I would like to have a type that is not GC'd or ref counted or any other nonsense, but supports virtual functions.. Value type polymorphism has shown to be problematic. One notable problem is object slicing: http://en.wikipedia.org/wiki/Object_slicing Am I missing something here? Thanks I *think* the language allows implementing something akin to value type polymorphism (sans syntax sugar), but currently the required compiler features (alias this, compile-time symbol/address evaluation) are not implemented well-enough to test my idea.
