Not compiling using Intel 16.0 (with Visual Studio 2013) about visit_struct HOT 10 CLOSED

Hi,

I didn't test with that compiler, I could attempt it by pasting test code into godbolt or something similar.

There is a standing pull request which I am evaluating to change how these macros work and do something that is simpler and most likely portable. You might want to try with Jarod42's version.

Another thing you could do is try the intrusive syntax, it doesn't use this macro. It worked in MSVC 2015, I'd like to know if it works in Intel.

from visit_struct.

Hi,

thank you for your fast reply. I am evaluating using such an approach for existing header files with structs that are also used by other stakeholders that use different compilers and potentially also plain c. The intrusive approach is therefore not really an option.

I am not really a preprocessor guru, it seems that Intel compiler has problems with this part of your code:

#define VISIT_STRUCT_PP_MAP0(f, x, peek, ...) f(x) VISIT_STRUCT_PP_MAP_NEXT(peek, VISIT_STRUCT_PP_MAP1)(f, peek, VA_ARGS)
#define VISIT_STRUCT_PP_MAP1(f, x, peek, ...) f(x) VISIT_STRUCT_PP_MAP_NEXT(peek, VISIT_STRUCT_PP_MAP0)(f, peek, VA_ARGS)
#define VISIT_STRUCT_PP_MAP(f, ...) VISIT_STRUCT_PP_MAP_EVAL(VISIT_STRUCT_PP_MAP1(f, VA_ARGS, (), 0))

On the right hand side, the macros VISIT_STRUCT_PP_MAP0 and VISIT_STRUCT_PP_MAP1 have no arguments. I must admit that I also don't understand why this compiles with other compilers. Any insight?

Thanks

from visit_struct.

One of the features of C preprocessor is that sometimes a token is expanded, and sometimes its expansion is delayed. Sometimes two tokens are concatenated, and then in a later "expansion" of the current line, the concatenated name will refer to a new macro which then gets expanded there.

I don't really understand the preprocessor rules in real detail or in terms of the standard, tbh I only really understand it at an intuitive level.

I think my assumption is that the Intel 16.0 compiler with visual studio probably uses exactly the same preprocessor as MSVC, if it is trying to be interchangeable with MSVC. If you want to see details about the bug, I did report it on swansontec/map-macro, he's the guy who developed this map macro. You can also see the full bug in our appveyor build logs, I guess you could tell me if the bug you get is identical?

I guess I should mention another thing:

I am evaluating using such an approach for existing header files with structs that are also used by other stakeholders that use different compilers and potentially also plain c. The intrusive approach is therefore not really an option.

This reminds me somewhat of another library: "magic-get" or "pod-flat-reflection": https://github.com/apolukhin/magic_get

This one does some really strange voodoo that at first glance seems to contradict what I wrote in my readme. Basically it's sort of like visit_struct, but you don't have to register anything. The way it works basically is, he assumes that your struct is POD, and that it always has aggregate initialization. Then using some complex template voodoo, he's able to figure out what your struct is based on what constructors it has, which he can sort of test by brute force using SFINAE.

So the catch is that I at least would never use this in production code, because in the end there is no reflection -- he basically "guesses" what the actual layout in terms of pointer arithmetic and padding of your class will be, since he can't actually get the member pointers, he only deduces what types are there based on what constructors are there. Then he just sort of adds the correct padding values and reinterpret casts things as necessary to get the struct members. So, if you used a nonstandard compiler that doesn't do things the way he expects, you'll get a lot of UB.

But depending on what you are doing, and esp. if this is not suppose to go in like production code, but rather generate diagnostics or debug tools or something, this lib might save you a lot of time, since it removes the need to register everything.

I never actually used this magic-get thing, but I did study it, and I think in the right scenario I would use it. Hope that helps.

from visit_struct.

Thank you for the magic-get stuff hint, I will have a look at it. But it definitely goes into product code. The reflection feature would be used only in non-product manner, but since the headers are used in production code it depends how both parts can be separated (I don't want to have any of this pseudo-reflection-stuff into production code). POD-iness can be easily tested with C++11 std::is_pod, perhaps this is sufficient.

from visit_struct.

Remark on https://github.com/apolukhin/magic_get:
It requires C++14 compiler and (as far as I understand looking at the examples) does not support variable names.

from visit_struct.

Yeah, if you need variable names then that's not what you want.

I merged this change I mentioned, it should hopefully be working for you. At least, appveyor build seems to be working. I don't know if appveyor can be used to test intel compiler, I might look into it.

from visit_struct.

Hi thanks! The new macro-code is ugly like hell BUT WORKS LIKE A CHARM! And still it is a very small file!. In a first test with Intel 16.0 in Visual Studio under Windows 7 it compiles and works well. Perfect!

Write access:
One question: how can I write to the struct? I used a visitor with
void operator()(const char * name, TYPE& i)
{
m_pVar=&i;
}
But I get an error that no overload of operator() matches the Argument list. Any idea? (With 'TYPE' instead of 'TYPE&' it worked...)

from visit_struct.

The new macro-code is ugly like hell BUT WORKS LIKE A CHARM!

Sounds about right 🎉

But I get an error that no overload of operator() matches the Argument list. Any idea?

Can you post an MCVE?

from visit_struct.

I found the problem. In short: IT IS NOT IN YOUR CODE.

Since I used nested templated stuff using std::tuple, it was quite difficult to find it. I implemented a visitor with functions for each basic integer type: uint8_t, int8_t, uint16_t, int16_t, uint32_t, int32_t, uint64_t, int64_t. First the member was transfered as a parameter copied by value. Your visit_struct worked without problems. Then I replaced it by a reference, because I wanted to have write access to the struct member. Then there was this strance compiler error. Finally I discovered the reason: for the compiler the type "long" (also used in some parts of our code) is a NINETH integer type in addition to the eight types mentioned above! When giving the parameter by copy, there was apparently an implicit type conversion and the code compiled. With the reference it did not. With an extra overload in the visitor for Long it works again.

from visit_struct.

Interesting, I never encountered that. I think on clang and gcc, long is always the same as one of those types.

from visit_struct.