Author Topic: Thor C++ Library – An SFML extension (Read 127725 times)

CJ_COIMBRA · « **Reply #30 on:** June 09, 2011, 09:58:45 pm »

Time and Event topics will be very helpfull for me!
Is it complete already?

Nexus · « **Reply #31 on:** June 09, 2011, 10:05:42 pm »

Quote from: "CJ_COIMBRA"

Is it complete already?

What do you mean? There is already a usable version 1.0, but of course there is always room for improvement

In fact, I suggest to use the SVN version to make use of newer features, improvements and adaptions to SFML. For example, the sf::Clock interface has recently changed, and the Time module of Thor's SVN version has been adapted to it (unlike Thor 1.0, which was released before).

Beliar · « **Reply #32 on:** June 11, 2011, 10:45:11 am »

The Library seems nice, it would be much better though if it wouldn't clutter me with warnings just by including headers from it:

Code: [Select]

Thor\Detail\MovedPtr.inl||In function 'bool thor::operator==(const thor::MovedPtr<T, OwnershipPolicy>&, const thor::MovedPtr<T, OwnershipPolicy>&)':|
Thor\Detail\MovedPtr.inl|153|warning: no return statement in function returning non-void|
Thor\Detail\MovedPtr.inl||In function 'bool thor::operator!=(const thor::MovedPtr<T, OwnershipPolicy>&, const thor::MovedPtr<T, OwnershipPolicy>&)':|
Thor\Detail\MovedPtr.inl|161|warning: no return statement in function returning non-void|
Thor\Detail\MovedPtr.inl||In function 'bool thor::operator==(const thor::MovedPtr<T, OwnershipPolicy>&, const thor::MovedPtr<T, OwnershipPolicy>&)':|
Thor\Detail\MovedPtr.inl|153|warning: no return statement in function returning non-void|
Thor\Detail\MovedPtr.inl||In function 'bool thor::operator!=(const thor::MovedPtr<T, OwnershipPolicy>&, const thor::MovedPtr<T, OwnershipPolicy>&)':|
Thor\Detail\MovedPtr.inl|161|warning: no return statement in function returning non-void|
Thor\Detail\SmartPtrImpl.inl||In function 'void thor::detail::ForwardDestroy(T*) [with T = thor::detail::ResourceSlot<sf::Image, thor::Resources::ImageKey>, U = thor::detail::ResourceSlot<sf::Image, thor::Resources::ImageKey>, OwnershipPolicy = thor::NoCopy]':|
Thor\Detail\SmartPtrImpl.inl:148|53|instantiated from 'thor::detail::SmartPtrImpl<T, OwnershipPolicy>::SmartPtrImpl(U*) [with U = thor::detail::ResourceSlot<sf::Image, thor::Resources::ImageKey>, T = thor::detail::ResourceSlot<sf::Image, thor::Resources::ImageKey>, OwnershipPolicy = thor::NoCopy]'|
Thor\Detail\MovedPtr.inl:38|16|instantiated from 'thor::MovedPtr<T, OwnershipPolicy>::MovedPtr(U*) [with U = thor::detail::ResourceSlot<sf::Image, thor::Resources::ImageKey>, T = thor::detail::ResourceSlot<sf::Image, thor::Resources::ImageKey>, OwnershipPolicy = thor::NoCopy]'|
Thor\Detail\ResourceManager.inl:132|102|instantiated from 'thor::ResourcePtr<Resource> thor::ResourceManager<Resource, ResourceKey>::AddResource(thor::ResourceManager<Resource, ResourceKey>::SlotIterator, const ResourceKey&) [with Resource = sf::Image, ResourceKey = thor::Resources::ImageKey, thor::ResourceManager<Resource, ResourceKey>::SlotIterator = std::_Rb_tree_iterator<std::pair<const thor::Resources::ImageKey, thor::detail::ResourceSlot<sf::Image, thor::Resources::ImageKey>*> >]'|
Thor\Detail\ResourceManager.inl:76|30|instantiated from 'thor::ResourcePtr<Resource> thor::ResourceManager<Resource, ResourceKey>::Acquire(const ResourceKey&) [with Resource = sf::Image, ResourceKey = thor::Resources::ImageKey]'|
Thor\Detail\SmartPtrImpl.inl|63|warning: statement has no effect|

(MinGW-GCC 4.5.0)

And, no, I won't disable warnings on my side.

[edit]
Well, I found a solution on my side, but I still dislike warnings in third-party header files.
[/edit]

lakunar · « **Reply #33 on:** June 11, 2011, 10:55:33 am »

Realy nice Nexus!

Thanks

But:
1. I think you use a outdatet version of mingw (current gcc version: 4.5) (but who cares

)

2. I tried the particles demo and it works, but in debug mode i get an error but the app ist not crashing.

Debug: http://projectbase.pr.funpic.de/ThorDebug.JPG (even the sf:text looks :?)
Release: http://projectbase.pr.funpic.de/ThorRelease.JPG

3. And in both cases the app crashes on exit.
[Edit]
3. Fixed, Ah it was the ati bug with dynamic linking but the debug error still exists
[/Edit]

@Beliar:
Get them too
But they are fixed easily

Nexus · « **Reply #34 on:** June 11, 2011, 12:24:56 pm »

Quote from: "Beliar"

The Library seems nice, it would be much better though if it wouldn't clutter me with warnings just by including headers from it:

