🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
a mixed bag
Author
I recently started using C++ and STL and found it''s not all wine & chocolates ... the string and vector templates are OK, but try making a priority_queue of pointers to classes -- you''ll get error messages that only James Joyce scholars can interpret. Maybe it''s because I''m using g++, but I still don''t trust STL quite yet. Anybody have any different experiences?
Well I''m not making fuzzy logic and neural networks with them for the latest greatest thing in AI or anything, but I use them pretty regularly in most of my programming projects. The only problems I have with it are stupid mistakes on my part, hey wait, they''re all stupid after you find out what you were doing or not doing. Anyways...
So I don''t know what the general consensus of everyone here in the gamedev community are about it, but maps, vectors, etc that I need from time to time, the STL comes in rather handy, as I don''t have to code from scratch linked lists etc everytime I want one, like every C++ programmer here does at first. C''mon, admit it, you know you did and you know who you are.
I will admit though that I am using MSVC primarily, guess I''m not smart enough to use g++ that and the fact I guess I''m a sell out, I''ve gotten pretty efficient at using it and making it work for me when I need it to when navigating my way around in new territory, which _in_my_opinion_ is very important any time you tackle gaining a new understanding in something you really know nothing about, the last thing you want is to have to fight with your compiler/debugger. They''re tools, make them work for you or find some that do.
blah blah blah words words
That''s all I have to say on the topic, whatever it was...
So I don''t know what the general consensus of everyone here in the gamedev community are about it, but maps, vectors, etc that I need from time to time, the STL comes in rather handy, as I don''t have to code from scratch linked lists etc everytime I want one, like every C++ programmer here does at first. C''mon, admit it, you know you did and you know who you are.
I will admit though that I am using MSVC primarily, guess I''m not smart enough to use g++ that and the fact I guess I''m a sell out, I''ve gotten pretty efficient at using it and making it work for me when I need it to when navigating my way around in new territory, which _in_my_opinion_ is very important any time you tackle gaining a new understanding in something you really know nothing about, the last thing you want is to have to fight with your compiler/debugger. They''re tools, make them work for you or find some that do.
blah blah blah words words
That''s all I have to say on the topic, whatever it was...
I personally dislike STL very much. In theory it''s a great idea, but the actual STL interfaces make me feel like I''ve been given a wedgie.
Personally I use my own template library for most of the things that STL does.
Personally I use my own template library for most of the things that STL does.
I swear by STL.
I haven't used it in other compilers, but in the VC++ world it's pretty slick. It's not perfect - the string class, for example, could be a lot better, and there's some debug info truncation issues - but on the whole I've found it incredibly useful.
It does, however, take some time to learn, and many people are put off by this. Give it a chance (and get yourself a good book on it) before you trash it.
The whole point of STL is that it's ANSI approved, which means it's guaranteed to work on any compiler that's also ANSI approved. This is a boon for developers who are worried about porting their code to other systems.
Also, keep in mind that the ANSI-approved STL libraries are created by *expert* programmers, working full-time, and with years of experience under their belts.
If the only thing you don't like about STL is the interface, I'd suggest wrapping it with your own before giving up completely.
It's my belief that in a few years STL will be as essential as the Standard C Runtime Library (i.e., #include ).
Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com
Edited by - mason on 1/11/00 2:48:10 PM
I haven't used it in other compilers, but in the VC++ world it's pretty slick. It's not perfect - the string class, for example, could be a lot better, and there's some debug info truncation issues - but on the whole I've found it incredibly useful.
It does, however, take some time to learn, and many people are put off by this. Give it a chance (and get yourself a good book on it) before you trash it.
The whole point of STL is that it's ANSI approved, which means it's guaranteed to work on any compiler that's also ANSI approved. This is a boon for developers who are worried about porting their code to other systems.
Also, keep in mind that the ANSI-approved STL libraries are created by *expert* programmers, working full-time, and with years of experience under their belts.
If the only thing you don't like about STL is the interface, I'd suggest wrapping it with your own before giving up completely.
It's my belief that in a few years STL will be as essential as the Standard C Runtime Library (i.e., #include ).
Mason McCuskey
Spin Studios - home of Quaternion, 2000 GDC Indie Games Fest Finalist!
www.spin-studios.com
Edited by - mason on 1/11/00 2:48:10 PM
I have other specific objections to STL over and above the interface.
The include method is a subversion of the preprocessor.
The STL has it''s share of inconsistancies. Primarily in the realm of iterators.
Have you ever tried to run a garbage collector against STL? Because of STL''s own private memory hacks certain garbage collection techniques fail miserably.
I personally find specific advantages of STL over other template libraries overrated. After all the point behind ANSI standardization is that *any* ANSI compliant code will run on any ANSI compliant compiler. Therefore, my own code libraries will work on any ANSI compliant compiler as well.
And Yes, I have used STL extensively. It''s one of the joys of working with inherited code. And I''ve be programming C/C++ for over 12 years, longer than STL has even been around. I think I''ve got enough experience under my belt to form my own opinion on STL.
But again, your milage my vary.
Back to the original topic, though, early versions of g++ didn''t handle templates correctly, so you may be getting error messages if your g++ isn''t new enough.
The include method is a subversion of the preprocessor.
The STL has it''s share of inconsistancies. Primarily in the realm of iterators.
Have you ever tried to run a garbage collector against STL? Because of STL''s own private memory hacks certain garbage collection techniques fail miserably.
I personally find specific advantages of STL over other template libraries overrated. After all the point behind ANSI standardization is that *any* ANSI compliant code will run on any ANSI compliant compiler. Therefore, my own code libraries will work on any ANSI compliant compiler as well.
And Yes, I have used STL extensively. It''s one of the joys of working with inherited code. And I''ve be programming C/C++ for over 12 years, longer than STL has even been around. I think I''ve got enough experience under my belt to form my own opinion on STL.
But again, your milage my vary.
Back to the original topic, though, early versions of g++ didn''t handle templates correctly, so you may be getting error messages if your g++ isn''t new enough.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
