std/stl is the root to all evil
Author
Join the freedom fighter and crush the STL library.
One step to unreadable compiler errors
1. use std/stl
How to write unreadable code == stl headerfiles
1. Write the code using appropriate variable names
2. Use the replace tool, replace all normal variable names to leet variable names that are extremely hard to read and understand.
3. Use leet formatter to format the code into nonsense
Why would one do this to me? em i alone out there or are there more who share this anger?
I know what ur thinking, RTFM and learn to use stl properly
At risk of sounding cliched, I will interject at this point: RTFM and learn to use STL properly.
Seriously.
It's definitely the single greatest timesaver in my programming, not having to invent a new container class or string everytime I need a feature, never have to worry about debugging it (that is a HUGE bonus, such a weight off your shoulders to be able to count on some code working properly all the time). I mean, for god's sake. You've done one container, you've done them all, and I for one never want to make another linked list except on pain of death [grin]
If you don't like their naming systems, well, that's your problem. All* template code produces very verbose and sometimes almost entirely unreadable errors, you either learn to recognize the problems, or not. I don't know about you, but I find the errors to be perfectly readable, although sometimes it takes a bit of time to get to the actual heart of the problem, which is of course not always the line or error reported. Same with debugging, when I break into STL code, it's fairly readable to me, as long as I glance at the surrounding code first.
*All syntacticly incorrect
But, to each his own. I'm sure you'll have plenty of fun hours, days, weeks even writing your own library for standardized containers and strings and everything else under the sun, not to mention debugging it, and THEN getting people to use it. Only to have it easily outperformed by the STL in all cases. Your choice.
Seriously.
It's definitely the single greatest timesaver in my programming, not having to invent a new container class or string everytime I need a feature, never have to worry about debugging it (that is a HUGE bonus, such a weight off your shoulders to be able to count on some code working properly all the time). I mean, for god's sake. You've done one container, you've done them all, and I for one never want to make another linked list except on pain of death [grin]
If you don't like their naming systems, well, that's your problem. All* template code produces very verbose and sometimes almost entirely unreadable errors, you either learn to recognize the problems, or not. I don't know about you, but I find the errors to be perfectly readable, although sometimes it takes a bit of time to get to the actual heart of the problem, which is of course not always the line or error reported. Same with debugging, when I break into STL code, it's fairly readable to me, as long as I glance at the surrounding code first.
*All syntacticly incorrect
But, to each his own. I'm sure you'll have plenty of fun hours, days, weeks even writing your own library for standardized containers and strings and everything else under the sun, not to mention debugging it, and THEN getting people to use it. Only to have it easily outperformed by the STL in all cases. Your choice.
Hmm...
For what it's worth, I've been in your position. There was a time when I strongly resisted the STL - the syntax is pretty darned obtuse when you aren't pretty familiar with Templates, and the whole iterator concept. And STL can also generate some pretty nasty (a.k.a. near unreadable) error messages at times, so I understand your frustration.
However, I will also say this - I'm damned glad I got over my problems with the STL and learned to embrace it. The amount of time and frustration I've saved by using std::map and std::string is well worth the price of admission. (not to mention Vector and List, and the sorting algorithms, and everything else)
Anyhow, at least let me try to make a helpful suggestion. Take a look at _older_ books on C++. "C++ Strategies and Tactics" by Robert Murray for example, has a section where he designs a templated list class and uses the iterator metaphor. The book is from 1993, which if I'm correct is before the STL was a popular, standard part of the language. I was also able to find the book dirt cheap on the Amazon Marketplace (think I paid like $8 for it). Looking through a book like this will provide some context as to why the containers are designed as they are.
Another helpful book might be Advanced C++ Programming styles and Idioms, by Coplien. He only dedicates like two pages to iterators in general, but the whole book is full of rational explainations for design patters which normally seem obtuse/overkill.
Oh yeah, and don't forget Scott Meyer's venerable "Effective STL". 8-)
Anyhow, good luck! Try not to give up, learning the STL is well worth the effort.
For what it's worth, I've been in your position. There was a time when I strongly resisted the STL - the syntax is pretty darned obtuse when you aren't pretty familiar with Templates, and the whole iterator concept. And STL can also generate some pretty nasty (a.k.a. near unreadable) error messages at times, so I understand your frustration.
However, I will also say this - I'm damned glad I got over my problems with the STL and learned to embrace it. The amount of time and frustration I've saved by using std::map and std::string is well worth the price of admission. (not to mention Vector and List, and the sorting algorithms, and everything else)
Anyhow, at least let me try to make a helpful suggestion. Take a look at _older_ books on C++. "C++ Strategies and Tactics" by Robert Murray for example, has a section where he designs a templated list class and uses the iterator metaphor. The book is from 1993, which if I'm correct is before the STL was a popular, standard part of the language. I was also able to find the book dirt cheap on the Amazon Marketplace (think I paid like $8 for it). Looking through a book like this will provide some context as to why the containers are designed as they are.
Another helpful book might be Advanced C++ Programming styles and Idioms, by Coplien. He only dedicates like two pages to iterators in general, but the whole book is full of rational explainations for design patters which normally seem obtuse/overkill.
Oh yeah, and don't forget Scott Meyer's venerable "Effective STL". 8-)
Anyhow, good luck! Try not to give up, learning the STL is well worth the effort.
Quote:Original post by Leadorn
Join the freedom fighter and crush the STL library.
No.
Quote:One step to unreadable compiler errors
1. use std/stl
There was a time when you couldn't understand C++. Was that because C++ is unreadable, or because you hadn't learnt to understand it? If you need stabalisers for your SC++L bike, try STLFilt. Newer compilers also tend to do better with template errors.
Quote:How to write unreadable code == stl headerfiles
1. Write the code using appropriate variable names
2. Use the replace tool, replace all normal variable names to leet variable names that are extremely hard to read and understand.
3. Use leet formatter to format the code into nonsense
Why would one do this to me? em i alone out there or are there more who share this anger?
How to write code that you can guarantee won't conflict with the users code == stl headerfiles. They use "leet variable names" because those variable names are reserved by the standard for use by standard library implementors. Imagine if you #defined the symbol DATA and your standard library implementation use the same symbol in a header. Could cause problems, no?
The formatting I have never had a problem with. It may be different to my standards, but it's usually consistent.
Quote:I know what ur thinking, RTFM and learn to use stl properly
Read my mind [lol]
Σnigma
Quote:
One step to unreadable compiler errors
1. use std/stl
Wrong. That problem is not caused by the std library.
It is caused by two other things:
Quote:How to write unreadable code == stl headerfiles
You aren't supposed to look at them - program to the interface, not the implementation.
Quote:Original post by Leadorn
Join the freedom fighter and crush the STL library.
I refuse. I join the empire. Crush the rebels!!! Their inexperience leads them to the evils of repeating. Repeating their own efforts, for their code is not reusable, repeating the efforts of others, for they reinvent the wheel a million fold, and repeating the mistakes of the past in their quest to make things themselves, instead of attempting to understand what their eventual destination will become anyways - if they continue to learn for a million years, at least.
Where you see unreadable error messages, I see an opportunity to learn, or failing that, cheating. Where you see unreadable header files, I see an opportunity to learn, at a bare minimum from the mistakes of others.
Quote:Original post by Leadorn
Join the freedom fighter and crush the STL library.
Create your own implementations of std::string (char arrays) and std::vector (dynamically resizable arrays) - and once you're done debugging them, tell me what you think of the standard library. Then procede to recreate anything else that might be useful (hint - take a look at the other containers, algorithms, and much more).
However, if you want to crush std::vector<bool>, you have my full support. [wink]
Quote:One step to unreadable compiler errorsYou've got a point there.
1. use std/stl
Quote:I know what ur thinking, RTFM and learn to use stl properly
RTFM
If you have a problem with the C++ standard library then you have a problem with C++ not with the library and the problem is
either
It's as simple as that.
either
- Your C++ is mediocre. In which case improve it and undo your bad habbits.
- You genuinely have a problem with C++ the language, it's not (generally) the library that is at fault. In which case find another language.
or:
It's as simple as that.
Quote:Original post by Will F
However, if you want to crush std::vector<bool>, you have my full support. [wink]
Just crush the allowances in the standard for it to behave totally different from any other std::vector< T >.
Okay, I just have to stick my neck out on this one... *prepares flame-retardant suit*
I _fully_ agree with the OP. STL is horrid, it's ugly... it's like a red-headed step-child. :)
I come from a background of around seven years developing games on consoles where code must be designed for performance and a small memory footprint. This is definitely something STL is not. Code must be kept simple, and reasonably easy to understand. I can't look at code that uses STL and figure out what someone is trying to do in just a few minutes because someone overloaded every single C++ operator to mean what he thought it should mean. Concatenate strings? That's what strcat is for! (although a good game engine would already have its own cut-down libc implementation anyway)
I look at some of the STL headers and my eyes just glaze over. When I look at a header file, I should see a cleanly laid out function list (or class of some sort) of what a module should do, not some madness that looks like a C++ run-on-sentence. Header files are the second-best documentation, after all.
I have no problems with understanding STL, though. I can read STL code if I have to, and I know how to use templates and operator overloading -- but I simply choose not to.
My opinion is that STL (and boost, and lots of other libraries out there) lead to overly-bloated code. Has anyone who ever _really_ uses STL ever looked at the disassembly of what goes on in there? Blame the CPU because it's too slow? No, no... programmers have gotten lazy and would rather leave the dirty work to someone else rather than build their own routines. Reinventing the wheel? Even so, someone who builds his own routines will _learn_ a lot while doing it. I'm all for it. And once you've built your own routines, they'll most likely be better than STL because _you_ designed it for _yourself_, and that leads to the most amount of code reusability in my book.
*steps off soap box*
Let's try not get into too big of a flame war here, okay? :)
I _fully_ agree with the OP. STL is horrid, it's ugly... it's like a red-headed step-child. :)
I come from a background of around seven years developing games on consoles where code must be designed for performance and a small memory footprint. This is definitely something STL is not. Code must be kept simple, and reasonably easy to understand. I can't look at code that uses STL and figure out what someone is trying to do in just a few minutes because someone overloaded every single C++ operator to mean what he thought it should mean. Concatenate strings? That's what strcat is for! (although a good game engine would already have its own cut-down libc implementation anyway)
I look at some of the STL headers and my eyes just glaze over. When I look at a header file, I should see a cleanly laid out function list (or class of some sort) of what a module should do, not some madness that looks like a C++ run-on-sentence. Header files are the second-best documentation, after all.
I have no problems with understanding STL, though. I can read STL code if I have to, and I know how to use templates and operator overloading -- but I simply choose not to.
My opinion is that STL (and boost, and lots of other libraries out there) lead to overly-bloated code. Has anyone who ever _really_ uses STL ever looked at the disassembly of what goes on in there? Blame the CPU because it's too slow? No, no... programmers have gotten lazy and would rather leave the dirty work to someone else rather than build their own routines. Reinventing the wheel? Even so, someone who builds his own routines will _learn_ a lot while doing it. I'm all for it. And once you've built your own routines, they'll most likely be better than STL because _you_ designed it for _yourself_, and that leads to the most amount of code reusability in my book.
*steps off soap box*
Let's try not get into too big of a flame war here, okay? :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
