i was actually just coming in here to talk about this so instead of a custom thread ill just continue this one, really i just wanted to ask around about difficulty debugging stl. i saved time writing a couple hundred lines and debugging pointer errors etc but now the debugger information is pretty sparse i can find my pointers to classes etc but its not like it used to be.

now im trying to do a pluggable factory for controls and i get this unresolved external symbol........

CDO error LNK2001: unresolved external symbol "protected: static class std::map<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class CtrlMaker *,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,class CtrlMaker *> > > CtrlMaker::Registry" (?Registry@CtrlMaker@@1V?$map@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PAVCtrlMaker@@U?$less@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@V?$allocator@U?$pair@$$CBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PAVCtrlMaker@@@std@@@2@@std@@A)

..... yah i dont even know where the problem is i think maybe the registry variable lol

STL helped the production process dramatically but the cost is coming on the debugging back end, the majority of the time when i miss a deref(*) or address of(&) i get such weird error message if i hadnt done the non stl for so long i prolly wouldnt understand the problem

thats an error for not declaring a static member

Thanks guys!

I like stl::list a lot because the number of functionalities (needed or not) are already there. but i am relative new linked list user so i am afraid that doing the easy way could hurt my own development.

I have been wondering whether stl::list is of any different to a custom linked list.

Looks like they are the same...

But I guess right now bug free is more important to me so i stick to stl::list thanks!

A few more questions. heh.

People were saying that if you want to implement stl::list with classes, your class should have default constructor, copy constructor, etc. I wonder this apply to structure? or are these optional?

They also mentioned that if you wan to use sort function you gotta overload operators.

does all these apply to structure as well?

One off topic question, does class have more overhead den structures? (my guess is yes)

Quote:Original post by lXciD
People were saying that if you want to implement stl::list with classes, your class should have default constructor, copy constructor, etc. I wonder this apply to structure? or are these optional?

Classes and structs automatically get a default constructor that default constructs all members. They also get a default copy constructor that copy constructs all members. For many objects, this is fine. For pointers, it probably isn't. But in most cases you can either avoid pointers or use boost::shared_ptrs instead. The rules for structs and classes are exactly the same.

Quote:
They also mentioned that if you wan to use sort function you gotta overload operators.

The default stl algorithms that involve ordering use the < operator by default, but you can replace the default with another functor instead.

Quote:
does all these apply to structure as well?

One off topic question, does class have more overhead den structures? (my guess is yes)

Classes and structs in C++ are exactly the same, except that members of a struct are public by default insead of private. Besides that, structs are mainly a holdover from C and by convention are used for making plain old data types instead of types that have methods.

Whats the different in them?
If there is not different which one is better? and which one is faster?

STL could increase your compile time (templates are sort of "compiler programming") because actually the compiler must create the code for the different lists you used before it can "compile" them.

For the speed I dont really see how you could improve STL list efficience (and in games the bottlenecks are elsewhere). STL are already implemented in the most efficent way. Probably after days of optimization, debugging and spaghetti code you could improve the overall speed by a 0,01%: is it that important?
A clean and stable code is a greater value than that (expensive) 0,01% "speed gain".

From a developer point of view there is no doubt: the answer is too clear :-D
- Bug-free data structures
- Stable, standard and clean code
- Less code
- Unification: you can switch from a vector to a list *without* change the code that use it (see iterators).

The real drawback of the STL is that you may forget how to write a linked list. :-D