quote:Original post by tok_junior
All i'm saying is that he should learn the pros and cons of (for example std::vector) and the "old" way of doing it.

When learning a language, one has to be selective about which features to learn when. It makes most sense to learn the techniques which are going to produce good results quickest. In this case, std::vector has very real benefits over an array, as detailed here. And not only is it wise for learners to prefer std::vector, it's also what clueful professionals do too, such as myself. I haven't used a plain array in my C++ code in a long time, and I've certainly not suffered any ill-effects.

quote:
A regular array is for example a lot faster than std::vector

As ever, the rule here is to profile before deciding what's "faster" for a given situation. If, for example, you have a section of code where a vector is processed during 0.01% of your program, then it is going to incredibly naive to want to optimise that code, possibly at the expense of significant time and effort. Another thing to consider is that, for the functionally equivalent intersection of array and vector characteristics, it's fairly unlikely that there will be any noticeable performance difference, since a vector *is* an array behind the scenes. For operations which can't be performed with an array, there is no comparison to be made.

quote:
it's WAY easier to debug

A debugger is a facility of your compiler toolset, not of the language. You can't make the claim that you know a vector is "easier" to debug on all debuggers in existence, since I'm very sure you don't know of all such debuggers. Furthermore, without setting out the criteria for what you mean by "easier", it's not clear exactly what you are talking about. Debugging is a high-cost technqiue for getting programs to function correctly, and there is far too much emphasis put on hacking programs into shape through such ad-hockery. We should emphasise achieving correctness early, through approaches like test-first or design-by-contract. It is easier to achieve correctness early on when you use the language features that are easier to use correctly.

quote:
and a lot less complicated to profile.

Huh? How so? And what does a newbie want to be running profilers for? Once you are the stage where you can make effective optimisations in your code, then you are no longer a newbie.

quote:
If you want to learn a language, you're better off learning it, instead of just learning enough to achieve what you want in an easy way that you don't understand.

Given that there's no possibility of learning *everything* in one hit, it makes great sense to learn the language features which achieve what you want in the easiest manner possible. That's the economics of learning for any topic. You don't suddenly dive in and make life as difficult for yourself as possible when there's an easier alternative well within reach. How exactly do you justify making things harder than they need to be?

quote:
Your way of thinking is why games of today won't run anywhere near to smoothly on a system without tons of ticks and a dx8+ gfxcard.

I'm not talking about making million dollar games, you numbskull. I'm talking about doing what is best for StormUK's program. That said, I'll wager use of std::vector won't impose a significant performance penalty for the majority of uses.

quote:
If people were actually interested in learning, and took the extra day o two, a lot of the software of today would be of a lot higher quality.

Right. It wouldn't have all the array overruns, buffer overflows and the like. You get better quality through making it easier for the programmer to achieve correctness, not harder. Your attitude of obsessing over efficiency before even having a correct program is far more responsible for bad quality s/w than probably any other factor (the decision to use C or C++ is another significant factor). StormUK's program doesn't work. What does it matter how fast it can go wrong? Premature optimisation is the root of all evil.

quote:
One example, take the standard A* pathfinding algorithm, which in 99% of the cases are implemented using linked lists.

What does that have to do with it?

quote:
STL aren't the answer to everything.

I've already pointed out that such a comment is insipid rhetoric. Please stay away from such debating devices.

quote:
Sure, the templates are wonderful for a lot of things, but to actually make the computer perform it's best, you need to know when to use them, and when not to. And without learning the basics first, you won't be able to.

The basics are the things which offer the required functionality in the simplest manner possible, not in the most brain-damaged manner possible.

[edited by - SabreMan on March 9, 2003 9:53:16 AM]

quote:Original post by StormUK
So far this STL stuff sounds too good to be true - what''s the catch?

There''s no real catch. It''s just that with arrays, a std::vector is what an array should have been all along. C and C++ programmers have been paying the price for a poor early language design decision for 30+ years, and some people are obsessed with the idea that newcomers must make the same sacrifices they always did. That''s not true. In fact, you''ll find that newer learning texts (good ones, that is) advocate using vector over array. For example, Accelerated C++, which is written by Koenig and Moo and edited by Stroustrup. Given that programmer time is far more expensive than CPU time, the philosophy of aiming for correctness before speed is morally unassailable.

