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.

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?

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..

Am I missing something here? Thanks

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.

> 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 :)

>> 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

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.

>> 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;

> 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.

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);
}

On Wed, Dec 21, 2011 at 10:20 PM, Froglegs <lugtug@gmail.com> 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.

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