But... Saying that the STL is horrible sounds like a beginner statement (beginners always fight against the STL). I doubt that you'll write less horrible code with a raw array. Unless you do something very limited or something that will crash at users face.
It depends on what you are doing, however in the case of a string holding user supplied input it is often much 'safer' than a char[]s.
Plus, at every strcpy() and strcat() we have the omnipresent risk of buffer overflows. And this is only a simple example with static arrays.
Would a memcpy not suffice if you know the maximum size?
When you need dynamic allocations (because you don't know the string length in advance),
the C version is even funnier, since ownership management and exception safety become real issues.
Is it not rather redundant talking about exception safety when the point of using the c alternative is to avoid the STL, where exactly would these exceptions be thrown from?
RAII negates most of this issue, unless your destructors are throwing exceptions that is, in which case you are screwed either way.
I don't agree. Some very good code can be written without using the STL. I don't need a lot of flexibility and the added complexity just isn't worth it.
Well said. The flexibility can come at a huge cost when you factor in GCC's fantastic compile time messages regarding the STL.
Nexus' point is also valid concerning strings, however the argument does not hold as strongly for the entirety of the STL.
Although it is often silly to avoid using the STL entirely, it is extremely wise to consider the alternatives (even more so in real-time applications). It is rarely a good idea to use a library utility when a language construct achieves the goal sufficiently.
The right tool for the job after all.
~Chris
