Why throw the wheel away if you already re-invented it? If the containers are taken out of the interface it would be too big a change and break all current Irrlicht applications that use them. Btw I really think that core::string > std::string.Zeuss wrote:why reinvent the wheel?
Why doesn't Irrlicht use STL?
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
I don't. It got less functionality.
And the fact that some people might depend on the core containers is one of the best example why we need to have them follow the standard, at the very least. It isn't uncommon for the Irrlicht community to see some new c++ coders come. If we teach them not to use the STL or a warped version of it, we're not making them any service. Let's be generous. Let's say they use Irrlicht for 8 years. Can you imagine trying to use the STL container in the real world of thousands of libraries out there afterward? Their perceptions will be flipped.
I also know this is a HUGE amount of work. Amongst other things because I have started to look to offer a STL friendly patch. But waiting will only make it worst and I am more than convinced that it is a bad design decision Irrlicht should do without. So here's my suggestion: A three steps plan.
-First step: Implement the STL container under Irrlicht form and have them be called instead of Irrlicht (basically, make a Irrlicht wrapper of STL) Users should have a config flag to switch between the wrapper or Irrlicht within Irrlicht itself, amongst other things because a wrapper is not always the most efficient way out there.
-Second step: Correct any non STL behavior of the core and the wrapper (which imitates the core). By then, users should start converting their application to STL already (or personal librarie, if the STL is somehow not good enough for your project).
-Third step: Removal of the core and the wrappers, replacing them by STL.
Those 3 steps can be stretched in time and versions as needed for people to follow, yet should not be waited too much on since the work will only grow bigger with time.
Also Zeuss, it is a discussion, not an argu...
Like I said in a previous post, we are nearly all friends here ^^
And the fact that some people might depend on the core containers is one of the best example why we need to have them follow the standard, at the very least. It isn't uncommon for the Irrlicht community to see some new c++ coders come. If we teach them not to use the STL or a warped version of it, we're not making them any service. Let's be generous. Let's say they use Irrlicht for 8 years. Can you imagine trying to use the STL container in the real world of thousands of libraries out there afterward? Their perceptions will be flipped.
I also know this is a HUGE amount of work. Amongst other things because I have started to look to offer a STL friendly patch. But waiting will only make it worst and I am more than convinced that it is a bad design decision Irrlicht should do without. So here's my suggestion: A three steps plan.
-First step: Implement the STL container under Irrlicht form and have them be called instead of Irrlicht (basically, make a Irrlicht wrapper of STL) Users should have a config flag to switch between the wrapper or Irrlicht within Irrlicht itself, amongst other things because a wrapper is not always the most efficient way out there.
-Second step: Correct any non STL behavior of the core and the wrapper (which imitates the core). By then, users should start converting their application to STL already (or personal librarie, if the STL is somehow not good enough for your project).
-Third step: Removal of the core and the wrappers, replacing them by STL.
Those 3 steps can be stretched in time and versions as needed for people to follow, yet should not be waited too much on since the work will only grow bigger with time.
Also Zeuss, it is a discussion, not an argu...
Like I said in a previous post, we are nearly all friends here ^^
Exactly my point, independent developers could instead of allowing the crap compiler compile it, rewrite all the routines in assembly, since that is best for them at that point in time. And where else would they have the code at hand? The Irrlicht containers.unless you go in machine code
I agree with BlindSide on the core::string > std::string.
TheQuestion = 2B || !2B
Not so much. It has been done multiple times already by different people. It will break code outside of Irrlicht that uses the containers of Irrlicht, but the functionality can be mapped to STL completely with little effort.Dorth wrote: I also know this is a HUGE amount of work. Amongst other things because I have started to look to offer a STL friendly patch. But waiting will only make it worst and I am more than convinced that it is a bad design decision Irrlicht should do without. So here's my suggestion: A three steps plan.
Nice quote mining.Halifax wrote:Exactly my point, independent developers could instead of allowing the crap compiler compile it, rewrite all the routines in assembly, since that is best for them at that point in time. And where else would they have the code at hand? The Irrlicht containers.unless you go in machine code
But as already have been said. If you need to change containers, do it in your STL implementation, as the STL is about containers (among others) and Irrlicht is not. I doubt you will win much with assembler in this context.
Also multi-threading is probably better done on application level rather then container level, as it is easier to control overhead. With OpenMP for instance it is rather easy to control this when using STL, if you need parallel sorting, you can implement it on top of STL, as it is pluggable for this very reason. Small Lego pieces to stick together.
It has been said here somewhere that the containers are STL compatible, that's true for two of them and false for the other ones. (map and string)
core::string != std::string at best. ^^Halifax wrote:I agree with BlindSide on the core::string > std::string.
There is something new as well as there is something missing. Among others core::string is not a Sequence, which prevents STL algorithms to be used on it.
What core::string has over what std::basic_string provides can be externalized.
Thats true. Like I said, we should first work on making the Irrlicht containers similar to the STL ones, then this would allow an easy exchange between the two with a simple typedef.
ShadowMapping for Irrlicht!: Get it here
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Need help? Come on the IRC!: #irrlicht on irc://irc.freenode.net
Yes I know dorth, I was only teasing a littleAlso Zeuss, it is a discussion, not an argu... Wink Like I said in a previous post, we are nearly all friends here ^^
Help make Irrlicht even Better! Create and submit your own Irrlicht Extension
Want a Games Education? Try The Academy of Interactive Entertainment
Want a Games Education? Try The Academy of Interactive Entertainment
Yeah, why is no one paying attention to this concept? This is probably the easiet, and most pleasing solution for everyone.BlindSide wrote:Thats true. Like I said, we should first work on making the Irrlicht containers similar to the STL ones, then this would allow an easy exchange between the two with a simple typedef.
TheQuestion = 2B || !2B
I know Zeuss, don't worry 
Halifax, please stop. You're not discussing, you're hammering, because contrarily to others on both side, you do not bring new arguments to the table. Also, quote mining is really of poor form. Please don't. Quote me fully or don't.
One cannot say the majority is always right. One cannot say it's always wrong. The one with the most argument isn't always right. He isn't always wrong either. The loudest is not always one or the other. So let's be objective about this. One thing we can do is start a new topic somewhere where people will list whether they use core or stl implementation in their IRRLICHT projects. If only 2% use core, this should pretty much answer the question. If more do, then let's ask why. Do they use the special functionality? Have they come to rely on them? Is it because of easier integration with Irrlicht? Is it by habit?
If many people did a patch to convert Irrlicht to stl, then great. Please, someone submit a well formed one to the tracker. This way, everyone can test with or without. Also, why not make it one of the subject for debate on the Irrlicht conference? With proper order, it could be quite enjoyable to debate.
And finally, I'm afraid that up to now, the only ones who backed their opinions were the replace with stl side. I am far from saying that the core side do not have argument, but please do back them? And not by "it would surely have been slower". Make a test. Give the source. Find numbers, example, something
And please, let's all stay friendly and calm, it's our great engine to all we're making.
P.S.: I do not see why having the source of the core pseudo stl is in any way better for someone coding machine code of one of the container. It pretty much means a complete rewrite no matter what.
Halifax, please stop. You're not discussing, you're hammering, because contrarily to others on both side, you do not bring new arguments to the table. Also, quote mining is really of poor form. Please don't. Quote me fully or don't.
One cannot say the majority is always right. One cannot say it's always wrong. The one with the most argument isn't always right. He isn't always wrong either. The loudest is not always one or the other. So let's be objective about this. One thing we can do is start a new topic somewhere where people will list whether they use core or stl implementation in their IRRLICHT projects. If only 2% use core, this should pretty much answer the question. If more do, then let's ask why. Do they use the special functionality? Have they come to rely on them? Is it because of easier integration with Irrlicht? Is it by habit?
If many people did a patch to convert Irrlicht to stl, then great. Please, someone submit a well formed one to the tracker. This way, everyone can test with or without. Also, why not make it one of the subject for debate on the Irrlicht conference? With proper order, it could be quite enjoyable to debate.
And finally, I'm afraid that up to now, the only ones who backed their opinions were the replace with stl side. I am far from saying that the core side do not have argument, but please do back them? And not by "it would surely have been slower". Make a test. Give the source. Find numbers, example, something
And please, let's all stay friendly and calm, it's our great engine to all we're making.
P.S.: I do not see why having the source of the core pseudo stl is in any way better for someone coding machine code of one of the container. It pretty much means a complete rewrite no matter what.
I do not feel as if I am hammering anything, and this is the first I have heard of quote mining. If anything I feel as if you are attacking me specifically while I am just supporting BlindSide's ideas. (Especially after directly quoting me, and writing a respone only to an agreeance, and not the true post.) I was originally going to use the whole passage, but seeing it as a waste of space I chose differently. That is my fault if that offended some of you, but most certainly was not the intention.
You still have not entertained BlindSide's solution, but I will just release that seeing as you just don't want to.
And Dorth, it has already been proven that the usage of STL is faster right now, and it is already implemented in 3Demon. Why not go over there, and formulate a patch for Irrlicht.
I am afraid to say this, but you continue to reiterate the point of staying "friendly and calm", but you seem to be the person bringing the heat into this discussion.
My clear opinion is the fact that Niko obviously put Irrlicht containers in there, they are quite mature, we can simply emulate STL, and then we can use BlindSide's solution. It's as simple as that!
If you want to go the way of seeing who uses the core containers, then go ahead, but I definitely won't advocate the deleting of these containers, especially since numerous applications already make usage of them. You will be breaking hunderds, maybe thousands of applications if you remove the Irrlicht containers.
And to hint on a point that you made, Saturn.
You still have not entertained BlindSide's solution, but I will just release that seeing as you just don't want to.
And Dorth, it has already been proven that the usage of STL is faster right now, and it is already implemented in 3Demon. Why not go over there, and formulate a patch for Irrlicht.
I am afraid to say this, but you continue to reiterate the point of staying "friendly and calm", but you seem to be the person bringing the heat into this discussion.
My clear opinion is the fact that Niko obviously put Irrlicht containers in there, they are quite mature, we can simply emulate STL, and then we can use BlindSide's solution. It's as simple as that!
If you want to go the way of seeing who uses the core containers, then go ahead, but I definitely won't advocate the deleting of these containers, especially since numerous applications already make usage of them. You will be breaking hunderds, maybe thousands of applications if you remove the Irrlicht containers.
And to hint on a point that you made, Saturn.
Intel implements it on the container level, and application level. It is needed for both, especially to optimize the memory structure, and usage.Also multi-threading is probably better done on application level rather then container level, as it is easier to control overhead.
TheQuestion = 2B || !2B
hundreds maybe thousands... just how many Irrlicht apps do you think there are out there? You have no basis for those numbers and as such, they are irrelevant. The core container ARE NOT mature, they have not been around for years, had consensus of people working on them, mass of people competing for it's better implementation. If anything, it's a juvenile implementation at best.
Halifax wrote:
You still have not entertained BlindSide's solution, but I will just release that seeing as you just don't want to.
BlindSide wrote:
Thats true. Like I said, we should first work on making the Irrlicht containers similar to the STL ones, then this would allow an easy exchange between the two with a simple typedef.
Dorth wrote:
-Second step: Correct any non STL behavior of the core and the wrapper (which imitates the core). By then, users should start converting their application to STL already (or personal librarie, if the STL is somehow not good enough for your project).
I'm going to call bad faith on you on this one since you seem to read my text enough to find quotes in it, this should have not passed you by.
Halifax wrote:
And Dorth, it has already been proven that the usage of STL is faster right now, and it is already implemented in 3Demon. Why not go over there, and formulate a patch for Irrlicht.
Then why keep entertaining the delusion that the core COULD be faster and that keeping the limping one with us will make things better?
Also:
Dorth wrote:
If many people did a patch to convert Irrlicht to stl, then great. Please, someone submit a well formed one to the tracker.
Did I or did I not suggest someone should and that I was working on one?
Halifax wrote:
My clear opinion...
And what is that worth? Not more than anyone's voice, at best.
Halifax wrote:
If you want to go the way of seeing who uses the core containers, then go ahead, but I definitely won't advocate the deleting of these containers, especially since numerous applications already make usage of them. You will be breaking hunderds, maybe thousands of applications if you remove the Irrlicht containers.
Again with the "I". And yeah? Prove it! Let's make it easy. Give me 15, just 15 apps that do use one of their feature that is not STL compatible. Bonus point if none of them would be happier with STL.
Facts are the base of sound judgment and decisions, not feelings.
Halifax wrote:
You still have not entertained BlindSide's solution, but I will just release that seeing as you just don't want to.
BlindSide wrote:
Thats true. Like I said, we should first work on making the Irrlicht containers similar to the STL ones, then this would allow an easy exchange between the two with a simple typedef.
Dorth wrote:
-Second step: Correct any non STL behavior of the core and the wrapper (which imitates the core). By then, users should start converting their application to STL already (or personal librarie, if the STL is somehow not good enough for your project).
I'm going to call bad faith on you on this one since you seem to read my text enough to find quotes in it, this should have not passed you by.
Halifax wrote:
And Dorth, it has already been proven that the usage of STL is faster right now, and it is already implemented in 3Demon. Why not go over there, and formulate a patch for Irrlicht.
Then why keep entertaining the delusion that the core COULD be faster and that keeping the limping one with us will make things better?
Also:
Dorth wrote:
If many people did a patch to convert Irrlicht to stl, then great. Please, someone submit a well formed one to the tracker.
Did I or did I not suggest someone should and that I was working on one?
Halifax wrote:
My clear opinion...
And what is that worth? Not more than anyone's voice, at best.
Halifax wrote:
If you want to go the way of seeing who uses the core containers, then go ahead, but I definitely won't advocate the deleting of these containers, especially since numerous applications already make usage of them. You will be breaking hunderds, maybe thousands of applications if you remove the Irrlicht containers.
Again with the "I". And yeah? Prove it! Let's make it easy. Give me 15, just 15 apps that do use one of their feature that is not STL compatible. Bonus point if none of them would be happier with STL.
Facts are the base of sound judgment and decisions, not feelings.
Now your just caviling, so go ahead and ruin this topic, I'm done. And oh yeah, I'll do the work that a simple search could turn up for you, I don't want to wear out your hands.
And wow, there are some pretty pivotal things in the Irrlicht community on that list. I'm out on this topic, have fun. You seem very partial to trying to tick off people in this community, and I'm just not going to be part of that.XEffects
Klasker Tree Scene Node
Tiled Terrain Scene Node
IrrNet
Cloth Scene Node
CCloudSceneNode
CGrassPatchSceneNode
BlindSide's Shader Preprocessor
CINIFileReader
CIrrklangAnimator
CLoadingBar
ATMOsphere
RenderTargetXXL patch
CAnimatedSpriteClass
JonLT's drag-and-drop GUI
TheQuestion = 2B || !2B
Dorth, honestly, you're the one that said you wanted a clean discussion, and now you're attacking Halifax's arguments by talking down to him and picking apart pieces of his sentences? :\ People who post on here should not have to re-read what they say a hundred times to make sure it is completely safe from attack >.>
As has been mentioned, it is not that the containers are necessarily faster, but that they COULD BE faster; why not take the time it would take to convert the Irrlicht engine to using the STL and instead work on improving the existing implementation of Irrlicht's containers? It's been pointed out that they are multi-threaded (which the STL is generally not), and therefore they could be faster, given some more work.
So far, the only real reason that I see you giving to use the STL is "it's standard!". My response is: so what? Why does that make it better? Writing in assembler was standard until C came along, it doesn't make it better.
I'm not trying to turn this into a flame war, so please...please respond without being patronizing. As you said, this is about helping out the community to build a better 3D engine...we can't have that if no one knows how to discuss things without putting down everyone else
-wyrmmage
As has been mentioned, it is not that the containers are necessarily faster, but that they COULD BE faster; why not take the time it would take to convert the Irrlicht engine to using the STL and instead work on improving the existing implementation of Irrlicht's containers? It's been pointed out that they are multi-threaded (which the STL is generally not), and therefore they could be faster, given some more work.
So far, the only real reason that I see you giving to use the STL is "it's standard!". My response is: so what? Why does that make it better? Writing in assembler was standard until C came along, it doesn't make it better.
I'm not trying to turn this into a flame war, so please...please respond without being patronizing. As you said, this is about helping out the community to build a better 3D engine...we can't have that if no one knows how to discuss things without putting down everyone else
-wyrmmage
I'm all for switching Irrlicht over to using the Standard C++ Library containers and algorithms. They are well documented, fairly well defined, and usually well tested.
I personally feel that it would be a bad idea to update the existing Irrlicht core containers to emulate the C++ containers. Doing this has several disadvantages.
First off, it requires that somebody implement compatible containers. I happen to work on an open source implementation, and I can tell you that this is not an insignificant task. It will take time to write a portable and complete implementation, and there will be lots of maintenance time which will take time away from the more important things that the Irrlicht development team should be worrying about, like the engine.
Second, changing the interface or implementation of the core classes will break compatibility with existing applications. If the plan is to eventually switch over to using the Standard C++ Library containers, then this will cause at least two compatibility breaks -- one when fixing the Irrlicht containers, and another when switching to the std container implementations. This is bad for users, and it will require additional development time for both end users and the development team.
If this is going to be done, then it should be done in such a way that it doesn't seriously impact users. That means breaking compatibility as few times as possible.
Travis
I personally feel that it would be a bad idea to update the existing Irrlicht core containers to emulate the C++ containers. Doing this has several disadvantages.
First off, it requires that somebody implement compatible containers. I happen to work on an open source implementation, and I can tell you that this is not an insignificant task. It will take time to write a portable and complete implementation, and there will be lots of maintenance time which will take time away from the more important things that the Irrlicht development team should be worrying about, like the engine.
Second, changing the interface or implementation of the core classes will break compatibility with existing applications. If the plan is to eventually switch over to using the Standard C++ Library containers, then this will cause at least two compatibility breaks -- one when fixing the Irrlicht containers, and another when switching to the std container implementations. This is bad for users, and it will require additional development time for both end users and the development team.
If this is going to be done, then it should be done in such a way that it doesn't seriously impact users. That means breaking compatibility as few times as possible.
Travis