Uninitialized members and Typeinfo

[duzenko]

@stgatilovCan we fix typeinfo? How do we point it to the right path for this .hpp?

[stgatilov]

1 hour ago, duzenko said:

@stgatilovCan we fix typeinfo? How do we point it to the right path for this .hpp?

Well, in principle we can.
There is some macro which is defined only by typeinfo compiler, and we can ifdef by it.
Of course, typeinfo cannot and should not parse third-party libs.

However, the first question is: what are you trying to achieve?

[duzenko]

26 minutes ago, stgatilov said:

However, the first question is: what are you trying to achieve?

Sorry, I should have started with that

I'm puzzled by these warnings in the xray test map. I'd like to see if the typeinfo lib could be used to debug this

[stgatilov]

11 minutes ago, duzenko said:

Sorry, I should have started with that

I'm puzzled by these warnings in the xray test map. I'd like to see if the typeinfo lib could be used to debug this

Oh yeah, that's not good...

Yes, you can use typeinfo lib to see member names, but it will by no means be easy. You will have to surround bad includes with #ifdef smth, replace all #pragma once with old-style include guard, do something with override (e.g. add #define override {empty} as predefined macro under typeinfo), add private: if some members are implicitly private... that's what I remember.

A somewhat cumbersome approach but easier to boot would be to put breakpoint to where this message is printed, then find manually in the debugger which member this offset corresponds to. I.e. binary search by class members in their order... maybe using offsetof macro (if debugger supports it).

[duzenko]

1 minute ago, stgatilov said:

 

A somewhat cumbersome approach but easier to boot would be to put breakpoint to where this message is printed, then find manually in the debugger which member this offset corresponds to. I.e. binary search by class members in their order... maybe using offsetof macro (if debugger supports it).

Umm... can it be automated by something like

for(auto& property: typeinfo::getPropertiesFor(this)) {

     if (offsetof(property) == missingPropOffset) {
		...
     }

}

Quote

Oh yeah, that's not good...

Yes, you can use typeinfo lib to see member names, but it will by no means by easy. You will have to surround bad includes with #ifdef smth, replace all #pragma once with old-style include guard, do something with override (e.g. add #define override {empty} as predefined macro under typeinfo), add private: if some members are implicitly private... that's what I remember.

Sounds like a PhD course work

[stgatilov]

11 minutes ago, duzenko said:

Umm... can it be automated by something like

for(auto& property: typeinfo::getPropertiesFor(this)) {

     if (offsetof(property) == missingPropOffset) {
		...
     }

}

Yes, if you have static reflection.
Did reflection got into C++20 already?

Quote

Sounds like a PhD course work

Yeah, it is a lot of fun, but only if you really looking for this kind of fun

[duzenko]

2 minutes ago, stgatilov said:

Yes, if you have static reflection.
Did reflection got into C++20 already?

What about our "basic" RTTI? Isn't that separate to typeinfo.lib? I am completely clueless, but the wiki says typeinfo.lib is only needed for memory logs, which kinda implies RTTI is something different?

[stgatilov]

7 hours ago, duzenko said:

What about our "basic" RTTI? Isn't that separate to typeinfo.lib? I am completely clueless, but the wiki says typeinfo.lib is only needed for memory logs, which kinda implies RTTI is something different?

The warnings that you look at are the memory log. Typeinfo is needed to associate member names to offsets.
The C++ RTTI only includes class names, inheritances, virtual methods (see reference).

[duzenko]

Another attempt at running typeinfo.exe

Fails with

Type Info Generator v1.0 (c) 2004 id Software
../darkmod_src/game
processing 'C:\Users\a\Documents\tdm\darkmod\..\darkmod_src\game\gamesys\TypeInfo_GenHelper.cpp' for type info...
ERROR: file ../darkmod_src/idlib\sys/sys_defines.h, line 148: #error without string

at this line

It does not matter if I define WIN32 in generator's own define list. It seems that it always executes compiler directives, even if they are disabled by an outer ifdef. Is typeinfo so hopelessly broken it cannot be used without major overhaul?

[duzenko]

Tried to suppress directive error

Next stop in idStr.h

Fails to evaluate

const int STR_ALLOC_BASE            = 32 - 8 - sizeof(char*);

because sizeof and char are not valid integers.

Makes you wonder in what year it was last run successfully

[duzenko]

After some history digging, it seems that it did not work as early as 2.0 work began, because idHashTable has a GNUC ifdef added around svn rev ~900 that typeinfo can't handle

[stgatilov]

6 hours ago, duzenko said:

After some history digging, it seems that it did not work as early as 2.0 work began, because idHashTable has a GNUC ifdef added around svn rev ~900 that typeinfo can't handle

The wiki page says when it was working. It was later than 2.00.

[duzenko]

You mean you were able to run it locally with a bunch of changes but never commited those changes to svn?

[duzenko]

Works in D3, but not in any TDM versions I have tried so far

[stgatilov]

8 hours ago, duzenko said:

You mean you were able to run it locally with a bunch of changes but never commited those changes to svn?

No, I committed all the changes to SVN at that time.
But typeinfo parser is very fragile. I'm sure it quickly broke after that due to normal development.

[duzenko]

Yes, it did work in June 2017

There's a number of things that broke since then, the ones I noticed so far

• #error
• include tracy
• sizeof(char) in const declaration

Fixed the first two, but the third is a tough one

[duzenko]

Hmm, I worked around a few more issues and it now seems to produce something

Not sure if my fixes make enough sense to you?

Svn 9711

 

[stgatilov]

9 hours ago, duzenko said:

Not sure if my fixes make enough sense to you?

Yes, except for silencing #error directive.

[duzenko]

8 minutes ago, stgatilov said:

Yes, except for silencing #error directive.

How should it be handled ideally?

[stgatilov]

44 minutes ago, duzenko said:

How should it be handled ideally?

By #ifdef-ing by ID_TYPEINFO.

I have committed a fixed version.
It turned out your problem was mainly due to ID_TYPEINFO being defined when building TypeInfo C++ code.

I committed fixed version.

[stgatilov]

Anyway, the generated typeinfo is wrong.

If you try to compile TDM with it, you'll get a lot of errors.
Most of the are due to not understanding C++11, and it is not wise to eradicate C++11 from headers or trying to #ifdef every little thing.

[duzenko]

1 hour ago, stgatilov said:

Anyway, the generated typeinfo is wrong.

If you try to compile TDM with it, you'll get a lot of errors.
Most of the are due to not understanding C++11, and it is not wise to eradicate C++11 from headers or trying to #ifdef every little thing.

I have put a few more fixes and cut some corners

Revision 9713 seems to work

I am particularly puzzled about the define private public trick, that I had to disable to make the modern compiler happy.

[duzenko]

It seems that all "uninitialized members" are in fact paddings added for complex members like structs or template parameters

It's easy enough to filter when dealing with simple types, but templates aren't supported by TypeInfo and will have to be assumed always ok.

[duzenko]

What is more important, how to prevent the uninitialized spam in the console for regular - no type info - builds?

[stgatilov]

Yes, padding is a problem.

One possible thing is to check every 8 bytes instead of 4 bytes: I guess it is already done like that in 64-bit builds. Of course, it allows the check to miss uninitialized members, but I don't think there is a way around it.