As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
The community reviewed whether to reopen this question 1 year ago and left it closed:
Opinion-based Update the question so it can be answered with facts and citations by editing this post.
I don't know much about C++ data structures but I am wondering do you (programmers) use STL or write your own code? After all STL is designed for doing tasks like searching, replacing and much more through a list of data.
Someone really don't need to learn much about the linked list, binary search and many more because I could use STL. What would you suggest?
You should use STL, because it is well tested and optimized.
That doesn't mean you shouldn't know how to write these data structures yourself. With that ability under your belt, you will be able to choose the best STL data structure for your application.
While the Standard Template Library is convenient when it comes to performing tasks as you mentioned like Searching, Replacing, using Linked Lists, it should not replace the knowledge of what is going on inside of the Library.
You mentioned not needing to learn about linked lists, binary searches and "many more", however you should have at least a working knowledge of how these Data Structures and procedures work as it will make using them (and knowing when to use them) much more effective.
Basically - you don't have to reinvent the wheel, but at least know what makes the wheels effectively turn.
Use STL and standard libraries in general when you can. First it is probably way better tested than your own code, and second it helps keep your code portable. The only time you should rewrite any of this functionality is for learning purposes. It may be educational to write your own associative map or linked list, but for production code, stick with well tested and standard compliant code.
A working knowledge of the underlying data structures, methods and applications of the tools provided by the STL will make you a much better programmer. Knowing when to use what container type, or which algorithm is as important as a proper implementation. Sometimes, the easiest way to understand some of the more complex concepts is to implement them yourself in the context of a data structures and algorithms class.
That said, the code in the STL has been written by experts and refined over time into a standard library that is used my millions of people world wide. In practicality, there is almost never a reason to "roll your own" except for extreme cases where performance (or size) matter to a point that is critical for your exact application.
I hesitate to write, since I haven't written C++ in 5 years. But a couple of things came to mind that haven't been discussed yet.
If the implementation is a bad fit for what you need, don't use it if you can write and test your own easier than using the library. I recently ran into this in Java, where I needed a fast bitset. Details:: There are two relevant classes in the JVM (BitSet and BigInteger). BitSet doesn't support initialization other than by setting one bit at a time; BigInteger has an irrelevant signum that confused things, and is immutable, which is costly in my case. I ended up writing my own, with tests, in a few hours. It fits better, is faster, and I can do whatever I want to it.
The other reason to write your own is if you don't understand the specification of the library implementation relative to your requirements, can't easily test it or read it to figure out what it does, and can easily roll your own. This is/was a particular problem with STL implementations that are (or at least used to be) shipped with terse, inadequate, cryptic documentation and commentless, opaque source code that rolls over your head like a huge rogue wave.
Just to add my answer (from comment above):
Yes you should think about implementing e.g. a sequence, a linked list, using your own code.
This is what they teach on Comp Sci courses and it is not without good reason. But, if you're looking to work quickly then just use STL.
I just think people should understand how the tools really work.
I use the C/C++ Standard library and STL because it is a really big time saver and I don't see the need to reinvent the wheel. I also use boost where I can.
It is still a good learning exercise to write your own container class and algorithms.
Use STL unless you have a compelling reason, e.g. speed or correctness, not to. Definitely know how to write basic data structures on your own.
In general you should use STL or Boost containers because of their effectiveness and reliability. Still you need to have a corresponding world view on existing containers. You should know its con and pros. Studying of the container internal structure and working principles allows you to reach better understanding.
STL is well tested and reliable but it is not the fastest solution. Some of the containers allocate a lot of small memory blocks rather than one big block. If you really have a speed problem then you may consider making your own fixed-size list. But for many purposes STL is the standard solution.
Very smart people wrote the STL. Then more very smart people have used it, tested it, and refined it. You think you are going to do better? Rarely. It is a great tool; you should use it whenever possible!
Write low-level stuff yourself when learning/playing, but at work use code that was written and refined by experts over years, and has/is being tested by thousands of engineers in thousands of different conditions.
In other words, use your code only if your code can beat the other codes!
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have tried to keep up with C++ since they introduced 1998 ANSI/ISO C++. I absorbed the new concepts and tried to understand them. I learned about exception handling, templates, and namespaces. I've read about the new cast mechanisms and worked with the STL library.
All of these concepts required a lot of energy. But now I am somewhat worried about the future of C++ when having a look at the new C++0x standard.
Things are getting more and more complicated. This language is becoming a monster.
I'm not sure that I want to keep up with the language anymore, since I don't do my day-to-day hacking in C++ anyway. I mostly use interpreted or bytecode languages.
So why should I bother to learn this difficult, yet exceptionally powerful, language? I can do 95% of my business with Python et al. With the remaining 5%, I can deal with plain old C++ or C without hassle.
What do you think?
Everyone uses a subset of C++. For almost all application programming in C++, whether server or client side, that subset is manageable. In my opinion, the only folks that need to stay on top of absolutely every nuance of the language are the library writers -- people implementing Boost, STL, Loki, etc.
But I would absolutely use the language that fits the task. If Python is more readable and more maintainable than C++ for your job, and you don't need what C++ offers, then certainly stick with Python.
Hear what Bruce Eckel { author of the two of the so-called best C++ books } commented on C++ a few weeks ago:
That said, I hardly ever use C++
anymore. When I do, it's either
examining legacy code, or to write
performance-critical sections,
typically as small as possible to be
called from other code (my preferred
approach is to quickly write an app in
Python, then profile it and if
necessary improve performance by
calling small portions of C++ using
Python's ctypes library).
Because I was on the C++ Standards
Committee, I saw these decisions being
made. They were all extremely
carefully considered, far more so than
many of the decisions made in Java.
However, as people have rightly
pointed out, the resulting language
was complicated and painful to use and
full of weird rules that I forget as
soon as I'm away from it for a little
while -- and I figured out those rules
from first principles while I wrote
books, not just by memorizing them.
Additionally, you should read this thread and Danny Kalev's predictions on C++.
However, the growing complexity of C++ will create pressure towards splitting the language into quasi-official dialects. We can already see this trend today; it will probably intensify in the future.
EDIT:
You should take a look at this discussion, too:
C++ - Anyone else feel like C++ is getting too complicated?
First, many features of C++0x are to make the language easier to use. More readable template compile errors, more consistent initialization syntax, support for threading, which would otherwise have to rely on platform-specific libraries and so on.
So if you do use C++, I feel learning the important parts of C++0x should be a manageable task. Remember that you don't need to learn all the new features to use the language. Some features are primarily added as an aid for library implementers, for example allowing the STL to be implemented more efficiently, but which shouldn't really affect the end-users usage of the language. And some are only really necessary in very rare cases. Ignore those parts of the language.
One of their stated goals with C++0x is to avoid it becoming harder to use.
But apart from that, do you need C++? If you do your coding in other languages, why bother keeping up with C++?
You're not forced to use every feature a language provides. I don't use setjmp/longjmp in C despite it being there. I also don't use every aspect of the Java collections.
If you think the new features will make your code delivery better (faster or higher quality or both), then use them. Otherwise ignore them.
It's useful to know at a high level what they all are, if only to get you through job interviews, but half the stuff they add to languages are unnecessary in my opinion.
I never even got around to using C++ templates before switching to Java, but I knew what they were for.
It's not always about learning the latest and greatest. Software (at least at your job) is about delivery of product. That can be done in COBOL or FORTRAN if you're proficient enough at it.
No one, except maybe Bjarne and Herb Sutter, know all of C++. As you've said it's an incredibly huge language. Expecting to be able to take the entire standard + the specific implementation details of your specific compiler or compilers is truthfully unrealistic.
But you don't need to know everything in order to use C++. Instead only learn the subset of C++ that is valuable to you and your projects. It doesn't hurt to keep expanding your knowledge but unless you're writing a C++ compiler, there's no reason to know the whole thing. Even if you accomplish it, all of the people you work with won't.
So why should I bother to learn this
difficult, yet exceptionally powerful,
language? I can do 95% of my business
with python et al. With the remaining
5%, I can deal with plain old C++ or C
without hassle.
Well, for the most part you answer your own question. There is no need for you to keep up with the bleeding edge of C++ at this time.
However, the language will keep marching on. In a few years, some of the concepts you consider a bleeding-edge waste of time today will be in common use. Someday you may find during your 5% of using "plain-old C++" that some example code or code you're collaborating on uses a construct you're not familiar with. At that point, you'll need to hit the net and brush up on the new "current" C++.
Is that going to be a problem? Of course not. You're a programmer. You keep abreast of the latest programming concepts in the context of your 95% language, which also changes over time. You will likely already be quite familiar with the concepts and need only familiarize yourself with its C++ syntax when the time comes that you must use them.
Personally I hope to continue keeping up with C++, even if my career moves more toward Java or another next-gen language. Why? I would like to say because it interests me the most and because I love the complexity and expressiveness of it all. More likely, though, is just because it was my first professional language; I consider it my "native tongue".
If it does not interest you, and does not concern your job or future job, don't bother. What's wrong with that? Nothing.
Good answers.
Computer makers compete for buyers, software competes for your disk space, and languages compete for users. They do this by trying to snag each other's features.
I'm wondering how long before we see Fortran come out with lambda expressions :-)
I am hard-pressed to find a single instance where C++0x has been made more complex than C++98. There are two things which really are complex:
Concepts.
the Memory Model
but the first one has been removed again (thankfully; standardizing unimplemented features has never worked out in C++, witness throw specifications, extern templates, auto_ptr, ...), and the second isn't really something that a modern programming language can escape. It's been externally induced by Intel & Co helpfully breaking your programs to make them run faster.
The rest is just fixing annoyances that every C++ programmer has been frequently hitting in the last decades.
As a side note: I find it ... amusing ... to see how languages such as C# get packed with a database query language (LINQ) and C++ is objurgated as being bloated.
You don't need to know every standard that comes out by heart. It does help to know about the big picture though. The 5% that you do code in may have you reinvent the occasional wheel. Depending on how much time, importance that 5% has (think Pareto) you need to take a call.
Also, any particular reason (like legacy code dependency) why you can't move that 5% to python?
First try attending a course on c++0x and make your firm pay for that :)
Our brains can fit amazing amounts of junk-knowledge. Instead of cursing and having programmer-wtf-moments we should first learn from program users and listen to other people's opinions/knowhows. Knowledge transfers much faster that way.
My suggestion would be to learn the new keywords of c++0x ( && FTW) but not bother trying to learn the entire lib. Use python for w/e you want, possibly C# for apps, then use C++(0x) when you need to do something powerful. and ask stackoverflow & google about the new container when prototyping.
You dont need to use a select few language,
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm learning C++ and the book I'm reading (The C++ Programming Language) says to not reinvent the wheel, to rely on the standard libraries. In C, I often end up creating a linked list, and link list iteration over and over again (maybe I'm doing that wrong not sure), so the ideas of containers available in C++, and strings, and algorithms really appeal to me. However I have read a little online, and heard some criticisms from my friends and coworkers about STL, so I thought I maybe I'd pick some brains here.
What are some best practices for using STL, and what lessons have you learned about STL?
There is a companion book to the Effective C++ series, which is called "Effective STL". It's a good starting point for learning about best practises using the Standard C++ library (neé STL).
You might want to pick up a copy of "Effective C++: 50 Specific Ways to Improve Your Programs and Design (2nd Edition)":
http://www.amazon.com/Effective-Specific-Addison-Wesley-Professional-Computing/dp/0201924889
I've found it to be invaluable, and it's still very relevant today, even if you aren't programming in C++.
If you really want to learn the C++ Standard Library (which includes things like strings, which have not traditionally been seen as part of the STL), you need a good book. The best one in this area is "The C++ Standard Library" by Nicolai Jossutis.
The only cases I can think of off the top of my head when the SC++L is not appropriate to use are some rare situations in which either a proper implementation is not provided (perhaps you're working on some obscure platform for which only limited C++ compilers have implemented) or extreme performance is required (perhaps for code that exists at the core of a graphics rendering system for next-generation games).
If you're using an ordinary computer, it's 99% certain that you're not in the first case. As for the second case, you should absolutely only consider implementing your own set of containers and algorithms for performance reasons if you have definitive evidence from good profiling tools that the bottleneck in your program is the SC++L.
The best practice regarding the SC++L is to simply use it whenever possible. In addition, almost all modern C++ code makes heavy use of Boost, which you can think of as an excellent and massive extension to the SC++L. Whenever you find yourself wanting to do a fairly standard algorithmic task, you should use Google to see if either the SC++L or Boost provide premade, tested, proven facilities for accomplishing this task.
Why don't you tell us those criticisms, and we'll respond? If the criticisms are valid, we'll tell you that. And if they're not, we'll tell you why not.
The STL has a mixed history, because initially, 1) few people understood it, and 2) few compilers implemented it correctly. But that was a decade ago. Today? It works. It's efficient. It solves a lot of problems. The biggest problem with it is that it takes some time to wrap your head around how it works.
The simplest best practice is "Use the STL whenever it offers functionality that you need".
And it's hard to offer more specific advice unless we know what criticisms it's up against.
But in general, it's typically the case that people who criticize it are simply not C++ programmers. C programmers who have learned to use classes fall into this category.
The STL was written by the best brains. You probably won't come up with better implementation than that in most cases.
Its performance is good, it's bug free, and it's a good standard for passing parameters between methods, APIs, code components, and needless to say, it encapsulates all the ugly stuff.
The thing is, you have to know how to choose the right container for your problem. Otherwise, you might not enjoy its benefits.
There are some articles on the web regarding how to pick the right STL container.
One good link is: STL Containers
, and it has a nice flow chart of how to pick your container.
You should understand the concept of template, and other polymorphism, in order to efficiently use the STL.
to learn about STL you need to understand templates and also you should be good in data structures.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I know that C++ is a very complex language that takes many years of practice to master.
Taking that into account do you know of a small project (around a 1k of loc) that tests all of C++ major features (inheritance, pointers, memory management, etc).
The thing is I'm a Java/Python programmer and I really want to learn C++ so I've been studying C++ for a while but haven't tested anything of what I've learned beyond small exercises.
I want to take all of that knowledge and put into practice.
Doing this alone you will obtain many harmful habits. It's much better to get an internship with a company that has high competence in C++ development and train under guidance.
C++ is like a grenade without a safety pin – looks cool and you've heard that all "real professionals" use it, but you don't know when it is to explode. A tremendous amount of features that can be used for good or for evil without knowing whether it's really good or evil. That's why guidance is a must here.
A memory manager. That should get you thinking about:
free store management
pointers (of course!)
inheritance (you will want your driver code to use this)
templates (another way to pass the manager around -- driver #2)
designing user defined data structures (a memory block)
efficient use of standard container(s)
algorithms (to move around, figure out empty blocks, defragment)
Effective C++ and More Effective C++
Other than that, pick a (small?) personal project you want to write and do it in C++. You are not going to learn C++ by reading a 1000 line project.
I'm not sure about anything that tests all major features. There are a lot of them, and some are rarely used together (templates and virtual functions come to mind. Both achieve a form of polymorphism, so you often use one or the other depending on your needs.)
A suitable project in that it'd touch on all the important features might be something apparently simple like writing a correct container class, similar to std::vector or std::list. Ensure exception safety, iterator validity, the appropriate time complexity on all operations and every other requirement specified in the standard.
The problem with this, as well as most other projects, is that you won't really know when you're done. Making a resizable array might take 50 lines of code, and 20 minutes of your time. And then a beginner would think he's done. Making it exception-safe requires you to be able to spot all the places where the class might be thrown into an inconsistent state by an exception.
That's a kind of general problem with C++. It's easy enough to think you get it, and the compiler certainly won't notify you of aspects you've forgotten to handle. So you might think your code is perfect, and yet it'll crash for all sorts of odd special cases.
As sharptooth said, for a language as messy as C++, writing code on your own is risky. It is easy to fall into the trap of "I've written some code, it compiles and it seems to run. Therefore it is correct".
Of course you could post your code here or on other sites for review, or maybe just supplement your coding with reading the docs for actual high quality C++ code (most boost libraries tend to have comprehensive documentation, specifying both the rationale for various design decisions, and how it safely handles all the weird special cases that tend to crop up in C++. The C++ standard itself would be another excellent resource, of course. In either case, these might help you determine what problems to look out for)
When I was learning C++, I used it to write my own language for writing Colossal Cave style adventures. Like most computer languages it never saw the light of day, but it did teach me a lot about C++.
Whatever you choose the thing to avoid when learning C++ is GUI programming, which is a trap which will drain all your gumption and probably teach you bad C++ habits in the process.
I'd recommend creating a text based game. That really helped me firm up my C++. Doesn't take too long and you can exercise all the features you want. Come up with the game yourself. It is more fun that way.
Another great idea is to write a simple mathematics library, supporting Vectors Matrices etc.
But with todays libraries, that is only of academic use.
In order to learn C++ it is useful to look at a lot of well written C++ code.
I think the Qt library is quite nice for this so I suggest: Write an Qt application.
Look how they use C++ and create your own graphical components in a similar fashion.
Ideas:
- Stock chart viewer widget that connects to one of the financial websites and scrapes history data.
- Simple Excel like spreadsheet widget.
Depends on what area you want to work in. But nothing worth doing correctly comes in at less than 1000 lines of code.
If you are going to be writing games then try writing a Tetris clone.
If you think you will be using sockets etc then writing a simple chat/irc client would help.
Do you have a specific itch that needs to be scratched? When was the last time you thought "this sucks, I could do better?". Can you do better?
I would recomend writing a Tetris clone.
You can learn a lot of c++ concepts with this and learn a 2d library like SDL or maybe even OpenGL throgh SDL.
It is always good to have a project with visual results and at the end of it you can play it.
There seem to be two themes coming from the answers:
You need to pick a project that might involve more than 1K LOC in order to get the true experience of the project.
You need to also pair up with an experienced C++ developer, who can help you think through problems and avoid pitfalls associated with the language.
You can get around both of these by swing by sourceforge.net and signing up to help with an existing C++ project. As long as you don't mind your code being open source, you should be able to find an existing project to learn from plus experienced developers who can help by reviewing your code and offering guidance.
An interactive world:
A matrix where each position can be a Void or a Being.
A Being is something with a few attributes: age, Time left, gender, neigbor connections, etc. Capable a few interactions: fights, having sex and kids, friendships, etc. Some have special Skills, depending on their fathers (inherited trades)... like ability to kill, ability to make food,, etc...
Possible outcomes of those interactions and skills are changes on the self attributes, or creating offspring (when possible), or change neigbor attributes.
At each iteration, print the matrix as symbols/numbers on the console (depending on the attributes, etc), starting from a Biblical iteration 0 (initial conditions of your choice... you're God here).
Now you got some real-life pattern simulator, and learned something about inheritance, polimorfism, virtual functions, instantiation of classes, etc.
I would suggest a simple text editor would be a reasonable goal.
It's a problem domain that you have a good grasp of.
You have memory management issues, library class reuse issues (stl/curses?), pointer issues, and lots of options where derived classes can be used.
For polymorphism, perhaps, you can have the editor read from a keyboard, or suck commands in from a text file.
There is another good one.... dealing with files.
You don't have to cross platform it. You don't have to open source it. You don't have to show it to anyone. You don't even have to finish it. It can be an exercise just for you.
If you're learning fron a book, it must have plenty of well-thought-out exercises you can implement and learn from. Also check out the university sites and their C++ labs / assignments.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Unquestionably, I would choose to use the STL for most C++ programming projects. The question was presented to me recently however, "Are there any cases where you wouldn't use the STL?"...
The more I thought about it, the more I realized that perhaps there SHOULD be cases where I choose not to use the STL... For example, a really large, long term project whose codebase is expected to last years... Perhaps a custom container solution that precisely fits the projects needs is worth the initial overhead? What do you think, are there any cases where you would choose NOT to STL?
The main reasons not to use STL are that:
Your C++ implementation is old and has horrible template support.
You can't use dynamic memory allocation.
Both are very uncommon requirements in practice.
For a longterm project rolling your own containers that overlap in functionality with the STL is just going to increase maintenance and development costs.
Projects with strict memory requirements such as for embedded systems may not be suited for the STL, as it can be difficult to control and manage what's taken from and returned to the heap. As Evan mentioned, writing proper allocators can help with this, but if you're counting every byte used or concerned with memory fragmentation, it may be wiser to hand-roll a solution that's tailored for your specific problem, as the STL has been optimized for the most general usage.
You may also choose not to use STL for a particular case because more applicable containers exist that are not in the current standard, such as boost::array or boost::unordered_map.
There are just so many advantages to using the stl. For a long term project the benefits outweigh the costs.
New programmers being able to understand the containers from day one giving them more time to learn the other code in the project. (assuming they already know STL like any competent C++ programmer would)
Fixing bugs in containers sucks and wastes time that could be spent enhancing the business logic.
Most likely you're not going to write them as well as the STL is implemented anyways.
That being said, the STL containers don't deal with concurrency at all. So in an environment where you need concurrency I would use other containers like the Intel TBB concurrent containers. These are far more advanced using fine grained locking such that different threads can be modifying the container concurrently and you don't have to serialize access to the container.
Usually, I find that the best bet is to use the STL with custom allocators instead of replacing STL containers with hand rolled ones. The nice thing about the STL is you pay only for what you use.
I think it's a typical build vs buy scenario. However, I think that in this case I would almost always 'buy', and use STL - or a better solution (something from Boost perhaps), before rolling my own. You should be focusing most of your effort on what your application does, not the building blocks it uses.
I don't really think so. In making my own containers, I would even try to make those compatible with the STL because the power of the generic algorithms is too great to give up. The STL should at least be nominally used, even if all you do is write your own container and specialize every algorithm for it. That way, every sorting algorithm can be invoked sort(c.begin(), c.end()). If you specialize sort to have the same effect, even if it works differently.
Coding for Symbian.
STLPort does support Symbian 9, so the case against using STL is weaker than it used to be ("it's not available" is a pretty convincing case), but STL is still alien to all the Symbian libraries, so may be more trouble than just doing things the Symbian way.
Of course it might be argued on these grounds that coding for Symbian is not "a C++ programming project".
Most of the projects I have worked on had a codebase way older than any really usable version of STL - therefore we chose not to introduce it now.
Introduction:
STL is a great library, and useful in many cases, but it definitively don't solve all the situations. Answering STL or !STL is like answering "Does STL meet your need or does it not?"
Pros of STL
In most situations, STL has a container that fit for a given solution.
It is well documented
It is well known ( Programmers usually already know it, getting into a project is shorter)
It is tested and stable.
It is crossplatform
It is included with every compiler (does not add a 3rd library dependency)
STL is already implemented and ready
STL is shiny, ...
Contras of STL
It does not mater that you need a simple Graph, Red-Black Tree, or a very complex database of elements with an AI managing concurrent access through a quantum computer. The fact is, STL do not, and will never solve everything.
Following aspects are only a few examples, but they basically are consequence of this fact: STL is a real library with limits.
Exceptions: STL relay on exceptions, so if for any reason you cannot accept exceptions (e.g. safety critical), you cannot use STL. Right! exceptions may be disabled, but that does not solve the design of the STL relaying on them and will eventually carry a crash.
Need of specific (not yet included) data structure: graph, tree, etc.
Special constraints of complexity: You could discover that STL general purpose container is not the most optimal for your bottleneck code.
Concurrency considerations: Either you need concurrency and STL do not provide what you need (e.g. reader-writer lock cannot(easily) be used because of the bi-directional [] operator). Either you could design a container taking benefit of multi-threading for a much faster access/searching/inserting/whatever.
STL need to fit your needs, but the revers is also true: You need to fulfill the needs of STL. Don't try to use std::vector in a embedded micro-controller with 1K of unmanaged RAM.
Compatibility with other libraries: It may be that for historical reasons, the libraries you use do not accept STL (e.g. QtWidgets make intensive use of it own QList). Converting containers in both directions might be not the best solution.
Implementing your own container
After reading that, you could think: "Well, I am sure I may do something better for my specific case than STL does." WAIT!
Implementing your container correctly become very quickly a huge task: it is not only about implementing something working, you might have to:
Document it deeply, including limitations, algorithm complexity,etc.
Expect bugs, and solving them
Incoming additional needs: you know, this function missing, this conversion between types, etc.
After a while, you could want to refactor, and change all the dependencies (too late?)
....
Code used that deep in the code like a container is definitively something that take time to implement, and should be though carefully.
Using 3rd party library
Not STL does not necessarily mean custom. There are plenty of good libraries in the net, some even with permissive open-source license.
Adding or not an additional 3rd party library is another topic, but it worth to be considered.
One situation where this might occur is when you are already using an external library that already provides the abilities you need from the STL. For instance, my company develops an application in space-limited areas, and already uses Qt for the windowing toolkit. Since Qt provides STL-like container classes, we use those instead of adding the STL to our project.
I have found problems in using STL in multi-threaded code. Even if you do not share STL objects across threads, many implementations use non-thread safe constructs (like ++ for reference counting instead of an interlocked increment style, or having non-thread-safe allocators).
In each of these cases, I still opted to use STL and fix the problems (there are enough hooks to get what you want).
Even if you opt to make your own collections, it would be a good idea to follow STL style for iterators so that you can use algorithms and other STL functions that operate only on iterators.
The main issue I've seen is having to integrate with legacy code that relies on non-throwing operator new.
I started programming C back in about 1984 or so and have never used the STL. Over the years I have rolled my own function librarys and they have evolved and grown when the STL was not stable yet and or lacked cross platform support. My common library has grown to include code by others ( mostly things like libjpeg, libpng, ffmpeg, mysql ) and a few others and I would rather keep the amount of external code in it to a minimum. I'm sure now the STL is great but frankly I'm happy with the items in my toolbox and see no need at this point to load it up with more tools. But I certainly see the great leaps and bounds that new programmers can make by using the STL without having to code all that from scratch.
Standard C++ perversely allows implementations of some iterator operations to throw exceptions. That possibility can be problematic in some cases. You might therefore implement your own simple container that is guaranteed not to throw exceptions for critical operations.
Since almost everybody who answered before me seemed so keen on STL containers, I thought it would be useful to compile a list of good reasons not to use them, from actual problems I have encountered myself.
These can be reasonably grouped into three broad categories:
1) Poor efficiency
STL containers typically run slower AND use too much memory for the job. The reason for this can be partly blamed on too generic implementations of the underlying data structures and algorithms, with additional performance costs deriving from all the extra design constrains required by the tons of API requisites that are irrelevant to the task at hand.
Reckless memory use and poor performance go hand in hand, because memory is addressed on the cache by the CPU in lines of 64 bytes, and if you don't use locality of reference to your advantage, you waste cycles AND precious Kb of cache memory.
For instance, std::list requires 24 bytes per element rather than the optimal 4.
https://lemire.me/blog/2016/09/15/the-memory-usage-of-stl-containers-can-be-surprising/
This is because it is implemented by packing two 64-bit pointers, 1 int and 4 bytes of memory padding, rather than doing anything as basic as allocating small amounts of contiguous memory and separately tracking which elements are in use, or using the pointer xor technique to store both iteration directions in one pointer.
https://en.wikipedia.org/wiki/XOR_linked_list
Depending on your program needs, these inefficiencies can and do add up to large performance hits.
2) Limitations / creeping standards
Of course, sometimes the problem is that you need some perfectly common function or slightly different container class that is just not implemented in STL, such as decrease_min() in a priority queue.
A common practice is to then to wrap the container in a class and implement the missing functionality yourself with extra state external to the container and/or multiple calls to container methods, which may emulate the desired behavior, but with a performance much lower and O() complexity higher than a real implementation of the data structure, since there's no way of extending the inner workings of the container. Alternatively you end up mashing up two or more different containers together because you simultaneously need two or more things that are fundamentally incompatible in any one given STL container, such as a minmax heap, a trie (since you need to be able to use agnostic pointers), etc.
These solutions may be ugly and add on top of the other inefficiencies, and yet the way the language is evolving the tendency is to only add new STL methods to match C++'s feature creep and ignore any of the missing core functionality.
3) Concurrency/parallelism
STL containers are not thread-safe, much less concurrent. In the present age of 16-thread consumer CPUs, it's surprising the go-to default container implementation for a modern language still requires you to write mutexes around every memory access like it's 1996. This is, for any non-trivial parallel program, kind of a big deal, because having memory barriers forces threads to serialize their execution, and if these happen with the same frequency as an STL call, you can kiss your parallel performance goodbye.
In short, STL is good as long as you don't care about performance, memory usage, functionality or parallelism.
STL is of course still perfectly fine for the many times you are not bound by any of these concerns and other priorities like readability, portability, maintainability or coding speed take precedence.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Recently, I've got a dangerous idea into my head after reading this blog post. That idea can be expressed like this:
I don't need most of what the C++ standard library offers. So, why don't I implement a less general, but easier to use version?
As an example, using the STL spits out reams of incomprehensible and mangled compiler errors. But, I don't care about allocators, iterators and the like. So why don't I take a couple of hours and implement an easy to use linked list class, for example?
What I'd like to know from the StackOverflow community is this: what are the dangers, possible disadvantages and possible advantages to "rolling my own" for most of the existing functionality in C++?
Edit: I feel that people have misunderstood me about this idea. The idea was to understand whether I could implement a very small set of STL functionality that is greatly simplified - more as a project to teach me about data structures and the like. I don't propose re-inventing the entire wheel from the ground up, just the part that I need and want to learn about. I suppose what I wanted to figure out is whether the complexity of using the STL warrants the creation of smaller, simpler version of itself.
Re-using boost or similiar.
Most of what I code is for University and we're not allowed to use external libraries. So it's either the C++ standard library, or my own classes.
Objectivity of this question.
This question is not subjective. Nor should it be community Wiki, since it's not a poll. I want concrete arguments that highlight one advantage or one disadvantage that could possibly occur with my approach. Contrary to popular belief, this is not opinion, but based on experience or good logical arguments.
Format.
Please post only one disadvantage or one advantage per answer. This will allow people to evaluate individual ideas instead of all your ideas at once.
And please...
No religious wars. I'm not a fan boy of any language. I use whatever's applicable. For graphics and data compression (what I'm working on at the moment) that seems to be C++. Please constrain your answers to the question or they will be downvoted.
So, why don't I implement a less
general, but easier to use version?
Because you can't. Because whatever else you might say about C++, it is not a simple language, and if you're not already very good at it, your linked list implementation will be buggy.
Honestly, your choice is simple:
Learn C++, or don't use it. Yes, C++ is commonly used for graphics, but Java has OpenGL libraries too. So does C#, Python and virtually every other language. Or C. You don't have to use C++.
But if you do use it, learn it and use it properly.
If you want immutable strings, create your string as const.
And regardless of its underlying implementation, the STL is remarkably simple to use.
C++ compiler errors can be read, but it takes a bit of practice. But more importantly, they are not exclusive to STL code. You'll encounter them no matter what you do, and which libraries you use. So get used to them. And if you're getting used to them anyway, you might as well use STL too.
Apart from that, a few other disadvantages:
No one else will understand your code. If you ask a question on SO about std::vector, or bidirectional iterators, everyone who's reasonably familiar with c++ can answer. If you ask abut My::CustomLinkedList, no one can help you. Which is unfortunate, because rolling your own also means that there will be more bugs to ask for help about.
You're trying to cure the symptom, rather than the cause. The problem is that you don't understand C++. STL is just a symptom of that. Avoiding STL won't magically make your C++ code work better.
The compiler errors. Yes, they're nasty to read, but they're there. A lot of work in the STL has gone into ensuring that wrong use will trigger compiler errors in most cases. In C++ it's very easy to make code that compiles, but doesn't work. Or seems to work. Or works on my computer, but fails mysteriously elsewhere. Your own linked list would almost certainly move more errors to runtime, where they'd go undetected for a while, and be much harder to track down.
And once again, it will be buggy. Trust me. I've seen damn good C++ programmers write a linked list in C++ only to uncover bug after bug, in obscure border cases. And C++ is all border cases. Will your linked list handle exception safety correctly? Will it guarantee that everything is in a consistent state if creating a new node (and thereby calling the object type's constructor) throws an exception? That it won't leak memory, that all the appropriate destructors will be called? Will it be as type-safe? Will it be as performant? There are a lot of headaches to deal with when writing container classes in C++.
You're missing out on one of the most powerful and flexible libraries in existence, in any language. The STL can do a lot that would be a pain even with Java's giant bloated class library. C++ is hard enough already, no need to throw away the few advantages it offers.
I don't care about allocators,
iterators and the like
Allocators can be safely ignored. You pretty much don't even need to know that they exist. Iterators are brilliant though, and figuring them out would save you a lot of headaches. There are only three concepts you need to understand to use STL effectively:
Containers: You already know about these. vectors, linked lists, maps, sets, queues and so on.
Iterators: Abstractions that let you navigate a container (or subsets of a container, or any other sequence of value, in memory, on disk in the form of streams, or computed on the fly).
Algorithms: Common algorithms that work on any pair of iterators. You have sort, for_each, find, copy and many others.
Yes, the STL is small compared to Java's library, but it packs a surprising amount of power when you combine the above 3 concepts. There's a bit of a learning curve, because it is an unusual library. But if you're going to spend more than a day or two with C++, it's worth learning properly.
And no, I'm not following your answer format, because I thought actually giving you a detailed answer would be more helpful. ;)
Edit:
It'd be tempting to say that an advantage of rolling your own is that you'd learn more of the language, and maybe even why the STL is one of its saving graces.. But I'm not really convinced it's true. It might work, but it can backfire too.
As I said above, it's easy to write C++ code that seems to work. And when it stops working, it's easy to rearrange a few things, like the declaration order of variables, or insert a bit of padding in a class, to make it seemingly work again. What would you learn from that? Would that teach you how to write better C++? Perhaps. But most likely, it'd just teach you that "C++ sucks". Would it teach you how to use the STL? Definitely not.
A more useful approach might be utilizing the awesome power of StackOverflow in learning STL the right way. :)
Disadvantage: no one but you will use it.
Advantage: In the process of implementing it you will learn why the Standard Library is a good thing.
Advantages: eating your own dogfood. You get exactly what you do.
Disadvantages: eating your own dogfood. Numerous people, smarter than 99 % of us, have spent years creating STL.
I suggested you learn why:
using the STL spits out reams of
incomprehensible and mangled compiler
errors
first
Disadvantage: you may spend more time debugging your class library than solving whatever university task you have in front of you.
Advantage: you're likely to learn a lot!
There is something you can do about the cryptic compiler STL error messages. STLFilt will help simplify them. From the STLFilt Website:
STLFilt simplifies and/or reformats
long-winded C++ error and warning
messages, with a focus on STL-related
diagnostics (and for MSVC 6, it fully
eliminates C4786 warnings and their
detritus). The result renders many of
even the most cryptic diagnostics
comprehensible.
Have a look here and, if you are using VisualC, also here.
I think you should do it.
I'm sure I'll get flambayed for this, but you know, every C++ programmer around here has drunk a little too much STL coolaid.
The STL is a great library, but I know from first hand experience that if you roll your own, you can:
1) Make it faster than the STL for your particular use cases.
2) You'll write a library with just the interfaces you need.
3) You'll be able to extend all the standard stuff. (I can't tell you how much I've wished std::string had a split() method)...
Everyone is right when they say that it will be a lot of work. Thats true.
But, you will learn a lot. Even if after you write it, you go back to the STL and never use it again, you'll still have learned a lot.
A bit of my experience : Not that long ago I have implemented my own vector-like class because I needed good control on it.
As I needed genericity I made a templated array.
I also wanted to iterate through it not using operator[] but incrementing a pointer like a would do with C, so I don't compute the address of T[i] at each iteration... I added two methods one to return pointer to the allocated memory and another that returns a pointer to the end.
To iterate through an array of integer I had to write something like this :
for(int * p = array.pData(); p != array.pEnd(); ++p){
cout<<*p<<endl;
}
Then when I start to use vectors of vectors I figure out that when it was possible a could allocate a big bloc of memory instead of calling new many times. At this time I add an allocator to the template class.
Only then I notice that I had wrote a perfectly useless clone of std::vector<>.
At least now I know why I use STL...
Disadvantage : IMHO, reimplimenting tested and proven libraries is a rabit hole which is almost garanteed to be more trouble than it's worth.
Another Disadvantage:
If you want to get a C++ job when you're finished with University, most people who would want to recruit you will expect that you are familiar with the Standard C++ library. Not necessarily intimately familiar to the implementation level but certainly familiar with its usage and idioms. If you reimplement the wheel in form of your own library, you'll miss out on that chance. This is nonwithstanding the fact that you will hopefully learn a lot about library design if you roll your own, which might earn you a couple of extra brownie points depending on where you interview.
Disadvantage:
You're introducing a dependency on your own new library. Even if that's sufficient, and your implementation works fine, you still have a dependency. And that can bite you hard with code maintenance. Everyone else (including yourself, in a year's time, or even a month's) will not be familiar with your unique string behavior, special iterators, and so on. Much effort will be needed just to adapt to the new environment before you could ever start refactoring/extending anything.
If you use something like STL, everyone will know it already, it's well understood and documented, and nobody will have to re-learn your custom throwaway environment.
You may be interested in EASTL, a rewrite of the STL Electronic Arts documented a while back. Their design decisions were mostly driven by the specific desires/needs in multiplatform videogame programming. The abstract in the linked article sums it up nicely.
Advantage
If you look into MFC, you'll find that your suggestion already is used in productive code - and has been so for a long time. None of MFC's collection classes uses the STL.
Why don't you take a look at existing C++ libraries. Back when C++ wasn't quite as mature, people often wrote their own libraries. Have a look at Symbian (pretty horrible though), Qt and WxWidgets (if memory serves me) have basic collections and stuff, and there are probably many others.
My opinion is that the complexity of STL derives from the complexity of the C++ language, and there's little you can do to improve on STL (aside from using a more sensible naming convention). I recommend simply switching to some other language if you can, or just deal with it.
Disadvantage : You're university course is probably laid out like this for a reason. The fact that you are irritated enough by it (sarcasm not intended), may indicate you are not getting the paridigm, and will benefit a lot when you have a paradigm shift.
As an example, using the STL spits out
reams of incomprehensible and mangled
compiler errors
The reason for this is essentially C++ templates. If you use templates (as STL does) you will get reams of incomprehensible error messages. So if you implement your own template based collection classes you will not be in any better spot.
You could make non template based containers and store everything as void pointers or some base class e.g. But you would lose compile time type checks and C++ sucks as a dynamic language. It is not as safe to do this as it would be in e.g. Objective-C, Python or Java. One of the reasons being that C++ does not have a root class for all classes to all introspection on all objects and some basic error handling at runtime. Instead your app would likely crash and burn if you were wrong about the type and you would not be given any clues to what went wrong.
Disadvantage: reimplementing all of that well (that is, at a high level of quality) will certainly take a number of great developers a few years.
what are the dangers, possible disadvantages and possible advantages to "rolling my own" for most of the existing functionality in C++?
Can you afford and possibly justify the amount of effort/time/money spent behind reinventing the wheel?
Re-using boost or similiar.
Rather strange that you cannot use Boost. IIRC, chunks of contribution come in from people related to/working in universities (think Jakko Jarvi). The upsides of using Boost are far too many to list here.
On not 'reinventing the wheel'
Disadvantage: While you learn a lot, you also set yourself back, when you come to think of what your real project objectives are.
Advantage: Maintenance is easier for the folks who are going to inherit this.
STL is very complex because it needs to be for a general purpose library.
Reasons why STL is the way it is:
Based on interators so standard algorithms only need a single implementation for different types of containers.
Designed to behave properly in the face of Exceptions.
Designed to be 'thread' safe in multi threaded applications.
In a lot of applications however you really have enough with the following:
string class
hash table for O(1) lookups
vector/array with sort / and binary search for sorted collections
If you know that:
Your classes do not throw exceptions on construction or assignment.
Your code is single threaded.
You will not use the more complex STL algorithms.
Then you can probably write your own faster code that uses less memory and produces simpler compile/runtime errors.
Some examples for faster/easier without the STL:
Copy-on-Write string with reference counted string buffer. (Do not do this in a multi-threaded environment since you would need to lock on the reference count access.)
Use a good hash table instead of the std::set and std::map.
'Java' style iterators that can be passed around as a single object
Iterator type that does not need to know the type of the container (For better compile time decoupling of code)
A string class with more utility functions
Configurable bounds checking in your vector containers. (So not [] or .at but the same method with a compile or runtime flag for going from 'safe' to 'fast' mode)
Containers designed to work with pointers to objects that will delete their content.
It looks like you updated the question so now there are really two questions:
What should I do if I think the std:: library is too complex for my needs?
Design your own classes that internally use relevant std:: library features to do the "heavy lifting" for you. That way you have less to get wrong, and you still get to invent your own coding interface.
What should I do if I want to learn how data structures work?
Design your own set of data structure classes from the ground up. Then try to figure out why the standard ones are better.