Entt: Trouble with Visual Studio 2017 debug mode.

[DJuego]

Hi! Thank you for EnTT. I want to notify this.

OS: Windows 10 x64

I have build successfully your library and the Code Example with MinGW Builds. And i get:

single component view
0,0
1,1
2,2
3,3
4,4
5,5
6,6
7,7
8,8
9,9
multi component view
0,0 - 0,0
2,2 - 0.2,0.2
4,4 - 0.4,0.4
6,6 - 0.6,0.6
8,8 - 0.8,0.8
single component view
9,9
1,1
2,2
3,3
7,7
5,5
6,6
multi component view

Process returned 0 (0x0)   execution time : 0.016 s
Press any key to continue.

Too I have build successfully your library and the Code Example with Visual Studio 2017. And i get the same result in release mode. However when i run in debug mode an exception is thrown:

    for (auto entity : ecs.view<Position, Velocity>()) {

The exception is produced in vector file "c:Program Files (x86)Microsoft Visual Studio2017EnterpriseVCToolsMSVC14.10.25017includevector"

 #if _ITERATOR_DEBUG_LEVEL == 2
    void _Compat(const _Myiter& _Right) const
        {   // test for compatible iterator pair
        if (this->_Getcont() != _Right._Getcont())
            {
            _DEBUG_ERROR("vector iterators incompatible"); <-----HERE
            }
        }

Thanks again!

DJuego

[skypjack]

Interesting indeed. I don't have Visual Studio 2017, so I cannot reproduce it right now.
If you have any clue of what's the reason, we can manage to arrange a test on appveyor and _fix_ it (even though it doesn't look like a bug in EnTT, so I'm not sure _fix_ is the right term to use here).

Just out of curiosity, I'm pushing an updated version of EnTT with improved performance and more features in a few minutes.
Can you try it to see if the problem persists?

[DJuego]

It is a pleasure for me to try to help you.

I have updated EnTT and the new Code Example. It's build successfully in MinGW (gcc 7.1.0).
However In Visual Studio 2017 i get:

1>------ Build started: Project: prueba00_msvc2017, Configuration: Debug x64 ------
1>main.cpp
1>p:\mis-proyectos\personal\prueba00\inc\entt\src\registry.hpp(192): error C2059: syntax error: 'template'
1>p:\mis-proyectos\personal\prueba00\inc\entt\src\registry.hpp(444): note: see reference to class template instantiation 'entt::Registry<Entity,Component...>' being compiled
1>p:\mis-proyectos\personal\prueba00\inc\entt\src\registry.hpp(192): error C2947: expecting '>' to terminate template-argument-list, found '<'
1>p:\mis-proyectos\personal\prueba00\inc\entt\src\registry.hpp(192): error C2061: syntax error: identifier 'Comp'
1>p:\mis-proyectos\personal\prueba00\inc\entt\src\registry.hpp(194): error C2334: unexpected token(s) preceding ':'; skipping apparent function body
1>p:\mis-proyectos\personal\prueba00\inc\entt\src\registry.hpp(16): fatal error C1075: the left brace '{' was unmatched at the end of the file
1>Done building project "prueba00_msvc2017.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

[skypjack]

Is this line that makes VS crazy?

template<typename... Comp> using view_type = View<pool_type, ident<Component...>.template get<Comp>()...>;

It looks like it fails to parse a call made to a dependent name when it's part of an actual template parameter for a class template. They'll never ship a decent compiler with that IDE, this is a fact.

I'll try to reproduce the error on appveyor, so that I can look for alternative syntaxes to put in an #if/#else for VS. :-)
If you manage to solve it, any help is appreciated.

[skypjack]

I've just reproduced the error on appveyor - https://ci.appveyor.com/project/skypjack/entt
Let's try to work around it somehow. I don't think they will fix their compiler any time soon.

---

EDIT

Ok, the previous error is gone. Now the following makes it crazy:

template<typename... Comp>
using view_type = View<pool_type, identifier<Comp>...>;

error C3546: '...': there are no parameter packs available to expand

Pretty hard to explain to VS2017 that Comp is the parameter pack...

[DJuego]

Thank you very much for your successive efforts! I feel especially grateful that you find the will to face a compiler that you do not use and you find it unfriendly. And that you could easily ignore.

I think it is interesting to remark that visual studio 2017 is widely used in video game development. And video game development is a target field for ECS. So i believe that the effort pays off.

Sadly i am not an advanced cpp programmer and I do not feel able to contribute. :-(
but I will be aware of any newness in the issue and i will retest it. Thanks again!

DJuego

[skypjack]

Upstream is a working version now. Can you test the master once more?
It works fine on appveyor with MSVC 2017, so I'm pretty confident.

Thank you for your help. Really appreciated.

Feel free to open issues whenever you find a problem.
I usually do my best to work on them and provide working solutions.

[DJuego]

@skypjack, It works like a charm!! Fantastic! You can close this issue with pride :-)

DJuego

PS: And thanks for your 'crash' course. :+1

[skypjack]

@DJuego

I've added also a few features in the last version. Suggestions for some others are welcome.
Just out of curiosity, are you using it in a real project? I hope you like it, I spent a while on the interface...

[DJuego]

Well @skypjack . Sincerely, I do not yet have enough skill about ECS to judge your work with any deep or make suggestions.

However i can say i like your work. I like your emphasis on performance and simplicity. It is critical for me that offers support for the main c++ compilers (gcc, clang, msvc). Header-only is an important bonus for me too.

The EnTT interface seems clean and well thought out. However one of the main values is your fast and selfless support. :+1

Perhaps I miss more documentation and samples, but it is better documented than many others.

I have not yet integrated it into a real project but I firmly intend to use it in the real world and put it to the test and then we will know the truth. I'll keep you informed. ;-)

I want more users to know it. So EnTT will stay alive and without bugs. And there will be motivation to add more amazing features.

DJuego

PS; Sorry for my English

[skypjack]

@DJuego Don't worry. You're English is fine. I'm not a native speaker. At the end of the day the goal is to get each other and we did it, so... ;-)

Performance are pretty important for me, you're right. Anyway I spent a lot of time designing an API that was both complete and easy to use. Who knows if I succeeded. Time will say.

Support other developers is... Well, interesting at least.
I'm fond of the game industry, but I don't have the chance to work in it right now. Probably it won't happen any time soon. Because of that I'm trying to offer indies and whoever is interested a few tools like EnTT to fill the gap.

Documentation and samples.
I hope the _crash course_ is good enough to document EnTT. Feel free to make any suggestion to improve it.
Samples are coming (sooner or later, I've another time consuming task called _son_ and it's far more important than everything else). The idea is to create another repo and use EnTT to _discuss_ about ECS in general. More details will come, I'm pretty sure you'll like it.

EnTT will stay alive for a while at least, don't worry.
The long term plan is to add a set of tools to help with event handling, resource management and so on.
I'm working also on a minimal 2D game (a POC more than anything else) based on SDL2 to show how to use all that stuff together. Unfortunately it will take a while because my free time isn't that much... :-(

That being said, I hope more users will use EnTT, of course.
I'll look forward for your feedbacks when you used EnTT in a real world project!! ;-)

Thanks for your help and support.

[skypjack]

@DJuego Just out of curiosity, a question about a possible change in the API. I'm interested in your opinion.

What about if you didn't have to declare components anymore when you declarare the registry?
In other terms, today you have this:

Registry<Position, Velocity> registry;
// ...
auto entity = registry.create<Velocity>();
// ...

It would become:

Registry registry;
// ...
auto entity = registry.create<Velocity>();
// ...

Main difference is in compilation time for large projects. Anyway it's also quite annoying for me to declare everything at compile-time and this would remove the burden.
Price to pay is that assign is slightly slower for it must check if the pool for the given component exists and create it otherwise.

Your thoughts?

[dbacchet]

@skypjack, @DJuego, sorry if I sneak into this thread.
the API change that you're proposing makes __a lot__ of sense. I'm using EnTT in a decently big simulation environment, and the compilation time overhead due to the current template structure is already pretty big (a few seconds per file, I have 20+ components). And the number of components will grow quite a bit in the next future.

On the general API, I really like it. It's consistent and does not introduce unnecessary abstractions.

[skypjack]

@dbacchet You're welcome and sorry if I didn't keep in touch with you too to ask your opinion!! Good to know you are usingEnTT and you like the feature.
Probably I should create a dedicated discussion issue to discuss about upcoming changes, so that I can concentrate all the feedbacks in the same place.
I'll do it today. Stay tuned and give me your suggestions, please. They are really precious for me!! ;-)

[skypjack]

@dbacchet @DJuego See #13 for a discussion about upcoming changes. Thank you.