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 ran into this supposed interview of Bjarne Stroustrup, the inventor of C++.
http://artlung.com/smorgasborg/Invention_of_Cplusplus.shtml
Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would...
Interviewer: Yes, but C++ is basically a sound language.
Stroustrup: You really believe that, don't you? Have you ever sat down and worked on a C++ project? Here's what happens: First, I've put in enough pitfalls to make sure that only the most trivial projects will work first time. Take operator overloading. At the end of the project, almost every module has it, usually, because guys feel they really should do it, as it was in their training course. The same operator then means something totally different in every module. Try pulling that lot together, when you have a hundred or so modules. And as for data hiding, God, I sometimes can't help laughing when I hear about the problems companies have making their modules talk to each other.
Is this a hoax? Do any of these points seem true for any of the veteran C++ programmers out there?
You just have to check the Stroustrup's website (the FAQ part) to find that it's wrong - a well known hoax as Judah Himango already pointed :
Did you really give an interview to IEEE?
in which you confessed that C++ was
deliberately created as an awful
language for writing unmaintainable
code to increase programmers'
salaries? Of course not. Read the
real IEEE interview.
It's a well-known hoax.
And no, learning C++ isn't a waste of your time, something that's been discussed on StackOverflow many times.
As mentioned, this is a well-known hoax.
But it does provoke some interesting points. These days C++ is a waste of time, except for when you can't afford to waste time. Less opaquely: C++ is a waste of development time, except for when you can't afford to waste execution time.
From the article titled "The Real Stroustrup Interview" in IEEE Computer Magazine Vol. 31 Issue 6 pp.110-114 (June 1998):
For the past few months, a hoax interview between Stroustrup and Computer has been making the rounds in cyberspace. While we regret the incident, it offers us a welcome opportunity to have the father of C++ share his insights on Standard C++ and software development in general. We can also attest to his continued sense of proportion and humor—he suggests that the fictitious interview would have been a much funnier parody had he written it himself.
As others mentioned, this Interview is hoax.
Well, I am one of the persons who hate C++ and normally doesnt use it, but learning it was definitely not a waste of time. At least now I know why I hate C++ and I understand why other persons use this language and think it is good.
If you want to learn this language to know about its concepts, its benefits and its drawbacks, to be able to read code written in it, and in general to be able to "talk about" it, it is never a waste of time. Same for any other programming language. It will increase your expierience. For example, C++ shows one common way of OOP - a way I dont like, but a way many other people use.
But if you want to learn it because "the people say that it is the best" (as I sometimes read), then it is really a waste of time. Same for any other programming language.
Programmers that feel attracted to higher level languages that take care of memory management and other tasks for them, could feel that C++ is a waste of time.
It certainly is if you can achieve the same goal with another language in less time and with less bug fixing and don't mind the downsides as efficiency.
But I don't regret having learned and spent so many hours coding in C/C++ for it's such a beautiful language and allows you to produce things that not many other languages can.
I mean, don't you want to use the language with which operating systems and compilers are written? that's not a waste of time at all from my perspective.
C++ is far from being a waste of your time. You'll understand valuable concepts that will help you understand many other concepts in different programming languages. I.E.: VTABLE.
There is not a single framework which uses all language features of C++. This introduces a huge inconsistency to the language's ecosystem.
QT is one of the few APIs which I would call a framework (or API for a lot of things):
But it defines own string, own array, ...
What's the point of a "standard" library when no one can use it in a portable and compatible way (from the aspect of interaction with other APIs)?
I know, there is boost, but what is boost compared to an API such as QT? Nothing.
Look at Java: The is the standard Java API, and every "foreign" API uses it, it's all perfectly compatible.
C++ (and Java) probably the best language to learn to understand concepts of OOP.
I remember learning it in college benefited me a lot.
Stroustrup is not that stupid to say that! It is definitely a hoax!
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 12 years ago.
C++ introduces OOPS, templates and variety of other concepts. But sometimes I am stuck in unmanageable storm of calling convention incompatibilities between methods, convoluted casting between distantly connected classes and struggling with code that forces me think in the level of byte-alignment.
I am very tempted to go back to plain old-C language that is low level enough and simple enough that I can spend much of my time solving a problem at hand, than having to figure out the conceptual implementation and nuances of using C++.
What is your take on such an issue. Using C-language as the first class citizen in my code-base and coating it at the end with a C++ primer make for a better way to manage a conceptual code-base ??
sometimes I am stuck in unmanageable storm of calling convention incompatibilities between methods, convoluted casting between distantly connected classes and struggling with code that forces me think in the level of byte-alignment.
It sounds like you might be doing something wrong. I don't know what sorts of projects you work on, but I've rarely had to deal with any of those things--certainly never in over 99.9% of the code I've written--and I've written a bit of C++ code (though not nearly as much as others here on StackOverflow).
What is your take on such an issue.
You should consider getting a good book on C++ (like one of the introductory books or any of the best practices books listed in The Definitive C++ Book Guide and List) and really learn C++ if you want to use C++.
I often feel the way you do. C++ compilers are incredibly bitchy about insignificant details and, if you considered them an object, they have appalling encapsulation, and they give horrendously bad error messages. Sometimes, programming C++ feels like fighting against the Standard.
However, I'd never, ever ditch it for C. If you're considering it, you fail C++. Yes, templates and their syntax and some of their semantics can be a bitch, but the power they offer is unparalleled. The things offered like automatic memory management and the power of the STL just can't be matched by C.
In addition, nobody is forcing you to use templates. You could write a whole C++ program using nothing but the pre-provided templates. You could never use polymorphism, or templates, or encapsulation, or object-orientation as a whole, and yes, sometimes none of those solutions are appropriate. But it's plain stupid not to give yourself the option.
And if you're casting classes in C++ (frequently), it sounds to me like whoever wrote the original code flat out didn't know what they were doing. Same for byte alignment.
I've never had to worry about byte alignment unless I was writing binary files.
Casting distantly related classes to each other is bad design.
I've never worried about calling conventions unless I was writing interrupt routines.
If you forced to frequently "cast distantly connected classes" and "think in the level of byte-alignment" - there is something wrong with the architecture of the project. Language is not the problem here.
C++ is heavy. You probably should not use all the features it provides. KISS principle, you know.
You can always pretend that C++ is just "C with classes" and exploit templates and other "hard" stuff only when it will provide reasonable improvement in some areas (like code simplicity, as a matter of fact).
I recently switched back from C++ to C and took a liking in C99. But it certainly depends on what you are doing. For a library of reasonable size, C99 with its advantages over C89, is good enough, and as somebody else said you can easily provide a C++ wrapper, if necessary. C++, I only would go for a big project that has large amount of code reuse (internal or external) with templates.
Things from C++ I missed in C89 have nothing to do with objects or so, but are simple things as declaration of variables inside the for and a well defined inline feature. C99 has that plus variable length arguments for macros, so I am happy with it.
You are not alone. These are all well-known flaws in C++, a language which forces developers to attend incompatible conventions, to struggle to overcome a convoluted caste system, and to take their code in for byte-realignment every 3,000 lines. Definitely switch back to C.
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.
I have been a C++ / Linux Developer till now and I am adept in this stack. Of late I have been getting opportunities that require Perl, Unix (with knowledge of C++,shell scripting) expertise. Organizations are showing interest even though I don't have much scripting experience to boast off. The role is more in a Support, maintenance project involving SQL as well. Off late I am in a fix whether to forgo these offers or not.
I don't know the dynamics of an IT organization and thus on one hand I fear that my C++ experience will be nullified and on the positive side I am getting to work on a new technology stack which will only add to my skill set.
I am sure, most of you at some point of time have encountered such dilemmas and would have taken some decision.
I want you to share your perspectives
on such a scenario where a person is
required to change his/her technology
stack when changing his/her job.
What are the merits and demerits in
going with either of the choices?
Also I know that C++ isn't going
anywhere in the near future. What
about perl? I have no clue as to what
the future holds for perl developer?
Whether there are enough
opportunities for a perl developer?
I am asking this question here because most of my fellow programmers face this career choice dilemma.
EDIT:
Since the last time I asked this question, I made up my mind to switch.
I was just about to sign on the dotted line but some divine intervention made me seek some clarification about the working hours, and to my horror, the profile required me to work in
shifts which I am never comfortable with. I was all the more livid because they didn't clarify this point earlier. It was a reputed organisation but still I gave them my piece of mind and said thank you very much.
Thanks.
Regarding changing of stack, it definitely helps you long term in your career, both from extra experience available to offer to next employer to expanded job set you can qualify for to increased programming IQ due to knowing different points of view (e.g. Perl, for all its scripting origins, when used properly, has both OO and very nice functional paradigms available, but this point applies to any new technology).
However, you must be willing to put extra effort in to actually learn new stack/environment/language, and to learn to do things new way (e.g. don't write C++ code in Perl :) - especially for that last benefit to kick in. Please note "environment" there - the jump involves for example learning new debuggers and debugging techniques (for me the hardest thing about C++ development after switching from Perl so far is probably doing effective gdb debugging after being used to flexibility/power of perl debugger).
Personally I had to make this jump twice - from C developer to Perl and 10 years later Perl to C++. I learned a lot both times, and am not sorry I made the jump. The first jump was from IT role (Junior SA/Production with some C coding) to a full-on developer, the second was just a jump between different business teams.
As for demerits, please be aware that you WILL lose your edge in whichever stack you're not currently using for a while. Not completely forget, but nowhere near where you left off - and that does not even count the fact that the stack may have naturally evolved in the time elapsed. Also, as I said, you MUST expect that to be effective, you have to put in a lot of effort to become fluent in idiomatics, philosophy and ecosystem of the new stack. E.g. simply learning Perl is a small piece of the puzzle - you need to become familiar with a large chunk of CPAN, just as you had to know STL etc... Not really a demerit as far as I'm concerned, but a point that needs to be kept in mind.
As for opportunities for Perl developer, this was extensively covered on SO before. While the absolute # of jobs is likely less than that of Java or C++ ones, a high quality developer will always be in demand, and there's plenty of companies (including, or may be especially, in financial industry) heavily using serious Perl development (as opposed to simple administrative scripting). The language itself is developing and moving forward as well.
This is a highly subjective question. Whether C++ is "going places" depends on where you look and who you ask. For instance, C++ is the development language for video games and graphics processing, and is also used a lot in device drivers in conjunction with C (usually I see a hybrid "C+-", where some features are used from C++ in conjunction with more C-style architecture).
I myself moved from a C/C++ environment into a mostly Perl one, with strong Unix all the while (I actually know next to no windows API programming, .NET, VB-Basic etc).
Basically what I would suggest is sticking with what you enjoy most. This may not be the same as what you currently know or are best at. There are opportunities in a diverse set of technologies. Don't also assume you should tie yourself to one environment -- dabble a little and have some fun. Many facets of programming are constant across languages and environments. Get good at problem solving, writing unit tests, refactoring and planning a project, and you'll do well no matter what set of technologies you're working with.
Why not use your C++ expertise when working with Perl (where appropriate)? It's quite possible to extend Perl with C and C++. I'm not suggesting that you write all your code in C++ just because you know it and than put a thin Perl layer on top, of course.
Being experienced in related technologies is a really big advantage, not a mis-qualification for a technical job. I would suggest you take the opportunity to learn a new technology. Going back from "experienced but rusty" to "on top of it" in your bread-and-butter discipline should be a piece of cake if you have to at a later point in time.
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.
I'm currently learning C++ and would like to start reading others sourcecode to pick up tips. I was wondering if anyone has examples of well written C++ that I can take a look at (and not pick up bad habits from)
As you've probably discovered, there are many Internet sources for examples of C++ code. StackOverflow, CodeProject, etc. all have examples of source. But of course, they're all over the map in terms of quality and educational value.
I think, in this area, books still trump the Internet. There's no substitute for going to the bookstore, thumbing through a few tomes, and picking one that you find readable. They've been proof-read (unlike may Internet submissions), so the samples are more likely to work and to be of high-quality.
While the books typically have small snippets of code or a few functions, they usually come with a CD or URL that points you to more full-blown examples.
O'Reilly, Thinking in C++, Petzold, and Wrox (and more) all have good books on C++.
The Boost library? It is generally considered some of the highest quality C++ code written. (A lot of it is also more or less unreadable unless you're a C++ guru yourself, though)
In general, I'd advise against you to be cautious with this approach though. In C++, the source code probably won't be as informative as in many other languages.
If you see some Python code, you can pretty much assume it's correct as long as it runs. If it's written by someone who seems to know what they're doing, you can even assume that it's well written.
In C++, there are just so many nasty pitfalls and subtle exceptions to every rule that you really need to know what you're doing. Going by what compiles, or what seems to work, or what you saw in someone else's source code is dangerous, and pretty much guarantees that you'll sooner or later end up with a program that relies on undefined behavior, and will crash when you least expect it.
If I were you, I'd try to stick to books. There are some very well written ones, which in addition to letting you see some source code, also teach you the langage "properly". And as long as you stick to reputable authors, you're ensured that they won't teach you any bad habits or plunge you into nonportable code.
In my opinion if you read a good C++ book (like "The C++ Programming Language", "(More) Effective C++" or "Exceptional C++").
You will not only learn good practices but should also get sense of how to write code.
Of course the samples in these Books are mostly artifical. If you read 'real-world-applications' you will always encounter pieces of code which are pretty ugly, but sometimes there wasn't just a nice clean solution for it (or a not-so-clean solution was just more efficient in terms of speed).
So I don't know if it's best to start with real applications since they can also be very overwhelming due to the amount of codesize and complexity, whereas sample codes in Books are compact and clearly laid-out.
I think for starters you would be best off reading such references as the books I have listed.
If you have to be flexible at some point in the future and have to produce ugly code, you will at least know that it's ugly code and not mistake it for "that's how it should be" ;)
Reading through open source software can be very educational if you already have a little bit of knowledge of C++. If you're just starting out, I imagine the Boost libraries will go right over your head. You could start with the WebKit project, which is an excellent resource. Also Google releases a lot of their source code, which also happens to be VERY clean: Protocol Buffers is a great example. And while you're at it, you may as well read their C++ Style Guide as well.
Personally, I started learning C++ by picking up a couple of books and writing some little challenge applications. Bear in mind that learning a language as extensive as C++ takes a long time, like 10 years long.
Many years ago, I was told that if I ever wanted a career as a C++ developer, I should definitely read Effective C++ by Scott Meyers. That should prevent you from falling into many of the language's pitfalls. If you find you need something even simpler, start with The C Programming Language by Kernighan & Ritchie. Be patient and good luck!
If you want a complete project to browse through, I would recommend Ogre3d. It is a well structured graphics engine with decent documentation and the source code itself is nice, too.
How about: Programming: Principles and Practice Using C++ by Bjarne Stroustrup?
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.