Thanks. I try to get rid of the warnings as soon as possible. What flags did you use to compile? I couldn't reproduce all warnings with -Wall -Wextra...

The smart pointer comparison operators are actually forbidden, they just exist to avoid the implicit conversion to safe-bool. g++ behaves strangely in this way, I was already forced to modify the static assertion to depend on the template parameter in order to compile. According to how I know the C++ standard, templates aren't defined before their instantiation, so this should actually work.

Quote from: "lakunar"

I think you use a outdatet version of mingw (current gcc version: 4.5)

Yes, it was up-to-date some time ago

Now I have updated it.

Quote from: "lakunar"

2. I tried the particles demo and it works, but in debug mode i get an error but the app ist not crashing.

Which Thor version and which compiler/OS do you use? Does the SFML OpenGL example work?

I just compiled the debug version of Thor (SVN revision 19) with MingW (g++ 4.5.2) and static linkage, and everything worked fine.

lakunar · « **Reply #35 on:** June 11, 2011, 01:04:50 pm »

Thor: 1.0 (not precompiled ) (maybe i should try the svn version)
Sfml: The recommended one (from the Thor website)
OS: Win7 64bit
Compiler: MingW (g++ 4.5.1) ( :oops: )

SFML Opengl example works with dynamic linkage.
with static linkage i get a bunch of undefined reference errors, and i don't know what to link to

if i try to static linkage thor i get some undefined references to:

Code: [Select]

glOrtho@48
glTranslatef@12
glTranslatef@12
glRotatef@16
glTranslatef@12
glColor4ub@16
glTranslatef@12
glRotatef@16

And right now I link to libopengl32 and libglu32

Nexus · « **Reply #36 on:** June 11, 2011, 01:52:38 pm »

Quote from: "lakunar"

Thor: 1.0 (not precompiled ) (maybe i should try the svn version)

Yes, I recommend it. Static linkage with MinGW works in the meantime. In version 1.0 I accidentally had a wrong library dependency order (and didn't know that g++ would care about it, because MSVC++ does not).

About your particle problem: I have tried many configurations with 1.0 and the SVN version, even linking Thor (Debug) with SFML (Release), and in none of them I could reproduce this problem. Try to upgrade to a recent SFML and Thor revision and make sure there are no relicts of older versions that might lead to conflicts. If the error persists, could you try to find out where that OpenGL underflow happens?

lakunar · « **Reply #37 on:** June 11, 2011, 03:42:04 pm »

Shame on me

Made the same mistake: wrong library dependency order

Now everything works
Thanks

Beliar · « **Reply #38 on:** June 11, 2011, 05:01:31 pm »

Quote from: "Nexus"

[...]
What flags did you use to compile? I couldn't reproduce all warnings with -Wall -Wextra...

I am using CodeBlocks, but as far as I can see, its only -Wall.

Nexus · « **Reply #39 on:** June 11, 2011, 06:23:20 pm »

I hope I have removed them all

Laurent · « **Reply #40 on:** June 11, 2011, 06:49:29 pm »

Quote

g++ behaves strangely in this way, I was already forced to modify the static assertion to depend on the template parameter in order to compile. According to how I know the C++ standard, templates aren't defined before their instantiation, so this should actually work.

gcc performs a syntax check on templates when they are first seen (not instanciated), I think this is called "two-phase template lookup", and it is specified by the standard.
So it already checks/resolves all the code that doesn't depend on a template parameter, before instanciating the template.

Nexus · « **Reply #41 on:** June 11, 2011, 07:24:36 pm »

That is true, but g++ performs checks far beyond syntax, which I thought was not allowed. But you are probably right, I have just read Boost.StaticAssert and they mention exactly this problem. Interestingly, the Boost people also use exactly the same workaround

During the development of Thor, I have come across other situations where some compilers apply template rules in a wrong way. MSVC++ isn't strict about missing typename, and g++ probably misinterprets this code (its output is twice "T").

Code: [Select]

#include <iostream> 

template <typename T> 
void Func(T) 
{ 
    std::cout << "T" << std::endl; 
} 

template <typename T> 
void Use() 
{ 
    Func(T()); 
} 

void Func(int) 
{ 
    std::cout << "int" << std::endl; 
} 

int main() 
{ 
    Use<double>(); 
    Use<int>(); 
}

Laurent · « **Reply #42 on:** June 11, 2011, 07:45:10 pm »

Which version of gcc do you use?

Nexus · « **Reply #43 on:** June 11, 2011, 07:47:38 pm »

g++ 4.5.2 (with MinGW)

lakunar · « **Reply #44 on:** June 11, 2011, 07:51:02 pm »

Quote from: "Nexus"

... its output is twice "T".

Because:

Code: [Select]

#include <iostream> 

template <typename T> 
void Func(T) 
{ 
    std::cout << "T" << std::endl; 
} 

template <typename T> 
void Use() 
{ 
    Func(T()); //AT THIS POINT 
} 

void Func(int) //it doesnt know this func so it calls the top one, by putting this before use it should work
{ 
    std::cout << "int" << std::endl; 
} 

int main() 
{ 
    Use<double>(); 
    Use<int>(); 
}

OT: Is there a reason why i can't use one Zone (thor::Emitter::ZonePtr) for two emitters(thor::TargetEmitter::Ptr)? -> Assertion fail !IsNUll() : include/Thor/Detail/SmartPtrImpl.inl, line 210