I just wonder if there's such a thing as POD type in D? I have failed to find one. The extern(C) struct seems not to be the thing because it is hardwired to the ABI.

Aleksey S. Skidan wrote:
> I just wonder if there's such a thing as POD type in D? I have failed to find
> one. The extern(C) struct seems not to be the thing because it is hardwired to
> the ABI.

Basic types and structs are POD (plain old data).
Unless you're referring to a different kind of POD.

== Quote from Hasan Aljudy (hasan.aljudy@gmail.com)'s article
> Aleksey S. Skidan wrote:
> > I just wonder if there's such a thing as POD type in D? I have failed to find one. The extern(C) struct seems not to be the thing because it is hardwired to the ABI.
> Basic types and structs are POD (plain old data).
> Unless you're referring to a different kind of POD.

Great thanks, but I do know what POD is. But unfortunately D's structs are not POD types. They depend on TypeInfo. For ex.:

module blah;
struct Foo{ int a; }
static Foo bar = { 3; };

Then
$ dmd -c blah.d
$ objdump -t blah.o

And you'll see a section named like .gnu.linkonce.d.*__initZ that contains the bar. But this section contains a reference to TypeInfo object for the Foo.

Aleksey S. Skidan wrote:

> I just wonder if there's such a thing as POD type in D? I have failed to find one. The extern(C) struct seems not to be the thing because it is hardwired to the ABI.

http://www.digitalmars.com/d/glossary.html#pod

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi

Aleksey S. Skidan wrote:
> == Quote from Hasan Aljudy (hasan.aljudy@gmail.com)'s article
>> Aleksey S. Skidan wrote:
>>> I just wonder if there's such a thing as POD type in D? I have failed to find
>>> one. The extern(C) struct seems not to be the thing because it is hardwired to
>>> the ABI.
>> Basic types and structs are POD (plain old data).
>> Unless you're referring to a different kind of POD.
> 
> Great thanks, but I do know what POD is. But unfortunately D's structs are not POD
> types. They depend on TypeInfo. For ex.:
> 
> module blah;
> struct Foo{ int a; }
> static Foo bar = { 3; };
> 
> Then
> $ dmd -c blah.d
> $ objdump -t blah.o
> 
> And you'll see a section named like .gnu.linkonce.d.*__initZ that contains the
> bar. But this section contains a reference to TypeInfo object for the Foo.

Sure, but the TypeInfo doesn't affect the size or layout of Foo.


Sean

Aleksey S. Skidan wrote:
> But unfortunately D's structs are not POD
> types. They depend on TypeInfo. For ex.:
> 
> module blah;
> struct Foo{ int a; }
> static Foo bar = { 3; };
> 
> Then
> $ dmd -c blah.d
> $ objdump -t blah.o
> 
> And you'll see a section named like .gnu.linkonce.d.*__initZ that contains the
> bar. But this section contains a reference to TypeInfo object for the Foo.

So? That doesn't have anything to do with POD-ness.

[after removing the extra ; in the initializer]
Actually, I don't see any such thing in my object file:

--------------------

$ objdump -sr test.o	# show relocation records and section contents

test.o:     file format elf32-i386

RELOCATION RECORDS FOR [.text]: (none)

RELOCATION RECORDS FOR [.data]: (none)

RELOCATION RECORDS FOR [.gnu.linkonce.d._D19TypeInfo_S4blah3Foo6__initZ]:
OFFSET   TYPE              VALUE
00000000 R_386_32          _D15TypeInfo_Struct6__vtblZ
0000000c R_386_32          .rodata


Contents of section .data:
 0000 03000000                             ....
Contents of section .rodata:
 0000 626c6168 2e466f6f 00000000 00000000  blah.Foo........
Contents of section .gnu.linkonce.d._D19TypeInfo_S4blah3Foo6__initZ:
 0000 00000000 00000000 08000000 00000000  ................
 0010 04000000 00000000 00000000 00000000  ................
 0020 00000000 00000000                    ........

--------------------

I don't see any special section for 'bar' at all (unless you count .data, which happens to only contain 'bar', already initialized to 3).
The only references to TypeInfo I see are the TypeInfo for Foo (not bar) and a relocation record that fills in the vtable pointer for TypeInfo_Struct.
The TypeInfo is probably emitted in this object file to avoid having to potentially emit it everywhere it's used. If nothing actually uses it in this program, the linker should be able to throw it out. IIRC optlink does this automatically on Windows, but on Linux you need to pass -L--gc-sections to DMD to get ld to do this.

What it's all about is that I wanted to port my kernel from C++ into D. With C++ it's an easy task. Just turn off ABI-dependent stuff. With D it's not that story. I can't turn off RTTI for ex. Thus I can't compile my kernel not implementing object.d from ABI. And that's not good. I don't want to have extra needless data in my data section. The data I will never use!

Aleksey S. Skidan wrote:
> What it's all about is that I wanted to port my kernel from C++ into D. With C++
> it's an easy task. Just turn off ABI-dependent stuff. With D it's not that story.
> I can't turn off RTTI for ex. Thus I can't compile my kernel not implementing
> object.d from ABI. And that's not good. I don't want to have extra needless data
> in my data section. The data I will never use!

As I've said before, object.d isn't hard to port. The version for my kernel has minimal modifications.

If you're using ld, just pass --gc-sections on the command line to remove unreferenced data and code[1]...


[1]: Caveat: you may need to modify your linker script to use KEEP() around sections containing any multiboot headers or other things not referenced directly from the code, to make sure they don't get thrown away.
That includes .ctor* and .dtor* sections, if you use static this(), static ~this() or unittest{} blocks in your code and expect the ModuleInfo linked list with their info to be built like in Phobos on Linux.

== Quote from Frits van Bommel (fvbommel@REMwOVExCAPSs.nl)'s article
> Aleksey S. Skidan wrote:
> > What it's all about is that I wanted to port my kernel from C++ into D. With C++ it's an easy task. Just turn off ABI-dependent stuff. With D it's not that story. I can't turn off RTTI for ex. Thus I can't compile my kernel not implementing object.d from ABI. And that's not good. I don't want to have extra needless data in my data section. The data I will never use!
> As I've said before, object.d isn't hard to port. The version for my
> kernel has minimal modifications.
> If you're using ld, just pass --gc-sections on the command line to
> remove unreferenced data and code[1]...
> [1]: Caveat: you may need to modify your linker script to use KEEP()
> around sections containing any multiboot headers or other things not
> referenced directly from the code, to make sure they don't get thrown away.
> That includes .ctor* and .dtor* sections, if you use static this(),
> static ~this() or unittest{} blocks in your code and expect the
> ModuleInfo linked list with their info to be built like in Phobos on Linux.


Great thanks I'll try it. Though IMHO it's not a convinient way (more C-lysh is
more convinient as for me [the KISS rule]).
But as the language is young...

I am learning D and reading the Kindle spec. It says:

"In C++ parlance, a D struct is a POD (Plain Old Data) type" with
a trivial constructors and destructors".

<POD (Plain Old Data)> is a link. Clinking on it leads to this
definition at dlang.org:

"Refers to a struct that contains no hidden members, does not
have virtual functions, does not inherit, has no destructor, and
can be initialized and copied via simple bit copies. D structs
are POD."

The definition says no destructor and no hidden members. Whereas
above it says that a D struct has a (trivial) destructors.

And below that in the spec there is a table which has a row for
"hidden members". It shows that a D struct has hidden members.

Not a major issue of course, but I am just wondering why the
definition of POD says "no destructor" and "no hidden members"
whereas a D struct has both and is referred to as POD.