[fixed] core::list copy constructor

[codwarrior]

I had a bug due to non-initialized members when using core::list's copy constructor, so I'd rather like to see it defined as

Code: Select all

//! copy constructor
list(const list<T>& other) : 
    root(0), last(0), size(0)

instead of just having

Code: Select all

//! copy constructor
list(const list<T>& other)

in irrList.h, line 91.
I think this would be nicer

[hybrid]

Oh yes, that's much better.

[vitek]

Yet another bug that does not exist in std::list<>. :)

[Spintz]

i know Vitek, I think that horse has been beaten to death. STD libraries would be smarter to use, but they aren't going to change it. Or do you think if we keep bugging them, they'll change????

[vitek]

Nope, I don't think they'll ever change. I just like to keep poking them in the ribs with my finger...

[Saturn]

Well, Hybrid you are also Pro-STL, not? IIRC only the founding father himself doesn't want it in Irrlicht.
/me poking too.

[hybrid]

I guess we could drop these classes more easily as soon as VC++6 support is dropped. But this seems to be an everlasting story, so it's highly unlikely that we drop those helper classes in favor of STL.
Moreover, those bugs should be finite and we keep on hunting them

[Spintz]

There is a patch for VS6 to fix the STL problems. The other problem would be gcc < 3.x, there's no patch for that, just have to upgrade to a newer compiler.

There's no excuses for not upgrading, except personal opinion, technically, it's not an issue.

[Warchief]

Dont want to disturb your peace guys, i do actually prefer STL; but i was having some memory allocation problems in my game and here it was i finally discovered:

Bugs

I was using some stringstreams to fill paths in the main loop.

[vitek]

If I remember right, this is a locale leak. The bug has been there for a long time. Even so, the container classes don't use the input/output library.

Travis

[Warchief]

Though memory is not freed localy, the game ends without memory leaks (CRT wont detect any). But it just could lead to a std::bad_alloc if runs out of memory.
Anyway, as the link says, it should be patched on VS8 SP1, which i have downloading and installing this nite. Will give it a try later. Just wanted to point that stl (as any other program/library) is not bug free.

For example, i have seen that every frame (on irrlicht), arrays of renderable objects are cleared and restored, which leads to continous allocations/deallocations. This could be a performance decrease, as current irr:core::array frees the data memory on clear(). It does not separate capacity from size, as current stl implementation does.

A lot of work to examine for a MySTL vs STL thread.

[Saturn]

Not to be nitpicking, but the bug is not in the STL, it is in iostream.
But to confirm, it is indeed fixed with SP1.

Yep, that clear() frees the memory is annoying. Irrlicht doesn't have to reinvent the swap-trick, but maybe it is a good idea to make clear not destroy the buffer and add another function, that does. Maybe named purge() or with another fitting name.

[vitek]

You can use a.erase(0, a.size() - 1) to clear the array without freeing the allocated memory.

[Warchief]

Not to be nitpicking, but the bug is not in the STL, it is in iostream.

What do you mean? Streams are part of the STL according to Bjarne Stroustrup. It is a bug on Microsoft's STL implementation.

[vitek]

The STL is the Standard Template Library, which is a collection of containers, iterators and algorithms that eventually became part of the Standard C++ Library. People typically refer to the Standard C++ Library as STL, but it is not _really_ correct. Also, just FYI... http://en.wikipedia.org/wiki/C%2B%2B_Standard_Library

Travis