www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - POD

reply Aleksey S. Skidan <al.skidan gmail.com> writes:
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.
Dec 29 2006
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
Dec 29 2006
parent reply Aleksey S. Skidan <al.skidan gmail.com> writes:
== 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.

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.
Dec 29 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
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.

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
Dec 29 2006
prev sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.
Dec 29 2006
parent reply Aleksey S. Skidan <al.skidan gmail.com> writes:
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!
Dec 29 2006
parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.
Dec 29 2006
parent Aleksey S. Skidan <al.skidan gmail.com> writes:
== 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!

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...
Dec 29 2006
prev sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
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
Dec 29 2006