Look Sabreman, i don''t think you''re quite getting what im going for here. I''m not saying std::vector is the wrong thing to use here, it''s not, and that part of the discussion seems pretty much over.
It seems more to have turned to the pros and cons of learning your language as well as possible.
The A* example was one example of where using linked lists (which is what anyone implementing it using STL uses) is not the best way to go, and people who doesn''t know their language well enough would usually not even be aware of the fact that you could to it another way.
The way you seem to think a debugger shouldn''t be needed pretty much says you''re trying to make the impression you''re way more experienced than you are, it''s a very useful tool that IS needed in a lot of cases. And i have yet to find a debugger which doesn''t require the painful process of finding your way through the stl-code to get to your own methods.
And the part about apps running slow these days weren''t about the use of stl, which atleast i thought was pretty obvious. It''s about programmers not bothering to learn anything of a lower level than they think is necessary. Not knowing that rules out a lot of possible optimizations.
And believe me (numbskull), i''m the last person to advocate premature optimization. I''m saying you have a higher possibility to optimize your code if you actually know what and how it is doing it, and in some cases just doing it in another way from the beginning will mean you don''t have to optimize that part.
And like i said, the example of A* pathfinding was to illustrate the fact that you need to know the language.

Alpha_ProgDes:
You can see all of it, send me an email on tok_junior@hotmail.com and i''ll mail it to you.
And I''m not using a 2x2 matrix, you''ll see how it works
Oh, and std::map is an array that can use other types than int for indexing, the common thing being a string. Like i could use MyMap["NiceIndex"]=2 for example.

--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.

quote:Original post by tok_junior
Look Sabreman, i don''t think you''re quite getting what im going for here. I''m not saying std::vector is the wrong thing to use here, it''s not, and that part of the discussion seems pretty much over.

Good.

quote:
It seems more to have turned to the pros and cons of learning your language as well as possible.

That''s what you''ve turned it into since you raised an objection over my suggestion to prefer vectors to arrays. It hasn''t just magically and unexpectedly materialised into that.

quote:
The A* example was one example of where using linked lists (which is what anyone implementing it using STL uses) is not the best way to go, and people who doesn''t know their language well enough would usually not even be aware of the fact that you could to it another way.

That''s a non-sequitur. If linked-lists aren''t appropriate, why on earth are you claiming that as a problem with the STL? You seem to think there''s some unseen force emanating from the STL which coerces people into poor design choices.

quote:
The way you seem to think a debugger shouldn''t be needed pretty much says you''re trying to make the impression you''re way more experienced than you are, it''s a very useful tool that IS needed in a lot of cases.

Huh? What''s my experience got to do with it and how have you decided how much experience I do have? You''re sailing very close to an ad-hominem. I hope you can demonstrate that you''re interested in the logic of my suggestions, rather than in making a personal attack.

Let me put it another way. If you are spending significant amounts of time in your debugger, then there might be a problem earlier in your development process that needs to be fixed.

quote:
And i have yet to find a debugger which doesn''t require the painful process of finding your way through the stl-code to get to your own methods.

Which debugger do you use that doesn''t implement breakpoints?

quote:
And the part about apps running slow these days weren''t about the use of stl, which atleast i thought was pretty obvious. It''s about programmers not bothering to learn anything of a lower level than they think is necessary.

If you stuck to the basic premises of the debate, you wouldn''t be meandering in this fashion. We''re talking about someone learning to program in C++. Just because someone learns the most productive features in the early phases of the learning process does not rule out going into greater depth later on. I''m not sure why this line of reasoning so often gets paraded around when discussing the STL. It''s got nothing to do with the STL, and quite a lot to do with competence.

quote:
Not knowing that rules out a lot of possible optimizations.
And believe me (numbskull), i''m the last person to advocate premature optimization. I''m saying you have a higher possibility to optimize your code if you actually know what and how it is doing it

Yes, but you can''t magically wake up one day and suddenly understand all this stuff. People have to start small, and they need to be productive to build momentum.

quote:Original post by tok_junior
The A* example was one example of where using linked lists (which is what anyone implementing it using STL uses) is not the best way to go ....

I''ve never seen an A* implementation use std::list, but I''ve seen several use std::vector (with and without std:riority_queue). Maybe you''re still suffering from the misconception that std::vector is a linked list.

quote:
And i have yet to find a debugger which doesn''t require the painful process of finding your way through the stl-code to get to your own methods.

Just because you don''t know how to use your debugger doesn''t mean there''s a problem with the STL code, or the debugger. Maybe if you posted an example of code you have trouble debugging we can help educate you. (Though it should probably in another thread at this point.)

quote:
Oh, and std::map is an array that can use other types than int for indexing....

std::map is an associative container implemented on balanced binary trees, not an array.