strncpy crashes!

Started by
21 comments, last by peter86 21 years, 9 months ago
Do your own tests. It''s obvious that something that''s designed to be general that can work with every possible case will break down because of it, even if it speeds up code creation time.

The STL is a solution to speed coding time. It is not a panacea for obvious misguidings about a language. In short: if you don''t know the language, you will not utilize anything past your current level with any sort of efficiency.

We''ve already had the argument over what "the basics" are. It''s totally subjective, and in this case the subject needs to learn more before he takes the easy way out. Refute that and I''ll stop writing rebuttals.

Later,
ZE.

//email me.//zealouselixir software.//msdn.//n00biez.//
miscellaneous links

[twitter]warrenm[/twitter]

Advertisement
quote:Original post by ZealousElixir
Do your own tests.

My personal experience lead me to say the STL is completely acceptable in terms of performance. However, it's a shame you won't discuss the results of your tests.
quote:
It's obvious that something that's designed to be general that can work with every possible case will break down because of it, even if it speeds up code creation time.

The genericity of templates is a compile-time feature, and a well designed template class will not be any less efficient at run-time than a custom-built class.
quote:
The STL is a solution to speed coding time.

Amongst other things.
quote:
It is not a panacea for obvious misguidings about a language.

Such as?
quote:
In short: if you don't know the language, you will not utilize anything past your current level with any sort of efficiency.

That depends what it means to "know" the language.
quote:
We've already had the argument over what "the basics" are.

Yes I know we have, and I don't wish to repeat it.
quote:
It's totally subjective, and in this case the subject needs to learn more before he takes the easy way out.

I don't agree that it's subjective - I believe that it's objectively observable. However, since I've conducted no such investigations, I cannot claim to be doing anything more than hypothesising.
quote:
Refute that and I'll stop writing rebuttals.

Refute that the subject needs to learn more? I can't - we all need to learn more.


[edited by - SabreMan on June 28, 2002 6:00:42 PM]
quote:Original post by ZealousElixir
I don''t care if I get flamed for this, but in my personal tests, the STL was vastly slower than my own implementation. If you encourage people to just start out using something simple and slow, they will still be just as ignorant of better solutions when it comes time to optimize.


Take std::string as an example. If you don''t use it you could use C style strings, which means you have to worry about memory allocation, buffer over-runs along with a high scope for error. If you wanted to write you own C++ class, you then have to test this to verify it works. Both of these methods takes considerably more time to do (design, implementing, testing, debugging, optimzing) than using STL.

Perhaps you might be able to gain a small improvement in speed, but is that where the bottle neck would have been in the first place? For example, I don''t reckon string manipulation is going to be the bottle neck in Doom 3. Get your program working first, then optimize if you have to (although, you should obviously optimize on an algorithmic scale first, within reason).

All that time you spend reinventing the wheel, your competitors are implementing important things. You just simply cannot be productive and meet deadlines if you insist on writing everything yourself because you think it might be faster.

You say no general solution will be fast in all cases. Why are you so obsessed with speed? It seems to me you are clouding your programming judgement by thinking about it so much. Would you not rather finish your game in a fraction of the time instead of taking significantly longer to do so with a tiny percentage speed increase? Where exactly do you draw the line anyway? Why not write everything in assembly? Speed is not the most important aspect of programming.

STL implementations are normally fully tested and you can use them in high confidence that they work, unlike something you just made yourself. I have found, for example, STLPort to be very well written and fast.

I have had a few programming jobs and if you told your company they have just payed you a good chunk of money to reimplement STL because you *think* it might go a little faster, they would not be happy.

quote:
STL, when used effectively, may slightly reduce dev time and be easier, but it will NOT cut dev time in half, nor will it benefit you in any other way.


I strongly disagree with "slightly reduce dev time". Think of all the work it takes to design, write, test, optimize and maintain code. If you can avoid this whilst incurring minimum speed costs, you should. Imagine the collective lost work time if every programmer wrote their own linked lists, vectors, strings etc. You need to stop basing everything on speed.

This topic is closed to new replies.

Advertisement